New Z-wave ZWA-2 Keeps Jamming. "The controlled is jammed."

[toxic frost]

Ever since I upgraded to the new ZWA-2, I'm seeing it jam at least twice a day. It results in delays on some automations, and in some rare cases, automations not firing during that 3 second windows of the controller not being able to transmit. It's not associated to just one "problem node" and seems to happen at random. Any have any advice for a fix for this issue? I knew when Zwave 800 first came out it had its issues, but I was really hoping it would have been resolved by now. My 500 series stick worked better than this.

Log entry:

2026-01-12 19:25:00.549 INFO Z-WAVE: [Node 006] Value updated: 113-0-alarmLevel 0 => 0
2026-01-12 19:25:00.549 INFO Z-WAVE: [Node 006] Value updated: 113-0-Home Security-Motion sensor status 0 => 8
2026-01-12 19:25:00.567 CNTRLR The controller is jammed
2026-01-12 19:25:00.567 INFO Z-WAVE: Controller status: Controller is unable to transmit
2026-01-12 19:25:00.727 INFO Z-WAVE: [Node 006] Value updated: 113-0-alarmType 0 => 0
2026-01-12 19:25:00.727 INFO Z-WAVE: [Node 006] Value updated: 113-0-alarmLevel 0 => 0
2026-01-12 19:25:00.728 INFO Z-WAVE: [Node 006] Value updated: 113-0-Home Security-Motion sensor status 8 => 8
2026-01-12 19:25:00.945 INFO Z-WAVE: [Node 006] Value updated: 113-0-alarmType 0 => 0
2026-01-12 19:25:00.945 INFO Z-WAVE: [Node 006] Value updated: 113-0-alarmLevel 0 => 0
2026-01-12 19:25:00.946 INFO Z-WAVE: [Node 006] Value updated: 113-0-Home Security-Motion sensor status 8 => 8
2026-01-12 19:25:01.708 INFO Z-WAVE: [Node 006] Value updated: 113-0-alarmType 0 => 0
2026-01-12 19:25:01.709 INFO Z-WAVE: [Node 006] Value updated: 113-0-alarmLevel 0 => 0
2026-01-12 19:25:01.709 INFO Z-WAVE: [Node 006] Value updated: 113-0-Home Security-Motion sensor status 8 => 8

[crimson bolt]

Share some driver logs on loglevel DEBUG that span more time than just a second. Something like 2-3 minutes before and after the problem.

[toxic frost]

Got the Z Wave JS Logs running on Debug. I'll send you something when it jams

[crimson bolt]

Thanks. I'll check it out next week when I'm back from vacation. Or someone else might get to it first.

[elder marsh]

Those aren't driver debug logs. See https://zwave-js.github.io/zwave-js-ui/#/troubleshooting/generating-logs?id=driver-logs

[toxic frost]

Gotcha. I'll get the driver logs this time

[brittle forum]

I'm getting jams all the time as well with ZWA-2. I saw SDK 8.0.0 came out on the 22nd of January. https://docs.silabs.com/sisdk-release-notes/latest/sisdk-zwave-release-notes/

I was hoping this might fix some stuff.

[toxic frost]

When will this be available for us zwave JS UI users?

Or is this the SDK version that the ZWA-2 uses?

I guess we're just waiting on home assistant to roll out an update with that SDK for the zwa-2?

I’m also getting these error messages. Anyone know why the node can’t handle being asked to turn on? It works about 95% of the time

[tardy galleon]

Thats the outward symptom of the controller being jammed when it happens for me

[crimson bolt]

Check Z-Wave debug logs

[crimson bolt]

There is a new beta firmware based on SDK 2025.12.1/8.0.0 -> https://github.com/NabuCasa/zwave-firmware/releases/tag/1.2.0

You can also install it through Z-Wave JS UI if you go to the firmware updates tab under your controller and enable the "include pre-releases" checkbox.

[toxic frost]

Awesome. Thanks AlCalzone

[tardy galleon]

When do you expect this new firmware to released into production @crimson bolt ?

[sly mantle]

It’s released now.

[tardy galleon]

How do u force a re-check?

[elder marsh]

It's still a Pre-release, which you can enable in ZUI

[tardy galleon]

Oh, OK, I'll wait forthe production release

[crimson bolt]

The more people test it and give feedback, the quicker we can promote it to stable

https://github.com/NabuCasa/zwave-firmware/issues/17#issuecomment-3928340961

has some positive feedback

[tardy galleon]

I did the update to 1.2.0 BETA and then saw a JAMMED within 40 minutes

[crimson bolt]

any chance you have the debug logs around it?

[tardy galleon]

Let me look if they are enabled

[tardy galleon]

Here are today's logs

[crimson bolt]

Which devices are nodes 4, 66, 75, 76 and 85?
Manufacturer / model / firmware version?

---

Node 4 (probably a motion sensor) seems to send BinarySensorCCReport, often followed by redundant BasicCCSet to the controller. There are several instances where it even repeats some of those commands, possibly due to bad connectivity

For example, the one "motion detected" event at 07:53:28 results in 8 actual reports over 4 seconds.

Similar instances happen a couple of times throughout the day, with at least 1 leading to a "jammed".

---

Nodes 66 and 75 send their motion detection reports as a NotificationCCReport, followed by two redundant BasicCCSet.

This happens pretty frequently, so whenever there is a collision with other devices transmitting, you have a good candiate for a jam.

---

Node 85 bursts 4 temperature reports in under 50 milliseconds, repeated every 3 minutes.

These reports often do not vary, or just by less than 0.1 °C

Again, not sure what this device is, but I strongly recommend switching to threshold based reporting with meaningful thresholds instead of fixed timing.

---

Node 76, is that a power strip? After being controlled, it sends MultilevelSwitchCCReports for its 5 channels, plus a BasicCCReport (for whatever reason).

And when it's on, it sends power updates like these every 2 minutes:

34.8 => 34.6 W

I don't think you can do much about the former, but maybe you can tone down the power reporting.

Most likely you'll have some success if you:

• improve the connection to node 4
• figure out how to make your motion sensors send only one type of command
• use threshold based reporting instead of fixed intervals

[tardy galleon]

Thanks for the help @crimson bolt

Which devices are nodes 4, 66, 75, 76 and 85?
Manufacturer / model / firmware version?

4 - Fibaro FGMS001 FW: v2.7 - Motion Sensor
66 - Fibaro FGMS001 FW: v3.2 - Motion Sensor
75 - Fibaro FGMS001 FW: v3.2 - Motion Sensor
76 - Fibaro FGRGBW FW:27.27 - RGBW Controller
85 - Fibaro FGBS001 FW: v2.1 - Universal Binary Sensor - has 4 temp sensors plugged into it

Node 85 config:

I changed the Node 76 ' Power Load Reporting Frequency' to '0' - hopefully that disables it reporting.

This is the config of node 4. Im not sure what to change in this to improve the reporting frequency/type:

[crimson bolt]

Node 4: Can you show me the groups tab? I suspect node 1 may be in more than one of them:

Should look roughly like this

[crimson bolt]

Parameter 11 is supposed to have 0 (disabled) as an option. I suggest trying to set that. If that doesn't work, you can use the manual fields at the bottom to set parameter 11, size 1, value 0.
Parameters 10 and 12 let you configure threshold based reporting. Param 11 is the time in seconds between measuring the temperature. When this differs from the most recent report by more than param 12, then a report is sent.
Setting parameter 12 is a bit weird though:

delta T – Threshold to trigger a report
x = parameter value to set:
x = delta T x 16 - for Celsius
x = delta T x 80 / 9 - for Fahrenheit
delta T – maximum acceptable temperature gradient in Celsius or
Fahrenheit

[crimson bolt]

Same for the other motion sensors please. Due to a different firmware version they probably have a different group layout though

[tardy galleon]

the manual fields at the bottom to set parameter 11, size 1, value 0 didn't seem to do anything when I clicked [SET]

[crimson bolt]

Uhhh, wat? Can you click refresh?

[crimson bolt]

Can you make a log of just clicking [SET] with the correct values? Maybe followed by a [GET].
You canuse this button to make this easier. Start, do the action, stop

[tardy galleon]

Yip!

Here is the debug from doing the manual Param 11 set.
When I did the [Get] the red text showed up under Param 11 "Value must be between 1 and 255'

[crimson bolt]

Ok that confirms my suspicion. You need to remove two associations.
For node 66 and 75, remove the Motion and Tamper.
For Node 4 I think you need to keep only the Tamper. We seem to have the wrong group names for that older firmware.

[crimson bolt]

Ok the value was set correctly.

I've raised https://github.com/zwave-js/zwave-js/issues/8643 to make this less painful in the future

[tardy galleon]

OK, with a bit of battery out/in work I have updated the Groups settings as per your recommendations on all three FGMS001

[crimson bolt]

Fingers crossed

[tardy galleon]

Unfortunately it hasnt stopped the jams 🙁
Still jamming about every 2 hours or so.

Any use in looking at a new set of logs now Ive removed those unneeded Associations?

[crimson bolt]

Yes, log please.

[tardy galleon]

Yeah, sorry, busy day. Will do

[crimson bolt]

no stress

[tardy galleon]

Here are the last 2 days logs

[toxic frost]

Same here. Still jamming. I'll provide logs soon

[crimson bolt]

Ok, so it looks like our association changes did something. Nodes 4, 66 and 75 no longer send unncessary reports for the same events.

Node 7 might need the same association treatment as the other motion sensors (is that also a FGMS001?)

Node 4 and potentially 7 have connectivity issues. I still see lots of repeated frames from them ahead of jammed events.

Can you try the following tool to diagnose the connection to them?
After clicking start, you will need to wake them up manually at the device.

[crimson bolt]

Nodes 30 and 72 have the same issue as the other motion detectors. 3 commands sent instead of 1. Assuming those are also FGMS001, they'll need the same fix.

[toxic frost]

Got 2 jams in the last 24 hours. No idea if these logs look good or not. I seemingly have a lot of repeated messages

[crimson bolt]

Wrong logfile. That's the application log, not the driver log.

[toxic frost]

Which one of these is the correct log file?

[elder marsh]

You'll need to enable debug driver logs, z-ui are application logs. https://zwave-js.github.io/zwave-js-ui/#/troubleshooting/generating-logs?id=driver-logs

[toxic frost]

Is it this crazy thing?

I feel like I am logging. This is Zwave JS UI general settings

[elder marsh]

Check the link

If it doesn't scroll to the right section, go to "Driver logs"

[toxic frost]

I did, but that looks like the same thing I'm showing, no? Am I missing something?

[elder marsh]

It's not the same

[toxic frost]

Got it, thank you for your patience

[toxic frost]

Just jammed

[tardy galleon]

Yes, Node 7 is a FGMS001 (FW: v3.4)

Removed Motion & Tamper

Also have done the same thing for 30 & 72

I'll send a 24-hour log tomorrow

[crimson bolt]

That is a terrible connection. I suggest testing the connection to "Hallways Treads" too, so you know if it's just a problem with the 2nd hop

If it is, try finding a different route to set as a priority route (and priority return route for the unsolicited reports). Depending on the location maybe there is a better repeater, or maybe a direct connection would work.

[crimson bolt]

That particular jam was caused by a flood of incoming repeated reports from Node 85.

You have a couple of nodes with bad connection (either requiring frequent re-transmits or lower speed):
Node 18: communication works exclusively at 40 kbps (lower speed than normal)
Node 74: even worse, this one needs 9.6 kbps
Node 85: 2/3 commands need to be re-transmitted, often at lower speed
Node 90: Like 74, only works at 9.6 kbps. Several repeated reports, indicating that it is not receiving the acknowledgements.
Node 112: Several re-transmissions
Node 114: Only works at 40 and 9.6 kbps
Node 121: Only 40 kbps
Node 122: Only one command was sent, but this needed 9.6 kbps. Several repeated reports, indicating that it is not receiving the acknowledgements.

Node 122, 85 and 90 seem to be the most problematic for the jamming issue. When they re-transmit their commands at low speed, they take up a lot of airtime, which can easily trigger the clear channel assessment the controller needs to do before transmitting.

Look at your mesh from inside out. Does it make sense how the devices are connected, e.g. is there one that is very close to the controller but takes multiple hops through the network?
Make sure that all closeby devices use a direct connection, if not help them out with a priority route (outbound connection) and priority return route (inbound connection). Prefer 100 kbps, and perform a link reliability check after you assign a priority route.

Then look at the ones with lower speed (yellow/red lines). Try to get rid of all of them. Some yellow lines in less dense areas may be okay, but try to eliminate them.
To do that, you can try rebuilding the routes of that particular node and perform another check. If nothing changes, also try assigning priority routes that make sense to you.

Also don't forget to enable this when you are watching the map during tests:

[toxic frost]

Thank you. I've seen this map before, but I was unaware I could manually assign priority routes per device. Whenever I saw a non-ideal route, I would try to have it rebuild and hope it figured out a better path

Question: If I removed the power consumption entities from node 85 (disabled the entities in HA), would that cause fewer floods of info and therefore fewer controller jams?

I don't actually care about the power consumption data. I just want a simple on/off zwave plug for node 85

Some of the nodes that you mentioned are fairly new and modern. Why would they be only capped to transmit at 9.6 kbps?

I set a priority route (and return route) through a closer node, and that turned the line green, but there is still a brown line from the controller to the node. How can I get rid of this?

in fact, I have a lot of those "double connections" but one is green and one is brown

Example:

[crimson bolt]

That would help, but the connection is still terrible

[crimson bolt]

Bad connectivity

[crimson bolt]

This means one of the nodes routing through that device has a 9.6k route and another one has a better one. We don't get these statistics per hop so this is a good enough approximation

[toxic frost]

Gotcha. I thought you meant it was capped due to hardware or software contraints on the actual device itself

[toxic frost]

Is there a way I can "snip" the crappier route? I'm assuming it's smart enough to just use the better route, or do I have to manually set that as a preferred route?

So basically the goal is to manually reconfigure each node with slow connections to have a better path with preferred routes, and if I can't find one, eliminate unneeded entities that I don't care about (Lux, power levels, etc) to free up air time?

[crimson bolt]

Sounds about right

[toxic frost]

Thanks Al, this has been very informative and helpful. I’ll start working on this stuff tonight

[toxic frost]

I also get a lot of these "cannot decode the message" errors from my new inovelli red mmWave dimmer switch. It seems to be something with S2 authentication

[crimson bolt]

question is what happened before that

might be the device restarting unexpectedly, might be a desync, or something else entirely...

[toxic frost]

Hmmm

it does that all the time

[crimson bolt]

if you can show me a longer log, I can check

[toxic frost]

but no "outward facing symptoms"

Okay let me grab that

[crimson bolt]

I'll look at that tomorrow

[toxic frost]

Okay no worries. I appreciate it

[tardy galleon]

This is the result of testing the Hallway Treads:

[crimson bolt]

Oof. Looks like using that as a repeater isn't a good idea.

[tardy galleon]

Now I've set a better Priority route 🙂

So looks like I need to go around all the RED links on the map and see if I can manually set priority routes thru better Repeaters?

[tardy galleon]

Not too much RED there...

[crimson bolt]

Still a few red. Look at those, because one alone is capable of causing jams

[tardy galleon]

Getting better...

Still gettting jams though...

[crimson bolt]

Now it is getting more complicated.
I see a couple of instances in your log where Z-Wave JS polls devices because they don't report their sensor values regularly. Almost all of those look like they are for power meters you disabled, but the behavior is a certification requirement:

I did notice that these logs appear more often than I expect them to, so I'm looking at that. The next release will also include a fix to spread these queries out more.

At least one jam is triggered by node 9, which is communicating at 9.6 kbps. I assume it is actually still transmitting (or re-transmitting) at the time the controller wants to do that.

I would say you try to optimize those routes and we take another look at this once my fixes are both released.

[crimson bolt]

@tardy galleon can share the node dump for node 8 please?

[tardy galleon]

Sorry - been out of town for 3 days 🙂

Set the Priority Route and Return Route on Node 9 to direct, then did the stats

[crimson bolt]

Node 9 looks great

[crimson bolt]

One more red here:

[tardy galleon]

Yeah, that one is proving 'elusive'. Its node 81 - Aeon Smart Switch 6. Gave it another go...

[crimson bolt]

-98 dBm doesn't seem like a stable direct connection. You'll likely need to find a repeater that it has a good connection to then try a priority route via that one.

[brittle forum]

Still seeing many zwa-2 jams a day with firmware 1.2 and sdk 8.0.

[tardy galleon]

This is todays logs. Still getting multiple jams a day.
Have done all I can (I think) to optimise the nodes Priority Routes.
Thanks for your help @crimson bolt looking into this 🙂

Node 92 is a problem: