Hello Friends,
Any one knows how I can fix this Z-Wave Transmission queue full problem?
Error: Unable to set value 7-38-3-targetValue: zwave_error: Z-Wave error 202 - Failed to send the command: Transmission queue full (ZW0202)
I get this message irregularly when I run my “good morning” or “good night” automations, and it sometimes causes a few Z-Wave commands within the automation to not run.
I’m using the latest stable HAOS with Z-Wave JS and a Philio PAU01 Z-Wave USB dongle.
Post those automations.
You may need to add delays in the automation or waits to wait for the action to be reflected by the device. Automations run super fast, and the zwave actions complete quickly as they only wait for the command to be sent to zwavejs. Where as zwave sending to the physical devices take 50-100ms typically.
How do these zwave statistics looks. TX,RX, timeout errors?
Hi Pete,
Thank you for the clarification. I added 500ms delays between each command step.
I hope it will solve the issue 
Can you, please, explain where I can find the TX, RX, timeout errors details you mentioned?
If you are using zwave-js-ui then you can access the stats here:
Or the HA interface for the device via the three dots menu next to the configure link:
I’m curious, does your automation generate an error? If you look at the trace does it show that it completed or does the automation show that an action failed?
Just guessing here, but if the z-wave queue is full, wouldn’t the integration propagate that exception up to the automation?
Hi busman, thank you for your reply.
Here is the Trace info from this morning. As you can see in the screenshot, there was a problem with the second line. It ran a few of the commands in it, but not all of them.
Since this morning, I edited the automation and created separate commands for each device. Whereas, before I sent one command to a few similar devices (for example, one line would send a “close” command to 4 different window blinds, and a second line will send a “turn off” command to 6 different lights).
These are the statistics info for one device that didn’t run this morning.
I hope this information helps.
This is the edited automation I created. I will test it in the next few days.
alias: Good Night
description: ""
triggers:
- trigger: state
entity_id:
- switch.bedroom_good_morning
from: "on"
to: "off"
conditions: []
actions:
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.bedroom_light1
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.bedroom_light2
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_on
metadata: {}
data:
brightness_pct: 100
target:
entity_id: light.bed_right_blinds
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: climate.set_hvac_mode
metadata: {}
data:
hvac_mode: "off"
target:
entity_id: climate.salon_ac
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: fan.turn_off
metadata: {}
data: {}
target:
entity_id: fan.salon_tv_fan
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_on
metadata: {}
data:
brightness_pct: 100
target:
entity_id:
- light.salon_desk_blinds
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_on
metadata: {}
data:
brightness_pct: 100
target:
entity_id:
- light.kitchen_blinds
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: cover.open_cover
metadata: {}
data: {}
target:
entity_id:
- cover.salon_balcony_blinds1
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: cover.open_cover
metadata: {}
data: {}
target:
entity_id:
- cover.salon_balcony_blinds2
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_on
metadata: {}
data:
brightness_pct: 89
target:
entity_id: light.salon_window_blinds
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id: light.balcony_shade
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.salon_tv_light1
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.salon_tv_light2
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.salon_desk_light1
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.kitchen_light1
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.kitchen_light2
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.entrance_light1
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.entrance_light2
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.bathroom_light1
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.bathroom_light2
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.balcony_light1
enabled: true
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- action: light.turn_off
metadata: {}
data: {}
target:
entity_id:
- light.balcony_light2
enabled: true
mode: single
Look at the stats on the controller (e.g. the USB stick)
Here are the controller stats. Although the info written appears to be inaccurate, because it’s not a HUSBZB-1. This is actually a Philio PAU01 USB dongle.
Those look good. The stats get reset whenever zwavejs is restarted, so if you restarted after the error then the stats are not useful.
On your trace you have an error:
What error do you see when you click on that? The queue full message?
I kind of wonder if that “queue full” message is misleading. Briefly looking at the code it seems more like a dropped message than a queue issue. Need someone that knows the code, but I do find a 202 here (and see here for your message).
Controller_MessageDropped = 202,
And also here’s your “queue full” message, but is that really what MessageDropped means?
case "response NOK": {
if (isSendData(sentMessage)) {
return new ZWaveError(
`Failed to send the command: Transmission queue full`,
ZWaveErrorCodes.Controller_MessageDropped,
receivedMessage,
transactionSource,
);
So, maybe it’s failing for another reason.
By the way, you are just setting a bunch of lights, right? Have you tried making that a scene? I assume it would send the zwave commands the same, but might be nice to separate out the changing of the lights from the automation and run it separately.
Difficult to say now that I changed the automation commands and it ran without problems.
Today the “good night” “good morning” automation worked as they should, so if I get the errors again, I’ll share the error code.
In these automations I’m setting lights, window blinds and AC states.
Include any Traceback, too. Might reveal more about what the actual problem is. It is frustrating when these problems just seem to resove. I have a door lock where sometimes the round-trip-time goes way up and commands time out. But when I start to try and look at it in detail it starts working again.
Scenes can do all that, of course. Just can’t do conditions – or the delays, but I still question if that was the issue.
Glad things are working now.
Hey all just dropping in my 2 cents if it is any help, I got the exact same issue after updating to the latest zwavejs UI version 4.0.3.
Before that update I had never seen it before, and also did not change anything with the automations that possibly gave the error or added anything to Zwave either for a long time now.
Using the Aeotec gen5+ stick and the latest HA from March 3.4.
I have rolled back the Zwavejs UI to an older version 3.18.0 cause I knew that one did not give me any issues before and zwave has been rock solid for years now before this happened.
It seems fine for now, but time will tell. I cannot say for sure that it is an issue with the new version that is why I am testing this. If I do not report back on this in a day or 2 then the issue is solved for now and maybe u can try something simular.
Can you please explain what a Traceback is ,and how to send you the information for it?
The problem were not solved even with the 500 miliseconds delays I added.
Here is the Trace code for today’s point of failure:
Executed: April 7, 2025 at 11:52:25 PM
Error: Unable to set value 7-38-3-targetValue: zwave_error: Z-Wave error 202 - Failed to send the command: Transmission queue full (ZW0202)
Result:
params:
domain: light
service: turn_on
service_data:
brightness_pct: 89
entity_id:
- light.salon_window_blinds
target:
entity_id:
- light.salon_window_blinds
running_script: false
You’ll need to grab the zwavejs logs, there will be more detail in there. Put it into debug mode.
The next item to look at is too much zwave traffic. You may have devices reporting power too often, etc. Logs will show that.
@PeteRage has a good point about cleaning up devices that report frequently. I forgot I did that a month or so ago and really reduced the traffic on my network.
You can turn debug on the Z-Wave integration, but I find there’s too much noise in the home-assistant.log file. Still, might be able to see something useful there.
I use the Advanced SSH & Web Terminal Add-On with Protection Mode disabled. I also have debug enabled, which is here in the ZUI config:
I prefer to use the terminal and I connect to the container and look at the logs there:
➜ ~ docker exec -it addon_a0d7b954_zwavejs2mqtt bash
root@a0d7b954-zwavejs2mqtt:/$ cd data/store/logs/
root@a0d7b954-zwavejs2mqtt:/data/store/logs$ ls -lt | head -5
total 64352
-rw-r--r-- 1 root root 33642831 Apr 7 17:42 zwavejs_2025-04-07.log
-rw-r--r-- 1 root root 2953704 Apr 7 17:42 z-ui_2025-04-07.log
lrwxrwxrwx 1 root root 22 Apr 7 09:51 zwavejs_current.log -> zwavejs_2025-04-07.log
lrwxrwxrwx 1 root root 19 Apr 7 09:51 z-ui_current.log -> z-ui_2025-04-07.log
I find the z-ui_current.log is easier to watch:
root@a0d7b954-zwavejs2mqtt:/data/store/logs$ tail -f z-ui_current.log
2025-04-07 17:45:08.132 INFO Z-WAVE: [Node 081] Value updated: 50-0-value-66561 120.753 => 120.726
2025-04-07 17:45:08.250 INFO Z-WAVE: [Node 081] Metadata updated: 50-0-value-66817
2025-04-07 17:45:08.253 INFO Z-WAVE: [Node 081] Value updated: 50-0-value-66817 4.342 => 4.34
2025-04-07 17:45:27.244 INFO APP: GET /health/zwave 301 0.875 ms - 162
2025-04-07 17:45:33.399 INFO Z-WAVE: [Node 082] Metadata updated: 50-0-value-66049
2025-04-07 17:45:33.404 INFO Z-WAVE: [Node 082] Value updated: 50-0-value-66049 6.729 => 11.929
2025-04-07 17:45:33.904 INFO Z-WAVE: [Node 083] Metadata updated: 50-0-value-66049
2025-04-07 17:45:33.907 INFO Z-WAVE: [Node 083] Value updated: 50-0-value-66049 0 => 0
2025-04-07 17:45:38.501 INFO Z-WAVE: [Node 081] Metadata updated: 50-0-value-66049
2025-04-07 17:45:38.504 INFO Z-WAVE: [Node 081] Value updated: 50-0-value-66049 338.088 => 338.314
2025-04-07 17:45:44.217 INFO Z-WAVE: [Node 080] Metadata updated: 50-0-value-66049
2025-04-07 17:45:44.220 INFO Z-WAVE: [Node 080] Value updated: 50-0-value-66049 1.7 => 1.7
If you have a LOT of traffic there (like devices reporting voltage, power, etc.) then those can be configured to report less frequently or with larger changes in value. Once your logs are pretty quiet, and you are still getting the error, then watch or search the zwavejs_current.log for when the error happens. (I wonder if there’s a zui tool to grep those logs for a single node.)
I assume your ‘7-38-3-targetValue’ is node 007, and 38-3-targetValue is the dimmer/blind value commandClass (and endpoint 3?).
Is it always that same ‘7-38-3-targetValue’ that generates the error?
You can search the zwavejs_current.log (or previous logs) for node 007 and hope there’s something that provides more detail on why it’s failing. I don’t understand what it all means there, but you might find somethihng.
Sorry for the long post (especially if this is already familiar to you).
By the way, do you know why HA added those as a light instead of cover?
Unfortunately, I don’t.
I’ve been trying to research why HA recognized some covers as lights, but I couldn’t find the reason.
Before I started using HA I used this ZWave USB controller with OpenHAB, so all the Zwave devices were included using OpenHAB.
Later, when I connected this Zwave USB controller to HA with Zwave JS, HA just found the already included ndevices on the USB dongle.
Could this be the reason?
Could excluding the devices and then re-including them using Zwave JS help solve this?
Or maybe it’s a problem with how the devices were defined in the Zwave devices archive that HA uses to find the devices capabilities?
Thank you for the detailed explanation. The things you mentioned were not familiar to me, so they are very helpful.
The errors don’t always happen with the same device. They happen sporadically with different devices.
Try just reinterviewing the device, first. Did you see this discussion about a blind showing up as a light?