@RBoy Whether you force delete a device from the mobile app or the web app (i.e. any of the different client applications) the end result will be the same. As you suspect the hub’s routing table is updated when a device is removed. Routes used by the hub to reach other devices will not attempt to use the forced deleted device as part of a route anymore (assuming the removed device had routing capabilities in the first place). However, the routes stored in the devices (used to route messages back to the hub) are not updated automatically. In practice this is usually not an issue because the device has up to three more routes stored in it that are used in case of route failures. If all of them fail then the protocol uses something called “explorer frames” to obtain a new route back to the hub automatically.
If you have made some significant changes in the network (i.e. removed/added a few devices) it may be beneficial to run a network repair operation. However, keep in mind that any sleeping devices (like sensors or anything battery powered in most cases) will not be awake to receive the updated routes during the repair operation unless you manually wake them up for the duration of the repair operation. This can be a bit labor intensive of course (to manually wake up all the sleeping devices) so if you are having trouble with a particular device then perhaps limit the manual wake-up do just those devices.
Just did another z wave repair. The process finished I was able to see the message Z-wave network repair finished.
Only one Unknown Device found (not 3 as before). Waiting for more instructions…
Thanks for running the repair again. We have the logs now and we are going to analyze internally.
One thing we see right away is that you do not have any “ghost” devices in your Z-Wave network. More specifically, for every Z-Wave device you see in any of our client UIs there is one (and only one) device represented at the protocol level. The logs do show that two of the devices did fail to execute one of the steps involved in the repair operation. However, your network health should still not be impacted as these failures correspond to optimization attempts and are not critical to complete.
What we are focusing on answering now is why the message you see in the app refers to “Unknown Device” when we are certain there are no actual unknown or “ghost” devices in the network.
Great news !! Thanks for testing and analyzing and letting me know that there are NO “ghost” devices in my Z-Wave Network. Waiting for your final answers regarding the Unknown Z-wave devices found during my Z-wave Repair process…
I have been trying to troubleshoot a Z-Wave device (which happens to be furthest away from my SmartThings V3 Hub) that is offline so I ran a Z-Wave repair. Like @dotan_shai , I too get an “Unknown device - failed to update mesh info” message, though just one in my case, with no other diagnostic info.
To try and learn more and understand my Z-Wave mesh, I installed a “Z-Stick 7” Z-Wave device and the “Z-Wave PC Controller” software which has allowed me to generate this Z-Wave topology map:
My troublesome device has NetworkId 27 (0x1B), outlined in green on the table. Apart from the SmartThings Hub (Id 1), it only routes to devices 29 (0x1D), 30 (0x1E), 31 (0x1F) & 32 (0x20), outlined in yellow. When I run a rediscovery process I get an error “nodes: 27 - 1 FAILED. Report Missing” which matches the “offline” status of the device in SmartThings.
I used the Advanced Web App to get the DeviceId for every Z-Wave device and then used the CLI to lookup the NetworkId for each device. I have accounted for every device in the topology apart from 29, 30, 31 & 32.
As all my Z-Wave devices are accounted for, and no unknown devices are shown, I suspect that these four devices:
are ghost devices that for some reason have not been deleted, even though I read above that the hub is supposed to find and delete them
are creating routing problems that are stopping my troublesome device from working
may have been devices that I struggled to setup a long time ago and then re-added without excluding them properly
So, can anyone help confirm the above and help me sort this suspected mesh routing problem?
Predicting that @nayelyz will ask the same questions put to @dotan_shai:
The email account registered in the forum is the same one I use for SmartThings
Do you have a Schlage Z wave lock by any chance? Those are notorious for failing during pairing, and leaving a partial entry in the node table. The fact that you have four potentially problematic nodes in sequence does make it feel like a failed pairing generated multiple entries.
You should be able to use “node view“ in the PC utility and get the device class, at least, of the problem devices.
No, I don’t have a Schlage lock, no locks at all. I assume these are the node device classes you mean, with the suspected ghost nodes outlined:
There are three “Switch Multilevel” devices listed there, a device class not used on any other devices. I suspect they may be related to a Fibaro in-wall switch that I remember having many problems setting up, hence potential multiple pairings with me not realising back then that I need to exclude the device first? I’m going back about 4 years though. That device eventually failed when one of the relays fused on, so I replaced it with a different Fibaro model. I don’t know what a “Virtual Node” is.
“Switch multilevel” is usually a dimmer, so that makes sense with a fibaro.
But “virtual node” z wave is a network management construct, usually used with a “bridge controller“ (which is a static controller with 128 reserved proxy devices that are listed as “virtual nodes“ by the primary controller). Note that a bridge controller is different from a “secondary controller” in zwave. We’re starting to see more of these with the Z wave 700 and 800 series (for example, the hubitat C8 uses virtual nodes for some networking administration). But AFAIK it’s unusual in a smartthings set up.
@nayelyz , make sure the engineering team knows this “unknown device” is reporting itself as a Z wave “virtual node,” not a SmartThings virtual device.
There are no Unknown devices in the SmartThings Advanced device list. I’ve been having some issues with slow triggers, but not sure if this is related. I’ve dumped the logs and enabled support access.
Hi, everyone. I shared your comments with the engineering team. They were checking this issue directly, so, in case they need more info, they’ll let you know.
In case it matters, when running a Z-Wave repair, I too am seeing an increase in Unknown Devices , though up from one to two in my case. Are there any expected causes of these messages? My four suspected “ghost” devices are still present in the Z-Wave topology map.
AlejandroPadilla
(Please contact @nayelyz or @Luis_Humberto_Medina )
33
Hi everyone the team commented they need more information, please if you can replicate the issue and send the hub logs, it will help in the investigation.
Just did Dump Hub logs from my hub. After performing Z-wave repairs twice. Both repairs were with Unknown devices.
Please let me if you can see my logs and need anything else.
Shai Dotan
Hello, when trying to repair the network, it seems to get stuck on either 1 Unknown device for hours, or reports many unknown devices and then fails.
Other issues leading me to attempt the repair: my locks always show 100% battery, though one has had the batteries die recently. I also frequently get missed notifications about locks opening and by whom. I have added a buffering device to no avail.
I have enabled support access to my smartthings account and downloaded my hub logs.
SmartThings Hub v2
Would greatly appreciate some help
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
36
Your lock is having classic packet loss. Add a buffering repeater close to your lock because the hub doesn’t do a good job of it. See this
Hi @RBoy thanks for your reply. I actually followed your advice about the repeater already, following another thread a few months back. Unfortunately I am still having the same issues, and the z-wave repair is showing all these “Unknown device” with failures to “update mesh info” and failure to “update route”
