That's your opinion. The problem hasn't been solved.
Yeah the title: we're at .158 now, almost a month, and still no solution.
Totally valid.
I have like 10 ecolink sensors. Never had a hiccup. Most of them are still at 100% after 3 years too.
*edit nevermind I'm on C4s and C5s, so I'm useless here.
My experience aligns with your theory.
The open / close status continues to report correctly and quickly, but and resulting Z-Wave output becomes jammed. ie: the resulting automation is delayed and - while it's delayed - all other Z-Wave devices fail to respond. Once the automation "clears", everything runs smooth again. It's as if every time a contact sensor triggers an automation, Z-Wave output locks up for anywhere from 5-60'ish seconds.
1 Like
During the "delay time", if you manually toggle a z-wave switch NOT related to the automation, does its status update in hubitat (dashboard or device page)?
I'll check that when I return home. I can confirm that during the delay time devices not related to the automation don't respond, but I'm not sure if their status updates at all on their respective device pages. I can also confirm that - when monitoring the Z-Wave logs, it's only once the delayed automation fires that all other "queued" z-wave instructions for unrelated devices are transmitted.
This has always seemed like a key part of figuring out what's happening. I believe that folks who have reported the issue have been able to confirm via logs that the sensors are reporting promptly and accurately, but the automations are delayed or (less often?) don't run. Correct?
Correct in my situation.
Correct in my situation, as well.
yes exactly. the mesh becomes unuseable after the sensors reports open but before the action (light turns on) occurs
and it is not just the contact sensor although that is more common i have seen it with one of my ecolink motions as well..
I can do better than that. As I was waiting for the basement lights to turn on this morning, (they never did), I sashayed over to a couple other doors and their rules worked fine. But who knows.
Also, the issue appears to manifest after said contacts have sat idle for some time... If I'm opening the door / contact regularly, it doesn't manifest. Walk away for a few hours (or day), and try again: delay.
Yes, only mine was a Zooz.
True.
1 Like
If indeed there are people who are running without problems with 2.2.4.158 on C7 with Ecolink contact sensors, then they should pipe up and we could compare setups.
2 Likes
That would actually be helpful
2 Likes
Spitballing: On the C7, have you ever seen another similar issue where "something" caused outbound zwave commands to get queued or "hang"?
Not in my setup.. That’s what I’m trying to recreate..
2 Likes
Apologies, I meant in general, not just to this specific issue. Didn't know if there's other zwave specific situations that have cropped up in the existence of the C7 (or even before? but I get the 700 series chip is a new beast) that led to an investigation of how outbound zwave can or would be queued or hung before sending.
I understood what you meant ..
2 Likes
My production hub does not experience anything like this.. I have a pretty large z-wave mesh.. But I am picky on what devices I allow on my production mesh..
All my contact sensors are Ring V2 (700 series) and my “canary in a coal mine”, ie my first indication when something is amiss is my door chime.. Ring V2 z-wave S2 triggering my Aeotec Siren 6 S2 chime.. And since .153 I have not heard any delay of even a whole second. All in the millisecond range.
1 Like
