I was perusing a thread on the issue. It seems most people are seeing anything from some improvements to nearly euphoria. But, it also seems to involve running a full mesh repair--and devices that should be 1 hop (based on running 500 series firmware) are often 2 hops. And, some are still having some issues.
All in all, the comments sounded hopeful that it was better than before--but it kinda seems it might need another .x or so to fully shake out.
At least it seems SiLabs is finally (after how long???) getting into the meat of the matter.
Fingers crossed...most of the issues I'm now experiencing would be easily explained by the bug they seem to be working on stomping out.
The 'fixed issues' section seems kind of sparse. Nothing actually calls out neighbor discovery or repair fixes, but there is a reference to a problem with Assign Return Routes (yet listed in 'known issues in Current Release'... does that mean it is not fixed?).
The (listed as fixed) FreeRTOS tickCount overflow bug sounds interesting; PIR sensors in EM4 (deep sleep mode) apparently stop working after 49 days. But a hub update won't cure them if FreeRTOS that the note is referring to is the software running on 700-series SoC's in the sensors.. I assume that would require a sensor firmware update.
The link @danabw posted earlier really does have some interesting commentary that actually gets into the issue of concern--and it points off to the 7.17.1 release as being a potential fix...
Rather specifically, the comment says:
It seems that 700-series sticks (including the currently latest firmware 7.17) have some problems which mostly appear on networks that:
are relatively busy (lots of unsolicited reports like motion sensor, power meters)
are large and/or
contain some battery-powered devices
When lots of reports reach the controller in a short time, the 700-series sticks are not able to send any message.
It looks like the stick is somehow blocked and simply doesn’t send anything, maybe not even the protocol level acknowledgements for receiving the messages, causing end nodes to repeat their messages over and over, making the situation even worse.
We're working with Silabs to get to the bottom of this. Please don't open any further issues.
We believe the following symptoms are all caused by this:
Huge delays (up to 60 seconds) when sending messages
Failure to send anything (TransmitStatus: Fail)
Floods of incoming reports that are transmitted over and over
Incorrect neighbor information (e.g. controller doesn't list some/any nodes as neighbors, etc.)
Failure to heal the network or individual nodes, especially in busy situations
The thread describes problems that I've been having a long time - its good to see there may finally be a fix. I suspect Hubitat's 2.3.1 firmware is pretty well baked by now so I'm just waiting / hoping to see if it is in there! Its been almost 3 months since the 2.3.0 beta, so hopefully the 2.3.1 beta comes out soon and we can see.
Oh wow. This actually answers some recent issues I was seeing. In my case, it’s gotten bad enough that the whole stack seems to partially fail. Some stuff will keep responding, but the hub stops logging Zwave related stuff at a certain point.
@bcopeland any hope for us seeing this update sooner rather than later?
No promises.. But we are testing this internally, if internal testing goes well before beta then it will likely be in beta. If it goes to beta and tests well there, then it would be in the public release.
X 2 , I am quite interested in this myself. Having some odd issues with several devices but one in particular FLiRS device that the manufacturer and I think is related to the SDK, specifically the 700 series.
The only thing I'll mention here is, why have we been complaining about this for over a year and SILabs seemingly didn't care. But then zwave-js reports an issue on 12/15/21 and SILabs claims to have fixed it within a little over a month (which is actually SUPER fast for a firmware release for an embedded device)? What gives zwave-js so much more pull with SILabs than Hubitat?
They were clearly more vocal and focused in their efforts.
I'd add that Eric Raymond's Cathedral v/s Bazaar analogy is quite apt here. Open-source stack permitted technically proficient end-users to present the issue with greater voice than a closed source stack with a smaller number of developers, even if the "cathedral" is a paying customer v/s the bazaar.
They gave detailed, and fairly easy to reproduce, steps to replicate it directly to SiLabs.
They provided volumes of zniffer logs to back up the findings. From multiple hubs, showing it is not an isolated issue.
They got 3 other vendors/systems to chime in and support the claims / say they have seen this too.
It took quite a lot for it to gain notice and get action from SiLabs.
Although I will say that in my testing it does not seem to be 100% fixed - I have been able to get 1.17.1 firmware to stop ACKing, just like before. I will say that it took quite a number of tries to do it (so it does seem much more resilient than before) - whereas before I could get it to do it in about 5 minutes (after I knew how/understood what was happening with the issue).
Fair points, I guess my feedback to Hubitat would be though, in the future instead of saying "it's just the way zwave is" or "it's just because you built a weak mesh", maybe, just maybe, there is actually an underlying issue that needs to be addressed. I kind of wonder how vocal Hubitat was given that most threads on here seemed to lead towards a suggestion that the issue was on the user's end, not the hub/radio/firmware. Just my 2 cents!
I've never even heard confirmation that Hubitat was able to reliably reporoduce the issue on their end. There is only so hard they can push/report something if they can't tell SiLabs how to reproduce it...
But I don't know what Hubitat does behind the scenes. I'm not an employee .
If the issue were easy to identify/understand/reproduce it likely would have been fixed 18 months ago... I certainly wish it had been, as I've had my own challenges with zwave 700 on and off that I couldn't quite explain...
.
