Remove a ghost Z-Wave Node from HABmin

Hi @Wolfgang_Rosenauer

That really sounds promissing!
I’m trying to get rid of ghost devices since a long time without success.

The current installation on my Raspberry Pi is:

  • openHABian Configuration Tool [master]v1.4.1-466(0824b76)
  • Release = Raspbian GNU/Linux 9 (stretch)
  • Kernel = Linux 4.14.79-v7+
  • Platform = Raspberry Pi 3 Model B Rev 1.2
  • openHAB 2.4.0-1 (Release Build)
  • 234 │ Active │ 80 │ 2.4.0 │ ZWave Binding

I’m not sure about this instructions:

  1. Do I have to do some deinstallations or preparations first or can I just start the installation of z-way on my Raspberry by following this instructions?
  2. Instruction: After upgrading clear browser cache and cookies . => On my Windows Pc?

Would you please briefly describe how you managed it?
Thanks in advance!

I just copied the Z-Way Raspberry Image on a different SD-Card, stopped the system and booted via the Z-Way SD-Card.
After finding the Z-Way webinterface there was some advanced configuration screen somewhere where it was possible to remove failed devices. It took me a bit of search in the z-way interface but I eventually found it. Unfortunately I already do not remember anymore where I exactly needed to go within the interface. I did not do any other setup within z-way. Just gave it enough time to recognize all devices and find the ones which did not react anymore.

Okay, using a different SD-Card! :bulb:
Did not think of that.
Thanks a lot. I will try that.

You do not need a different SD-Card, just stop OH and install and start Z-Way.
Before restarting OH simply stop Z-Way :slightly_smiling_face:

Hi,
sorry but I can’t find a way to remove a dead node from my controller. There is no real problem now, but it would be nice if I can remove the node.

I tried to set the node as failed in HABmin. This is the debug log:

But the device is now NODE 34, not 33. Why the log tells me my node are healthy?

Later in the log appears this messages:

21:14:01.210 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 33: Polling...
21:14:01.211 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 33: Polling deferred until initialisation complete

I try for several days now without success.
OpenHAB is 2.5M3 since today, before it was M2.

So, any idea what to do?
Of course I can remove the Stick from server and plug into my workstation te use another zwave tool, but first I want to remove the dead node with open hab if there is a way.

The device is a fibaro smoke sensor (FGSD002). The (default) wakeup Interval is 21600 s.

Thanks,
Daniel

I think @chris said if you mark the Thing as failed in HABmin the controller may remove it.
Of course, you then need to delete it from HABmin after some time.

You can’t remove nodes that are working - the controller will not let you. If the node is working, then you should simply exclude it from the network.

If the node is not working, then you need to mark it failed - the controller will only allow you to do this if the controller thinks it really has failed. Once it is in the controllers failed node list, then you can send the command to remove the device.

Thanks @chris and @Bruce_Osborne for your answer,
The device is resettet and reincluded as node 34, so I can’t exclude it regulary from controller.
So I tried exacty what chris said, I tried to set the device failed in HABmin.
What can be the reason that the controller think the device is working? It isn’t.
I own only one Fibaro Smoke Sensor.
I’am realy confused.

I had no success using either habmin nor paperui to get rid of failed (ghost) nodes with my Razberry. I just used Z-Way server (that i installed and deactivated on my rpi). It worked like a charm, no dead devices anymore. I don’t know what’s the problem with Razberry and openhab, but I cannot exclude devices and I can’t remove nodes from the controller.

As far as I know, you cant use neither Habmin or PaperUI to remove ghost nodes. Both options require that the connection to the device is working (online) which isnt the same as a ghost node. When the device isn´t online, PaperUI or Habmin cant remove the node.
At least thats how I understand it. @chris may know more.

You need to use a product like Zensys Tools to delete the node from your controller. The network is stored there. You can then delete the ghost thing and it will not be rediscovered.
A ghost node can cause Z-Wave network issues when other nodes try to route through it.

As mentioned above, this should be possible to remove ghost devices from the controller using the binding. The binding does exactly the same thing as the Zensys tool.

OK, when I tried marking a node as failed it did not work for me so I resorted to Zensys Tools.

The binding does the same thing as the Zensys tool. Sometimes it works, sometimes not. Often the controller will report that the device is not considered dead, and therefore cannot be moved to the dead devices list. I don’t know why it does this as it’s the controller that decides and it seems a little random at times.

Okay, thats news to me. I´ll give it a try next time I have a ghost node.

Now I removed my failed device with Zensys Tools with no problems. With HABmin I had no success.
Thanks for your help.

Didn’t we determine that the Zensys procedure includes sending a NOP as the first step? If the node isn’t in the controller’s failed list, won’t this step makes sure the controller has the node in the failed list? That’s the only thing I saw that’s different between the Zensys procedure and HABmin.

You might be right - I don’t recall.

I don’t know - I’ve not looked at the controller source code. In theory, I expect that the first command sent should do that - that’s what it is for (ie the command to set the device into the failed list should, well, set the device into the controllers failed list). This command should explicitly do that according to the documentation, but it might be that it doesn’t always work and the NOP is required.

Do you have the reference for the discussion we had on this?

It’s further up in this thread.

Thanks. So I see that I (rightly or wrongly!) concluded the same thing at the time - that the NOP is just there to get it into the failed list, which should do the same thing as the “set node into the failed list” command.

In the log you provided above, you don’t seem to use the “set node as failed” command at all.

I can try adding the NOP before the “set node as failed” command to see if that works, but it’s a bit messy. Something else that you could try that does the same thing is to send any command to the device.