Zwave get updated 7.17.1

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?

2 Likes

Playing with the ZWave stack isn't something I'd like to rush, better to let them take their time and test as many scenarios as possible...

5 Likes

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.

16 Likes

All we could ask. =) Thank you sir!

1 Like

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.

1 Like

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?

6 Likes

Strongly agree...doing a z-wave stack update isn't something that should be done in a hurry.

1 Like

A few things:

  1. A very active community on GitHub.
  2. They got it picked up the technical press.
  3. 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.

5 Likes

I also heard that chocolate was involved. Moves mountains. :wink:

4 Likes

@dman2306

  • 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).

11 Likes

Excellent summary, thanks.

1 Like

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!

7 Likes

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 :slight_smile: .

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... :confused:

5 Likes

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