As far as I understand UserGuide (Page 52, chapter 4.2.8) correct, you can only replace a failed node with an existing node from the node list.
See here:
What does ‘NOP’ stand for?
NOP = ‘No Operation’ – to send a frame not carrying any functional info to a node.
It is like a ping.
See here:
1 Like
Can the serial stream be sniffed, or do we know the exact serial data being sent to the controller stick that removes a phantom node? I’d like to make a command line utility that writes the proper sequence to the stick.
There were also more recent discussions about improving the ability for the binding. Somebody was sniffing the data when deleting a node from the controller.
You would need to shutdoen OPenHAB first. There us already a Linus utility that is supposed to be able to do that but I could not get it to work well.
I was using Z-Wave PC Controller 5 to remove ghost nodes from a Z-Stick. With version 5 you just need to go into the “Network Management” option, click the node, click “Is Failed”, then it should turn red. Once red you can click “Remove Failed” (fuller explanation here).
However two of my nodes which I knew no longer existed on the network would repeatedly fail the NOP test but never go red, meaning you couldn’t remove them. The solution was to click the “Topology Map” and note the failed nodes were apparently routing between each other. Fortunately I had one of those failed nodes still available, so I plugged it back in then in “Network Management” did a successful “Is Failed” test then “Neighbors Update”. A check in “Topology Map” then showed it no longer considered the other failed node as a neighbor. As soon as that happened the “Is Failed” test for the remaining problematic node failed and made that node red and able to be deleted.
TLDR: If you have trouble removing a node, check its neighbors in the topology map and do a “Neighbors Update” for such neighbors.
What program is this? or is this a feature in openhab?
That looks like the zwave log viewer for debug logs. It is located here.
https://www.cd-jackson.com/index.php/openhab/zwave-log-viewer
Just wondered what was happening with this issue as I still cannot remove ghost nodes using OH.
It seems the conclusion was Zensys, which works, sends:
NOP
IsFailed 0x62
RemoveFailed 0x61
when I try “Set device as FAILed” in OH it sends:
which is a different sequence:
ReplaceFailed 0x63
IsFailed 0x62
So did we try the Zensys sequence in OH at all?
3 Likes
This was very helpful. Thank you!
Bodo
Any updates on this?
I’m facing the same problem of failing to delete ghost things, and I’ve tried all options to set the device as failed and remove device from controller but without success. Ghost things keep getting discovered in the inbox.
I didn’t try to use 3rd party software yet.
I’m using Aeotec Gen5 Z-Stick.
3 Likes
I’m suffering the same issues but with a Razzberry there is no way to remove “ghost” devices in OH3.
I think the issue is with the commands sent by the Zwave binding, just from checking the log, it appears as if the “Heal The Device” sends the Replace Node command.
The issue is the “Set device as FAILed” also sends the same command. Where I think this should be the IsFailed 0x62 command
That would make the following Remove device workflow actually work:
- “Set device as FAILed”, then
- “Remove from Controller”
TLDR: issue is the Zwave devices aren’t being set as FAILED which then prevents any chance of removing/replacing the device.
3 Likes
The issue is that the binding needs to send a NOOP prior to setting failed, otherwise the controller rejects this command. Unfortunately with the way the binding works it is difficult to be sure of sending tow commands immediately like this as there is no way to link two commands together.
Thank you so much for replying, I know this is an old thread.
Do we know how soon after the NOP is sent that the Replace Failed needs to be sent?
I’m not seeing the issue you describe, we don’t necessarily need to send the two commands at the same time. Have the UI button labeled “Set device as FAILed” send the NOP,
and the UI button labeled “Remove Device from controller” send the Remove/Replace Failed command.
If those as the only two commands needed to remove devices from the controller.
I hate to push this matter but there appears to be a fix, the binding needs to send a NOP prior to trying to either Remove or Replace the device.
The binding has UI elements which allow the following:
“Set the device as FAILed” - which sends a ReplaceFailedNodeMessageClass
“Remove device from controller” - which sends a message.RemoveFailedNodeMessageClass (but cant remove the device as it is not “Failed”)
finally “Heal this device” which also sends a ReplaceFailedNodeMessageClass
Since there appears to be two UI elements doing the same thing, I propose you change the “Set the device as FAILed” UI element trigger a NOP. From looking at the Forum post above it appears as tho there is a 4 second wait for NOP to complete (according to Celaeno1’s screenshot)
Then the following workflow to remove devices from the Zwave controller in the binding will work;
- open the “ghost” thing,
- Click “Set device as FAILed”
- Click either “Remove this device from the controller” or “Heal this device” to complete the process.
1 Like
Do we know if they need to be sent together?
From the image posted by Celaeno1 - it takes 4 seconds for the NOP to complete. As well as the Zensys workflow stating the process is
- Send NOP, wait for it to complete
- Send SetFailed - which was determined not to be needed as it only affects the Zensys software
- Send either ReplaceFailed or RemoveFailed - this completes the removal/replacement of “ghost” nodes
This suggests the NOP command doesn’t need to be sent at the same time.
If you agree the fix is to send the NOP why can’t the binding get that functionality?
I have spent a lot of time trying to resolve this in the binding, and it has not worked reliably. I have another commercial implementation that works differently in the way messages are queued, and that works well, but the binding has a complex queuing system. IMHO providing an unreliable system is the same as providing one that doesn’t work. Currently this does work “sometimes”, but not reliably.
This function is not one used commonly - it is only used to remove failed nodes, and there are other mechanisms that can be used for this - it’s not like it needs to be used routinely at all.
Again - the fix is NOT that clear - sorry. As above a lot of work has gone into this in the past!
Then please walk me throught the/any process for removing failed nodes. Considering I am using a Razzberry.
And no it appears alot of other people helped provide the answer which is a NOP sent prior to the replace/remove, came to you with the details years ago, and then nothing.
If you say you were testing and QAing it yourself and had issuses with the reliability then release it to all and maybe with everyones help we can get it over the line.
I will take a solution that can work over not having the functionality at all.
Also note I’m running out of nodes, what happens when I reach the 232 max? It’s ment to loop back and pick numbers it knows are available, but at the moment it thinks they are all available and online. So please tell me what happens then.
I’m already on node 21 from only adding 5 devices.
Also wait…you have a commercial implementation that works differently? You want me to pay for the solution that works?
Facts:
-
“Set device as FAILed” UI element in the binding DOES NOT WORK - it doesn’t set the nodes to FAILED, how is this not a bug.
-
What is needed is a NOP (a frame sent fom the controller with no data, consider it a ping) then the device can be moved to FAILED
TLDR: Then please walk me throught the process for removing failed nodes. Considering I am using a Razzberry.
Sorry - but that’s incorrect. I have spent a LOT of time working on this. I’m not sure how much you have contributed here, but I’ve been working on OH for around 8 or 9 years and spent an awful lot of time on the ZWave binding…
Why? I don’t really understand how you would get to this point so maybe you should look at how you’re running things!
Not at all - I’m not asking anyone to pay for anything. It was just a comment to indicate (again!) that I’ve spent a lot of time trying to characterise this issue, and I can’t keep doing so.
1 Like
Blockquote Why? I don’t really understand how you would get to this point so maybe you should look at how you’re running things!
As you’ll note in the image https://imgur.com/a/oQnQ91b the instructions for adding the device, note what it says to do if the device isn’t added.
If you do as the instructions you end up with https://imgur.com/63FEwz2
note that those two nodes are one device and that device is already included in the network as node 19
If this is a bug that you’re not looking to fix, what about the fact that devices aren’t being marked as DEAD, since that would also put it in a state where it will allow me to remove the device
Blockquote A battery device will be considered DEAD if the controller does not receive a wakeup notification, or some other message, within approximately twice the wakeup period. In this event, the thing will be set offline and the device considered DEAD.