He got a copy of Zensys's Tools working. Zensys is the originator of ZWave and they had very very low level tools available for ZWave device developers. The tools have leaked to the Internet and people can get a copy and do significant damage to their Wave network with them or improvements. Skills being the differentiator
There's a 2nd tool available called OZWCP (Open ZWave Control Panel) that is similar. It's based on the Open ZWave project and calls OpenZwave code to do those low level actions.
Once the tool is functioning, you tell it to "find" a ZWave usb stick and then clicky your way through the process. For "ghost" devices, you ask the Controller (the usb radio stick attached to the tool) to verify the health of a device. It will almost always tell you it's fine. Even when it's not. Ask repeatedly and eventually it discards the cached status and confirms the node is dead. Then you can run the low level command to delete the failed node. Your "ghost" is gone. Rinse, repeat.
There's a recipe for OZWCP in that thread. It's an OLD thread and I'm only going to say the recipe is the part of it I'd keep TODAY. Back in February, that Thread was useful. Today, barely.
A frozen hub is a sign of an unhealthy hub. A power cycle may be required to bring it back to life, on exceptional basis. But without identifying the root cause, the exception becomes the rule and the experience turns fast into a nightmare. Usually there are signs preceding this event, like diminished responsiveness. Screening the Logs for errors may prevent a frozen hub. But if it happens, I strongly suggest reaching out for support. Plugging the Hubitat Elevation hub into a smart outlet is not a solution.
Completely agree I should have clarified because above there was conversation of rebooting periodically/proactively to prevent lock ups. That is why it would be nice if a scheduled reboot could be setup within Hubitat itself like I can do in other computer systems.
This is an anti-solution, and a not a good idea. The better idea is to find and correct the problem. If you are having to reboot for any reason to make your hub work, you have a problem that needs diagnosis. Contact support, don't just keep on rebooting as a fix --- it's not a fix at all.
We have customer hubs that have run continuously without updates or reboots for over a year. This is to be expected.
Years ago I invested in a Digital Loggers Web Power Switch. Its expensive but worth in my opinion. I have all my network closet gear plugged into it and I can power cycle everything with a click of a button and it will shut them all off and turn each back on at a defined interval. It can even ping a site and automatically restart certain outlets too such as modem and router.
There was even a DTH for it in ST land that I haven't ported over yet. You can buy them on Amazon and it appears like they may have a new "pro" version too.
I am close to one of these and not experiencing issues fortunately. But as others have said here in the forum reboots have been necessary so its just a suggested. Take it or leave it.
I want to believe that the Hub doesn't need a periodic reboot. I've been wrong before... I can remember a time 3 years ago... ...
The ONLY time I've rebooted the Hubitat Hub (and I also have 2 of them) is during Upgrades. My Hub Event's log is nothing but code upgrade events. By that I only mean, there's no inherent ... oh Darn!! I see Bruce has replied and said it better! That guy!!
I have to say that's not a fair statement. I'm following Hubitat's advice to the letter, to the point to where my hub is no longer as capable as I need it to be. But thus far no solution has been provided to the frozen hub. I have no choice, daily, but to pull the plug and reboot. I'd love that to not be the case, which is why I've been in contact with support, long before posting here.
Without a solution coming out of my contact with support, I need to look at what other options there maybe so that I can find the problem myself. Absent access to the logs you guys have through the backdoor, I have no other recourse. I'm admittedly no expert in this area, but things can't continue as they have.
But your case is exactly what I said. If you find it necessary to reboot, it is time to get support involved. You did, and as a consequence your problem is going to be resolved — at least the one we know about. Net net is that contacting support and getting to the bottom of an issue is going to benefit you and anyone else that has the same issue.
I’m suggesting that having to reboot is a sign of a problem, and that doing so out of a random belief that it needs to be done otherwise is not the answer.
I used a third party tool and investigated the tables on the zwave radio, finding two 'rogue/ghost' devices. One of them has been a very problematic device. I have no idea if this will impact performance and reliability, as Bruce states these get cleaned up periodically. None the less, I removed them and I'll let it be overnight. If it doesn't crash, I'll reintegrate my custom telnet driver tomorrow. If that doesn't crash, it's probable that ghost nodes are the problem. If it does crash after reintegration, then it's pretty clear that telnet or specifically my driver is the problem.
or improvements. Skills being the differentiator 
