Devices reacting slow or not at all, most likely due to Zigbee2MQTT

Configuration Zigbee
1

After stopping the containers to make a backup and restarting them, the devices reacted slow or not at all.
Here’s what I have and did(lots of information below, I tried as much as possible before posting, I hope someone can help out)

Home Assistant running in Docker container, as well as Mosquitto and Zigbee2MQTT (all in separate containers).
Zigbee2MQTT stick (coordinator): SONOFF ZigBee 3.0 USB Dongle Plus, TI CC2652P
No changes were made in any configuration file or docker-compose.yaml

Automations with time triggers still work (switch on light at 8.30, open curtain at sunset, etc.)
Automations based on states work at random: he states are not passed anymore (switch on light at 8.30 if state == off)
When controlling devices from a dashboard, they sometimes react immediately, sometimes not at all:
switch on a lamp: immediately at first, switching it off within a few seconds after switching it on: no reaction. Same goes for dimming or adjusting the color.

Error logs shows timeouts when trying to pass states:

  • error: z2m: Publish ‘set’ ‘brightness’ to ‘Slimme lamp dimbaar kleur’ failed: ‘Error: ZCL command 0x08ddebfffe46e95a/1 genLevelCtrl.moveToLevelWithOnOff({“level”:97,“transtime”:0}, {“timeout”:10000,“disableResponse”:false,“disableRecovery”:false,“disableDefaultResponse”:false,“direction”:0,“srcEndpoint”:null,“reservedBits”:0,“manufacturerCode”:null,“transactionSequenceNumber”:null,“writeUndiv”:false}) failed (Data request failed with error: ‘Timeout’ (9999))’
  • error: z2m: Publish ‘set’ ‘state’ to ‘eetkamer_lampen’ failed: ‘Error: Command 1 genOnOff.on({}) failed (AREQ - AF - dataConfirm after 3000ms)’
  • error: z2m: Failed to read state of ‘Slimme lamp dimbaar kleur’ after reconnect (ZCL command 0x08ddebfffe46e95a/1 genOnOff.read([“onOff”], {“timeout”:10000,“disableResponse”:false,“disableRecovery”:false,“disableDefaultResponse”:true,“direction”:0,“srcEndpoint”:null,“reservedBits”:0,“manufacturerCode”:null,“transactionSequenceNumber”:null,“writeUndiv”:false}) failed (Data request failed with error: ‘Timeout’ (9999)))

Another series of errors are:
[2025-03-04 22:20:58] error: z2m: Error while starting zigbee-herdsman
[2025-03-04 22:20:58] error: z2m: Failed to start zigbee
[2025-03-04 22:20:58] error: z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
[2025-03-04 22:20:58] error: z2m: Exiting…
[2025-03-04 22:20:58] error: z2m: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
at ZStackAdapter.start (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:119:27)
at Controller.start (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:127:29)
at Zigbee.start (/app/lib/zigbee.ts:63:27)
at Controller.start (/app/lib/controller.ts:139:27)
at start (/app/index.js:154:5)

These seems to point at the coordinator as well.

Tried to analyse this in a structured way. The coordinator is:

  • visible (symlink visible)
  • active (’ adapter attached to ttyUSB0’)
  • correct port (/dev/serialby-id/…)
  • not used by another process
  • user is in the dialout group

-? not known in the logs? ‘docker logs zigbee2mqtt | grep “Coordinator”’ gives no output. (I must admit iI don’t know if there was output when it did work normally)

Placed the coordinator closer to devices: no improvement

I did stop and restart the containers and the NUC more often and dit not have this problem before. 2 Weeks ago This problem occurred, in tested the same things as described above
, finally unplugged and replugged the coordinator and after plugging it into another USB port it seemed solved. I did stop and restart the containers a few times and it kept on working…until 3 days ago when I stopped the containers again and restarted them
(docker-compose stop; docker-compose up; with and without specifying the containers, to get the started in the correct order and wait ten minutes in between, just to be sure (first Mosquitto, wait ten minutes, then Zigbee2MQTT) (10 minutes, since I went to get some tea to kill the waiting time ;))

re-paired a device: gave timeout, then paired. Time triggered automation works. Controlling via a dashboard: same as before, so direct at first, then slowly or not at all.

My final thought is that the coordinator is broken, but since this behaviour did disappear before too and no started again, I find htat hard to believe.
What more can i try to find out what’s going on and what would be a solution?

2

Please post your Z2M config. An example

data_path: /config/zigbee2mqtt
socat:
  enabled: false
  master: pty,raw,echo=0,link=/tmp/ttyZ2M,mode=777
  slave: tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5
  options: "-d -d"
  log: false
mqtt:
  server: mqtt://core-mosquitto:1883
  base_topic: zigbee2mqtt_1
serial:
  port: tcp://192.168.50.40:6638
  adapter: zstack
  rtscts: false
advanced:
  homeassistant_legacy_entity_attributes: false
  homeassistant_legacy_triggers: false
  legacy_api: false
  legacy_availability_payload: false
device_options:
  legacy: false
3

If you’re not using a USB extension cord between your NUC and the dongle: add one. USB 3.0 ports can generate a lot of Zigbee interference.

4

ZCL errors indicate an interference issue as @robertklep stated. You may need to change the Zigbee network channel.

Scanning the ZigBee network will show channel usage around the adapter.

These may be attributed to switching USB ports.

5

Thanks for thinking and the suggestions!

zigbee2mqtt configuration.yaml

homeassistant: true
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://192.168.1.86
  user: XXXX
  password: XXXXX
serial:
  port: /dev/ttyUSB0
frontend:
  port: 8080
devices: devices.yaml
groups: groups.yaml
advanced:
  log_level: error

All did work fine for months on end, even with the occasional stopping/starting containers or rebooting Home Assistant.

There is a cable between de NUC and coordinator stick. I do understand the interference and busy channels. At the same time I find it hard to believe it ‘suddenly’ triggers when stopping/ starting containers. To be sure, how should I do the scan?

6

Have you tried defining the adapter in your config.

adapter:

Example

serial:
  port: tcp://192.168.50.40:6638
  adapter: zstack
  rtscts: false
7

An error like this:

[2025-03-04 22:20:58] error: z2m: Failed to start zigbee

makes me wonder about why anything is working at all. You get that error and then you’re able to turn on a lamp with Z2M? Are you sure something really weird isn’t happening, like two instatnces of Z2M running at once?

Have you tried to monitor traffic using the mosquitto_sub client (if you are able)?

8

I might be a little bit further along in this maze. I’ve tried changing the zigbee channel to 15 (looked like there is way less noise/traffic on that channel),
There seems to be a problem between the connection zigbee2mqtt and the MQTT server (Mosquitto). Both of the processes are running fine. I’ve checked the user/password,which were ok.
running

docker exec -it mosquitto mosquitto -v

results in:

1741549806: mosquitto version 2.0.18 starting
1741549806: Using default config.
1741549806: Starting in local only mode. Connections will only be possible from clients running on this machine.
1741549806: Create a configuration file which defines a listener to allow remote access.
1741549806: For more details see Authentication methods | Eclipse Mosquitto
1741549806: Opening ipv4 listen socket on port 1883.
1741549806: Error: Address in use
1741549806: Opening ipv6 listen socket on port 1883.
1741549806: Error: Address in use

I found no other process on the port (1883), but changed the listening port from 1883 to 1884 just to be sure. Unfortunately, then it results in:

1741549238: mosquitto version 2.0.18 starting
1741549238: Using default config.
1741549238: Starting in local only mode. Connections will only be possible from clients running on this machine.
1741549238: Create a configuration file which defines a listener to allow remote access.
1741549238: For more details see Authentication methods | Eclipse Mosquitto
1741549238: Opening ipv4 listen socket on port 1883.
1741549238: Opening ipv6 listen socket on port 1883.
1741549238: mosquitto version 2.0.18 running
^C1741549558: mosquitto version 2.0.18 terminating

Am I looking in the right direction?
Where of how should I look for other processes on 1883 and why does it keep on listening on 1883? I’ve adjusted the mosquitto.config, zigbee2mqtt configuration.yaml and docker-compose.yaml and the MQTT configuraiont in HomeAssistant.

9

Especially when using Docker, this may be a reason why z2m cannot connect. You need to define a listener that will allow access from all interfaces:

listener 1883 0.0.0.0

I don’t see you passing the config file into the Docker container, so it’s using the built-in default config file.

Take your pick:

sudo lsof -i tcp:1883
sudo ss -tulpn | grep :1883
10

I think I understand the logic of what you say, but then cannot understand why it simply used to work fine without passing the config file into the docker container (or am I doing that and not understanding your explanation?). Here are my docker-compose.yaml, zigbee2mqtt configuration.yaml and mosquitto.conf. can you tell me where/how I should pass the config file into the docker container?

I always understood it works as is supposed to since Zigbee2mqtt and Home Assistant connect to 1883, where Mosquitto is listening. (Checked it with your advice and they are connecting to 1883 :slight_smile: )

sudo lsof -i tcp:1883

Docker-compose.yaml

  zigbee2mqtt:
    container_name: zigbee2mqtt
    image: koenkk/zigbee2mqtt:1.39.1
    restart: unless-stopped
 
    volumes:
      - /opt/zigbee2mqtt/data:/app/data
      - /run/udev:/run/udev:ro
    ports:
      # Frontend port
      - 8080:8080
    environment:
      - TZ=Europe/Amsterdam
    devices:
      - /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_XXX-if00-port0:/dev/ttyUSB0

  mosquitto:
    image: eclipse-mosquitto
    container_name: mosquitto
    volumes:
      - /opt/mosquitto:/mosquitto
      - /opt/mosquitto/data:/mosquitto/data
      - /opt/mosquitto/log:/mosquitto/log
    restart: unless-stopped
    ports:
      - 1883:1883
      - 9001:9001

Zigbee2MQTT configuration.yaml

homeassistant: true
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://192.168.1.86:1883
  user: XXX
  password: XXX
serial:
  port: /dev/ttyUSB0
frontend:
  port: 8080
devices: devices.yaml
groups: groups.yaml
advanced:
  log_level: warning
  channel: 15

Mosquitto.conf

persistence true
persistence_location /mosquitto/data/
log_dest file /mosquitto/log/mosquitto.log
listener 1883

## Authentication: username and password that will be needed to use the broker ##
allow_anonymous false
password_file /mosquitto/config/password.txt
11

Ignore my previous remark, I misunderstood.

Your setup looks okay for Mosquitto running on port 1883. It doesn’t matter if you change your Mosquitto config to run on port 1884 because your port mapping assumes it’s running on 1883, and it also exposes it on 1883:

    ports:
      - 1883:1883
      - 9001:9001

But all this is irrelevant to your original issue:

[2025-03-04 22:20:58] error: z2m: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)

This points to a problem with your Zigbee dongle. Either due to it being underpowered (perhaps through an unpowered USB hub), a problem with the extension cable, or the dongle itself.