Hi,
I’ve had a new firmware provided by Chris, 7.21.0. I applied it 3 hours ago, and haven’t seen a single jammed status since. I’ll report back when its been in place for 24 hours, and see where I stand then. 
I’m definitely interested in seeing if it holds up for you. I’m running 7.17.x and it tends to go 24-36 hours at most in between Jammed events. My last event as of right now was nine hours ago.
Sorry, not good news. It looked promising yesterday, only 2 jammed events. Today though has been a different story, we’ve had about 6 events in the past 40 mins. No change to config deliberately, and less people home all morning too 
I’m going back to re-enable my 3 hourly restart of the z-wave add on, which appeared to work fairly well. 
Any chance you could join the convo over here to share your info?
added my 2p to the discussion. I’ll try and get log files showing the issue tomorrow, on the 7.21.0 firmware.
1 Like
Any good news? I’m also struggling with my z-wave-network since Sep. 2023. Changed from Aeotec gen5 to gen7 stick. Since then the network is unreliable, status of devices is often wrong (e.g. roller shutters show wrong degree of opening). It’s pretty frustrating. Before September gen5 stick run without bigger issues. After z-wave update in Sep. gen5 seemed to be no option for the future, so I changed to gen7.
Does anybody know, if other smart home software like openhab have the same problem with z-wave gen7 sticks?
Yes, the problem is with the 700 chip made by SiliconLabs, so all systems are suffering from this.
Even in their new firmware (released this week, will still need a few weeks before Aeotec makes this available for the Gen-7), the bug is still present (see SiliconLabs release notes for the 7.22 firmware).
That’s the reason I went back from a Gen-7 to a Gen-5 stick, I was fed up with the frequent jams of the controller and slow or none response.
Whole process to go back to a Gen-5 is very simple, download the NVM data from the Gen-7 stick (using ZwaveJS-UI), translate the data to Gen-5 format (there is a tool for that) and upload the data to a Gen-5 stick again with ZwaveJS-UI.
Did this a week ago, and after 3 months of frustration with the Gen-7, I now have a perfect running zwave system for a week.
The issue is not with the 700 chip specifically.
SILabs makes the chips for vendors to use in their products and releases Software Development Kits (SDK’s) for the vendors to use to create firmware to run the devices. The SDK’s for the 700 and 800 series chips (apparently) has a bug in it that causes ALL firmware developed by ALL vendors to not be able to handle certain communications flows correctly. Until SILabs patches the bug in the SDK’s, there NO ABILITY to create bug-free firmware.
Correct, all 700 and 800 chips suffer from this.
As I said, I moved to a gen5+ stick (500 chipset), since then no problems anymore. I trashed my Gen-7 stick, have no confidence in SiliconLabs solving the issue, is going on since gen-7 was first released, never solved.
What you “said” is that the defect is in the chip and that “all systems” are dealing with the problem. The issue is NOT the chip - it’s the software, even though you have again stated this in a way that implies the problem is the hardware.
And if SILabs ever gets off their collective rear end to fix it, the product vendors will be able to compile new firmware so it works properly. And if they don’t, it’s going to result in a decline on further use and adoption of ZWave to where they won’t have anyone to sell the hardware to going forward.
500 series chip-based controllers are “fine”, but also lack certain features that the 700 and 800 series chips offer. So, going backwards is not a solution - it’s a temporary workaround at best.
It’s also not accurate to state that “all systems” are dealing with the problem. I have a Zooz 800 series stick (ZST39 LR) running 7.19.3 and (at least so far!) have not experienced any noticeable jamming issues. I’m not denying there are serious issues… just clarifying that they don’t seem to affect everyone in the same way.
I would actually support the premise of this being dealt with on “all systems” (that use a 700 or 800 series controller). The size of the system, the exact configuration of devices, and other variables can factor into how often an issue occurs where the controller ends up in a "“Jammed” state.
You can look at the status of your controller and zoom out to see how long ago it entered the Ready state. And as you look back further in time, you should see that there are status changes occurring that you aren’t even aware of.
Fair clarification. I definitely see “Jammed” a few times a day in my logs, but since it only lasts for a few seconds each time, the noticeable impact is low. At least so far. And for reference, I currently have 33 standard and 2 LR devices connected through this stick.
I have about 50 devices, a 700 series controller stick, and see state changes a couple of times per day. The issue isn’t so much that it goes into a Jammed state because it does get recovered fairly quickly (a few seconds, typically) but WHEN that happens. If the state change occurs when my system is attempting to collect information or react to a trigger, the control commands can get lost and not execute.
I have spent a considerable amount of time minimizing the amount of communications on my network in an effort to reduce the likelihood of the Jammed state occurring. This is why I have said my system is relatively stable in terms of its overall operation, but I do still experience the odd incorrect behavior here and there.