First question, are they battery devices or mains powered? If battery, you may need to wake them up first.
If a device can’t be reached or is not longer updating on the Devices page, the best course of action is to first attempt to power cycle the device itself, or exclude the device then re-include it. Running a repair on dead nodes can result in failure of entire mesh.
I had this same multiple node failure, but luckily a C7 reboot brought them all back as expected
Thanks for that info. Some of the nodes that failed are battery powered (Zooz 4in1 sensor, etc) but several (Zooz Zen15 for example) are online and reporting. I can turn the device on and off through the app so why does HE say the repair failed?
When an individual Z-Wave repair is started on this device (15) the dialog box says Refreshing Node States, then Repair is pinging the node, then Repair is running, then Repair timed out updating neighbors.
This Zen15 is connected to the refrigerator in the kitchen. It would be a pain in the patootie to slide the built in fridge out, so if a Z-Wave exclude/include is required, trim moldings would need to be removed to slide the fridge out.
Just noticed another failed node (37) on the list is also a Zen 15 connected to the basement refrigerator. This too is reporting and can be turned on and off from the app yet it also timed out updating neighbors.
Another mains powered node that failed is 1C which is an Aeotec Smart Switch 6.
I have rebooted the C7 to no avail. Hesitant to power cycle the C7 because rebuilding the ZigBee mesh takes a while, and devices that have increased the WAF will be offline. 
As you pointed out, repair times out trying to update unresponsive neighbors. The most tedious task is identifying and resolving the problem with unresponsive devices, before attempting to run a repair. Repair process removes the existing routing paths, then tries to rebuild them using nearby devices. If these nearby devices are not responding to the hub's wake up call, then repair fails.
Does "nearby" mean physically near or just near in terms of what the hub thinks is near based on the routes created during inclusion (and subsequent updates)?
I think there is a lot of confusion about this.
In my experience, physically has nothing to do with it. Seems to be based on what the hubs knows with some black magic thrown it.
1 Like
2 Likes
Yes that's my point I guess.. It can be confusing if you have devices that are physically near and no routing takes place through them. This would be a reason why.
As an aside - 2 days ago I added a Ring repeater (paired S2) and a side porch light stopped responding to commands until I manually toggled it on/off. Seems like there is some fragility to the ZW mesh - I'm not sure it's HE though - might be the device itself having issues adjusting to routes maybe.
I may be imagining things, but it lloks to me that some devices may be impatient when they request an update from the neighborhood, and I’m wondering if the S2 overhead or response schema may be part of the issue. It took me quite a while to get a few of my dimmers (without security) to recognize the fact that a Ring extender (which requires S2) was on the mesh (they were actually the strongest signal when measured from the dimmer’s perspective).
My experience too.. at my client's house the repeaters are finally starting to repeat - one device has like 19 devices routing through it. It took a couple of months for this to happen though.
So in a lame attempt to bring this back to the topic all of this can impact the mesh and running a full Z-Wave repair seems like the "nuclear" option that could take weeks to completely resolve ..
Exactly
2 Likes
I’m not above a targeted (device level) tactical strike when it seems appropriate, but it is generally one of the last options.
1 Like
Technically speaking, the hub itself plays no role in mesh maintenance. The "magic" happens between the radio and devices. Check out the training module we just added to the post you shared above. As much as we all wish that things were straight forward and simple, in reality Z-Wave mesh maintenance and performance depends on a multitude of variables.
1 Like
Thanks just watched it from the beginning! Very interesting.. thank you.
So it looks like the controller's static routing table only gets updated when including/excluding/replacing devices or doing a "neighbor update" which is a full "repair" I guess. Also when doing a full repair it does do low power pings to nearby devices to determine neighbors. I don't know if this is just the controller or all powered "mains" devices but that kinda shoots down my idea about lack of physical neighbor awareness I guess.
The other takeway is it can take up to 30 seconds for a device's routes to get discovered. This means potentially super long full repairs and also more patience required during pairings..
Keep in mind that Z-Wave protocol has limited number of hops a device can jump through, so by default, a device will route through the furthest device, that is closest to the hub.
2 Likes
Ah right - forgot about that, you want to minimize hops as well.. good point.
IMHO nuclear is resetting the radio.
1 Like
They are both nuclear. Resetting is quick death, repairing an unhealthy mesh is the slow and painful death.
3 Likes
That’s the part that I keep forgetting. Looking at it in that light there may be 1 or 2 repeaters that could be moved......Hmmmm
1 Like
