Hubitat needs to have a built-in feature to get rid of "Ghost Nodes" what works consistently and reliably.
Most of us have had to resort to the "Ghost Node" removal guides. Thanks to those who put these guides together, but it is amazingly bad that these guides have to exist and that we all need to know how to follow them. Wherever the fault lies, Silicon Labs SDK, Hubitat, whatever, a real consumer-friendly solution is needed. Particularly frustrating is the near-useless "Remove" button that sometimes can appear on the z-wave details page. I say "sometimes" because its appearance is totally unpredictable - sometimes you can do a "repair" on a ghost node to get it to appear, sometimes not. And when it i s clicked, its mostly useless and the node doesn't remove anyway, but sometimes it does, so ...
I gotta feeling that this 'ghost removal' capability lies outside of HE engineering and squarely on the Z-Wave's API's that are either woefully incomplete or not available in this aspect.
I TOTALLY agree with you, having to purchase and pair a USZ to manually remove the ghost devices is not ideal, but at least a work around for now... We can only hope that this is covered in an upcoming upgrade..
I switched from ST to HE a couple/few months ago... I've known for a while that I ought to move on from ST, so I lurked around the community here for ~1 year prior to soak up knowledge to prepare for as smooth a transition as possible.
During that time, the many posts about C-7 z-wave ghost issues are the one thing that concerned me most... I don't have a windows PC, so the stick fix wasn't an option (not willing to buy & sideload Windows just for SiLabs). I was very worried that inclusion-related ghost issues would be a show-stopper for me.
The later 2.2.3.x f/w started sounding better for z-wave stability, so I jumped over around then... I only have ~15 Z-wave devices, but they all mercifully transferred over perfectly fine - I ran into one ghost issue but that one was entirely my fault, and I was able to quickly resolve it without any fuss using the documented steps (Remove button etc).
It would be interesting to know why some ghosts are particularly stubborn (requiring a stick) and why some are more straight-forward to remove.
I would re-phrase your enhancement request to say the Z-Wave pairing should not result in "Ghost" nodes (in the first place). I think this is almost entirely in Silicon Labs camp but Hubitat does need to keep pushing it. This problem is not good for Hubitat or Silicon Labs (or us Hubitat users).
That's my guess too. Maybe there's been an updated SDK that just has to be integrated. Maybe this is fixed when Hubitat address the Z-Wave Long Range firmware, but the problem has been around long enough that people have figured out additional systems that you need and written detailed guides to fix it - very frustrating that Silicon Labs let this linger and, as an end-consumer, we really have no influence other than indirectly through Hubitat pushing this to them as a priority.
Consider yourself fortunate. Most often, they can be removed and a power off reboot does the trick. I had several that would not depart unless I used the stick. I also like the stick to pair some devices without security.
Long time lurker, first time poster. Been with SmartThings for years and decided to come over to Hubitat for my new house build this year. I have mostly all Z-Wave with only 2 devices Zigbee. Most of my devices I brought over from the old house and are older Non-Plus sensors, switches, and range extenders. Had to supplement with Z-Wave Plus Switches and Aeotec Plus Range extenders. All was going well during install. Followed the Z-Wave Build guide to the "T" only adding several devices at a time, doing Z-Wave repair, and giving the network time to heal. The response from the hub was rock solid and lightning fast.
Then, after about 50 - 60 devices, I began having non-plus and plus switches alike not respond. So, I tried to remove the switches that were not responding and they would not come off at all no matter what I tried. On 2 of them, I accidentally hit "Force Remove" and there you have it, a ghost node! I am now up to 5 ghost nodes and can't remove any! My Z-Wave repair comes up with more that the five devices failing to respond but yet all seem to work except for the ghost ones of course.
Response from switches has noticeably slowed as well and the WAF is declining. It sucks that it was all going so good and then the ghost nodes and the messed up mesh crept up on me.
Anyway, I digress. The question was how does it happen? In my case, devices became unresponsive overnight, I tried to remove them, they would not remove, and in the many attempts to remove I accidentally hit "force remove" and got the ghost nodes. "Full disclosure" only three happened that way, the other 2 were totally my fault, I removed the switches from the wall before excluding them but same thing, I did a force remove on them. In my defense, I already had 3 ghost nodes going and would need to use the z-stick anyway.
Until then zwave was solid, reliable and predictable , using gen 500
Since moving to gen 700 the moving of 100 zwave devices was a miserable experience for quite a few of the devices, others like the greenwave sockets 30 plus of them went in really easy.
Ghost devices have been a continuous issue.
As a Mac user it has been extra hard to sort out, as the silabs pc controller software needed to remove stubborn ghosts only runs on Windows 10.
The ghost devices were apparently causing issues and stopping zwave inclusion, so I had to get Windows 10.
For the sake of transparency I believe that HE should make it clear that a Windows 10 pc is required to resolve HE zwave issues.
The zwave 700 network I have running on HE is nowhere as solid and reliable as the 500 (with same zwave devices) I had before but not so unreliable I would go through the pain of moving all the devices back.
That is a good guide. Very helpful for those sophisticated enough to use it. But that's the problem -- the people on this forum are likely at the high-end of sophistication for a consumer electronics product like this. Silicon Labs / Hubitat / whomever needs to get to the point where nobody even needs to know the term "ghost node." I'm assuming the Z-wave Long Range firmware will have many changes in it (old bugs fixed, new ones created, etc.) and hope this ghost node / device node removal problem is among those fixed! The real solution to this problem is that there should never be a need for a solution to this problem.
To clarify the interface, I suggest relabeling the "Remove" button on the Z-Wave Details page.
It should be labeled: "Button that does nothing but frustrate the consumer after an inclusion failure which, itself, should never happen." Might need a bigger button.
I'm closer to 0%. I've just spent the last hour clicking Remove, rebooting, repairing, disabling and enabling the Z-wave interface, watching the browser reloading icon spinning, etc. etc.
Yeah, I get that, and can do that, but this is a consumer device and it should behave like one and act as you would expect from what the interface tells you. People on this forum are probably at the highest levels of technical knowledge for this device and know that "Remove" really means get a USB stick and set up a silicon labs account so you can download some techey and esoteric Silicon Labs Z-wave tools that you then set up on another computer to perform the function of Remove because the button won't do what it says it does. That frustrates me endlessly and with each firmware release I expect to see this fixed, but that doesn't seem to happen.
Why would you expect that? If the issue is on the SiLabs (not Hubitat) SDK or firmware side, it won't be fixed until it is fixed there. Based on my experiences on other ZWave 700 hubs I have access to, I do think it is a SiLabs issue predominantly.
So far Hubitat has never updated the SDK or firmware on the C7 (actually maybe 1 firmware early on)... So no one should really expect this to be fixed 100%.
Worked around, made better, sure. But fixed? No.
I'm sure we'll get a new SDK/firmware this year though. Whether it fixes this issue or not, I don't know. I don't see anything in the SiLabs release notes that makes me super optimistic.
