If a device is offline then it’s routing tables cannot be updated. It’s best to have all devices online or exclude / delete offline devices and pair them again.
Thanks - But I don’t even know what devices it is looking at. All my devices are powered. And I have 13 ghost devices, making my legacy z-wave devices all go offline. So what should I do now?
Do you know the device network ID’s of your 13 ghost devices? If so you can follow the steps in the first post to get rid of them.
1 Like
Thanks. I did that - but they keep popping back up with the same network ID. Any other ideas?
Additionally, now exclusion now does not work from the app for those devices. Maybe because they are offline?
Some times you just have to call Support. They were the only way I could get rid of two failed Z-wave repeaters (associated with the Iris plug) that ghosted.
Why would a Z-wave device not show the route? I have one Z-wave outdoor plug device who’s table rows go from Last Updated to Data. No “Route” or “Metrics” row showing like on all the other devices.
The route that you see in the IDE is the last used route. So if it hasn’t been used for a while, or it’s a brand new device, it might not show up.
Not working, it use to work, not anymore…
This was a timely reminder, as I worked to remove a few ghosts. At first, I was impatient and kept repeating the prescribed method (create/delete/repair). This time, I waited overnight for each device to be exercised and updated. Looks like it is fully healed now.
3 Likes
Tried to remove 2x devices yesterday as well, let it sit overnight, they never showed up as issues in a repair, but this morning they are still in my system.
Might something have changed for this trick to no longer work?
1 Like
i just did this and it worked, and for the first time in months the routes on all my devices updated paths !!! they would not updated there paths with this error in here
response time to my faraway locks is better - not great - but much better
i ran z-wave repair from the IDE and it completed and i don’t see ghost devices in the routes anymore. but still some routes are plain stupid. i’m almost surprised that there isn’t a device that routes around the house 10 times thru all the devices.
Thankfully that won’t happen since the Z-Wave specs have a hard limit on a maximum of 4 hops; plus it also implements an algorithm to prevent “looping”. There’s a big advantage to having beaming repeater between your battery operated z-wave device and the hub. Having other beaming repeaters in the mesh is also helpful to create alternate paths. Unfortunately due to signal reflections and other quirks the mesh may not always choose the most optimal path (which is what you’re seeing, the last used path), but that may change since it’s a “mesh” and not bound to a single path (thankfully again).
Here’s another topic which may give some pointers on how to improve the performance of the z-wave mesh. FAQ: How to improve the performance (responsiveness, speed) and reliability of a Z-Wave mesh
1 Like
Yup, that’s allowed, 4 hops. This just represents the last path followed, not necessarily the only path or the optimal path. The next time it could take a different path. Doing a Z-Wave repair may change the optimal path it takes.
Here’s a simple example of what the mesh routing table looks like:
Now if 5 wants to talk to the hub (1), then it can go through 5 → 4 → 3 → 1 or it can go 5 → 2 → 1 or it can go 5 → 3 → 1 etc. So it has multiple options. It’s possible the packet may be go through more than one path and the hub will only accept the first one it receives.
So what the IDE is showing you is the first packet that was received which may not be the same path it takes the next time. This can happen for MANY reasons, some of which were explained the link on the last post.
3 Likes
Understood, its just funky knowing al the other devices near it. Been dealing with trying to remove 3x ghost devices that dont want to delete. Currently have ST Support looking at it. Z wave repair ran a few times but no change to this device yet. We’ll see if anything changes after the ghost devices are removed!
I’ve seen some unusual paths too. For example here is a rough layout of how some of my devices are in relation to each other.
Device 4 usually follows the path of 4 > 1 > Hub. That makes sense because there is a lot of physical house material between 4 and the hub. There is more open air going between 4 > 1 and then between 1 > Hub.
But, device 5, shows a path all the way around:
5 > 4 > 3 > 2 > 1 > Hub. Crazy that it wouldn’t show the same path as 4 since it talks to 4.
Normally 3 > 1 > Hub is a common path, but I have seen 3 go directly to the hub at times. Even more strange I’ve seen #2 > 4 > Hub. Completely skipping 1.
Routes seem to change on a whim from time to time.
Which is the expected behavior. A mesh has multiple paths form one device to another (by design to create redundancies). As I had mentioned in my post above:
It can pick any path from it’s routing table to and each repeater along the way can change that path so it can change from one packet to the next. The topic helps identify a ghost devices in the mesh and get rid of it since it can cause delays, loss of packets and performance issues. Using the last used path is one way to identify potentially impacted devices and ghost devices. The ideal way is to do a full z-wave repair and look at the device events to identify every ghost device in the controllers table (explained in detail in the first post).
Theres no way to force the device to use the optimal path everytime (although the mesh is supposed to do that). But what you’re seeing is a possible fallout of the mesh repair operation which is saying that there may be interference (radio or physical or reflections etc) between some devices which is causing the mesh to use a longer path instead of the shortest path.
So in your scenario, the device may have sent the packet 3 > 1 > Hub and then also 3 > Hub but the 3 > Hub packet never reached the hub and but the 3 > 1 > Hub packet did reach the hub. That would indicate to me that there’s a problem with the 3 > Hub path. There could a number of reasons, for example
- If 3 is a battery operated device (sleepy or FliRS), then that may explain it since the hub doesn’t do a good job of buffering packets, which leads to a loss of the packet and eventually the
3 > 1 > Hubpacket reaches the hub - There could be radio interference or a physical object causing the signals to bounce/reflect which then causes interference between 3 and the Hub thereby making it choose the alternate route or the packet sent via the alternate route reaches the hub eventually.
So what is really is telling you is to investigate why the mesh would take a longer path when there are shorter alternate paths available.
HERE IS A FIVE HOP ROUTE (or is it counted as four?):
1D to hub is about 20 feet unobstructed line of sight.
So my point stands, i’m surprised some routes don’t circle the house 10 times… guess that is why they built a limit in because it would happen…
Z-WAVE LAYOUT of listening devices, minus sleepy devices. WITH SOME EXAMPLE ROUTES:
all i got to say is zigbee is sooo much better… knock on wood! all my zigbee route complete within one hop and more then half are direct to hub.
1 Like
for your scenario, in my network it would be 5->6->2->4->3->1
another scenario for my network would be this: lets say the hub is 2 and it want to talk to 5
2->1->6->3->4->2 and what would be wrong with a straight thru route 2->5
the z-wave stack SmartThings is using needs to be fixed.