Any phantom or ghost nodes in the network? Devices trying to route through non-existent nodes can cause many random network issues. The bad nodes need to be removed from the Z-Wave controller to resolve this.
I have one node doing this now for me but I think my issue is marginal W-Wave signal at that location. Mains powered nodes or repeaters can help resolve issues like that,
It was fixed on 17 Oct 2019. Snapshot 1731 was released on 20 Oct 2019.
Having a similar (or the same?) problem, so it’s not fixed.
Please open an issue on GitHub then. That is how the PR I linked to finally got resolved. Chris is extra busy right now with Zigbee and posting on GitHub lets other developers try to help.
I have the SAME issue!
Nope.
All of the affected devices are mains powered.
I’ll do further investigations (when I’m back from work 
) . After that I’ll open an issue on GitHub.
The one device giving me headaches at healing is mains powered.
Correction, 1 of them is battery powered.
I have 19 zwave devices with openHAB 2.5.0~S1733-1 (Build #1733), no issues at all till now. May I ask you to explain a bit more?
Andrea
You got me thinking about this, so I investigated further, and found 1 device that I couldn’t get to respond properly. I tried to mark it as failed and remove it, and I kept getting errors, I eventually had to restart the ZWave binding to get it to remove the old node:
2019-10-24 08:13:42.645 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:d662a132:node8' to inbox.
2019-10-24 08:13:59.308 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node not placed on stack due to error 0x18.
2019-10-24 08:13:59.572 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node not placed on stack due to error 0x18.
2019-10-24 08:13:59.834 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node not placed on stack due to error 0x18.
2019-10-24 08:15:30.257 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:d662a132:node8' to inbox.
2019-10-24 08:17:06.254 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node returned with response 0x3.
2019-10-24 08:17:43.762 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 8: Remove failed node failed as Controller Busy!
2019-10-24 08:17:44.021 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 8: Remove failed node failed as Controller Busy!
2019-10-24 08:17:44.283 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 8: Remove failed node failed as Controller Busy!
2019-10-24 08:27:07.726 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:d662a132:node29' to inbox.
2019-10-24 08:27:20.161 [INFO ] [ommandclass.ZWaveVersionCommandClass] - NODE 29: Command Class COMMAND_CLASS_BASIC has version 0!
2019-10-24 08:30:11.240 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node returned with response 0x3.
2019-10-24 08:32:31.994 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node failed as Controller Busy!
2019-10-24 08:32:32.252 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node failed as Controller Busy!
2019-10-24 08:32:32.514 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node failed as Controller Busy!
2019-10-24 08:33:03.360 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node failed as Controller Busy!
2019-10-24 08:33:03.619 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node failed as Controller Busy!
2019-10-24 08:33:03.880 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node failed as Controller Busy!
2019-10-24 08:33:13.392 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node failed as Controller Busy!
2019-10-24 08:33:13.644 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node failed as Controller Busy!
2019-10-24 08:33:13.903 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node failed as Controller Busy!
2019-10-24 08:33:14.161 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 8: Remove failed node failed as Controller Busy!
2019-10-24 08:33:14.420 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 8: Remove failed node failed as Controller Busy!
2019-10-24 08:33:14.683 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 8: Remove failed node failed as Controller Busy!
2019-10-24 08:33:23.950 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 8: Remove failed node failed as Controller Busy!
2019-10-24 08:33:24.467 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 8: Remove failed node failed as Controller Busy!
2019-10-24 08:33:24.722 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 8: Remove failed node failed as Controller Busy!
2019-10-24 08:37:28.591 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node failed as Controller Busy!
2019-10-24 08:37:28.851 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node failed as Controller Busy!
2019-10-24 08:37:29.108 [ERROR] [essage.ReplaceFailedNodeMessageClass] - NODE 8: Replace failed node failed as Controller Busy!
I have also set my network to heal at 9 am to see if this resolves the issue.
sometimes it’s useful also to remove the device from the USB key. What controller are you using btw?
Another thing to do:
stop openhab
remove the file with the zwave node in the name in the zwave folder (/var/lib/openhab2/zwave) -> something like network_xxxxxxxxxx__node_8.xml
start openhab of course
The Z-Wave network is stored on the controller. Deleting the xml file achieves nothing useful. I have put my USB controller on a Windows box & used Zensys Tools to delete phantom nodes.
I now suspect I have dome phantom nodes and will likely try OpenZWave Control Panel on Linux, with OpenHAB shut down.
I did manage to get it to remove. I am using a Aeotec Z-Stick Gen5
It might take 1 or 2 network heals to get it all sorted.
Not totally correct. I see that, if your device is broken, you can remove it from the controller and also from “things”, but at the next discover you should find it again … the only way to avoid that is to check also the files, in my case there was still the old file there.
My two cents
Only if it is not removed from the network on the controller.
I think there are currently issues doing this through the binding. Research & troubleshooting are ongoing.
I usually remove the nodes from the controller without the support of the binding itself. But I agree with you, it’s a try approach
Here is the latest conversation I saw on failed nodes.
Troubles will start after network healing…