Unlike sleepy Zigbee devices, sleepy Z-Wave devices maintain lists of routing-capable neighbors and need to be told to update them during a Z-Wave repair. So when a Z-Wave repair is done, if a battery operated Z-Wave device happens to be asleep at the time, it will be oblivious to the notification and you will see a 'xxx failed to update' message logged during the repair. The way of handling this is to do repeated Z-Wave repairs, at some point the sleepy device will hopefully be awake to receive the notification (I know, hope is not a strategy... welcome to Z-Wave!).
Seems a bit flaky, yet Z-Wave is pretty resilient when it comes to handling routing issues. It may look simple but it is amazingly complex under the covers. Though sleepy Z-Wave devices are not themselves routers, they initiate routed messages (directed to a routing neighbor known to them) and will retry multiple times specifically to this neighbor if no acknowledgement is received. This would allow the message to be retried via another neighbor in case of a failed transmission. A sleepy Z-Wave device has no notion of topology or distance; lower node ID's in its list of neighbors can get chosen in order of preference (supposedly some statistics can be used to choose them) but basically if something is a always-on neighbor it is eligble to be chosen as the first hop for a transmission. Until recently, the internals of how all this was done was considered proprietary Zensys information (SiLabs has made it available without a license fee now); Z-Wave wasn't conceived as an open peer-reviewed standard like Zigbee and a lot of how it works was inferred by reverse-engineering. For an idea of just how much complexity is involved in routing/retry, check out sec. 4.1.5 of The Z-Wave routing protocol and its security implications - ScienceDirect
In contrast, a sleepy Zigbee device (aside from broadcasts it initiates during a join or rescan) will only communicate to a single dedicated 'parent'; that parent is responsible for storing and routing the child messages. It's up to the parent to perform all routing on behalf of its child devices. The 'repeater' designation for a Zigbee router has always bugged me; it is responsible for much more than merely repeating in a Zigbee network. In addition to participating in routing for the mesh, each Zigbee parent node is kind of like a little post office-- accepting and storing messages for its specific child nodes becuase they are normally asleep with their radios powered down; checking in during periodic 'awake' intervals).
Z-Wave has no similar dedicated child/parent end-device relationship (though it also awakens periodically to listen). A Z-Wave battery operated device can have more than one routing neighbor accessible to it; it only receives data when it hears something relevant being broadcast during its wakeup interval-- if it wakes up before/after that transmission has occurred, another wakeup interval (and coincident transmission) has to elapse before the message is received. This has always sounded a bit too non-deterministic to me; and likely explains the need for a 'beaming device' in lock applications (something that will repeatedly hammer a Z-Wave lock with a transmission to increase the odds of low-latency operation). It also explains why I can 'refresh' my Zigbee contact sensor in the UI at any time and see within seconds the updated temperature information or contact status of the device. Can't do that as reliably with a similar device on Z-Wave; odds are my refresh command will be sent to the Z-Wave device and it will be asleep at the time.
As far as I know, a beaming device 'intercepts' the 'wake' from the sleepy device and responds with "YES, your hub wants to talk to you" -- allowing the sleepy device to get a much quicker response. The problem it solves is the sleepy device wakes, sends the "awake, got anything?" message to the Hub but before the Hub finds it's way to answer, the device is back asleep. Beaming tells the sleepy device to stay awake longer.. so that it is awake when the Hub responds.
I have been working with this toolbox and made a slight mess of my Z-wave network. When trying to get the unit working (learning curve). I added and removed it a few times. This create these devices that do not exist. I presume the toolbox is getting this info from the controller (HE). They were removing from HE "devices" (some force removed). I have also done several Z-wave repairs but the old devices remain. Is there a way to clear out the old bad entries?
I have the tool. In the past, not sure what happened, removing the tool using exclude will delete the node, but recently I had the same as your phantom nodes created by the tool, I have c4 hubs, the only way to remove them was using zensys, HE will not remove them. If you have c5 then it's a good question for @bobbyD , but anyway, it looks like no other nodes are trying to route through the phantom nodes.
I have C4. I just downloaded the zensys tool. Any documentation on how to remove them? From what I see it sounds like I need to shut down HE pull the Z-wave stick and put it in my PC running zensys and then open controller. Just wanted to find out as much as possible before I messed it up.
Also a device listed as DEV 6 is connected to just my 3 locks and nothing else. I do not have a device 6 anywhere. Wondering where it is coming from and why it is routed to my locks (just the locks)
The way I fixed them was to do a Z-wave repair, reboot the hub, and wait 24 hours. All the phantom nodes were then gone on the C4 hub.
The problem I have now with the Z-wave Toolbox it doesn't see new Z-wave devices. So had to remove/exclude it, did a rebuild of the mesh, rebooted, and am now waiting 24 hours before including on the Hubitat again.
One of my big gripes about the Z-wave Toolbox is that when you manually put in device names and save them, you have to do it again if you need to reconnect. I only have around 25 devices at this point, but there should be an export/import for the custom names.
Ok, that was exactly what I did but I still had the phantom nodes after various attempts, after like a week a did the zensys procedure. The tool is intended for an installer, one use, good bye, so probably that's the reason it will not update the devices, it just store the mesh data once when paired I believe, I been some time not using it so I don't remember very well how to use it.
I don't know about documentation, but checking the node until it's marked as failed then it will let you remove it. There is a button to check if the node is bad, another button to remove it.
Unfortunately that didn't work the last time I tried it on the Z-wave Toolbox. The 'connect to network' should put the Toolbox into inclusion mode. I've tried it starting the connect on the Toolbox first and the Hubitat include (or exclude) second and vice-versa (as you recommended). There's no consistency that I've been able to find so far when it will include/exclude successfully.
What version of the firmware is on your Z-wave Toolbox? Mine are at V. 1.3.4 which is the latest.
One thing that could be causing issues is that I currently (on purpose) have a VERY chatty Z-wave network.
How far is the toolbox away from the hub? You might want to consider to moving the toolbox closer to the hub if you are having issues removing/adding the tool box. Mine sits pretty much next to it as I am not testing for repeater placement anymore. I wonder if your pairing get's interrupted due to a "chatty" network...
I follow the above procedure (1. start to exclude, 2. press the connect button) each time I add a new Zwave device to HE and have no issues. You need to remove/add the tool box from HE so it can get the new device. The "Refresh Network" doesn't get the new devices.
Anyhow, the tool box joins HE as a non-repeating device. So, even if you have phantom left over device, it won't affect your mesh
The Z-wave toolbox is a foot and a half from the hub. Any idea on what the "Refresh Network" does do?
Being the epitome of lazy, I threw together a (poorly coded) Windows script that reads a text file that I use to document my Z-wave devices and have it send key the device names to the 'Control Panel' in 'Network Health' page so I don't have to retype or cut-and-paste them each time I include the Z-wave Toolbox.
When I have more time free, I'll play with the include/exclude a little more. Stray thought: maybe I can use one Z-wave toolbox to troubleshoot another one doing an include/exclude? I need to see what the packet analyzer potion shows during an include/exclude processes.
