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
at _ClientAPI._commandTimeout (http://192.168.1.100:8111/client/ClientAPI.js:807:179
Seeing this randomly when returning to open browser tab after being away awhile. Once, maybe twice a day.
"What did you do to trigger it?" Literally nothing, just walked away and returned and there it was.
Actions taken in reasonably close proximity to this particular instance of it popping up: I'd restarted the MSR container in Portainer.
I'll try to grab some logs here shortly.
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.
This post does not apply to users of Intel/AMD-based systems. If you are using a Reactor image tagged latest-amd64 or stable-amd64, then this post does not apply to you. It also does not apply to bare-metal installs; it's for users of docker images on ARM-based systems only (principally Raspberry Pi hosts, but could be others).
After January 15, 2026, I will no longer produce the aarch64-tagged docker image for Reactor. The ARM images will be arm64 for 64-bit operating systems, and armv7l for 32-bit operating systems.
For those of you running a container from the aarch64 image today, this will be a relatively simple change: you just need to switch the image used for your docker container to a differently-tagged image. If you are using docker-compose, then this is a relatively simple matter of changing the image line in your docker-compose.yaml file and then stopping (docker-compose down) and restarting (docker-compose up -d) your Reactor daemon.
But there's a catch... not all of you can safely just switch from the aarch64 image to the arm64 image. And, you can't just trust the output of uname -m, for example, because this exposes the CPU architecture, but not the word size of the OS running on that CPU.
For Raspberry Pi systems, the transition to 64-bit operating systems was long (starting in 2016) and not always obvious — although there was a first "official" 64-bit OS for RPis in 2020, it did not become a default recommendation in the Raspberry Pi Imager until 2021, and then that was only the default for Pi 3/4 systems with >4GB RAM; it was 2022 before it was universally recommended for all 64-bit CPUs regardless of RAM size. Depending on when you first imaged your RPi system and what default you may have been offered/chosen, you could today easily have a 64-bit CPU Raspberry Pi running a 32-bit version of the operating system. Upgrades along the way would not change this; changing it to fully 64-bit requires a full reimage of the system.
To establish if your OS is 64- or 32-bit, log in to your Pi and run: sudo dpkg-architecture -q DEB_HOST_ARCH. If the response is arm64 or aarch64, then you are running a 64-bit OS and you should use the arm64-tagged image. If it's anything else, you are running a 32-bit OS, and you should use the armv7l-tagged image.
pi@rpi4-1:~ $ sudo dpkg-architecture -q DEB_HOST_ARCH
armhf
pi@rpi4-1:~ $ uname -m
aarch64
pi@rpi4-1:~ $
In the example above, the uname command reports that the CPU is 64-bit architecture (aarch64), which is true for the host on which I ran these commands, but the DEB_HOST_ARCH value is armhf, indicating a 32-bit operating system. This system has to use the armv7l-tagged image.
Other systems will have their own ways of determining the word size of the running OS. Since the majority of Reactor users running ARM systems are on Raspberry Pis, I am able to supply the above instructions, but if you happen to have a different ARM system, you'll need to do some web searching to figure out how to expose that information. Or, you can just try the arm64 image, and if it doesn't start up, try the armv7l image.
Remember to always back up your system before making any changes.
For everyone, please make this change as soon as possible, and if you have any trouble finding a working image, please (1) go back to the current aarch64 image; and (2) let me know in this thread along with as much detail about your host system as you can offer (including the output of the dpkg-architecture command mentioned above).
Hi,
I'm in the process of migrating from a Raspberry Pi 4 (ARMv7) to a Raspberry Pi 5 (ARMv8/aarch64), but I’ve run into an issue: there is no proper ARMv8/aarch64 image available.
None of the existing images run on the Pi 5 - they all exit immediately with code 139 (segmentation fault), which typically indicates that the binaries inside the image are not compatible with the ARM64/aarch64 architecture used by the Pi 5.
Would it be possible to publish a correct ARMv8/aarch64 (linux/arm64) image?
Building one should be relatively straightforward using docker buildx with multi-arch support. For example, my own Node.js images are built this way:
docker buildx build --push \
-t <localrepo>/<project>:<tag> \
--platform=linux/arm64,linux/amd64 \
--file ./apps/<project>/Dockerfile .
This produces both the AMD64 and ARM64/v8 variants automatically.
Also, as a side note, it may be best to avoid using Alpine as the base image for the ARM64 build, since musl-based builds often cause compatibility issues and unnecessary headaches. A glibc-based base image (e.g., Debian or Ubuntu) tends to work far more reliably on ARM64, especially for Node.js applications.
@toggledbits - tagging you in case you missed this.
Thanks,
mgvra
Sorry to write here without trying, but I’m flying today.
Am I correct if i say that script action with alarm() makes it possible to execute a reaction in a given interval, lets say 15 seconds or 3.5 minutes?
That sounds amazing, since I’ve used weird tricks, including a custom controller, just to do this.
Just throwing out a general hint to the people running Homebridge and MQTT.
Homebridge MQTT-Thing hasn't been updated in almost 2 years and it falls behind on compatibility with the development of Homebridge.
I was looking for a replacement and found Homebridge Easy MQTT and I think it's a good replacement for MQTT-Thing. I particularly find Easy MQTT Value tranformers easier to to understand and use compared to MQTT-Thing Apply function.
It took a while to migrate everything but I'm pleased and can recommend.
@toggledbits Do you know if this is related to that PR or is it a change they made in 2025.11.1?
[latest-25310]2025-11-11T13:16:24.319Z <HassController:INFO> HassController#hass perform x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_dag with { "time": "10:45" }
[latest-25310]2025-11-11T13:16:24.320Z <HassController:INFO> HassController#hass: sending payload for x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_dag action: { "type": "call_service", "service_data": { "date": (null), "time": "10:45", "datetime": (null), "timestamp": (null) }, "domain": "input_datetime", "service": "set_datetime", "target": { "entity_id": "input_datetime.vvb_dag" } }
[latest-25310]2025-11-11T13:16:24.321Z <HassController:ERR> HassController#hass request 1762866984320<2025-11-11 14:16:24> (call_service) failed: [Error] Not a parseable type for dictionary value @ data['date'] [-]
[latest-25310]2025-11-11T13:16:24.321Z <HassController:WARN> HassController#hass action x_hass_input_datetime.set_datetime({ "time": "10:45" }) on Entity#hass>input_datetime_vvb_dag failed!
[latest-25310]2025-11-11T13:16:24.321Z <HassController:INFO> Service call payload:
{"type":"call_service","service_data":{"date":null,"time":"10:45","datetime":null,"timestamp":null},"domain":"input_datetime","service":"set_datetime","target":{"entity_id":"input_datetime.vvb_dag"},"id":1762866984320}
[latest-25310]2025-11-11T13:16:24.322Z <HassController:INFO> Service data:
{"fields":{"date":{"example":"\"2019-04-20\"","selector":{"text":{"multiline":false,"multiple":false}}},"time":{"example":"\"05:04:20\"","selector":{"time":{}}},"datetime":{"example":"\"2019-04-20 05:04:20\"","selector":{"text":{"multiline":false,"multiple":false}}},"timestamp":{"selector":{"number":{"min":0,"max":9223372036854776000,"mode":"box","step":1}}}},"target":{"entity":[{"domain":["input_datetime"]}]}}
[latest-25310]2025-11-11T13:16:24.322Z <Engine:ERR> Engine#1 reaction rule-mgb8pfhs:S step 0 perform x_hass_input_datetime.set_datetime failed: [Error] Not a parseable type for dictionary value @ data['date'] [-]
[latest-25310]2025-11-11T13:16:24.322Z <Engine:INFO> Engine#1 action args: { "time": "10:45" }
[latest-25310]2025-11-11T13:16:24.322Z <Engine:INFO> Resuming reaction Sätt Schema VVB i Home Assistant<AKTIV> (rule-mgb8pfhs:S) from step 1
[latest-25310]2025-11-11T13:16:24.323Z <HassController:INFO> HassController#hass perform x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_natt with { "time": "03:00", "timestamp": 0 }
[latest-25310]2025-11-11T13:16:24.323Z <HassController:INFO> HassController#hass: sending payload for x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_natt action: { "type": "call_service", "service_data": { "date": (null), "time": "03:00", "datetime": (null), "timestamp": 0 }, "domain": "input_datetime", "service": "set_datetime", "target": { "entity_id": "input_datetime.vvb_natt" } }
[latest-25310]2025-11-11T13:16:24.324Z <HassController:ERR> HassController#hass request 1762866984323<2025-11-11 14:16:24> (call_service) failed: [Error] Not a parseable type for dictionary value @ data['date'] [-]
[latest-25310]2025-11-11T13:16:24.324Z <HassController:WARN> HassController#hass action x_hass_input_datetime.set_datetime({ "time": "03:00", "timestamp": 0 }) on Entity#hass>input_datetime_vvb_natt failed!
[latest-25310]2025-11-11T13:16:24.324Z <HassController:INFO> Service call payload:
{"type":"call_service","service_data":{"date":null,"time":"03:00","datetime":null,"timestamp":0},"domain":"input_datetime","service":"set_datetime","target":{"entity_id":"input_datetime.vvb_natt"},"id":1762866984323}
[latest-25310]2025-11-11T13:16:24.324Z <HassController:INFO> Service data:
{"fields":{"date":{"example":"\"2019-04-20\"","selector":{"text":{"multiline":false,"multiple":false}}},"time":{"example":"\"05:04:20\"","selector":{"time":{}}},"datetime":{"example":"\"2019-04-20 05:04:20\"","selector":{"text":{"multiline":false,"multiple":false}}},"timestamp":{"selector":{"number":{"min":0,"max":9223372036854776000,"mode":"box","step":1}}}},"target":{"entity":[{"domain":["input_datetime"]}]}}
[latest-25310]2025-11-11T13:16:24.324Z <Engine:ERR> Engine#1 reaction rule-mgb8pfhs:S step 1 perform x_hass_input_datetime.set_datetime failed: [Error] Not a parseable type for dictionary value @ data['date'] [-]
[latest-25310]2025-11-11T13:16:24.324Z <Engine:INFO> Engine#1 action args: { "time": "03:00", "timestamp": 0 }
[latest-25310]2025-11-11T13:16:24.325Z <Engine:INFO> Resuming reaction Sätt Schema VVB i Home Assistant<AKTIV> (rule-mgb8pfhs:S) from step 2
[latest-25310]2025-11-11T13:16:24.325Z <Engine:INFO> Sätt Schema VVB i Home Assistant<AKTIV> all actions completed.
Hello,
I currently have an office light (connected via a Leviton Zwave Dimmer switch) controlled from a Gen5 Aeotech Zwave switch installed on my Synology 720+ NAS. I run HA(2025.11.10) in a virtual machine from my NAS and Reactor on the container manager of the same NAS. Prior to updating to 25304 the rule I had set to turn the light on to a specific dimming value worked correctly. Now the rule appears to follow the decision tree, however the reaction does not trigger setting the dimming or turning on the office light?
Strangely I can still turn the light on and off as well as dim it directly from HASS..? I have tried using the ''try this action'' button in the rules reaction setting and it will not control the light and does not throw an error flagÉ
Please help,
P.S
Reactor has been rock steady for me over the last few years and I'm a big fan of this solution.
I don't know if you guys are into dashboards, but I am.
For a second home I tried the Shelly Wall Display 2, and while not so big, it worked well over the summer.
Since we're remodeling our house, I just swapped my old Fire Tablet (with its own problems) with two new Shelly Wall Display XL. I just removed the standard firmware, and I added mine (https://github.com/dbochicchio/ShellyElevate), forked from https://github.com/RapierXbox/ShellyElevate
I just managed to support buttons (this thing has 4 of them) and it's all auto-discovered by Home Assistant and accessible via Reactor.
I also have a new build in the works with support for buttons inside HA.
I added a bonus Javascript interface sending events (screen/screensaver status, buttons, motion) to automatically drive the dashboard (all doing in HTML+Javascript and monitoring Reactor's variable).
This specifical thing excluded, go get one of them, the device has a decent CPU for HA dashboards and blends wonderfully in the decor.
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 ?