openLuup: Tasmota MQTT Bridge

ArcherS

@therealdb said in openLuup: Tasmota MQTT Bridge:

@archers it should work regardless. The openluup log page is under /console

Aha, I thought it ended up in a separate logfile.

This is what I get in the log when changing the temperature of the device (no 50):

2021-05-10 22:59:37.312   openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=50&serviceId=urn:upnp-org:serviceId:TemperatureSetpoint1_Heat&action=SetCurrentSetpoint&NewCurrentSetpoint=15 HTTP/1.1 tcp{client}: 0x1ec57b0
2021-05-10 22:59:37.313   luup.call_action:: 50.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.SetCurrentSetpoint 
2021-05-10 22:59:37.314   luup_log:50: VirtualDevices[3.0-beta2@50](actionSetCurrentSetpoint@86):actionSetCurrentSetpoint(50,"15","Off","Heating")
2021-05-10 22:59:37.314   luup_log:50: VirtualDevices[3.0-beta2@50](actionSetCurrentSetpoint@90):actionSetCurrentSetpoint: skipped
2021-05-10 22:59:37.315   openLuup.server:: request completed (44 bytes, 1 chunks, 2 ms) tcp{client}: 0x1ec57b0
2021-05-10 22:59:50.043   openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x1ec57b0

Buxton

@akbooer OK that worked. Thx

Edit: Humidity variables are back. Looks like about 4 hours passed

~~I still do not see the humidity variables on the cache page though. The humidity values have recently updated as a scene I run based on humidity trigger points, fired about an hour ago.~~

Buxton

@akbooer One small error creating the energy variables

2021-05-10 17:22:42.275   openLuup.context_switch::  ERROR: [dev #0] ./openLuup/whisper.lua:662: Cannot create file '%s'
2021-05-10 17:22:42.275   openLuup.scheduler:: 30001.ENERGY.Current/1 ERROR ./openLuup/whisper.lua:662: Cannot create file '%s' function: 0x5633603dd490
2021-05-10 17:22:42.276   openLuup.context_switch::  ERROR: [dev #0] ./openLuup/whisper.lua:662: Cannot create file '%s'
2021-05-10 17:22:42.276   openLuup.scheduler:: 30001.ENERGY.Current/2 ERROR ./openLuup/whisper.lua:662: Cannot create file '%s' function: 0x5633603dd490

therealdb

@archers said in openLuup: Tasmota MQTT Bridge:

This is what I get in the log when changing the temperature of the device (no 50):

Looking at the logs, you're setting the temperature while the heater is off, so it's skipped. Do you want to turn it on if the temperature is below the target?

akbooer

@buxton said in openLuup: Tasmota MQTT Bridge:

Humidity variables are back. Looks like about 4 hours passed

Yes, that's not unexpected. In fact, it requires two variable updates before the variable appears on the historian list (because many, otherwise untinteresting, variables are updated once at startup.)

@buxton said in openLuup: Tasmota MQTT Bridge:

One small error creating the energy variables

Ah yes, those pesky topic separators '/' in the variable name – I knew it would come back to bite me. They are, of course, in the Unix file world, directory path separators. Some work required on the HIstorian filename handling...

akbooer

@Buxton

@akbooer said in openLuup: Tasmota MQTT Bridge:

Some work required on the HIstorian filename handling...

...now done in latest development version v21.5.11.

ArcherS

@therealdb said in openLuup: Tasmota MQTT Bridge:

Looking at the logs, you're setting the temperature while the heater is off, so it's skipped. Do you want to turn it on if the temperature is below the target?

I created a new device just to start from fresh:

When I try to change the dropdown from "off" to "Heat" it reverts back after I e.g. change rooms or reload the browser. The same thing when changing the temperature. Should it not stay at the value I set? I may be missing something obvious here on how the heater controller works, since it is the first time I play around with one.

These are the attributes:

and the variables:

The current temp was at 2000 when the device was created, tried changing it to e.g. 20, but makes no difference.

Some log entries from when changing the values:

2021-05-11 16:04:04.239   openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=52&serviceId=urn:upnp-org:serviceId:TemperatureSetpoint1_Heat&action=SetCurrentSetpoint&NewCurrentSetpoint=21 HTTP/1.1 tcp{client}: 0x2697800
2021-05-11 16:04:04.242   luup.call_action:: 52.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.SetCurrentSetpoint 
2021-05-11 16:04:04.243   openLuup.server:: request completed (44 bytes, 1 chunks, 2 ms) tcp{client}: 0x2697800
2021-05-11 16:04:09.775   openLuup.server:: GET /cmh/skins/default/img/devices/device_states/dimmable_light_30.png HTTP/1.1 tcp{client}: 0x2697800
2021-05-11 16:04:09.777   openLuup.server:: request completed (938 bytes, 0 chunks, 0 ms) tcp{client}: 0x2697800
2021-05-11 16:04:16.134   openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x2697800

2021-05-11 16:05:43.757   openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=741810207&Timeout=60&MinimumDelay=1500&_=1620741805209 HTTP/1.1 tcp{client}: 0x2882ed8
2021-05-11 16:05:45.244   openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=52&serviceId=urn:upnp-org:serviceId:HVAC_UserOperatingMode1&action=SetModeTarget&NewMode=HeatOn HTTP/1.1 tcp{client}: 0x2d32838
2021-05-11 16:05:45.246   luup.call_action:: 52.urn:upnp-org:serviceId:HVAC_UserOperatingMode1.SetModeTarget 
2021-05-11 16:05:45.247   openLuup.server:: request completed (39 bytes, 1 chunks, 1 ms) tcp{client}: 0x2d32838
2021-05-11 16:05:53.818   openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x2d32838

Log from when the device was created:

2021-05-11 10:05:35.089   luup.create_device:: [52] D_VirtualHeater1.xml / I_VirtualHeater1.xml / D_Heater1.json   (urn:schemas-upnp-org:device:Heater:1)
2021-05-11 10:05:35.099   openLuup.server:: request completed (6440 bytes, 0 chunks, 34 ms) tcp{client}: 0x1c6c030
2021-05-11 10:05:35.099   openLuup.scheduler:: [52] VirtualHeater2 device startup
2021-05-11 10:05:35.099   luup_log:52: VirtualHeater starting...
2021-05-11 10:05:35.100   luup_log:52: VirtualDevices[3.0-beta2@52]:Plugin starting
2021-05-11 10:05:35.100   luup.device_message:: device=52, status=4, message=Starting..., timeout=5, source=VirtualDevices
2021-05-11 10:05:35.100   luup_log:52: VirtualDevices[3.0-beta2@52]:Child #52 - "VirtualHeater2"
2021-05-11 10:05:35.101   luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.DebugMode was: EMPTY now: 0 #hooks:0
2021-05-11 10:05:35.101   luup.variable_set:: 52.urn:upnp-org:serviceId:TemperatureSetpoint1.CurrentSetpoint was: EMPTY now: 18 #hooks:0
2021-05-11 10:05:35.102   luup.variable_set:: 52.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.CurrentSetpoint was: EMPTY now: 18 #hooks:0
2021-05-11 10:05:35.102   luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.TemperatureDevice was: EMPTY now: 0 #hooks:0
2021-05-11 10:05:35.103   luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.SetPowerURL was: EMPTY now: http:// #hooks:0
2021-05-11 10:05:35.103   luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.SetPowerOffURL was: EMPTY now: http:// #hooks:0
2021-05-11 10:05:35.103   luup.attr_set:: 52.subcategory_num = 2
2021-05-11 10:05:35.106   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:HVAC_UserOperatingMode1.ModeTarget
2021-05-11 10:05:35.108   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:HVAC_UserOperatingMode1.ModeStatus
2021-05-11 10:05:35.111   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSetpoint1.CurrentSetpoint
2021-05-11 10:05:35.113   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.CurrentSetpoint
2021-05-11 10:05:35.116   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature
2021-05-11 10:05:35.116   luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.Configured was: 0 now: 1 #hooks:0
2021-05-11 10:05:35.116   luup.set_failure:: status = 0
2021-05-11 10:05:35.117   luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0
2021-05-11 10:05:35.117   luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: EMPTY now: 0 #hooks:0
2021-05-11 10:05:35.117   openLuup.scheduler:: [52] VirtualHeater2 device startup completed: status=true, msg=Ready, name=VirtualDevices
2021-05-11 10:05:35.626   openLuup.server:: request completed (4456 bytes, 1 chunks, 8545 ms) tcp{client}: 0x20a2fc0
2021-05-11 10:05:35.714   openLuup.server:: GET /data_request?id=user_data&output_format=json&DataVersion=679125970&_=1620678904534 HTTP/1.1 tcp{client}: 0x20a2fc0
2021-05-11 10:05:36.145   openLuup.server:: request completed (764639 bytes, 48 chunks, 429 ms) tcp{client}: 0x20a2fc0
2021-05-11 10:05:38.584   openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=679159576&Timeout=60&MinimumDelay=1500&_=1620678904535 HTTP/1.1 tcp{client}: 0x20a2fc0
2021-05-11 10:05:41.932   openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x1c6c030

Buxton

@akbooer No historian errors and all "checked" variables are publishing to my InfluxDB server.

akbooer

That's great. The next release will have a new openLuup > Historian > Rules page so that you can see what patterns are being used to match variables for archiving. Not yet editable, but that may come in future. Feel free to ask for more/better rules and I can put them into another release, or tell you how to add them in Lua Startup.

Buxton

@akbooer Cool. Making the checklist active would be great as there are some oddball variables that I'd like to incorporate, and creating wsp files by hand, while not super difficult--I have several-- is not exactly easy either....

akbooer

@buxton said in openLuup: Tasmota MQTT Bridge:

some oddball variables that I'd like to incorporate

...trivial to add with a custom rule.

ArcherS

@akbooer said in openLuup: Tasmota MQTT Bridge:

...now done in latest development version v21.5.11.

Installed and it seems to work as it should. Next step is to upgrade on my main OpenLuup server after some runtime on the test server.

therealdb

@archers said in openLuup: Tasmota MQTT Bridge:

2021-05-11 10:05:35.103 luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.SetPowerURL was: EMPTY now: http:// #hooks:0
2021-05-11 10:05:35.103 luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.SetPowerOffURL was: EMPTY now: http:// #hooks:0

This is by design. As you can see, you've not set SetPowerURL and SetPowerOffURL to anything significant, like the mqtt message, so it's not sending anything, and it's acting with the default behavior: if you're not replying with 200-ish HTTP response, it will not change variables. When using mqtt:// prefix, it will update immediately.

I'll work on this anyway, since it's not sending temperature command at the moment, but I think it's a good addition in your use case - and to other people as well.

Please try with mqtt commands and let me know, because I have it working good.

EDIT: it's done, just set SetSetpointURL variable to

mqtt://cmnd/TasmotaIR/IRhvac/=/{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"On","Celsius":"On","Temp":%s,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}

(notice the %s). it's sending the temperature that's set. it's beta3 on GitHub, from master branch.

ArcherS

@therealdb my feeling was that I had missed something.
Yes I think it could be a good usecase.

Edit: I got to send the Mqtt message a few times, but not every time. Not sure why it does not send every time though. Does it matter if it is "off" or "heat"?

Edit 2: It seems as if it works! Mode "off" and then the set temp sends the Mqtt message. Maybe if was a poll delay or something. I will test some more.

~~I tried to add the above mqtt:// into the SetSetpoint URL but nothing seems to be sent, i.e. nothing is appearing in the Tasmota Console.~~

This is what I see in the log (device no 52):

2021-05-12 20:18:02.023   openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=843427346&Timeout=60&MinimumDelay=1500&_=1620843427214 HTTP/1.1 tcp{client}: 0x1b09e50
2021-05-12 20:18:14.970   openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=52&serviceId=urn:upnp-org:serviceId:TemperatureSetpoint1_Heat&action=SetCurrentSetpoint&NewCurrentSetpoint=19 HTTP/1.1 tcp{client}: 0x2204008
2021-05-12 20:18:14.972   luup.call_action:: 52.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.SetCurrentSetpoint 
2021-05-12 20:18:14.973   openLuup.server:: request completed (44 bytes, 1 chunks, 2 ms) tcp{client}: 0x2204008
2021-05-12 20:18:20.877   openLuup.server:: GET /console?page=log.1 HTTP/1.1 tcp{client}: 0x2204008
2021-05-12 20:18:20.981   openLuup.server:: request completed (185478 bytes, 0 chunks, 102 ms) tcp{client}: 0x2204008
2021-05-12 20:18:21.107   openLuup.server:: GET /favicon.ico HTTP/1.1 tcp{client}: 0x2204008
2021-05-12 20:18:21.107   openLuup.servlet:: file not found:favicon.ico
2021-05-12 20:18:21.108   openLuup.server:: request completed (126 bytes, 0 chunks, 0 ms) tcp{client}: 0x2204008
2021-05-12 20:18:21.108   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x2204008
2021-05-12 20:18:23.314   openLuup.io.server:: HTTP:3480 connection from 192.168.1.145 tcp{client}: 0x1c7ed70
2021-05-12 20:18:23.316   openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x1c7ed70

I also tried with a number, e.g. "20" instead of %s but no difference.

Startup log, it seems as if I have the right version:

2021-05-12 20:29:18.833   luup_log:52: VirtualHeater starting...
2021-05-12 20:29:18.834   luup_log:52: VirtualDevices[3.0-beta3@52]:Plugin starting
2021-05-12 20:29:18.834   luup.device_message:: device=52, status=4, message=Starting..., timeout=5, source=VirtualDevices
2021-05-12 20:29:18.834   luup_log:52: VirtualDevices[3.0-beta3@52]:Child #52 - "VirtualHeater2"
2021-05-12 20:29:18.835   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:HVAC_UserOperatingMode1.ModeTarget
2021-05-12 20:29:18.837   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:HVAC_UserOperatingMode1.ModeStatus
2021-05-12 20:29:18.838   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSetpoint1.CurrentSetpoint
2021-05-12 20:29:18.840   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.CurrentSetpoint
2021-05-12 20:29:18.841   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature
2021-05-12 20:29:18.841   luup.set_failure:: status = 0
2021-05-12 20:29:18.841   luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0
2021-05-12 20:29:18.842   luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0
2021-05-12 20:29:18.842   openLuup.scheduler:: [52] VirtualHeater2 device startup completed: status=true, msg=Ready, name=VirtualDevices

therealdb

@archers temp is sent for set target only, but I could add easily to power on/off.

ArcherS

@therealdb said in openLuup: Tasmota MQTT Bridge:

@archers temp is sent for set target only, but I could add easily to power on/off.

Thanks for all the effort! It could be a useful addition for a more generic usecase, i.e. to have the posibility to add on/off in the same way as for temperature with a vaiable similar to %s.
I tested on my Fujitsu and "Power":"On" resp "Power":"Off" in the Mqtt message turns it on and off so it seems quite straight forward.

For my particular usecase I may go in a slightly different direction. My idea is to put the Tasmota IR so that it can both send commands to the HVAC and also that it can capture commands from the remote via Mqtt and IrReceived.
I have tested this a bit and it seems to work quite well. I setup at Reactor pulling the data sent from the remote to the HVAC and also sending data to the HVAC, so far only when changing the temp, but I may add e.g. fan speed.

therealdb

@archers heater is a bit behind the others, where I’m already supporting mqtt messages to update values. I could add it easily over the weekend. You’ll find two variables to update. Send me your messages, so I could try to replicate it and give you precise instructions. It’s one of the things I’ll change in my setup, so it’s work I’m doing for myself as well

ArcherS

@therealdb for my Fujutsu unit:

Message to turn off device:

mqtt://cmnd/TasmotaIR/IRhvac/=/{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"Off","Celsius":"On","Temp":20,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}

Message to turn on device:

mqtt://cmnd/TasmotaIR/IRhvac/=/{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"On","Celsius":"On","Temp":20,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}

I do not know if it would be possible to control the fan also, I am not sure there is a good controller for it. If so the fan is controlled with the "Fanspeed" being set to five values 1-4 and auto: "Min", "Low", "Medium", Max" and "Auto" e.g.

mqtt://cmnd/TasmotaIR/IRhvac/=/{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"On","Celsius":"On","Temp":20,"FanSpeed":"Max","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}

therealdb

@archers after we’re done with heaters, I’ll definitely add a thermostat to the mix, even if it’s a mess and it’s not easy. In the meantime, you could control it with a dimmer. Maybe it’s time to add transformation to the mix, so we could easily produce a range (1…4) from 0/100.

Anyway, I was speaking of mqtt messages to get the status, if available in your use case - ie when changing the mode via the official remote.

ArcherS

@therealdb I also thought of using a dimmer or something similar.

When I press the remote and the IR reveiver in the Tasmota captures that I get an IrReceived message in the Console:

07:45:47 MQT: tele/TasmotaIR/RESULT = {"IrReceived":{"Protocol":"FUJITSU_AC","Bits":128,"Data":"0x0x1463001010FE0930400400000000206C","Repeat":0,"IRHVAC":{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"On","Celsius":"On","Temp":20,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}

It always contains the same elements as above, i.e. it reports all of the status fields every time.

So e.g. when changing the fan to "Min":

01:57:31 RSL: tele/tasmota_E0D649/RESULT = {"IrReceived":{"Protocol":"FUJITSU_AC","Bits":128,"Data":"0x0x1463001010FE09304004040000002068","Repeat":0,"IRHVAC":{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"On","Celsius":"On","Temp":20,"FanSpeed":"Min","SwingV":"Off","SwingH":"Off","Quiet":"On","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}
IRVAC{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"On","Celsius":"On","Temp":20,"FanSpeed":"Min","SwingV":"Off","SwingH":"Off","Quiet":"On","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}

The FanSpeed values are:
"FanSpeed":"Min"
"FanSpeed":"Low"
"FanSpeed":"Medium"
"FanSpeed":"Max"
"FanSpeed":"Auto"

When powered on:

01:55:23 RSL: tele/tasmota_E0D649/RESULT = {"IrReceived":{"Protocol":"FUJITSU_AC","Bits":128,"Data":"0x0x1463001010FE0930410400000000206B","Repeat":0,"IRHVAC":{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"On","Celsius":"On","Temp":20,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}

When powered off:

00:26:45 RSL: tele/tasmota_E0D649/RESULT = {"IrReceived":{"Protocol":"FUJITSU_AC","Bits":56,"Data":"0x0x146300101002FD","Repeat":0,"IRHVAC":{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Off","Power":"Off","Celsius":"On","Temp":16,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}

For some reason it also sends "Mode":"Off" when powered off and not only "Power":"Off"

When changing mode you get for the four modes:
"Mode":"Heat"
"Mode":"Cool"
"Mode":"Dry"
"Mode":"Auto"

When I have looked in the Tasmota IR wiki there is some info on this also.
Both the IrReceived and IRhvac send protocols seem quite generic in terms of the mode, fan speed etc.

openweather plugin ?

Openluup: Datayours

openLuup: Shelly Bridge plugin

zigbee2mqtt and openLuup

UPnP event proxy plugin using systemd service file

Sonos system alerts truncated

Generic support for vacuums

Switchboard plugin

Cannot publish new version in ALTAPP Store

openLuup: UI Device / Tile Text

Reactor scope issues

Virtual Devices Plug-in update (with async HTTP support)

AltUI will not update under openLuup (Vera: not sure what it does)

Reactor: double click action

Virtual Pronto Remote plugin

openLuup: SmartSwitch plugin

Reactor icons for local lan

openLuup: Tasmota MQTT Bridge

AltUi

AltUI sort?

openLuup: Tasmota MQTT Bridge

Recent Topics