Myth-buster edition: True Or False?
"Z-Wave Repair" is a tool that should be used to resolve any problems with failed and unresponsive devices.
- True
- False
0 voters
Thank you for taking the time to vote. Please check back for the correct answer!
Myth-buster edition: True Or False?
"Z-Wave Repair" is a tool that should be used to resolve any problems with failed and unresponsive devices.
0 voters
Thank you for taking the time to vote. Please check back for the correct answer!
With results in from various social media outlets, here is what people believe the right answer should be:
31% thought true is correct answer
47% thought true is correct answer
28% thought true is correct answer
And the right answer is: FALSE
And here is why:
According to Bryan Copeland, our Z-Wave specialist, for the repair process to work, the hub must be able to reach the device. The first task of the repair is to request the list of neighboring devices from the device itself, so that optimal routes can be determined.
If the device can't be reached, the repair does nothing. That’s why we always ping the node before attempting repair.
With that being said, it is possible that a device may become unreachable due to mesh routing errors. In this case, the repair process may be possible after all the neighboring devices are repaired first. Hubitat Elevation attempts to perform this automatically as illustrated below:
Node 15 & 16 failed initially:
Hubitat Elevation attempted to repair the failed nodes and the process was successful:
If a node (device) can’t be reached or is no 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.
For more details on Z-Wave Repair, check out below document: Anatomy of a Z-Wave Repair | Hubitat Documentation
....was the question purposely worded this way?
Are we assuming z-wave problems (since we're talking about Z-wave Repair), or any device problems, since the question litereally says that?
Are we assuming this is an initial way to resolve the issue, or something in a chain of things to try?
This seems like a trap...
Another thing is that certain ZWave devices to not participate in the ZWave repair process. They are also not repeaters. I notice that my ZWave siren and smoke/co detectors never participate in the ZWave repair process. They are always skipped.
Stay tuned... Looking for this to change in future hub versions by intercepting the wake-up process at the hub level. So sleepy devices can be scheduled to repair on their next wakeup.
If true ("Z-Wave repair does nothing if the hub can't reach the device") this statement raise a series of questions for me. I'm not saying that with current standards it may be the case (and I realize that Z-Wave's inner workings re: routing have always been proprietary and have had to be reverse-engineered to be understood) but it doesn't seem reasonable. If so, how did/could Z-Wave ever work with pre-explorer frame devices?
Those devices would of course have to be joined near the hub, taken to their ultimate (and potentially out-of-range final location) and then cease to function. But 'per the book', that's when you are supposed to do a Z-Wave repair to restore connectivity. And classic Z-Wave worked in that environment, without explorer frames, thanks to Z-Wave repair.
Here's my rationale (my takeaway from things that I have read about Z-Wave in the past):
In a given Z-Wave mesh, some nodes are physically within direct radio range of the hub and some are not.
Devices that aren't NWI capable may have do initially be joined within range of the hub, and when relocated may lose radio connectivity with it. But all nodes in a viable mesh need to be within radio range of at least one other node (not necessarily the hub).
The hub needs to produce and maintain a table of adjacent nodes in order to generate (and distribute) optimal routes.
It gets the information it needs by broadcasting a command during Z-Wave repair which says (paraphrasing): 'Give a shout out, and send me a list of nodes that responded. They're your current neighbors'.
Nodes that aren't within direct radio range of the hub don't hear this command. But other nodes within their range have heard it.. and thus those 'out of reach' nodes are now brought into the loop when they get reported as some other node's current neighbor.
When the 'in range' nodes report an 'out of range' neighbor node, that outlying node can now appear in the hubs adjacency table. Z-Wave repair has done its job.
Without muddying the water with the explorer frame enhancements (which classic Z-Wave didn't use), what am I missing here?
I don't think anything in your post is in contradiction of (or contradicted by) anything in Bobby's post, but you seem to assume that "the hub can't reach the device" in his statement means "the device is not within direct radio range of the hub, but is within range of another device and otherwise is functioning perfectly", whereas I think Bobby is assuming the device is having other problems (hence power cycle device or exclude and re-include device before trying repair).
For the record, I'm down for a weekly Home Automation Myth-buster knowledge drop.
What happens after a total power outage? Does the mesh remember its settings and routes?
Possibly, but HE's advice "Adding devices near the Hubitat Elevation™ hub, then moving them to their final location may lead to dropped device and other issues down the road. Therefore, it is recommended to always join your devices in their final, intended location" -- quoted from How to Build a Solid Z-Wave Mesh - Hubitat Documentation ) isn't consistent with the way Z-Wave is designed to handle pairing of devices that don't use network wide inclusion. Those devices by definition have to be paired near the hub, not their final location. And when moved, the hub can't reach them, at least not without a functional Z-Wave repair.
Ive had many occasions where a device will not complete its repair (ie multi SUC messages, then timeout before moving on to next device), but it will still turn off/on and respond to a refresh. So its "working" and ought to be "pingable", but why cant it complete its repair?
At least one route gets saved in nonvolatile memory-- per Silicon Labs Z-Wave Network Installation and Maintenance Procedures User Guide : 'When a frame is sent, the route that was used successfully will always be saved in NVM as a Last Working Route (LWR) so the routing algorithm knows what route to try first the next time.'