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.
