A few nights ago, the class of every device in my Z-wave mesh changed from SPECIFIC_TYPE_* to BASIC_TYPE_*, and everything stopped working. Any ideas? This smells more like a Silicon Labs issue than Hubitat, but wondering if anybody has ever seen this.
Not sure about that change but you've got a boatload of what appear to be ghosts there.
2 Likes
Usually when there's a ghost, the device name is replaced by a "Discover" button. And usually when there's a ghost, the controller is still working. I just tried adding including my UZB stick to the mesh and the hub isn't seeing it. So something is broken in the hub.
I also notice that all the speeds have dropped to 40K or 9.6K.
Those are outright ghosts. You need to get ride of them and likely re pair the devices. the 9kbps one is likely not routing through one of nearer powered mains because they're ghosts. Overall your mesh is a mess. 
Do you have any other devices showing no routes?
1 Like
Yeah, about half the devices show no routes. I've seen that before, but then when I ping the device it responds and a route appears. But I've never seen all the device classes change from SPECIFIC to BASIC or GENERIC.
These devices all became ghosts at the same time. The entire mesh was working fine, and then something happened and now nothing responds.
Try shutting down the settings menu, unplug at the wall (not the hub) for 20 mins. This will clear the z-wave radio and bring it back up and see how it is
1 Like
OK, I'll give this a try. Is there any science behind that 20 minute figure (versus 2 or 200)? Some really huge capacitor? Some tiny backup battery? And what difference does it make where power is disconnected as long as 5V goes to zero?
This issue with ghost devices appears to be really chronic. I have five different HE units at five different locations and all of them have had ghost devices appear at one time or another. And each time I need to break out the UZB stick and forcibly delete them. Can't someone write a plug-in to simplify this?
It's so the caps can drain out.... Probably 10 mins would do it but I tend to err on the side of caution. I also wonder about db corruption as well. But start with this (it's simple) and see if that helps you.
The recommendation to pull at the wall vs the usb connector is due to the fragility of USB connectors in general.
There have been lots of updates over the last few releases to improve zwave reliability and make it easier to remove ghosts should one occur, but I still occasionally have to reach for the zwave stick too.
1 Like
The issue is that the SDK that is required to be used by a 700 hub makes it difficult; the PC Controller software can utilize the older SDK and doesn’t have to jump through as many checkpoints which is why it has a higher rate of success.
4 Likes
30 seconds is what staff have recommended to fully power down the Z-Wave radio (which is not affected by a hub reboot or a regular shutdown if power is left attached). Sometimes people recommend 20+ minutes to make Zigbee devices enter "panic mode" and find new routes to the hub, but if your only concern is Z-Wave, you probably don't need to go that long. 
(On a slightly related note, I recently re-did my entire Z-Wave network from scratch on a C-7 running 2.3.0 and was amazed at how much easier this was than just a few platform versions ago--and definitely compared to the 2.2.3 or 2.2.4 era and original radio firmware. Not a single ghost was created except for a battery device that I think just died mid-way through pairing. Version 2.2.9 introduced SiLabs' new Z-Wave radio database format that should be less subject to corruption, and if your network is older than that, I'd guess that removing unwanted nodes should also be easier afterwards, though unfortunately I don't think an firmware upgrade affects the format if it was created earlier. Not fun, but worth it for me. )
3 Likes
Yeah, micro B is especially fragile. In my case the USB power adapter is integrated into the outlet, so I pull on the A connector rather than the micro B. The C connectors certainly seem more durable.
So, if I need to rebuild the mesh from scratch, is there any way to maintain my existing devices and logic, but just "repair" one at a time? If the answer is definitively "no", I suspect I will spend next weekend exploring OpenHAB.
You can make a place holder device and reset each device and repair it... That said, it wouldn't be any different with any other 700 series controller. It's an issue with the SDK...Not inherently hubitat
2 Likes
And the answer is ..... IT WORKED!
So, next questions:
(1) Why can't rebooting the hub reset the radio?
(2) Failing that, is there no "gentle reset" interface to the chip which achieves the same effect? (as opposed to the big red reset button that nobody ever wants to press?)
So, until there is some better remedy, I guess I need to pair a WiFi receptacle with every hub so that they can be power cycled remotely, or always install pairs of hubs so that one can power cycle the other.
1 Like
You don't want to just power cycle it, that will corrupt your working database. That said, rebooting the hub doesn't clear the radio because there is still power to it. Unplugging and letting all power dissipate resets it. Now if you shutdown from the menu remotely, with lets say 2 or 3 mins then shut down the outlet, that would be pretty safe I would think. How does your z-wave details page look now?
2 Likes
Great that you solved the problem but I think you still need to figure out why it happened in the first place, if you can. Otherwise it could happen tomorrow, and that would be a pain.
PS: I use PoE splitters to power my hubs. Shut down safely, recycle PoE on the port, tada!
1 Like
Yeah, I use PoE splitters at the office. I wish Hubitat would just build native PoE support into the hardware, which is pretty much the nicest package available today.
1 Like
Looks good but I would re pair all those devices that are paired as s2 and re pair them as none. Leave only locks and garage doors paired with security
Yeah, I learned that the hard way. I wish the inclusion interface offered that recommendation. Some other discussion in this forum recommended using s2 for mesh reliability, but I guess that's just wishful thinking?
Is there an easy way to repair a device without first removing it? You mentioned a "placeholder device". How exactly is that accomplished? Do I have to create a virtual device and use that in apps and rules?
