How to turn off 19 Z-Wave devices reliably

🛎️ Get Help Devices
1

C7 with xxx.200 platform

I have have a very simple Rule that turns off 19 devices (all Z-wave, a mix of dimmers and switches) at a preset time. My problem is that occasionally one will stay on. It appears somewhat random which one is it.

Would turning off each one individually with perhaps adding a time delay between each turn-off help?

2

When I've had similar problems, I wound up doing something like this:

  • Turn all OFF
  • Wait 2 or 3 seconds
  • Turn all OFF again

making sure that "Command only switches that are on?" is turned OFF, so the commands are sent regardless of what state the hub thinks the switches are in.

2 Likes
3

Another similar option is to use the "All Off" app that is in the Hubitat public repo.......Architecture to solve not all lights turning off - #27 by bravenel

It is meant to turn off multiple devices with recheck. I use it and it has worked well for me.

5 Likes
4

I might check that out, thanks.

1 Like
5

This ^^^ Can kill anything. :slight_smile:

2 Likes
6

I’ll vouch for that! I use to use it as part of my good night routine, and it did a great job.

2 Likes
7

I use it to close a water valve that can sometimes be a bit recalcitrant...all off bangs on it a few times and it closes!

2 Likes
8

I have had similar issues with an all off and all on rule I created.

I learned a few things.

  1. it didn't happen that often, maybe 5-10% of the time one device would go rogue and not change state.
  2. Often (more than 1/2 the time) it was only the GUI that didn't state change when in fact the device did properly toggle. I created a refresh all rule and ran that to prove this out. Running the refresh rule corrected any state errors in the GUI.
  3. I have a rerun of all off commands at certain points of the day (1AM, 3AM) just to catch any prior devices which didn't switch off.

I found making a device state change is more truly "an attempt" to state change rather than a hardened handshake confirmed state change. Sometimes it just doesn't work and everyone blames the RF environment being fickle. Maybe so, but seems the handshaking in the request/ACK/confirm is suspect. I would think this handshaking could be hardened further without a lot of code/traffic (timers to wait for confirmation and if failed do a refresh, then a retry, perhaps with an exponential back-off ...). Vera told you when a command failed (red dot in the gui), Hubitat is much more capable so should be able to show when command has failed.

1 Like
9

If you're living in WebCore this is part of my Reboot. There is a System Start piston to match.
Slowly turn everything off before the reboot.

image
image1215×1020 41 KB

10

Yes, That's a key statement - ZWave, by default, is "unsupervised" communication - Basically, fire and forget, and hope the other end gets the request or update.. So my other recommendation, is to potentially enable S2 security on these 19 nodes, to get more error correction/CRCs that comes along with the encryption. It's not clear to me, if all your 19 devices support S2, and your still effectively flooding the Zwave mesh with a bunch of requests, and the expected state replies. So the weakest link is still likely to fail.

See: End Nodes: Guidelines for communication with S2+Supervision · Issue #5471 · zwave-js/node-zwave-js · GitHub & [GUIDE] Writing Z-Wave Drivers for S2

The other options, noted above, it either use the "All Off" app, or if you just want to do this in RM, send the command for all off (to with the switch enabled for just those devices that are on) - Then wait 2 secs, refesh all these nodes, to force a current state update, and then issue the same command above. Bottom line, and as you've learned, unsupervised Zwave (the default) isn't the most "reliable" network protocol, think UDP

Or better yet, move off ZWave to Matter, which is a more recent protocol that requires updates and handshaking to support the multi-admin function feedback. I'm guessing that's not an option for 19 devices, but YMMV

1 Like