Kills power to the switch - it won't control lights/circuits it's connected to, and won't broadcast at all. Essentially like killing it from the circuit breaker.
Well, that’s what I thought, too, but this may be the case of two people (you and me) opining without definitive knowledge of the facts. I only speak authoritatively about code I wrote unless I can view all the source.
That said, regardless of how cloud Z-Wave restore works, because you have a cloud backup to restore, seems like you could blow everything away with a full (not soft) reset to factory defaults and do a cloud backup restore to that.
1 Like
Except for your zigbee devices... which I think would have to be re-paired though they would slide gracefully back into their existing slots, so to speak.
1 Like
I am far from a Zwave expert, but my understanding is once the radio is corrupted, that is it. Maybe @bobbyD or @bcopeland could confirm?
+1
@dman2306 Could you humor us and post a screenshot of your Zwave details page? Or better yet, a screenshot using Tony Fleisher's Zwave Mesh tool? I would be curious if there is something in there we could see that might be the root cause of all this.
1 Like
Yeah but the cloud back up only goes back so far... If the z-wave db was corrupt when it was backed up, the backup databases are going to be corrupt too (not like the regular platform db which is cleaned on backup)
Now at this point likely a full reset of the z-wave radio is needed. But even with that, if you have those devices on your mesh that corrupted it in the first place will likely corrupt it again. The worst thing about it is regardless of who it is (HE, HA, Etc, ) With the current way the z-wave sdk is, it would still be corrupted by those devices. It's not just a hubitat thing, it's a 700 series chip thing.
3 Likes
The restore I did was from before the power outage and back when everything was working fine.
2 Likes
That doesn't mean corruption wasn't already present. Do you have any of the zooz double plugs? They are well know to corrupt the z-wave database
1 Like
No. Honestly I’m open to ideas but this sounds like a wild goose chase. The problem began exactly at the power outage. It’s reasonable to assume that is the root cause and I have zero evidence of prior corruption. Everything worked perfectly up until that point and thus evidence points to that event resulting in the issues.
3 Likes
At this point you could simply reset the z-wave radio (without resetting anything else) Re pair all your z-wave devices (I still would leave any zooz dounble plugs or 4-in-1's) out of the mix and see if things work then. If not, you can always restore the radio from previous backup. The 700 chip previously had been so subject to corruption I would do this to completely eliminate a problem. But that's just me, I won't live with issues like this if Ive tried everything else. I don't mind restarting something. Better than pulling my hair out.
Well, that approach has been ruled out, I believe, for reasons I can understand:
I’d suggest hooking up the Z-Wave Toolbox and see if some failed device is chattering and hogging the mesh. That would seem to be consistent with the one-way communication mentioned above:
You sound like the perfect candidate to work with Bryan Copeland (@bcopeland) as the lead beta (alpha) tester of the new Silicon Labs firmware for the Hubitat Z-Wave 700 radio.
1 Like
Just did that. I see a few failed device messages (no idea how figure out what device it is???)
What I do see is hundreds/thousands of CRC16 checks. I know what a CRC is, but I have no idea why they're happening so much?
I think that they (the 'CRC16 command' logs) are not flagging a CRC errors but indicating that the command is encapsulated with an additional CRC-16 checksum (which is kind of unusual).
When Z-Wave is running at the 9.6kbps data rate (maybe 40kbps too, I'm not sure), commands only use an 8-bit simple checksum by default which not good at detecting burst errors. Optional CRC-16 encapsulation was added as a mitigation for applications that need better error detection (Z-Wave running at 100kbps uses embeded 16 bit CRC's and does not need further CRC-16 encapsulation). @JasonJoel can probably elaborate on this.
2 Likes
Thanks, Now that you've said that I'll have to try it on different devices to see what they disable.
And my comment was regarding Jasco/GE/Honeywell switches and Dimmers, paddle style, as those are the devices w/air gap switches that I have experience with.
That's OK, your comment made me think all I have to do to check is pull the air gap switch then try to contact it with my Hub.
1 Like
Normally, the number on one end (1) should be the Hub, and the number on the other end (81 or 31) should be the same number as is in the Z-Wave details page.
1 Like
Did you spot anything? I've noticed other things lately that seem indicative of problems bigger than just zwave, for example all my Simple Automation Rules no longer work when the door closes even though the rule hasn't been touched and has worked fine for months, see Simple Automation Rule Stopped Working it's making me think something bigger is wrong than just zwave (some kind of corruption?) Unless I uncovered some unrelated SAR bug at the same time (note I have several similar rules and they are all broken)
1 Like
I am going to move your post in its own thread, as this one went in many different directions. Please add more details about your specific issues. Screenshots of Z-wave details table would be a good start.
