Very true. I get your point. Also, displaying that information without providing tools needed to fix it can be equally frustrating. In my case, support indicated the existence of the stranded devices to me, but I had to use third-party tools to remove them ......
1 Like
Just throwing this out there as I don't know if this is a valid idea/process or not.
If you have a ghost zigbee device, could we get the DNI.
Then could we define a device and allocate the DNI to it and allocate Generic zigbee switch or something.
If we then deleted that device would it then remove it as a ghost device.
I'm sure we were able to do something like this on SmartThings but I'm not sure.
My mind keeps going back to the idea that we build home automation SYSTEMS. My System is pretty large, 3 Hubitat hubs, 1 each: SmartThings, Homebridge, HubConnect NodeJS, Smartbridge Pro,
The Administration component of my System isn't small. Lots of upgrades plus my own desire to add in the 4th Hubitat. I have augmented my System with OZWCP and Zensys Tools for years. I've found that Silabs ZWave tool PC Controller is my current favorite. But the point is, I don't consider them differently from say.. Homebridge, or Lutron SmartBridge Pro or Hue or a Raspberry Pi. All 'round off the sharp edges' of my total system.
"Third Party Tool" in my vocabulary isn't anything to be shy of. "I have a Need --> this is what does That" where I don't want to have 300 tools when 4 will do the job. 
And it's that last that adds me to the chorus of "add these tools Hubitat" because I see there value for the subset of "us" that are trying to get the very most juice from this Hubitat fruit. LOL
2 Likes
Yes we do. Hubitat, however, does not. They build a single device.
Yes I would like to see them add tools and diagnostics, but surely you can't expect them to cater to someone that chooses to make their system really complicated (even by home automation standards) like you, though?
2 Likes
How does one find and remove these stranded/ghost devices? I suspect that could be part of my issue with commands taking 5+ minutes.
There is a big difference between a "stranded" device and a "ghost". I will try to break it down. A ghost device is a device that has been removed from the controller but is no longer active on the radio. These are automatically removed during the nightly task. Things may be rocky for a day or two while they are in the process of being removed. Slow down can happen but rarely frozen mesh. I would not worry much about these, as they can exist in the system without much impact. On the other hand, a stranded device is a device that is active and continues to communicate with the radio but doesn't have a corresponding driver attached to it (this will change soon). These devices can bring a mesh down. The only way to remove them (without 3rd party tools) is to make them inactive. To make them inactive, they must be powered down. A reconciliation of devices listed on the Devices table with phisical inventory of devices in a home should highlight which devices may be stranded. Taking the batteries out or unplugging devices that don't exist on Devices table would stop the communication with the radio, and as result, the radio will mark them dead so they can be removed during the nightly tasks. If the device continues to be powered, these will remain active in the system.
4 Likes
Correct me if I'm wrong @bobbyD, but a stranded device can occur is your don't exclude a Z-wave device and just force remove it or if a Zigbee device is not powered on when removed from the hub then subsequently gets powered back on. In both those cases, the device doesn't get reset so it's still trying to talk to the hub but they hub doesn't know who they are so it just ignored them.
It's like getting a wrong number over and over and over again.
1 Like
In other words, turn Stranded into Ghosts 
where they get automagically removed.
2 Likes
It's good now to have some specific explanation and instruction on what to do and why 
Sounds harsh but I guess the developers don't use GH as speakers so it feels like its not a priority
Nope. According to the email I got from Bobby, they use it and have no issues...
"For some users, including our own Hubitat staff, the integration works without a problem, for others, such as yourself, the integration creates problems."
Ha ha ha, that made me laugh (but not in a sympathetic way).
The email states they are aware of the issues in the field but as I said above they are unable to prioritise resources to this project at this time. Incredible but true (I suppose since they don't have issues themselves it's probably less of a priority for them than it might be for many of us, despite the fact they recognise this is causing issues in the field). If their hubs were seizing/slowing up with this as the cause every day (as they state it is for mine) I guess they'd soon prioritise it. My question is how come all HE staff don't see this and yet we do?!?
Anyway, it's good to know they are working hard to fix other root causes for issues that are maybe more serious.
I wouldn't assume that. I would think it has a lower priority because there is not a large number of users with that same problem.
Try power cycling the Chromecast devices. Also if you screen Logs (Past Logs) you can identify the nonresponsive Chromecast devices. Disabling Chromecast Integration is just one way to resolve the problem, temporarily. Or at least doing so clears your hub's logs so that other problems can be highlighted, which otherwise are buried in the Chromecast errors.
2 Likes
I don't see Chromecast errors at the time of slow downs and crashes... In fact I rarely have any issues with my Chromecast devices. I use TTS all the time and it works ok. That's why I don't believe this is the root cause of my issues to be honest.
2 Likes
Latest update. The UPS is installed and working. So now I'm pretty sure that any power spikes or interruptions can't be causing issues. Still, the hub just rebooted itself this afternoon (no app did this, the hub just decide to crap out and reboot). This time there is a log entry error related to Chromecast (but with timestamp after the reboot, not before). And 3 motion sensors dropped off the mesh. My woes with this crappy situation continue...
I think I will try another soft reset and shutdown/reboot today, now that the UPS is installed.
Try a beefier 5v power supply as well. That has helped other users with hubs that have rebooted themselves. I have been running three hubs for the better part of 2 years, and none of them have ever rebooted themselves. All three are on a UPS.
2 Likes
Imagine that.. You don’t want to follow the troubleshooting steps to actually diagnose your issue.. So you continue to have problems... I have no idea why your problems don’t just magically go away...
4 Likes
As I have learned, the data accessed by @bobbyD when he troubleshoots hub slowdowns exceeds what is shown in the logs that are displayed to me.
It is entirely possible that your hub has Chromecast errors that aren't visible in the logs displayed to you.
2 Likes
I had the Chromecast(Beta) integration installed a while back and had nothing but problems with it, including bringing my hub to its knees over time. I removed it and haven't missed it at all. I use Amazon Echos for most of my voice assistant needs these days, including TTS.
4 Likes
Thank you, Yes I was thinking to try that if things don't improve through the various other things I'm trying.
