All the ones that aren’t motion sensors, are old nodes (not even in the house) that were discovered on first scan with the controller. The motion sensors are duplicated while I was testing and replicating this issue
First post in the thread, describes the same issue I’m having
or this one, certainly doesn’t sound like the issue I’m having does it /s
hmmm another person who gave up instead of being able to resolve the issue.
Another agreeing they have the same issue, but sure it’s just me having this problem and yeah you never seen it before
theres also this, after the “fix” was merged. Oh look same issue.
Tho I will thank you, since I have reread this post I saw just gem I must have missed while looking for a solution.
Blockquote ** If you mean the RaZberry card (you need to tell!) then you can use Z-Way, downloadable on zwave.me**
To be honest, I need to remove dead nodes a few times a year and, even though I agree it is better to exclude devices, there are several situations when this function is required. Devices could stop working all together or need to be factory reset because they stopped functioning and provide no exclusion function anymore. So I tend to agree with @A_Fro that the function to remove (or replace) a failed node would be desirable. Other z-wave solutions provide this function as well and the openHAB z-wave binding has the (non-working) function to “Remove a device from the Controller” and the documentation refers to “Dead” or “Failed” devices to be removed from the network.
I also agree with @chris that we cannot demand him to work on this feature and apparently a lot of time already went into this.
The workaround I use is that I have all z-wave controllers (including z-way) connected to my openHAB system through ser2net → RFC2217 instead of directly, even for the controller physically connected to my openHAB server. When I need to do maintenance I set up a virtual COM port (using the Eltima Virtual driver, HW Virtual Serial Port tool) on a windows client and run the Z-Wave PC Controller software. This works flawless and even allows for replacing failed nodes instead of deleting them. Added benefit is that even my old Aeotec USB controllers that disconnect since recent 64 bit nrjavaserial versions work reliable again and this also allows for OTA firmware updates.
It seems to me that sending the NOP command followed by setting the node to failed after which it can be removed or replaced should be doable. Unfortunately I am not a great Java programmer so a pull request by me is not going to happen 
.
This seems to be the right moment to also give my input.
Basically I agree with @mvbergen and his last post. I also would really really like to have this function working in OH, but I trust @chris when he says, that it is not an easy job in the binding to do.
I currently also have 2-3 ghost devices floating around. Typically I wait until I have 5 or more devices, then my procedure looks like this:
- OH runs on a Raspberry with a Razberry ZWave controller
- Connect my Aeotec USB Z-Wave controller to my Windows-PC
- Start Simplicity Studio
- Add the Windows-ZWave-Controller as a Slave to my OpenHab ZWave-Network
- Set devices as failed and remove devices by using Simplicity Studio
- Exclude Zwave-Slave-Controller from OH
Especially from 2018 to 2019 I had extreme problems with Fibaro Motions Sensors and Smoke Sensors which somehow reset themselves (no communication to controller anymore) and I had to include them again as new device (which was working without problems which supports the fact that they were not included anymore). Meanwhile I replaced the Smoke Sensors with Non-ZWave devices and the issue is gone.
Sorry - you misunderstood my comment. I know that there is this issue removing failed nodes - that is not the point. The point that I was making above is that you should not get into a situation where you have 21 nodes to remove after adding just 5 nodes. This is not normal.
Guys, over the years I have spent thousands of hours working on the binding, and quite a bit of time looking at this issue. I have recently moved around the world and have limited time at the moment and I also do not currently have a ZWave system to test on as I’ve only just moved in to a new house. I had to get rid of all my ZWave devices when I moved as ZWave is region specific and my old devices are not legal here! At the moment I do not even have a coordinator to test against.
The problem is it is not reliable due to the way the binding works, and to make it reliable would require a lot of work. It does not need to be a NOOP - it can be any command - so if you want to try this, just send a normal OFF command or whatever.
1 Like
I can try this, but the issue with this is, that the ghost devices are typically battery devices which do not have an OFF or any other command, but only readings. Any suggestions for this?
I actually can’t see how this can work work with battery devices - even with the NOOP since the message can’t be sent until the device wakes up - which it won’t.
I don’t know how it works in Simplicity Studio, but I can remove battery devices with 2 clicks in some seconds. The software is explained a bit here:
I don’t think it matters if the device is awake or not. In fact, I don’t think it matters if the device is even there. After all, the device is “failed”. 
BTW, @chris, I didn’t know you moved to New Zealand. Nice! That’s on my bucket list of of places to visit.
Sorry - to be clear I meant from the binding perspective. The binding queuing system will not send commands to battery devices. This includes a NOOP which is occasionally sent. Everything goes into the queue and is sent when certain rules allow (awake, priority, security etc).
Sorry - I wasn’t clear above - I was talking only from the binding perspective.
Yep - just recently made the move so still getting settled. We’re in Auckland (or close to the city and about 30 minutes from the Airport) so if you get down this way let me know 
Yeah, in that case, I get it. It’ll be queued in the binding because the device will never wake up. So, it’ll never make it to the controller. Ouch. Then that’s a deal killer.
Nice. Probably won’t get to NZ for a couple years. Our trip to Africa is still pending. We were all set to go there, then Covid hit. Hopefully in mid-2022.
Well - the damn borders are still closed so no-one can get here and we can’t now leave 
. It’s a real pain and the government is dragging their heals a bit (IMHO of course).
Snap!
We booked to go to Kenya and Tanzania again for Sept last year - that was moved to Sept this year, and now it’s Sept next year, but who knows. Maybe I’ll see you there first 
.
Yeah, not good. Not much fun in Australia from what I’ve heard, too.
We’re going to Kenya and Tanzania too. But unlikely we’ll see you in September. Our daughter gets married in September 2022.
seems like Fibaro Motions and Smoke Sensors fail pretty often. I have some Motion Sensors too, which kept dying. Using ZigBee Motion Sensors now.
Yes, but imho it must be OH-related. I switched from FHEM to OH some years ago and never had these issues with FHEM before using the same hardware.
I think there was another thread here about this but in the end we never found out what is causing this. I had a talk to the Fibaro support and they told me that basically the only reason for a device to reset is when the controller sends the command to do so.
I very much doubt that - I can’t see any mechanism that OH can influence the controller. And if so, why only one brand?
I think there were some issues around some of their devices I’ve seen reported here that are clearly the device and this was acknowledged by Fibaro and required firmware updates to resolve.
I am having a real problem removing a couple of ghost Z-Wave nodes. I have an Aeotec Z-Stick Gen5. I ran the Simplicity Studio and removed several occurrences of a multisensor. At this point, none of the multisensors show up on Simplicity Studio. But when I look on OH3 at the Inbox, two multisensors are shown. All of my multisensors are off, with no power connected.
I have cleared the cache several times, and rebooted several times, but these two nodes still continue to exist.
I have added the multisensors as Things, and then have marked them as dead, and selected to remove the node, followed by deleting the Thing. But they still reappear in the inbox.
Any ideas?
Brad
I’ve never (at least in a couple of years) had a situation where I removed a node with the Silabs PC controller and it showed up in the inbox after I put the stick back into my Rpi OH. Did you clear the cache and restart before you ran the scan? If there was some memory of the device in OH and you scanned and it showed up, a restart and clearing the cache at that point might not work. Also once you add them, you have to use the Silabs PC controller to remove them “again”.
My suggestion is to remove with the PC controller again (check if failed, remove failed) and if they still appear after a OH shutdown and clear-cache to mark as “ignore”. Also delete the userdata\zwave\node.xml while OH is shutdown. Can’t say that would work, but maybe.
Bob
1 Like