I think the above answers are probably more technically correct, but remember that Hubitat was the only 700 series for a while. Once the 700 series chips hit a critical mass with the introduction of these other ecosystems, it probably became less easy for Silabs to ignore the isolated (Hubitat only) reports of trouble.
You would think since Hubitat was the flagship for certification and showing the benifits of the 700 series chip that SILabs would have listened a bit more,.
2 Likes
I should have said above that I was completely speculating how it happened.
But yea, you would have thought SL would be carefully monitoring the early adopters for issues, and been right on top if it.
1 Like
Oh I get that.... Didn't think otherwise.... Eitherway it seems that SILabs has been really not giving a crap
3 Likes
Warning hearsay âŚ
I was told on the grapevine that it maybe canât be fixed in early 700 hardware.. requiring either more recent revisions or 800 series. I have absolutely no reliable information to back this up and it came from a group of other users with vested interests.
3 Likes
Time will tell. It wasn't a big problem for me pre-7.17.1, so now that it seems even more stable in 7.17.1 I'm probably fine as-is.
But that would stink for others that aren't fine in 7.17.1.
2 Likes
I think the controller cost must be considered. Itâs an inexpensive item, IMHO overly so given itâs complexity and ongoing support investment. SmartThings set an unrealistic commercial price for such a product and it hasnât, again IMHO, resulted in storming the market. Itâs not a significant component cost within the complete system. Maybe two sensors cost. If you have to bin it and upgrade to gain such extra/working feature support then so be it.
An HA system controllers warrant a facelift or a day off pampering at the spa. If that doesnât work then look around at the younger models.. thatâs life.
2 Likes
I bought an expensive car - surely it should now be able to run on unleaded and even this new âelectricâ fuel 
FWIW, I have early 700-series controller hardware, and the vendor indeed told me they did not have a way to update the radio firmware (at least when one of the first updates came out--and they still might not, though given the limited beta run I doubt they'll put any more effort into it regardless). I don't think I'm at liberty to disclose who/what this is, but we have heard Hubitat staff confirm that they are testing 1.17.1 internally, so I don't have a reason to suspect that the C-7 is affected. 
3 Likes
The hubitat C7 hub has already had 1 zwave 700 firmware update since its release (7.14 to 7.15). So I don't think there is a question whether it technically can be updated or not.
4 Likes
Actually this was a bad analogy based on cost. Replacing a controller carries a huge cost based on the time and emotional effort involved in re-pairing all devices. Some protocols worse than others but ZWave at least is retainable.
Not yet mentioned - SiLabs may be paying more attention due to the competitive threat from Thread/CHIP/Matter.
5 Likes
SiLabs also makes Zigbee and Thread chips.
3 Likes
Non-sequitur. Who else makes Z-Wave chips?
Any info on how you were triggering it?
Basically nobody. Sigma Designs acquired Zensys (the Danish outfit that invented Z-Wave) and was the sole source; they licensed Mitsumi Electric as second source (for 500-series only) in 2014. Silicon Labs bought Sigma Designs in 2018.
4 Likes
Interesting - I did not know that history, nor the sole source part for Z-Wave chips. So any 700 (and presumably 800 when available) Z-Wave chips come from SilLabs.
3 Likes
Do a mesh heal, pair a few devices at the same time and/or re-interview a few devices at the same time. In a nutshell, make a crap ton of traffic until the controller loses its mind and stops sending ACKs - then the â â â â storm begins as every other device trying to talk re-transmits their payloads since they didn't receive an ACK.
For me it is definitely much harder to make it happen on 7.17.1, but I can still get it there if I try hard enough.
In practice, for me I think they have fixed it "good enough". If I had a ton of baseline traffic (power monitoring on multiple/many devices, for instance) I don't know if it would handle it. But I don't, so.... 
3 Likes
This is basically what I feel causes a lot of the problems everyone has. Chatty sensors or power reporting, or just having a large group that sends off a lot of messages at once. I have learned to add delays into everything, which IMO we should not have to do, the controller should not send commands out faster than it can handle the replies.
I think this is why some of the chattier devices get a lot of route changes as well, I have seen the Acks come back slower than the device expects or possibly not at all, and after a few times of that the device goes into a route finding frenzy and causes even more problems with all the messages they send out.
If that's what this new 7.17 fixes (or makes much better) it will be a great improvement.
1 Like
In this specific issue/case it is really that the DEVICES send data in faster than the controller can handle/respond to. Really the complete opposite situation as you described, and the controller has zero control over what the end devices decide to report - except in the cases of heals and interviews.
I've never been able to make the specific issue being described happen with normal command class calls only (unless you want to consider a re-interview command class calls, but that is a weird edge case).
Not saying you are wrong in what you are saying, just that it isn't the specific issue that was addressed in 7.17.1 (controller sops sending ACKs). MAybe the changes in 7.17.1 will help the issue you describe as well though!
