Delay in Action?

Are these real, functional devices? If so, they aren't ghosts (that's just one possible explanation for the above). If they aren't, you might try waiting a bit and trying the above again -- one node at a time if you weren't.

A virtual device won't show up in your Z-Wave Details table, so none of the above is applicable.


I can't tell if they're real or not. A few had the linked zwave device, but many are just displaying the 'device class'. or just the route but no 'device'?

  • "Ahren's Bed Sensor" for example shows no route, but functions perfectly and with high activity :wink:
  • Regarding the locks, I only have 2 (plus digital lock events app to capture the lock button presses on keypad from exterior)
  • The radiator zone controller is paired and powered, but is not used (but will get to it eventually)
  • The Landing Repeater by Aeotec is placed dead center between the locks (and paired with security) before I did the dual antennae mod but is probably no longer needed and doesn't seem to be repeating any traffic since no route info anyway...

Here they all are...

I just checked another item on the troubleshooting page for locks and noticed "SecurePairingComplete" is only on the Mud Door Deadbolt and not the Front Door Deadbolt. I swear these Schlage locks are so painful!

Mud Door:

Front Door:

If there is nothing in the "Device" column, you at least know you aren't using the device on the hub, so ghost or not (and they probably are), they should be safe to remove.

Functional devices, even without routes, like that first sensor you mentioned, are never ghosts. The route information is updated periodically, not in real-time, and it's reset when the hub (I think? Or maybe Z-Wave radio...) is rebooted, so sometimes it will be blank but normal.

That they are (or at least can be). :smiley: If both locks are working fine, this shouldn't be a problem, though they are supposed to need at least S0 (or S2) to function. Your first lock above looks fine, but the second one looks...interesting. If it's working fine, I wouldn't worry about it. A battery-powered device is unlikely to cause mesh problems (not like it's routing), though if you get bored or desperate, I suppose you could try excluding and re-including (swap it it out with a virtual device first to make updating apps afterwards easier if you want).

Thanks so much for helping me through this @bertabcd1234

I hit 'refresh' on this one, then the status changed to 'pending' and the 'remove' and "discover' buttons appeared. I clicked remove and it just did this for a few minutes and then it times out I guess.

I'm not going to worry about the Front Door Deadbolt just yet, as it's so time consuming to repair them and if not a big concern anyway...

I mean the pretty picture of my mesh looks pretty darn great except for all this.. and the 'Garage Door" is actually pretty far away, at the end of the block and our house is in the middle. I got one of the Zooz repeaters (with power outage detection, very helpful) which it's communicating through.

Ugh, really feel like this is a pretty glaring problem and running out of levers to pull.

@bravenel I think this is what I've been running into with Scenes not completing, etc (you recommended the All Off app, which helped dramatically.)

Any other suggestions/thoughts?

"Logs" might show a reason (not all of which are easily fixable,'s something, at least the underling status from the Z-Wave SDK).

For troubleshooting mesh issues, I'd focus on mains-powered devices/repeaters first, as they are the most likely to cause problems.


I ran a full zwave repair yesterday, and there were probably 20 'failed nodes' but not sure how accurate that is (esp considering battery devices, etc)

I see several of the ghost nodes I was trying to remove yesterday still say "Pending" today, and when I tried to "Remove" one of them while watching logs, this was the entry that was recorded:

I hit 'Refresh' once again, no change of course, and then tried to run 'Remove' again and got these new entries:

The no longer in failed node list is normal if the node has more than just the hub as a neighbor (more than 1). Seems to be some sort of bug in the zwave firmware. The busy message is then normal if you keep trying to do things with it after the failed removal. Best thing to do once you start getting the busy message is a shut down and unplug for 30 seconds.

shut down and unplug the hub?
I have thought about killing power to the entire house (network on UPS) and using battery to boot HE. Battery devices would still be present, but quiet theoretically and the mains powered would all be silent.

Yes, just to restart the z-wave radio.

To try and remove the ghost nodes? That wont actually work, its a myth. If they have more than one neighbors listed then it is rare that the hub will let you remove it. Usually gets that same error you are getting. You will need a USB stick to remove them. How To: Remove Ghosts using hub tools or a UZB Stick

1 Like

Ok, I've followed your incredibly well documented guide on doing this (THANK YOU!) and have removed all the nodes without route information. I am curious though, there are several nodes that do have route info, but don't have a link/device name. I assume this is also failed? Ok to mark these as failed and remove as well?


1 Like

Yes you can remove those also. Sometimes the routes get stuck in there when the pairing fails and they never go away. If there is a live device attached still the PC Controller wont be able to remove it either because it will respond to a ping. If there is a live device on there, you have no control over it because there is no device linked to it in HE.

Also, not my guide but I had contributed some content to it. Not sure who created it originally but @danabw had a big part in bringing it all together and posting it.


I put it together w/a lot of help/advice/edits from @erktrek, but of course our work on it was based on info provided by many others before us in the forum. So yes, we stole most of it. :wink:

1 Like

I'm not sure what happened but many devices are able to be controlled physically, and will immediately update status to the hub, but commands outward from the hub don't seem to be going anywhere. Including exclusion and inclusion.

Did you happen to migrate from a C5? Seems to be a common denominator in many of the recent z-wave communication issues popping up.

Check this thread out: S2 Authenticated Z-Wave Devices Not Responding to Commands - #40 by jtp10181

1 Like

Thanks, that does sound similar but not limited to s2. And no to the migration, I've only ever had my current hub the c7

Did you try doing a shut down and unplug for 30 seconds to see if that brings it back?

Shut down, unplug.
Rebooted several times.
Disable/enable of zwave radio
Full zwave repair.

It's like it has a degenerative disease and slowly losing more. Kinda panicked since I have such a massive network and apps/rules base

If your Z-Wave firmware and ZIP Gateway updated?

Can check versions here: http://<hubIpAddress>/hub/zwaveVersion

More info about updating:

1 Like

Yes, should be:
VersionReport(zWaveLibraryType:7, zWaveProtocolVersion:7, zWaveProtocolSubVersion:18, firmware0Version:7, firmware0SubVersion:18, hardwareVersion:1, firmwareTargets:1, targetVersions:[[target:1, version:7, subVersion:18]])

I wish there was a way to include devices again, similar to how you can do with Aqara devices.. "hey remember this guy.. who? who? who? OHHH this guy."