@vezinpi
Thank you! That worked beautifully.
T
tamorgen
@tamorgen
Edit: Solved in latest-26221.
Bare-metal latest-26193
I have this group:
"OKforLarm":
name: OK för Larm
select:
- include_controller: vera
- include_capability: door_sensor
filter_expression: entity.attributes.door_sensor.state
It contains the entities I expect but behaves a bit odd. When I open vera>device_10097 the entity attribute door_sensor.state changes to true but it won't show up as member in the group, when I also open vera>device_10095 they both shows as members and when I close vera>device_10095 it disappear from the group but when I close vera>device_10097 it lingers in the group until I restart Reactor.
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.
Hey @toggledbits I'm back to trying to optimize a couple of things based on dynamic group.
First of all, I think I found a typo in the doc:
primary_attribute: "binary_sensor.state"
primary_attribute_value: |
d = false;
each id in members: d = getEntity(id)?.attributes?.power_switch?.state or d,
d
I think the correct code snippet is d = false,
All that said, my use case for dynamic groups is to group 3 different climate devices, so I could easily command them at the same time. Commands are good, but sometimes I want to check if any of the devices are on, and that's easily done with a similar snippet as the one you have in the docs. But this is limited to the primary attribute, while I want to have any of the attributes in the group to be driven by a similar logic (while all are null in the group). ie, access hvac_control.mode and see if any of the unit is set to cool, or heat. Is that possible, without re-defining an expression in each of my rules? Thanks!
Love openLuup - it just keeps working perfectly.
I started looking at trying to add a gen4 Shelly device to the Shelly plugin via L_ShellyBridge.lua. The plugin is a little uncooked (no rudeness intended), so a bit of a rabbit hole for me.
All of a sudden no console pages available in either Firefox or Chrome. AltUI works perfectly and all the log files indicate no errors. openLuup still running everything works as it should - just no console pages.
I possibly screwed something up but any recently changes files show no problems. The original/ backup of L_ShellyBridge.lua was reinstated but still no console.
Bit stumped on this one. Not sure how to debug. Any ideas?
Hey @toggledbits
One thing that bothers me while doing work on new systems/new features, is that I cannot copy&paste actions, and I cannot drag&drop between set and resets.
#1 is for when I want to copy an action between different rules opened in two separate browser windows, while #2 is when I just need to flip a bunch of actions in the reset, or move some logic back and forth.
Both will be appreciated, but I understand the technical challenges. Thanks!
I'm currently on version 26011. I understand that the aarch64 image is no longer supported. So, I therefore need to update to the ARM64 image. Can anyone possibly suggest how I update my docker compose.yaml file (see below). Ideally I'd like to keep my existing reactions etc. rather than start from scratch.
# Multi-System Reactor template docker-compose.yml (version 22160)
#
# Change the lines indicated by "DO"...
#
services:
reactor:
container_name: reactor
environment:
# DO change the TZ: line to set your local time zone.
# See valid TZ list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
TZ: GB
#
# DO NOT change this path. Your directory location is in "source" below.
REACTOR_DATA_PREFIX: /var/reactor
# DO change the image below to the one you are using (e.g. armv7l or aarch64 for RPi 4)
image: toggledbits/reactor:latest-aarch64
restart: "always"
expose:
- 8111
ports:
- 8111:8111
volumes:
# DO change the /home/username/reactor below to the directory you created for
# your local data; DO NOT change the /var/reactor part
- /home/pi/docker/reactor:/var/reactor
- /etc/localtime:/etc/localtime:ro
tmpfs: /tmp
It appears that Ezlo is going to new levels of paid subscription for cloud services supporting Vera hubs. I have to congratulate them. It will soon be 8 years since Ezlo acquired Vera, and despite their purported financial and "intellectual" capital, they have to date not produced a viable full replacement for Vera. Now they are going to charge extra for services for a platform that they stopped updating years ago.
If you know anyone who hasn't yet fully moved on from Captain Ahab's White Whale Chase, please remind them that my Decouple project is still up on Github to decouple a Vera Plus/Secure/Edge from Vera/Ezlo's cloud services. Veras have been said to misbehave when they can't reach the mother ship.
I have also written my first new Vera plugin in... six years? more?... the AlertPushover project will send Vera hub alerts to Pushover, so you can still get messages generated by your Vera hub without paying for Ezlo's cloud service. It's crude but functional (i.e. better than nothing/worth every penny paid).
These two projects won't replace the functionality of their cloud service and app for those who need those things. But any that don't, this may help bridge the gap. Hopefully these stragglers who have waited so long and been disappointed so often will get the idea that it's time to move on.
If you are using the armv7l docker image, the OpenJS Foundation that publishes node is no longer producing 32-bit builds as of v24. That means the last supported LTS version of node for armv7l is v22, which will go End-of-Life in May 2027.
Therefore, the Reactor armv7l image is now deprecated and will only be produced until node v22 goes EOL, and I will not publish armv7l images beyond that date.
If you are running an RPi 3 or earlier with Reactor, you are on this image, and will need to upgrade hardware to a 64-bit model and use the arm64 image. If you need help getting it done, ask in this category.
Posts
-
Arming Envisalink panel from MSR -
Arming Envisalink panel from MSR@toggledbits, thanks I did look for something like that, but I might be looking in the wrong place.
FWIW, my panel is an actual EyezOn panel (UNO IP Hybrid). I had an EnvisaLink 4 with a DSC panel that took a hit and I had to replace the unit. From a HAAS/MSR perspective, the interaction is identical.
-
Arming Envisalink panel from MSRGood afternoon all,
I have a question for anyone who has experience with MSR and Envisalink/EyezOn alarm panels. The integration works fine for the most part, but there is an oddity when MSR arms the system to away. I get a notification from in the EyezOn app that says the system was armed by the last user to DISARM the system. I'd like to arm it in a way that it arms by the the user that leaves the home, which triggers the automated Arm process. I tried to do it with a dedicated user code for MSR, but it doesn't arm with that user.
This is obviously more of an annoyance, as the alarm does get armed, but the audit trail is incorrect, so I don't know who armed it. Anybody have any insight?
running latest-26193-50401535 in Docker
-
Condition for trendUpdate. Worked perfectly. Thanks for setting me striaght!
-
Condition for trendOkay, I understand. For a minute I thought it there was a setting I needed to enable. I've set it up and I'll know if it works in the morning. Thanks for all the help.
-
Condition for trendOkay, thank you. That makes sense…. Other than deadband. What do you mean by that?
-
Condition for trendOkay, so maybe I'm missing something or not explaining my train of though here....
First, I'm not trying to control an exhaust fan, I'm trying to control the shower light. The exhaust fan has it's own built in sensor and . I'm using the humidity to determine that someone is taking a shower, so the light should remain on. When someone stops taking a shower, the humidity will drop (due to the automatic exhaust fan), and then the light can be turned off. I can't easily put a motion sensor in the shower, so the humidity sensor is the logical sensor. I've observed the values before, during, and after taking a shower, and generally, the humidity in that room is 30's or 40's, and when a shower is in play, it jumps up to the 70's or 80's.
I tried doing it with just one rule, but there really isn't a operand to change below a number. There is Changes from x to y, and then < or <=. If I just have a simple rule to say below 65%, then the light will go off before the humidity level rises. This is why I was trying to latch aspect, because generally when I step into the bathroom, I manually turn on the shower light, turn on the shower, finish, and inevitably the shower light get's left on, whether it's me or my wife.
I initially thought about the trend/time aspect, but I thought that for this purpose, that is actually over complicating things. All I really need to know is a) did the humidity level rise above point A, and b) did it drop below point B, in that sequence.
So, from my understanding, you are saying I just need to change the value fo the first condition to >= 65, and the second condition can stay at <= 65?
-
Condition for trendSo, for some reason, my Latch method isn't working. I see the humidity go above 70, and I see the first condition go true. When I'm done showering, and fan evacuates the excess humidity, it drops back down and goes below 65, and that condition becomes true.
The second condition has the restriction that it must occur after the first condition is met.
I guess the second condition resets the Latched condition, so both conditions aren't true at the same time?
Is there another way to do a first condition, then the second condition that I'm missing?
-
Condition for trend@toggledbits said in Condition for trend:
VirtualEntityController can sample another entity's data and do time-series aggregation (moving average, rate of change, etc.).
Thanks for that. I wasn't familiar with that, and it sounds like what I was initially looking for.
-
Condition for trendI think I may have figured out a way...
If I use a Latch condition when the Humidity goes above 60, and then another condition when it goes below 45 (dependent on the first condition being true first), that should give me the result I'm looking for; that being the shower isn't being used anymore, and the shower light can be turned off. Am I correct in my understanding of how Latch works, in that that condition will stay true until the Set Reaction triggers?
-
Condition for trendIs there a way to set a condition for a trending number? I just installed a Zooz ZSE44 Temp/Humidity sensor in one of my bathrooms. I wanted to set a condition based upon how quickly the Humidity sensor reports the humidity level trending down (say after a shower).
If you look at the graph below from the device, you can see the humidity spiking at 5 am, then dropping, then spiking again, then dropping. I'm trying to set up a condition when the level trends up or down quickly.
-
Set reaction triggering wrong z-wave device@toggledbits said in Set reaction triggering wrong z-wave device:
The name is incorrect at ZWave-JS (on the node itself) if that's the case, so to keep your sanity later, make sure you go all the way back to the source and work your way forward from there.
I renamed the devices on the ZWave-JS UI, so i won't have the problem going forward. I'm still not sure how this all happened, as I did not experience this problem in years past. The only thing I can think of is there was some sort of glitch in an upgrade. I know I had to restore the Z-Wave JS UI to an earlier version back in October because of a change they made that broke window coverings, so perhaps during that restore something went wonky.
-
Set reaction triggering wrong z-wave deviceThank you. Perhaps the non-updating of the name was the root cause of my issue all along.
-
Set reaction triggering wrong z-wave device@toggledbits said in Set reaction triggering wrong z-wave device:
. Can you confirm that in the startup messages for Reactor, ZWaveJSController reports it is version as 25304
Yes, it shows up as 0.1.25304
So, you seemed to have hit it. There is a disagreement in the names in the Z-wave JS integration and the Z-Wave JS UI naming. I'm not sure how or when that happened, since I haven't touched the naming of these in at least 2 years.
The device that is 136 is truly the Front Porch Sconces. Everywhere in the HA dashboards when I click on the binary switch, it does turn it on. Same with 137 being the Soffit Lights.
It would seem it's getting the names from the ZwaveJS UI values, since they seemed to be off. I've gone ahead and renamed them in ZwaveJS UI to reflect the values in ZwaveJS. How do I get ZWaveJSController to update the names? They still show up as the incorrect name. I went ahead and restarted MSR, and the old naming is till persistent.
-
Set reaction triggering wrong z-wave deviceI also just noticed that if I performed an action from the Entities page in MSR fr 137-0, it's turning on 136-0 in HAAS. If I turn on 136-0 through entities, it's turning on 137-0 in HAAS. It would appear these devices are somehow switching actions, despite everything showing what they are.
-
Set reaction triggering wrong z-wave deviceHere are some logs of me turning the entities on and off from HAAS.
root@docker:/home/tmorgenthaler/reactor/logs# tail -f zwavejs.log | grep 13'[6-7]'-0 [latest-26011]2026-01-31T20:37:00.403Z <ZWaveJSController:5:ZWaveJSController.js:1148> ZWaveJSController#zwavejs _apply_value entity Switch#zwavejs>136-0 power_switch.state [latest-26011]2026-01-31T20:37:00.403Z <ZWaveJSController:5:ZWaveJSController.js:1161> ZWaveJSController#zwavejs handling Switch#zwavejs>136-0 power_switch.state by { "valueId": "37:currentValue:" } with { "endpoint": 0, "commandClass": 37, "commandClassName": "Binary Switch", "property": "currentValue", "propertyName": "currentValue", "ccVersion": 2, "metadata": { "type": "boolean", "readable": true, "writeable": false, "label": "Current value", "stateful": true, "secret": false }, "value": true, "__endp": { "power_switch.state": { "entity": "136-0", "impl": { "valueId": "37:currentValue:" } } } } [latest-26011]2026-01-31T20:37:00.403Z <ZWaveJSController:5:ZWaveJSController.js:1252> ZWaveJSController#zwavejs setting Switch#zwavejs>136-0.x_zwave_values.Binary_Switch_currentValue to true [latest-26011]2026-01-31T20:37:00.648Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event statistics updated entity Switch#zwavejs>136-0 [latest-26011]2026-01-31T20:37:18.529Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event statistics updated entity Switch#zwavejs>136-0 [latest-26011]2026-01-31T20:37:18.553Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event value updated entity Switch#zwavejs>136-0 [latest-26011]2026-01-31T20:37:18.553Z <ZWaveJSController:5:ZWaveJSController.js:1252> ZWaveJSController#zwavejs setting Switch#zwavejs>136-0.x_zwave_values.Binary_Switch_targetValue to false [latest-26011]2026-01-31T20:37:18.559Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event value updated entity Switch#zwavejs>136-0 [latest-26011]2026-01-31T20:37:18.559Z <ZWaveJSController:5:ZWaveJSController.js:1237> ZWaveJSController#zwavejs updating attribute power_switch.state with { "entity": "136-0", "impl": { "valueId": "37:currentValue:" } } [latest-26011]2026-01-31T20:37:18.559Z <ZWaveJSController:5:ZWaveJSController.js:1148> ZWaveJSController#zwavejs _apply_value entity Switch#zwavejs>136-0 power_switch.state [latest-26011]2026-01-31T20:37:18.559Z <ZWaveJSController:5:ZWaveJSController.js:1161> ZWaveJSController#zwavejs handling Switch#zwavejs>136-0 power_switch.state by { "valueId": "37:currentValue:" } with { "endpoint": 0, "commandClass": 37, "commandClassName": "Binary Switch", "property": "currentValue", "propertyName": "currentValue", "ccVersion": 2, "metadata": { "type": "boolean", "readable": true, "writeable": false, "label": "Current value", "stateful": true, "secret": false }, "value": false, "__endp": { "power_switch.state": { "entity": "136-0", "impl": { "valueId": "37:currentValue:" } } } } [latest-26011]2026-01-31T20:37:18.560Z <ZWaveJSController:5:ZWaveJSController.js:1252> ZWaveJSController#zwavejs setting Switch#zwavejs>136-0.x_zwave_values.Binary_Switch_currentValue to false [latest-26011]2026-01-31T20:37:18.779Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event statistics updated entity Switch#zwavejs>136-0 [latest-26011]2026-01-31T20:37:25.647Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event statistics updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:37:25.803Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event value updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:37:25.803Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event value updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:37:25.804Z <ZWaveJSController:5:ZWaveJSController.js:1252> ZWaveJSController#zwavejs setting Switch#zwavejs>137-0.x_zwave_values.Binary_Switch_targetValue to true [latest-26011]2026-01-31T20:37:25.808Z <ZWaveJSController:5:ZWaveJSController.js:1237> ZWaveJSController#zwavejs updating attribute power_switch.state with { "entity": "137-0", "impl": { "valueId": "37:currentValue:" } } [latest-26011]2026-01-31T20:37:25.808Z <ZWaveJSController:5:ZWaveJSController.js:1148> ZWaveJSController#zwavejs _apply_value entity Switch#zwavejs>137-0 power_switch.state [latest-26011]2026-01-31T20:37:25.808Z <ZWaveJSController:5:ZWaveJSController.js:1161> ZWaveJSController#zwavejs handling Switch#zwavejs>137-0 power_switch.state by { "valueId": "37:currentValue:" } with { "endpoint": 0, "commandClass": 37, "commandClassName": "Binary Switch", "property": "currentValue", "propertyName": "currentValue", "ccVersion": 2, "metadata": { "type": "boolean", "readable": true, "writeable": false, "label": "Current value", "stateful": true, "secret": false }, "value": true, "__endp": { "power_switch.state": { "entity": "137-0", "impl": { "valueId": "37:currentValue:" } } } } [latest-26011]2026-01-31T20:37:25.809Z <ZWaveJSController:5:ZWaveJSController.js:1252> ZWaveJSController#zwavejs setting Switch#zwavejs>137-0.x_zwave_values.Binary_Switch_currentValue to true [latest-26011]2026-01-31T20:37:25.898Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event statistics updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:37:29.297Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event statistics updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:37:29.447Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event value updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:37:29.448Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event value updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:37:29.448Z <ZWaveJSController:5:ZWaveJSController.js:1252> ZWaveJSController#zwavejs setting Switch#zwavejs>137-0.x_zwave_values.Binary_Switch_targetValue to false [latest-26011]2026-01-31T20:37:29.453Z <ZWaveJSController:5:ZWaveJSController.js:1237> ZWaveJSController#zwavejs updating attribute power_switch.state with { "entity": "137-0", "impl": { "valueId": "37:currentValue:" } } [latest-26011]2026-01-31T20:37:29.453Z <ZWaveJSController:5:ZWaveJSController.js:1148> ZWaveJSController#zwavejs _apply_value entity Switch#zwavejs>137-0 power_switch.state [latest-26011]2026-01-31T20:37:29.453Z <ZWaveJSController:5:ZWaveJSController.js:1161> ZWaveJSController#zwavejs handling Switch#zwavejs>137-0 power_switch.state by { "valueId": "37:currentValue:" } with { "endpoint": 0, "commandClass": 37, "commandClassName": "Binary Switch", "property": "currentValue", "propertyName": "currentValue", "ccVersion": 2, "metadata": { "type": "boolean", "readable": true, "writeable": false, "label": "Current value", "stateful": true, "secret": false }, "value": false, "__endp": { "power_switch.state": { "entity": "137-0", "impl": { "valueId": "37:currentValue:" } } } } [latest-26011]2026-01-31T20:37:29.453Z <ZWaveJSController:5:ZWaveJSController.js:1252> ZWaveJSController#zwavejs setting Switch#zwavejs>137-0.x_zwave_values.Binary_Switch_currentValue to false [latest-26011]2026-01-31T20:37:29.547Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event statistics updated entity Switch#zwavejs>137-0 -
Set reaction triggering wrong z-wave devicesaid in Set reaction triggering wrong z-wave device:
I updated to v25304 and restarted Reactor. I'll run some tests now.
Alright, it still seems to be doing the same thing. I'm tailing the zwavejs log, and pressing the button for the Set Reaction. I see it pushing the command for 137-0, however, the soffit lights (136-0) are coming on.
root@docker:/home/tmorgenthaler/reactor/logs# tail -f zwavejs.log | grep 137-0 [latest-26011]2026-01-31T20:25:01.008Z <ZWaveJSController:5:ZWaveJSController.js:1237> ZWaveJSController#zwavejs updating attribute power_switch.state with { "entity": "137-0", "impl": { "valueId": "37:currentValue:" } } [latest-26011]2026-01-31T20:25:01.008Z <ZWaveJSController:5:ZWaveJSController.js:1148> ZWaveJSController#zwavejs _apply_value entity Switch#zwavejs>137-0 power_switch.state [latest-26011]2026-01-31T20:25:01.008Z <ZWaveJSController:5:ZWaveJSController.js:1161> ZWaveJSController#zwavejs handling Switch#zwavejs>137-0 power_switch.state by { "valueId": "37:currentValue:" } with { "endpoint": 0, "commandClass": 37, "commandClassName": "Binary Switch", "property": "currentValue", "propertyName": "currentValue", "ccVersion": 2, "metadata": { "type": "boolean", "readable": true, "writeable": false, "label": "Current value", "stateful": true, "secret": false }, "value": true, "__endp": { "power_switch.state": { "entity": "137-0", "impl": { "valueId": "37:currentValue:" } } } } [latest-26011]2026-01-31T20:25:01.009Z <ZWaveJSController:5:ZWaveJSController.js:1252> ZWaveJSController#zwavejs setting Switch#zwavejs>137-0.x_zwave_values.Binary_Switch_currentValue to true [latest-26011]2026-01-31T20:25:01.104Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event statistics updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:25:15.710Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs performing power_switch.on on Front Porch Lights (Switch#zwavejs>137-0) with { } [latest-26011]2026-01-31T20:25:15.973Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event statistics updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:25:16.125Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event value updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:25:16.125Z <ZWaveJSController:5:ZWaveJSController.js:1252> ZWaveJSController#zwavejs setting Switch#zwavejs>137-0.x_zwave_values.Binary_Switch_targetValue to true [latest-26011]2026-01-31T20:25:16.125Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event value updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:25:16.126Z <ZWaveJSController:5:ZWaveJSController.js:1237> ZWaveJSController#zwavejs updating attribute power_switch.state with { "entity": "137-0", "impl": { "valueId": "37:currentValue:" } } [latest-26011]2026-01-31T20:25:16.126Z <ZWaveJSController:5:ZWaveJSController.js:1148> ZWaveJSController#zwavejs _apply_value entity Switch#zwavejs>137-0 power_switch.state [latest-26011]2026-01-31T20:25:16.126Z <ZWaveJSController:5:ZWaveJSController.js:1161> ZWaveJSController#zwavejs handling Switch#zwavejs>137-0 power_switch.state by { "valueId": "37:currentValue:" } with { "endpoint": 0, "commandClass": 37, "commandClassName": "Binary Switch", "property": "currentValue", "propertyName": "currentValue", "ccVersion": 2, "metadata": { "type": "boolean", "readable": true, "writeable": false, "label": "Current value", "stateful": true, "secret": false }, "value": true, "__endp": { "power_switch.state": { "entity": "137-0", "impl": { "valueId": "37:currentValue:" } } } } [latest-26011]2026-01-31T20:25:16.126Z <ZWaveJSController:5:ZWaveJSController.js:1252> ZWaveJSController#zwavejs setting Switch#zwavejs>137-0.x_zwave_values.Binary_Switch_currentValue to true [latest-26011]2026-01-31T20:25:16.224Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event statistics updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:25:33.510Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event statistics updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:25:33.661Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event value updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:25:33.661Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event value updated entity Switch#zwavejs>137-0 [latest-26011]2026-01-31T20:25:33.662Z <ZWaveJSController:5:ZWaveJSController.js:1252> ZWaveJSController#zwavejs setting Switch#zwavejs>137-0.x_zwave_values.Binary_Switch_targetValue to false [latest-26011]2026-01-31T20:25:33.666Z <ZWaveJSController:5:ZWaveJSController.js:1237> ZWaveJSController#zwavejs updating attribute power_switch.state with { "entity": "137-0", "impl": { "valueId": "37:currentValue:" } } [latest-26011]2026-01-31T20:25:33.666Z <ZWaveJSController:5:ZWaveJSController.js:1148> ZWaveJSController#zwavejs _apply_value entity Switch#zwavejs>137-0 power_switch.state [latest-26011]2026-01-31T20:25:33.666Z <ZWaveJSController:5:ZWaveJSController.js:1161> ZWaveJSController#zwavejs handling Switch#zwavejs>137-0 power_switch.state by { "valueId": "37:currentValue:" } with { "endpoint": 0, "commandClass": 37, "commandClassName": "Binary Switch", "property": "currentValue", "propertyName": "currentValue", "ccVersion": 2, "metadata": { "type": "boolean", "readable": true, "writeable": false, "label": "Current value", "stateful": true, "secret": false }, "value": false, "__endp": { "power_switch.state": { "entity": "137-0", "impl": { "valueId": "37:currentValue:" } } } } [latest-26011]2026-01-31T20:25:33.666Z <ZWaveJSController:5:ZWaveJSController.js:1252> ZWaveJSController#zwavejs setting Switch#zwavejs>137-0.x_zwave_values.Binary_Switch_currentValue to false [latest-26011]2026-01-31T20:25:33.760Z <ZWaveJSController:5:ZWaveJSController.js:948> ZWaveJSController#zwavejs handling node event statistics updated entity Switch#zwavejs>137-0I also see the results of turning off the device from HAAS in the ZWaveJS logs.
Here are the entries for the devices in HAAS from ZwaveJS-UI
Screenshot 2026-01-31 at 3.29.10 PMI've also creating an attirbutes text file for 136-0. Maybe something is funky in that entry.
-
Set reaction triggering wrong z-wave devicesaid in Set reaction triggering wrong z-wave device:
I wasn't sure if I was on the correct release or not. Does the Docker image include the Zwave release in the pull?
Never mind. It's says it does not in your documentation.
I updated to v25304 and restarted Reactor. I'll run some tests now.
-
Set reaction triggering wrong z-wave deviceI wasn't sure if I was on the correct release or not. Does the Docker image include the Zwave release in the pull?
-
Set reaction triggering wrong z-wave deviceI should also note that I compared/verified in HAAS/Zwave-JS the entity numbers are correct and correspond with what is in MSR.