Rule sometimes fails when a Z-Wave device is offline?

Rule Machine®
1

I have a rule setup to turn off multiple Z-Wave switches and plugs. It usually runs fine but occasionally does not turn anything off. I'm guessing this might be due to one of the Z-Wave devices being offline (plug unplugged completely, etc.), but it often works fine in this state too so I don't know. Is there some kind of timeout that might affect the rest of the actions?

Last night no devices in the Rule turned off. I ran the Rule manually this morning and everything turned off as expected. I have relevant portions of the log below but they don't seem to show anything.

SUCCESS

dev:27 2026-05-21 07:53:48.894 AM debug parse:zw device: 16, command: 2503, payload: 00 00 00 , isMulticast: false
dev:31 2026-05-21 07:53:48.864 AM debug supervision report for session: 5
dev:31 2026-05-21 07:53:48.859 AM debug parse:zw device: 1A, command: 6C02, payload: 05 01 02 , isMulticast: false
dev:30 2026-05-21 07:53:48.806 AM debug supervision report for session: 13
dev:30 2026-05-21 07:53:48.805 AM debug parse:zw device: 19, command: 6C02, payload: 0D FF 00 , isMulticast: false
dev:29 2026-05-21 07:53:48.763 AM debug supervision report for session: 62
dev:29 2026-05-21 07:53:48.761 AM debug parse:zw device: 18, command: 6C02, payload: 3E FF 00 , isMulticast: false
dev:28 2026-05-21 07:53:48.720 AM debug supervision report for session: 1
dev:28 2026-05-21 07:53:48.719 AM debug parse:zw device: 17, command: 6C02, payload: 01 FF 00 , isMulticast: false
dev:27 2026-05-21 07:53:48.506 AM debug supervision report for session: 1
dev:27 2026-05-21 07:53:48.500 AM debug parse:zw device: 16, command: 6C02, payload: 01 FF 00 , isMulticast: false
dev:31 2026-05-21 07:53:47.007 AM debug re-sending supervised session: 5
dev:30 2026-05-21 07:53:46.969 AM debug re-sending supervised session: 13
dev:29 2026-05-21 07:53:46.913 AM debug re-sending supervised session: 62
dev:28 2026-05-21 07:53:46.883 AM debug re-sending supervised session: 1
dev:12 2026-05-21 07:53:46.839 AM debug re-sending supervised session: 1
dev:27 2026-05-21 07:53:46.704 AM debug re-sending supervised session: 1
dev:31 2026-05-21 07:53:41.983 AM debug new supervised packet for session: 5
dev:31 2026-05-21 07:53:41.976 AM debug off()
dev:30 2026-05-21 07:53:41.944 AM debug new supervised packet for session: 13
dev:30 2026-05-21 07:53:41.943 AM debug off()
dev:29 2026-05-21 07:53:41.894 AM debug new supervised packet for session: 62
dev:29 2026-05-21 07:53:41.892 AM debug off()
dev:28 2026-05-21 07:53:41.865 AM debug new supervised packet for session: 1
dev:28 2026-05-21 07:53:41.864 AM debug off()
dev:12 2026-05-21 07:53:41.818 AM debug new supervised packet for session: 1
dev:12 2026-05-21 07:53:41.808 AM debug off()
dev:27 2026-05-21 07:53:41.640 AM debug new supervised packet for session: 1
dev:27 2026-05-21 07:53:41.631 AM debug off()

FAILURE

dev:31 2026-05-20 11:00:06.188 PM debug re-sending supervised session: 1
dev:30 2026-05-20 11:00:06.145 PM debug re-sending supervised session: 1
dev:29 2026-05-20 11:00:06.079 PM debug re-sending supervised session: 58
dev:28 2026-05-20 11:00:06.035 PM debug re-sending supervised session: 52
dev:12 2026-05-20 11:00:06.005 PM debug re-sending supervised session: 51
dev:27 2026-05-20 11:00:05.820 PM debug re-sending supervised session: 54
dev:31 2026-05-20 11:00:01.168 PM debug new supervised packet for session: 1
dev:31 2026-05-20 11:00:01.161 PM debug off()
dev:30 2026-05-20 11:00:01.126 PM debug new supervised packet for session: 1
dev:30 2026-05-20 11:00:01.125 PM debug off()
dev:29 2026-05-20 11:00:01.060 PM debug new supervised packet for session: 58
dev:29 2026-05-20 11:00:01.058 PM debug off()
dev:28 2026-05-20 11:00:01.016 PM debug new supervised packet for session: 52
dev:28 2026-05-20 11:00:01.015 PM debug off()
dev:12 2026-05-20 11:00:00.974 PM debug new supervised packet for session: 51
dev:12 2026-05-20 11:00:00.963 PM debug off()
dev:27 2026-05-20 11:00:00.780 PM debug new supervised packet for session: 54
dev:27 2026-05-20 11:00:00.763 PM debug off()
2

It would help others understand and possibly help if you posted a screenshot of your rule.

4

If you have a Z-Wave device that is getting unplugged regularly, then it can cause problems w/that device, with devices that route through it, and your Z-Wave mesh in general. Your rule will still run regardless, but the Z-Wave devices may not behave properly (as noted).

Is there anything you can do to keep your Z-Wave devices plugged in/online consistently? That's where I'd start...maybe change any devices you can't keep connected to Z-Wave LR devices.

5

I will try to remove the offline ones from the rule for now and see if I have any more problems. Thanks.

6

That may or may not help, depending on whether the missing devices are messing up your Z-Wave mesh, which is a common issue when Z-Wave devices drop (intentionally or otherwise) from your Z-Wave mesh. Removing them from the automation does not address any issues w/your Z-Wave mesh in general caused by their repeated absences.

What I'd actually recommend is you ensure all of your Z-Wave devices are plugged in/connected and keep them that way for a while and see if your issues go away. Might take a day or two for your Z-Wave devices to settle after you reconnect everything. Is there a reason why you can't leave everything connected for several days? Why are you disconnecting and reconnecting mesh devices (never a very good idea), if you don't mind me asking.

7

I have used Z-Wave for years but was just trying out some different switches in a few places.

This has me questioning the robustness and reliability of Z-Wave. I didn't know one missing node could bring down the whole network. I assumed it would be able to take different paths. I guess I don't understand the idea of the "mesh".

8

Z-Wave can adapt and adjust, re-route, etc., as you'd want/expect. It can also sometimes go haywire and mess up performance if you unplug a mains powered device w/out removing it from your mesh. Varies...I've had devices off my mesh on and off, but one at a time, I've never removed several doing a swap like you describe...that would be expected to cause the most churn as you're changing available routes back an forth across multiple devices. :man_shrugging:

If you swap in the new devices, wait a bit and confirm that you don't have any devices still showing routing through the devices you removed, then you should be good to then confirm the rule working.

9

I have an issue with two Zwave switches (Zooz Zen 15) that occaisionally drop off of the network. They are both in a rule that turns on/off my cameras depending on the mode. When when one dropped off, neither would work on the off or on action in the rule. I found that separating them into two actions at least let the one that was connected to operate.

(Note: the occurence is rare enough that I haven't been able to figure out the cause - power cycling the switches brings them back. Usually, I only notice because the rule fails to work - maybe once every 6 to 9 months)

10

I think it's telling that the latest is Long Range Z-Wave, which does away with the "mesh" entirely. I replaced most of my stuff (not a cheap thing) but it's quite robust.
edit: Then again, maybe it's just because they're new, lol.

11

Most of my devices are LR so I might re-connect everything that way if I continue to have problems. Do you lose any functionality going LR?

12

Nope. As long as the device can reach the hub.

14

Put my Z-Wave devices back, did a “Network Rebuild” in Hubitat settings, and the Rule still failed. I guess I will now try LR or just switch to the Wi-Fi Matter devices I was trying out since they seem pretty reliable and have more control flexibility.