Z Wave Routing Defies All Reason

Following all of the changes I've made there is an anomaly with one of the devices. One of the devices (it's working normally) is showing a route through a node that doesn't exist. I've clicked repair for that individual node but it just comes back with the same route. To be clear, there are no unknown devices in either the device list or the Z wave details page that could explain this. The following image shows the details:

The node 17 does not exist. It was previously an outlet, but that outlet was successfully excluded and removed before being replaced with another outlet which has a different address.

EDIT: When I've checked this using the Z Wave Mesh Details app it shows a different route:

It seems that although the most of the details and routes are updating themselves automatically on the Z Wave Details page, that one specific route has not. Manually clearing the browser history has corrected it. I'm not sure why all the other routes that have changed overnight have updated automatically on the page while that one wouldn't using refresh or repair.

Yeah "Ghost Routes" are weird - I still have one hanging around even after a month or so. The only option I know of is to re-include your device. I don't know what the actual impact is though as my device appears to be working as well..

Thankfully I've nothing showing as unknown in the Z Wave Mesh App. It appears that my browser couldn't refresh that particular entry.

I removed the unknown ones from devices just by pressing "repair" once or twice, waiting for the "remove" button to appear and then using that - it worked a treat.

1 Like

What you see in my report is a "ghost route".. Device "07" does not exist anywhere on my system (even when using a secondary contoller) as it was taken off a month ago or so. For some reason my basement door sensor - an Aeotec Recessed Door Sensor Gen 5 is still showing as routing through it. Not sure what the ultimate impact of this is but have been a little lazy in resolving the issue since I need to use a secondary controller to pair with no security.

What is the process of using another controller to add a device without security? I'm stuck at the moment as some of my Fibaro devices join to the C7 at S0. Is it relatively straightforward?

Yes and @danabw has a nice write up for removing ghosts but it also has the setup instructions as well..

1 Like

My Fibaro eye motion sensors had to be joined to C7 with a UZB secondary hub controller to get 'No Security'. They are operating much better in the 'no security' inclusion mode!


My z wave was pretty solid until the new update or when i removed some Homeseer switches at about the same time to remove security on them. I only have a 1500 sq ft house (wood/vinyl siding), so I agree that it really does not make sense, or there is some sort of bug causing the mesh to not heal properly. Devices now sometimes work or they don't. I removed all the ghost devices via the hub, my next step is to try the silicon labs software. I did z wave repair multiple times, rebooted, shut down for a while with no luck on getting the mesh to repair itself.

Wow, that's a lot of red. Lot of devices but largely battery powered or non-repeaters. I'm guessing that removing the Homeseer switches weakened the mesh enough that you are now having issues.

1 Like

The Homeseer switches were re-paired though without security (the 2 switches kept freezing up and had to be power cycled).

How long ago did you add them back in? (I've had repeaters sit idle for 2-3 weeks before the mesh seemed to start using them.)


Yeah especially if you have a lot of battery powered devices that don't update all that frequently. May take a while for them to get a clue.

1 Like

I added them back in 5 days ago.

If there are a few select devices that seem to have issues, you might try waking them up one at a time and then doing a Z-wave Repair for that device only. (A full repair of the mesh will only tie up traffic and not yield the results you want.)

1 Like

The strange thing is that devices 00-27, 3E, 42, 43,47, 49-4E, 53, 56-5E are hardwired/repeaters. Devices 28-3d, 3f, 41,44,45,4f,50,55 are battery powered, I would think the at least up to 27 there would be way more blue. I will see if waking devices up and repairing them helps when i get some time.

I had some repeaters I added (S2) that just sat there for a few weeks and then started routing devices. Not sure what happened to get them to start routing.

On a side note - I had a UZB-7 stick that I left paired and powered for a while and some devices ended up routing through it... was kind of a mess when I unpaired the stick, ended up with a bunch of ghost routes that eventually cleared either on their own or by re-including.

1 Like

From my experience it seems that routes (and some of the other stats as well) are only updated when the hub sends messages to the device. If it is a sleepy device that doesn't wakeup very often (or at all), it can take some time to update (my understanding is that repair doesn't target sleepy devices, currently).

Sometimes you can trigger messages from the hub for these by using the manual process on the device to wake it up (drivers for sleepy devices should respond to the Wakeup with the "Wake Up No More Information" command).

I agree! However no amount of triggering the sensor including replacing the battery (just in case) etc got rid of the route until I excluded and included. Keep in mind this has gone on for a while - at least a month or so for this particular ghost route.

I suspect it has something to do with the device itself (or the info from the hub) falling back on it's default table and being reluctant to change for whatever reason.

Yeah, I understand. Some devices are more difficult than they should be. Is it still (or again) an issue, or have you resolved it already?

One trick I have used to force messages from the hub to devices:

  • Change the driver to Basic Z-Wave Tool and watch the logs
  • Wake the device up
  • From device page (within 10s of wakeup) run either get command classes or get version report
  • The hub logs should show the wakeup received and the results of the commands

I already excluded/included this morning as verification of a claim I made on another about the UZB-7. The device in question is an Aeotec Recessed Door Sensor Gen 5. Doing this eliminated the ghost route.

1 Like