[SOLVED] Z-Wave: cannot remove "phantom" devices

While playing with a Z-Wave device I have removed and re-added it a couple of times. Now the real node ID is 18, but I keep getting its “phantom”, obsolete, copies as nodes 14 and 17 in my inbox. This happens every time I run thing discovery.

I tried to delete them while the Z-Wave controller is in the exclusion mode, but it didn’t help.

How can I remove them permanently (without having to “Ignore” them)?

check this recent post:

There is also the Zensys tool for more advanced stuff: http://docs.incontrolha.com/home/remove-a-failed-device

Thanks, it looks indeed what I was looking for. But I did what Rich suggested, this doesn’t seem to work. After clicking on “Remove device from controller”, I get an error popup:
Screenshot%20from%202018-12-06%2017-31-48

Then I delete the thing manually as per the advice, but after discovery it’s again in my Inbox. Arghhh.

This thing is Windows only I guess?

There were issues with the Inbox that have been corrected, but I’ve also had yhis happen on a recent snapshot. It does not look like these nodes are on your controller, so you won’t be able to exclude/remove them. You could try restarting OH and/or clearing the cache, IIRC, mine stopped being discovered after updating to another nightly build, which clears the cache.

1 Like

I’m facing the same issues that @ncwekjn describes. My only solution was in the end to put up a Domoticz instance and delete the devices using the OpenZWave console there. But that’s very tedious if you have many devices and doesn’t work reliable in all cases.

1 Like

The Zensys tool (only Windows) is very, very effective in cleaning up old Z-Wave nodes from the Controller (the USB Stick)

Even Aeon Labs uses it :slight_smile: Ref: Zensys zwave tool & zwave issues

If it just weren’t Windows… :wink: I don’t even have a copy of it. My computers all come without it.

Upgraded to the latest milestone release (2.4.0~M7-1), cleaned the cache, even removed nodes’ XMLs from /var/lib/openhab2/zwave/, they’re still coming back upon discovery. Removal from the controller action in HABmin still fails:

2018-12-07 11:43:52.228 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 14: Remove failed node failed as node not found

Will try digging some Windows box to run Zensys on it…

Been there.

1 Like

Phew. They’re finally gone, with the help of Zensys tools. What I have done:

  1. Stop my OpenHAB service
  2. Extract the UZB stick from my Raspberry Pi
  3. Spin up a Windows 7 VM in Virtual Box on another machine
  4. Insert my UZB stick into an USB port
  5. Connect the “Sigma device” to the VM in its device settings
  6. Install the usb.inf driver from z-wave.me website.
  7. Follow the steps from this how-to.
  8. Reinsert the UZB stick into my Raspberry Pi
  9. Start the OpenHAB service
  10. Manually remove the “phantom” Z-Wave things
2 Likes

I have the same issue but I do not have a Z-Wave stick but the RPi (Razberry) module. How to get rid of ghosts there?

About 2 weeks ago, @chris made a change to the binding that is supposed to fix the issue with deleting ghost nodes. I haven’t tried it out yet. If you’re running a recent version of the binding, you could try using HABmin to delete the ghost node. If you try it, please post your results back here.

Hmm, I was running 2.5.0~S1556-1 when I tried today to remove a device which was failing (and I had to reset). I couldn’t get rid of it with “setting to failed” and “remove from controller”. It always came back into the Inbox when I removed the thing. Updated later today to 1557 and just tried again to “remove from controller”:

2019-03-17 22:58:25.743 [DEBUG] [message.RemoveFailedNodeMessageClass] - NODE 12: Marking node as having failed.
2019-03-17 22:58:25.747 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: Added 205 to queue - size 1
2019-03-17 22:58:25.751 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-03-17 22:58:25.755 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 06 00 61 0C 01 CD 58
2019-03-17 22:58:25.759 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 06 00 61 0C 01 CD 58
2019-03-17 22:58:25.766 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2019-03-17 22:58:25.770 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 2<>126 : Message: class=null[0], type=ACK[2], dest=255, cal
lback=0, payload=
2019-03-17 22:58:25.789 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2019-03-17 22:58:25.792 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 205: [WAIT_RESPONSE] priority=Controller, requiresResponse=true, callback: 205
2019-03-17 22:58:25.823 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 61 10 8B
2019-03-17 22:58:25.849 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 3<>125 : Message: class=RemoveFailedNodeID[97], type=Response[1], dest=255, callback=0, payload=10
2019-03-17 22:58:27.795 [DEBUG] [sactionManager$ZWaveTransactionTimer] - NODE 255: TID 205: Timeout at state WAIT_RESPONSE. 3 retries remaining.
2019-03-17 22:58:27.799 [DEBUG] [sactionManager$ZWaveTransactionTimer] - TID 205: Transaction is current transaction, so clearing!!!
2019-03-17 22:58:27.801 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 205: Transaction CANCELLED
2019-03-17 22:58:27.803 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: notifyTransactionResponse TID:205 CANCELLED
2019-03-17 22:58:27.806 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-03-17 22:58:29.497 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Polling…

This is just one out of some ghost devices I have. My Fibaro wall plugs crash every few months so I have to reset them without being able to unregister anymore so I’m running into that regularly which will over time create some list of orphaned nodes :frowning:

Hello @mhilbush and @chris ,
I just tried to remove ghost nodes with the new version of the binding. my system is openHAB 2.5.0~S1556-1 (Build #1557). I understand, that ghost nodes are zwave device, which have been physically removed from the zwave network, but remain visible in the controller, even, when they have been deleted. I have several of these…

Unfortunately I was not able to remove the ghost nodes. This might be due to me handling the procedure wrong. i understood, that I need to:

  1. set the node as failed (in the “Show advanced section”)
  2. remove it from the controller (in the “Show advanced section”)
  3. delete the node from the list

mmm?

Since again two of my Fibaro Wallplugs stopped working (they seem to do that regularly every few months) I will have two more ghosts in a bit which I cannot get rid of. Any news?

I don’t know the status of the fix, but you can also use Zensys Tools to replace a failed node. This is nice, as you don’t have to change nodes. The process is similar to removing a failed node. From memory… reset your device, send the NOPs, mark the node as failed, then use the Replace Failed option.

AFAIK the Zensys stuff needs Windows? I have a RaZberry module not a z-wave USB stick. So my solutinos are limited to RaspberryPi.

Correct… and it will not work for your controller. Sorry… bad asumption on my part!

@Wolfgang_Rosenauer Did you manage to find a solution with the Razberry? I have the same issue and can’t get rid of some phantom nodes.

I found a solution which is not very comfortable though.
I downloaded a zwave.me image and put in onto a new sdcard. Everytime I need to remove such a device, which is every few weeks thanks to those rotten Fibaro Wall plugs which apparently lose their configuration very regularly, I’m reboot my Raspi to the zwave.me system in which removing the unreachable device is possible somewhere. I always struggle to find the option in the web interface but eventually find it somewhere. Rebooting back into openhab and everything is fine for the next few weeks. :frowning: