I needed to remove a failed z-wave dimmer. Couldn't get it in a state to exclude, so just did the "force remove" option in hubitat device details. This pretty much guarantees a ghost node in my experience.
So I fire up my archived windows VM, find my aoetec dongle, launch the silcone labs studio and manually fail and remove the node. This is the pattern pretty much any time a device fails, and even sometimes when the device falls off the network for no apparent reason.
So If the studio tool can remove this node, why can't this force removal also work from the hub? Does silicone labs not license this function in the SDK? Or has it just not been implemented? this is such a major pain/flaw in the product. (maybe every hub option out there with a 700 series devices)
What can we do to help solve this? If the function just doesnt exist in the SDK, can we help pressure silicon labs to produce it? Now that Lutron Cesata has a switch that isnt FUGLY, I am really tempted to dump zwave for switch/dim altogether. I still love the hub, but Z-Wave is a pain.
I was able to remove 3 ghosted nodes from a C7 last week from the hub UI no problem. Refresh once, remove, gone.
Then of course I go to do it on my own hub, no such luck. Had to use a USB stick. Its hit or miss.
The PC Controller software uses an older SDK which will basically just brute force removes the node. We are told that for the hub to be certified it is at the mercy of the zwave chip/firmware. The hub sends the request to the zwave chip and it may or may not do what we are asking it to do.
It sure can do it, but it does it in an orderly fashion. The node must be listed in the failed devices table before the remove button is shown. Sometimes a device might bounce in and out of that table, but nothing like time can solve the problem. So if you are the impatient type and cannot wait for the radio to sort it out, then you may need to fire up your archived windows VM, find your aoetec dongle, launch the silcone labs studio and manually fail and remove the node.
Like so many, I wish this was as simple as you describe.
Fundamentally the SDK in use on the 700 and 500 series chips expose the same "Is Failed", "Replace Failed" and "Delete Failed" as is found in PC Controller.
The PC Controller software does use a different path to the Chip, which is why it's chip agnostic. You can use a 500 series USB stick, a 700 or even a 300 series with PC Controller. Plus the PC Controller software is very low level and is running at a human speed.. you have to read the status and click to move forward.
To remove a device, the Chip does 99% of the work. The "Is Failed" command gets run and the chip tries to "ping" the device. A positive response from the device means the device is not failed.. "Is Failed" returns false. A True response needs to be followed by a "Remove Failed" command which will remove any/all devices in the failed list. However, and this is bit, the remove begins with yet another is failed. IF the 2nd pass the device responds, then Replace will abort.
You can see that on PC Controller in the status messages and as a human, redo, redo, redo til you get the red device = failed response. Then you click the "Replace Failed" and watch the status go through another is failed before it tells you it removed.
The hub does the same but it has to hand off to the chip and let it run in the background. It handles the simple/normal cases well.
So basically in the case where the device is, obliterated, powered off, off site, or otherwise obviously unreachable the only thing to blame is the SiLabs Z-Wave firmware. Because it is frequent where this happens on the C7, the remove fails. But then with PC Controller it works fine on the first try.
Something is broken with the remove process on the newer hardware for sure and I wish Silicone Labs would figure it out and fix it.
I don't want to be disrespectful, Bobby, you are pretty awesome. But a lack of patience is not the issue here. When a device is bricked, and taken off power completely, the remove, refresh, etc inside Hubitat simply doesn't work. The network replies "busy" 99% of the time. I have waited weeks and it does not self-resolve. This has been the case for 3 years with hubitat, on a C-6 and C-7 hub. I have 100 zwave switches and dimmers in my home.
I'd also include device manufacturer firmware. Something is responding. Yea, the real one might be in a drawer, but no one can be certain that a repeater isn't responding (proxy) in error. FLiRs would be a ultra specific example of how it's designed to work that way.
I think it's a "diminishing returns" situation... 90% work 1st Hub try, 90% of the remainder work the PC Controller 1st try, and the 90% of the little remaining needs multiple swings to cure. We know of stories where 2 weeks later, suddenly it works first time. I agree that SiLabs needs to explain how this can work 100% of the time.
I've seen it take several days sometimes to remove a ghost. Usually in the case you describe it may say Pending. But in the end, the overall issue is the SiLabs SDK which can only be fudged so much and still retain certification. This issue isn't limited to just Hubitat. The issue can/will happen on any 700 certified hub.
Thank you. I didnt intend this to just be a rant. If the real answer is "the SDK is limited", is there some way we as a community can help voice the need to Silicone Labs? Is there a way to provide feedback to them we can all engage in?
I never had a ghost that I wasn't able to remove on C-7, so I wouldn't be able to answer your questions based on personal experience. However, we have seen reports that some users with stubborn ghosts on C-7 were able to remove them following the C-8 migration (process is the same >> click remove button on the Z-Wave Details page when available).
Was more wondering if the sdk was the same or
different under the hood. If there was a force remove option for instance whether it thinks the device is powered or not. Sounds like it is the same. Thanks.
I have an old Aeon Z-Stick S2 which has the ZW0301 chipset. My guess it is a 300 series (the stick is pretty old).
I have the SiLabs PC Controller up and running, shows in the Hub Z-Wave status. However it is unable to delete a "ghost" node. It did recognize it as a failed node but no combination of Remove/Remove Failed/ Replace Failed was successful in removing this node.
This node cannot be removed from the hub although others can.
This sit he second time I've tried removing this node with the SiLabs PC Controller.
My only thought is the old Z-Wave chipset in my Z-Stick is not up to the task. I plan on purchasing a Zooz with the 800 series chipset and see if I have better luck.
In my limited experience with the C8 (and my experience is not representative) I've had a bear of a time with one or two ghosts. I suspect a deeper unidentified and unresolved zwave issue in my case though.
I kinda like them for places that are inconvenient to get to so you dont want to have to be constantly replacing batteries... but this one I just lost patience with. The magnets are a pain though.
It looks to me that you poured sugar in the gas tank, although the Mythbusters debunked the myth that is the end of the world for your controller.
Jokes aside, your Z-Wave radio is bombarded with messages and you cannot remove the ghosts. How you ended up in this situation is hard to tell. How you get out of it, is even more challenging.
