Adjusting quite a few lights at the same time seems to make the whole thing somewhat unresponsive (what I came to be calling "a z-wave storm"). At the same time some of the commands just don't get executed and the lights stay on (or off if I am turning them on). Just to show what I am talking about - pic below. Are there any best practices out there to sequence the commands, or time them properly to minimize this effect and ensure every light executes the command it's given?
1 Like
I don't know node red, but locally you could just use group lighting with a single trigger
3 Likes
Here is a simple app from @bravenel that turns off a number of devices with retry....
It works well for me.
3 Likes
Wow. You are hitting you z-wave network (if that is what these devices are) with a storm of commands.
Personally I don't think it is surprising if commands get dropped.
I had something similar (nowhere near as much though) that would be very intermittent.
I split mine up into groups of 5 devices.
First five, delay 1 sec, next 5, delay 1 sec, next five etc. etc.
I now have no issues.
Might be worth a try.
4 Likes
as @rlithgow1 said, use groups. i use groups to segment different areas in my home, and even the entire home as a whole, and haven't had any issues (knock on wood) with controlling the group
2 Likes
I suggest that you add a Device Node then a Switch Node in front of each Command Node to determine if the light is already off so that commands will only be sent to devices that are on. Make sure to uncheck the Send Events box.
1 Like
Umm, wouldn't requesting a device state create another data shitstorm going through the network, or the current values are somehow cached and not requested directly from the nodes?
Z-wave devices communicate at 9.6 - 100 kbps with a latency of 2-3 seconds. Zigbee devices communicate at 40-250 kbps with a latency of 10-20 milliseconds. If you are trying to get multiple devices to function at the same time, Zigbee is the better protocol, but there are still limitations.
I am pretty sure that you do not want to go to the expense and effort of replacing your Z-wave devices. However, I suggest that you might need to lower your expectations about the time required to turn things on and off. You might even want to set your rules so the devices turn on and off in a wave rather than trying to turn them all off at the same time. That may help with corrupted communications. If multiple z-wave devices try to communicate at the same time, the interference is likely to produce errors.
1 Like
Fortunately not. The current values are already in Node Red as seen below the Device Node.
2 Likes
Alright, so I ended up doing a lot of this... It works, I guess, makes NR more bloated, but works in the real world so all good. On a side note - I could never get groups working properly - one or 2 lights would always flake. And I didn't have too much patience with tweaking "optimize" or other settings in the group to see if it fixes it.
I save the on/off state of each device as a flow or global variable. This makes subsequent sequences to control a large number of devices much simpler.
That's one way. The obvious downside is that you are creating a 2nd source of truth, which will get outta sync with the original (and yes, it's not the question of if, but when).
Not if your flows are coded correctly. Haven't had this issue in 3.5 years of using Node-RED. But, as with anything else, YMMV.
This is my experience:
I have a bedside Zen34 wireless switch that turns on/off 44 light switches and outlets, all Z-Wave, in the house, plus some virtual switches.
It takes about 6 seconds to do its thing. It's kind of cool hearing all the clicks.
I like to cycle it once in a while, just for the "exercise". I think it does it some good.
Walking around the house, it's extremely rare that a switch is missed.
I use Simple Automation. No fancy sequencing.
Ooops: Didn't notice this was a Node-Red topic.
Well, noticed this just yesterday. And it was not Node-Red per se, but a general incorrect status. One of my switch for some reason showed OFF while the damn light connected to it was evidently ON. Issuing an OFF command would have just turned the switch off, since it's an imperative one, without a check. Adding a check basically fooled the system and the light never turned off.
Refresh command, of course, refreshed the state and the routine worked correctly after that, but this occurrence was quite emblematic of a problem where any stored state might and will de-sync from the device's actual state.
