FAQ: How to remove ghost devices from your z-wave and zigbee networks

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

I also have a (mains powered) device that has a funky path;

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. So it has 3 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.


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 > Hub packet 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.

It’s 4 hops. The originating device and the receiving device don’t count.


Is 4 hops.


They change based on traffic and obstructions. If a repeating device is busy with another message, then that route isn’t available. If a human is walking through the house, their body can block signal, making a route unavailable. The network is taking into account a lot of information that you don’t have when you’re just looking at the list of nodes the last route went through.

a body pack transmitter can be 50 to 70% less effective than a handheld transmitter simply because of the antenna location being against the human body


@RBoy So I just tried this process twice and my ghost still remains in another devices path. Does it take a while for the IDE to update or did the process fail?

Thanks for the info, but I noticed something different. Can’t find it in this topic with Find.

I see at Type so called “placeholder”.

Here how it looks, one picture with the duplicate name next to the functioning device, the other filtered on “placeholder”.

I will try to remove the placeholders and see what happens.

Grtn Ben

placeholder is for devices which are connected using Cloud to Cloud integrations using the new ST app. If you delete then you will need to reconnect them. They don’t have any impact on zwave or ZigBee

1 Like

Tnx for the info.

Thought delete it would solve my ghost devices.

DO NOT DELETE or otherwise mess with placeholder devices unless you want to fix whatever it breaks.


The path that you see in the I DE is the last reported path, but it can indeed take quite a while for this to update. (At one point it only updated once a day, but I think they’ve made it more often than that.)

So the first thing to do would be to actuate the device That path is for so at least there’s a new “last used” route. But you still might not see it in the IDE for a while.


Thanks for the input

1 Like