I was unable to get MQTT to work correctly in openluup... I had to give up... It's a real shame ... as ZwaveJS is by far the best thing I've seen to manage zwave networks.
R
ronluna
@ronluna
I’ve added a couple of Shelly Wave i4 as scene controllers and I’m planning to add more, since I can just use standard buttons instead of battery-powered scene controllers, which also looks better aesthetically.
That said, I’m struggling to figure out how to write a simple rule that cycles between states every time I press a button.
Example: Light 1 ON → OFF, then Light 2 ON → OFF.
The part I can’t get right is handling the case where Light 1 or Light 2 might already be ON independently of the rule.
Maybe it’s just too much sun and relaxation clouding my brain, but any hint would be appreciated.
Use case:
When performing home maintenance, such as air conditioning, I want all rules involving air conditioning to be disabled.
To do this, to day, I have a virtual switch that I placed within all rules involving air conditioning, meaning that if I turn it off, none of them work.
Then another situation: the water pump system and garden irrigation, another switch.
In short, I had to create several virtual switches in Hubitat to disable rules in MSR.
Unfortunately, however, I was unable to cover all scenarios, so I wondered if it would be possible for MSR to support a virtual MSR switch, which, when configured in the reactor settings, would function as a general on/off switch for MSR.
If it is configured and turned off, the entire rules and actions in MSR stops working, except for the status change reading process, specifically for this switch, which, when turned on, would restart the MSR.
Would it be possible to do something like this? Any recommendations from the experts?
Probably a really dumb question.
Currently I am using the owntracks_sensor for tracking phones being in region in MSR and it works great.
Digging around with Home Assistant and toying with some dashboards, is there any way of exposing that sensor to HA trivially? I could set MSR to trip a virtual switch in OpenLuup which can then be exposed to HA (with all my other Vera devices) but that feels a bit in-elegant if I can do it directly.
Any thoughts?
Apologies if the ask is not clear/
TIA
C
...is back....
https://arstechnica.com/google/2025/08/researchers-use-calendar-events-to-hack-gemini-control-smart-home-gadgets/?utm_source=facebook&utm_medium=social&utm_campaign=dhfacebook&utm_content=null&fbclid=IwY2xjawMBq-pleHRuA2FlbQIxMQABHlSqIalzbz1IxcJFzlw8GBE6nC3FwvxcHgR370nJhogU6JjqbmRxG-lysqgh_aem_lx9XboYFKw9tpHnedGQKUA
C
As there are statements about compatibility for home assistant versions in MSR new version announcements (e.g. "HassController: Bless Hass to 2025.7.3"), I thought it would be good idea to track other controllers as well.
As an example, I can confirm that build "latest-25208-c53e8513" works with Hubitat Elevation C-8 platform version 2.4.2.134 using Maker API.
Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here.
Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions;
Fix an error in OWMWeatherController that could cause it to stop updating;
Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later;
Improve error detail in messages for EzloController during auth phase;
Add isRuleSet() and isRuleEnabled() functions to expressions extensions;
Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases);
Fix a place in the UI where 24-hour time was not being displayed.
I foolishly let my system wipe all cookies this morning and with it my settings for my MSR home page.
Once logged back in I can no longer remove errant panes nor is the + available to add new ones.
Brave Browser v1.80.122 (Jul 16, 2025)
What have I done?!
Will check other browsers on my M1.
UPDATE: Safari exhibits same behaviour.
I've tried both sans last-four public key entry and with - no change.
@toggledbits, not sure if this is a feature request or I'm using the search tool wrong. You have a "Search for rule" in the Rules Set tab in MSR. It works nicely to find a rule and bring up said rule, but can it/could it be used for as a "where used?" global search? For instance, I have a fairly large set of rules, divided up into 10 different rulesets. There's easily a hundred individual rules, and many of the rules have Rule State triggers, which of course refer to other rules. Amongst my troubleshooting today, I came across what may have been a duplicate or troubleshooting attempt, but I can't tell if it's actually used as a Rule State in another rule without opening each rule that I suspect it may be a part of.
Thanks.
Hi Smart Home Community.
I have used a Sonos inline WiFi switch to make one of my light fittings smart, but it requires a hard reset for WiFi changes, plus it isn't zigbee compatible, which means I can't use the Hue app to control it with the rest of the lights.
To that end I bought a Samotech SM308-S as it is recommended as the better than the Sonos equivalent.
I am however not exactly sure how to wire it in.
The manual is available here
Can anyone help me by clarifying which ports I need to use, and whether I should be using the live or switched live line for live etc.
I will be keeping using standard switches for a while, although hope to upgrade to tap dials once I have all the fittings upgraded.
Thanks
Posts
-
ZWaveJS and MQTT -
openLuup: MQTT serverIf there is something I can do to help, please let me know.
-
openLuup: MQTT serverI had to disable the MQTT Handler from the startup as it was crashing the entire engine.
-
openLuup: MQTT server@akbooer with DEBUG enabled the logs show:
2022-03-20 15:54:54.501 openLuup.mqtt:: CONNECT tcp{client}: 0x55ae0e8b8318 2022-03-20 15:54:54.501 openLuup.mqtt:: ClientId: ZWAVE_GATEWAY-Zwavejs2Mqtt 2022-03-20 15:54:54.501 openLuup.mqtt:: WillTopic: zwave/_CLIENTS/ZWAVE_GATEWAY-Zwavejs2Mqtt/status 2022-03-20 15:54:54.501 openLuup.mqtt:: WillMessage: {"value":false} 2022-03-20 15:54:54.502 openLuup.mqtt:: UserName: ******** 2022-03-20 15:54:54.502 openLuup.mqtt:: Password: ******** 2022-03-20 15:54:54.502 openLuup.io.server:: MQTT:1829 connection closed tcp{client}: 0x55ae0a5f7e78 2022-03-20 15:54:54.502 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55ae0a5f7e78 2022-03-20 15:54:54.519 openLuup.server:: request completed (16415 bytes, 2 chunks, 1068 ms) tcp{client}: 0x55ae0c39f788 2022-03-20 15:54:54.587 openLuup.server:: error 'closed' sending 6 bytes to tcp{client}: 0x55ae0dfce198 2022-03-20 15:54:54.587 openLuup.server:: ...only 0 bytes sent 2022-03-20 15:54:54.587 openLuup.server:: error 'closed' sending 94946 bytes to tcp{client}: 0x55ae0dfce198 2022-03-20 15:54:54.587 openLuup.server:: ...only 0 bytes sent 2022-03-20 15:54:54.587 openLuup.server:: error 'closed' sending 2 bytes to tcp{client}: 0x55ae0dfce198Seems like is related to what @toggledbits has shared a couple weeks ago. clues?
-
openLuup: MQTT serverI'm currently having a problem where the only way to get openluup to start processing messages from subscribed topics is by restarting the ZWaveJS service. When the ZWaveJS MQTT service is restarted the ZWaveJS Clients send the subscribe messages to openluup and only then is when messages start to get processed.
Testing with the following inserted in the startup:
local json = require "openLuup.json" function MyMQTThandler (topic, message) local info = json.decode (message) local currentLevel = info.value luup.variable_set ("urn:upnp-org:serviceId:Dimming1", "LoadLevelStatus", currentLevel, 68) luup.log("Processed") end luup.register_handler ("MyMQTThandler", "mqtt:zwave/Hallway_2/DImmer_1/38/0/currentValue")I Couldn't find anything on ZWaveJS nor in openluup that might explain this behavior and my short mqtt knowledge is not helpful either.
Any ideas?
-
openLuup: MQTT serverBased out L_ShellyBridge.lua I've created initial L_ZWaveBridge.lua made changes in virtualfilesystem.lua to create D_ZWaveBridge.xml, D_ZWaveBridge.json and subcribed to zwave topic. which is how the MQTT messages are sent from ZWaveJS2MQTT by default.
my startup lua looks like:
luup.attr_set ("openLuup.MQTT.Username", "*********") luup.attr_set ("openLuup.MQTT.Password", "*********") luup.attr_set ("openLuup.MQTT.Port", 1811) luup.attr_set ("openLuup.MQTT.PublishVariableUpdates", true) luup.attr_set ("openLuup.MQTT.DEBUG", true)With my short mqtt understanding ZWaveJS is connecting and authenticating just fine to openluup although I've been unable to properly modify L_ZWaveBridge.lua to capture and parse the messages that ZWaveJS is sending.
-
openLuup: MQTT serverWould be awesome to get ZWaveJS2Mqtt added to openluup. As much as ZWay has proven to be faster and much more reliable than Vera... ZWaveJS has a bright future...
-
io module async ?Maybe adding sockproxyd natively into openluup and modifying io.lua to optionally use sockproxyd could be a real winner to finally solve the limitations/problems in the I/O module.
-
io module async ?There is a little issue I'm currently facing with openluup and plugins that relies on io module.
If openluup is watching a variable that belongs to a devices that relies on io module and there is an action attached that also relies on io module, when that watcher gets triggered, the action in question will get processed in openluup (it will show in the logs) but the parent device won't process it.
I have a feeling that this could be due to io packets crossing between each others somehow modifying the final message received by the parent device. it's feels like the io communication is happening in the same room for all plugins and sometimes they get crossed. Wondering if anyone has experienced something of that sort and if there is a way to prevent it?
-
Apple Homepod mini@akbooer That's right... and just like that... apple is taking over then entire home automation industry.... too bad there is no Home app for Android. Well Front end and first layer voice control related...
-
Apple Homepod mini@akbooer get the latest copy directly from github at https://github.com/damianxd/homebridge-vera as npm is not current/synced with the github repo. In other words, install the plugin through the homebridge plugin section and then replace all the files located at "/usr/lib/node_modules/homebridge-vera/" with the latest on github.
-
BroadLink Mark II plugin@a-lurker the second broadlink device in the network is indeed Mini split A/C that uses AC Freedom app. Both device are well within the wifi range and working fine when using their native apps so I doubt the timeout message has something to do with the strength of the connection. What I've noticed in the past when I've seen a timeout like this is due to the socket expecting a special carrier return <CR> or something in that sort, simply not understanding what was sent back to it.
I'm not familiar with the RM communication protocol... Although I'm all ears to see what else We could try to get this off the ground.
2021-04-03 14:20:18.155 openLuup.scheduler:: [82] BroadLink-Mk2 device startup 2021-04-03 14:20:18.155 luup_log:82: BroadLink_Mk2 debug: Initialising plugin: BroadLink_Mk2 2021-04-03 14:20:18.155 luup_log:82: BroadLink_Mk2 debug: Using: Lua 5.1 2021-04-03 14:20:18.155 luup_log:82: BroadLink_Mk2 debug: 0.57a --> PluginVersion 2021-04-03 14:20:18.155 luup.variable_set:: 82.urn:a-lurker-com:serviceId:BroadLink_Mk2_1.PluginVersion was: 0.57 now: 0.57a #hooks:0 2021-04-03 14:20:18.156 luup_log:82: BroadLink_Mk2 debug: Using: dkjson 2021-04-03 14:20:18.157 luup_log:82: BroadLink_Mk2 debug: Broadcasting discovery message 2021-04-03 14:20:18.157 luup_log:82: BroadLink_Mk2 debug: 10.1.11.22 2021-04-03 14:20:19.157 luup_log:82: BroadLink_Mk2 debug: Number of BroadLink devices found is 1 2021-04-03 14:20:19.158 luup_log:82: BroadLink_Mk2 debug: Header to be sent follows (ex checksum): 5A A5 AA 55 5A A5 AA 55 00 00 00 00 00 00 00 00 Z..UZ..U........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 9B 64 65 00 00 00 8D DE 18 B0 43 A0 .....de.......C. 00 00 00 00 FB C8 00 00 ........ 2021-04-03 14:20:19.158 luup_log:82: BroadLink_Mk2 debug: Payload to be sent follows (unencrypted): 00 00 00 00 A7 C5 DF 0A 91 33 F1 88 C9 82 A5 6D .........3.....m C8 BC F9 DF 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 2021-04-03 14:20:19.177 luup_log:82: BroadLink_Mk2 debug: Sending: Authorisation: txMsg length = 136 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: RX of Authorisation msg response from 10.1.11.20 failed: timeout 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: This device is probably offline - mac address: a0:43:b0:18:de:8d 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: k = rf433 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: k = rf433 has no associated code at this time 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: k = ir 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: a0:43:b0:18:de:8d_ir 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: a0:43:b0:18:de:8d 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: RM4 Pro - IR 1 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: urn:schemas-micasaverde-com:device:IrTransmitter:1 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: D_BroadLink_Mk2_IrRf_1.xml 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: type = function, value = function: 0x19a62d0 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: k = rf315 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: k = rf315 has no associated code at this time 2021-04-03 14:20:20.177 luup_log:82: BroadLink_Mk2 debug: {"a0:43:b0:18:de:8d":{"blInternalId":"00000001","blKey":"a7c5df0a9133f188c982a56dc8bcf9df","blDeviceType":25755,"blIp":"10.1.11.20","blDesc":"RM4 Pro"}} --> BroadLinkDevices 2021-04-03 14:20:20.177 luup.chdev.append:: [a0:43:b0:18:de:8d_ir] RM4 Pro - IR 1 2021-04-03 14:20:20.178 luup.chdev.sync:: [82] BroadLink-Mk2, syncing children 2021-04-03 14:20:20.178 luup.set_failure:: status = false 2021-04-03 14:20:20.178 luup.variable_set:: 82.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: false now: false #hooks:0 2021-04-03 14:20:20.178 luup.variable_set:: 82.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 1617440329 now: 1617474020 #hooks:0 2021-04-03 14:20:20.178 openLuup.scheduler:: [82] BroadLink-Mk2 device startup completed: status=true, msg=All OK, name=BroadLink_Mk2 -
BroadLink Mark II pluginI tested the latest changes to add support for the RM4 Pro and it created a "IR" Child although it did not list any of the devices that have been created inside the RM4 Pro itself (Probably because is an RF device and that child was not created?). Also the IP set in the plugin attributes is different than the IP This is what the logs are showing:
2021-04-02 08:53:44.604 luup_log:82: BroadLink_Mk2 debug: The BroadLink device at IP address 10.1.11.126 and of type 0x4e2a is not known to this pluginI do have another Broadlink device in the network so I guess is trying to discover that one as well.
2021-04-02 08:53:44.557 openLuup.scheduler:: [3] Alternate App Store device startup completed: status=true, msg=OK, name=AltAppStore 2021-04-02 08:53:44.557 openLuup.scheduler:: [82] BroadLink-Mk2 device startup 2021-04-02 08:53:44.557 luup_log:82: BroadLink_Mk2 debug: Initialising plugin: BroadLink_Mk2 2021-04-02 08:53:44.557 luup_log:82: BroadLink_Mk2 debug: Using: Lua 5.1 2021-04-02 08:53:44.557 luup_log:82: BroadLink_Mk2 debug: 0.57 --> PluginVersion 2021-04-02 08:53:44.558 luup_log:82: BroadLink_Mk2 debug: Using: dkjson 2021-04-02 08:53:44.559 luup_log:82: BroadLink_Mk2 debug: Broadcasting discovery message 2021-04-02 08:53:44.559 luup_log:82: BroadLink_Mk2 debug: 10.1.11.22 2021-04-02 08:53:44.603 luup_log:82: BroadLink_Mk2 debug: 10.1.11.126 2021-04-02 08:53:44.604 luup_log:82: BroadLink_Mk2 debug: Rx'ed a discovery response: rxMsg length = 128 5A A5 AA 55 5A A5 AA 55 00 00 00 00 00 00 00 00 Z..UZ..U........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ E5 D6 00 00 2A 4E 07 00 00 00 DD 8A EB A7 DF 24 ....*N.........$ 00 00 00 00 2A 4E 0A 01 0B 7E DD 8A EB A7 DF 24 ....*N...~.....$ E5 A5 A5 E5 85 8B E6 96 AF E7 A9 BA E8 B0 83 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 01 ................ 2021-04-02 08:53:44.604 luup_log:82: BroadLink_Mk2 debug: Looks like the Cloud bit is set - that's not good 2021-04-02 08:53:44.604 luup_log:82: BroadLink_Mk2 debug: Friendly name: e5a5a5e5858be696afe7a9bae8b083 2021-04-02 08:53:44.604 luup_log:82: BroadLink_Mk2 debug: The BroadLink device at IP address 10.1.11.126 and of type 0x4e2a is not known to this plugin 2021-04-02 08:53:45.604 luup_log:82: BroadLink_Mk2 debug: Number of BroadLink devices found is 1 2021-04-02 08:53:45.604 luup_log:82: BroadLink_Mk2 debug: Header to be sent follows (ex checksum): 5A A5 AA 55 5A A5 AA 55 00 00 00 00 00 00 00 00 Z..UZ..U........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 9B 64 65 00 00 00 8D DE 18 B0 43 A0 .....de.......C. 00 00 00 00 FB C8 00 00 ........ 2021-04-02 08:53:45.605 luup_log:82: BroadLink_Mk2 debug: Payload to be sent follows (unencrypted): 00 00 00 00 A7 C5 DF 0A 91 33 F1 88 C9 82 A5 6D .........3.....m C8 BC F9 DF 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 2021-04-02 08:53:45.618 luup_log:82: BroadLink_Mk2 debug: Sending: Authorisation: txMsg length = 136 2021-04-02 08:53:45.632 luup_log:82: BroadLink_Mk2 debug: Broadlink device: 649b replied with: 03e9 2021-04-02 08:53:45.632 luup_log:82: BroadLink_Mk2 debug: Error: errorMsg = fff9 2021-04-02 08:53:45.632 luup_log:82: BroadLink_Mk2 debug: This device is probably offline - mac address: a0:43:b0:18:de:8d 2021-04-02 08:53:45.632 luup_log:82: BroadLink_Mk2 debug: k = ir 2021-04-02 08:53:45.632 luup_log:82: BroadLink_Mk2 debug: a0:43:b0:18:de:8d_ir 2021-04-02 08:53:45.632 luup_log:82: BroadLink_Mk2 debug: a0:43:b0:18:de:8d 2021-04-02 08:53:45.632 luup_log:82: BroadLink_Mk2 debug: RM4 Pro - IR 1 2021-04-02 08:53:45.632 luup_log:82: BroadLink_Mk2 debug: urn:schemas-micasaverde-com:device:IrTransmitter:1 2021-04-02 08:53:45.632 luup_log:82: BroadLink_Mk2 debug: D_BroadLink_Mk2_IrRf_1.xml 2021-04-02 08:53:45.633 luup_log:82: BroadLink_Mk2 debug: type = function, value = function: 0x1a03140 2021-04-02 08:53:45.633 luup_log:82: BroadLink_Mk2 debug: {"a0:43:b0:18:de:8d":{"blInternalId":"00000001","blKey":"a7c5df0a9133f188c982a56dc8bcf9df","blDeviceType":25755,"blIp":"10.1.11.20","blDesc":"RM4 Pro"}} --> BroadLinkDevices 2021-04-02 08:53:45.633 luup.chdev.append:: [a0:43:b0:18:de:8d_ir] RM4 Pro - IR 1 2021-04-02 08:53:45.633 luup.chdev.sync:: [82] BroadLink-Mk2, syncing children 2021-04-02 08:53:45.633 luup.set_failure:: status = false 2021-04-02 08:53:45.633 luup.variable_set:: 82.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: false now: false #hooks:0 2021-04-02 08:53:45.633 luup.variable_set:: 82.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 1617316371 now: 1617368025 #hooks:0 2021-04-02 08:53:45.633 openLuup.scheduler:: [82] BroadLink-Mk2 device startup completed: status=true, msg=All OK, name=BroadLink_Mk2Any ideas how to get the RF portion working?
-
Generic support for vacuums@therealdb could use homebridge 2 openluup also...
-
Homebridge to Openluup -
Homebridge to Openluup -
Homebridge to Openluup@crille currently the plugin relies on an initial manual configuration and the current mechanism creates the children in a very dumb way. It is possible to build a more sophisticated interface although the plugin still in a "proof of concept state".
Yes, the devices are named DeviceType_UUID by default when they are created for the first time but after that I can rename them any way I want and the names remain persistent after engine reloads.
My understanding is that once a device is renamed on your setup it will get renamed back to the default deviceType_uuid after the engine reloads right? and that's what I can't replicate on my end.
-
Homebridge to Openluup@crille said in Homebridge to Openluup:
luup.chdev.append
I'm really puzzled by this... Your logs looks just fine... The devices should not get renamed back when luup.chdev.append runs . if the devices where getting re-created the engine should be getting reloaded right away... What openluup version are you running?
Wondering if @akbooer sees something weird in how the plugin is syncing the devices after the append runs that could be causing it... at line 601 of L_Homebridge2openllup1.lua as it is something I'm not experiencing on my end... and I'm not sure where else to look...
-
Homebridge to Openluup@crille I've been renaming renaming devices on my end without experiencing what you are describing. Are both Mitsubishi thermostat? Do you mind sharing an entire log output after an engine reload, additional 5 second log for the first device've value refresh and log output while rename a homebridge device from within openluup?
-
Homebridge to Openluup@crille said in Homebridge to Openluup:
THERMOSTAT_uuid
That's odd... It shouldn't do that...
is your deviceList Variable ending with a semicolon ";" after your uuid ?