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.
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.
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. )
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
(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.
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?
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!
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.
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?
Create a virtual device (say a switch) and name it place holder (or whatever you like) and change the rule using the device that you're changing out to place holder (or what ever you named it) exclude and reinclude (click skip when prompted) and then change the device back to what ever you named.
There can be some benefit to S2: it allows the use of Z-Wave Supervision, which is one way drivers can help make sure devices receive commands sent from the hub (send the command, take note, wait, and try again if no report back for that command: this is handled at the application later, which on Hubitat is the driver--not lower down, where any kind of Z-Wave also has some means along these lines with which I am less familiar). Maybe that is the discussion you've seen? Not all drivers do this, though I think most built-in ones do if there device supports it.
S2 does not cause the amount of overhead that S0 does, and I don't see you with any S0 devices, so that's good! I do think, anecdotally, that some device firmware may not have been as well tested with S2 (certification be darned), and some people will still recommended avoiding it for various reasons. FWIW, I think all gen 2 Inovelli devices are paired with S2 (just because I wanted to test the setup that o assume most users would use: the defaults), and most haven't given me any trouble except old firmware during pairing, they've released an update for at least one device recently that may help (as SiLabs' fix might in the future if this is indeed the problem).
No.... The database in the z-wave chip doesn't work like zigbee does. Regardless of the platform you're on they all operate the same in this case. I think you can try the replace, but I don't think that works with devices with the same id... (someone will correct me if I'm wrong). As @bertabcd1234 points out, there can be some benefit, but my own opinion is lessening the overhead of any encryption helps overall. If you are satisfied with the speed of your mesh after removing the ghosts, you can just leave it as is...
Yeah, about that ... at one point, I had started a discussion on the idea of using Supervision to increase reliability. I was motivated to try and find a solution to increase reliability because I would occasionally have periods where devices disn't respond, or had huge delays. I thought this was packet loss (many advised that these situations were issues with mesh strength). So, in theory, it seemed that Supervision would help allow recovery if a packet was lost (at least I thought it might). Turns out, as I've learned more, for non-secure devices, you're better off just letting the normal Acknowledgement / Retransmit routines in the SDK do the recovery (its simply too hard to accurately do the necessary Supervision timing and coordination, and as the Ack / Retransmit at the SDK level should already be handling things, its unnecessary overhead complicating the drivers). In the end, I learned that the only time its necessary to use Supervision is when using S2 security where its is necessary in the event that some of the security setup packets are lost.
So, yeah, using S2 for reliability turned out to be just wishful thinking. I went the opposite direction and removed all S2 from my network and reliability increased.
As for the initial problems I was trying to solve, I'm now convinced they were (largely) related to z-wave SDK problems. Some of the problems have lessened over time as the SDK used in Hubitat has been updated. Recently, there's postings about a new Z-Wave SDK 7.17.1 which looks like it may be the "fix" many of us have been waiting for (the notes in the article describe delay issues and other problems I'm still experiencing). Hopefully Hubitat gets it implemented soon. Zwave get updated 7.17.1 - #47 by 672southmain
