Hi so I have a section of my z-wave mesh that's down currently due to power in the garage being out due to rain tripping a GFCI on a landscape light circuit. The result is all z-wave devices are acting super slow or not at all across the whole property. Im guessing the hub is slammed trying re-send commands to the down devices. So I figured I would disable the devices using the disable check box in the devices page, and then do a repair. I was surprised to see the repair procedure still tried to repair the disabled devices, ie it sat there trying to ping the down devices for ages before timing out and moving on the next device. (Should the timeout really be over 7 minutes for each device?)
In normal operation (ie outside of repair), shouldn't the hub detect down z-wave devices and work around them more smartly and gracefully than just totally hanging up the whole mesh trying communicate with them repeatedly?
Shouldn't z-wave repair respect the disabled devices flag and not try to repair them? I suspect the answer to this is the device disable is only at the device handler level and not at the z-wave stick level, so the disable flag isn't seen by the stick and it goes ahead and tries to repair everything IT knows about?
I suppose I could go ahead and force-remove the down devices, but I dont really want to have to do that and then go though the headache of excluding and re-pairing them once I get power back on.
Maybe just disabling them would have been enough to get the mesh traffic cleared up without needing a repair? Ill do some more testing and report back.
But once the zwave repair has occurred it should recognize the devices are not responding and put them into a deactivated mode ... Not sure if that happens only after several attempts to find them.
Perhaps a zwave guru can advise?
I was asking a similar question about my Christmas lighting controls
Seems after each time a change is made to the mesh it takes a while to heal. I think forced removal won't help because it doesn't actually remove them from the zwave table....
I had a similar question when i had some devices turned off and the advice from @bobbyD was you should remove them as z-wave doesn't play nicely with devices it thinks should be there. I think it different in zigbee as it will just find a different route but z-wave is more stubborn.
Ignoring ZWave Repair for a moment, think of Battery devices.. they can be asleep for an hour or more and despite having a few dozen of them, the mesh isn't slow, all day, every day. A/C powered devices are supposed to be there, unlike battery devices. But the only significant reason to send data to them is when they, or something they repeat for, is being sent commands.
For ZWave Repair, obviously they are going to be queried and waiting for a ping response isn't cpu or radio intensive.
The repair gathers each devices list of nodes it can hear. Not what it routes for, but what it hears. The Hub / stick builds a full route table and sends a custom snippet of the route table to each device. The snippet can contain as few as 2 routing nodes if there's a memory constraint in the device.
I've had a Fibaro RGBW module joined for 9+ months and powered off all of that time (once I didn't find adequate drivers) and when I powered it back up last month it was fine. (I ended up Excluding it then Including it because I wanted to verify it would auto find the driver since it's a beta driver.) I doubt that would work today because of changes made to discard 'ghosts'.
Thus my answer is related to my first couple of questions.. if you have a lot of automations trying to find devices that route through your garage, I'd expect plenty of traffic, and therefore a small slowdown. If your garage is similar to mine, there's not that much out that direction, and what there is, doesn't have much automation.
