Zigbee2mqtt: getting rid of your proprietary Zigbee bridges (Xiaomi, Hue, TRADFRI)


I am still on my issue of hassio hang when launching this addon:
When I try to ping I get the following result:

64 bytes from 192.168.1. Xxx: icmp_seq=81 ttl=64 time=1.78 ms
64 bytes from 192.168.1.xxx: icmp_seq=82 ttl=64 time=1.37 ms
64 bytes from 192.168.1.xxx: icmp_seq=83 ttl=64 time=1.39 ms
64 bytes from 192.168.1.xxx: icmp_seq=84 ttl=64 time=1.41 ms
64 bytes from 192.168.1.xxx: icmp_seq=85 ttl=64 time=1.57 ms
64 bytes from 192.168.1.xxx: icmp_seq=86 ttl=64 time=754 ms
64 bytes from 192.168.1.xxx: icmp_seq=87 ttl=64 time=3320 ms
64 bytes from 192.168.1.xxx: icmp_seq=88 ttl=64 time=5319 ms
64 bytes from 192.168.1.xxx: icmp_seq=89 ttl=64 time=5359 ms
64 bytes from 192.168.1.xxx: icmp_seq=90 ttl=64 time=5631 ms
64 bytes from 192.168.1.xxx: icmp_seq=91 ttl=64 time=5898 ms
64 bytes from 192.168.1.xxx: icmp_seq=92 ttl=64 time=5359 ms
64 bytes from 192.168.1.xxx: icmp_seq=93 ttl=64 time=5401 ms
64 bytes from 192.168.1.xxx: icmp_seq=94 ttl=64 time=5815 ms
64 bytes from 192.168.1.xxx: icmp_seq=95 ttl=64 time=6130 ms
64 bytes from 192.168.1.xxx: icmp_seq=96 ttl=64 time=12408 ms
64 bytes from 192.168.1.xxx: icmp_seq=97 ttl=64 time=13463 ms
64 bytes from 192.168.1.xxx: icmp_seq=98 ttl=64 time=13034 ms
64 bytes from 192.168.1.xxx: icmp_seq=99 ttl=64 time=13215 ms
64 bytes from 192.168.1.xxx: icmp_seq=100 ttl=64 time=15294 ms
64 bytes from 192.168.1.xxx: icmp_seq=101 ttl=64 time=16617 ms

Access to hassio is then almost impossible.

Here is the log:

[Info] Configuration file found. Will overwrite configurable               fields with values from add-on configuration
[Info] Configuration written to /share/zigbee2mqtt/configuration.yaml
2018-11-24T11:24:44: PM2 log: Launching in no daemon mode
2018-11-24T11:24:44: PM2 log: App [npm:0] starting in -fork mode-
2018-11-24T11:24:45: PM2 log: App [npm:0] online
> [email protected] start /zigbee2mqtt-0.2.0
> node index.js
		Zigbee2mqtt requires node version >=8.11 10, you are running v8.11.4!
  zigbee2mqtt:info 2018-11-24 11:24:50 Logging to directory: '/share/zigbee2mqtt/log/2018-11-24.11-24-49'
  zigbee2mqtt:info 2018-11-24 11:24:51 Starting zigbee2mqtt version 0.2.0 (commit #unknown)
  zigbee2mqtt:info 2018-11-24 11:24:51 Starting zigbee-shepherd
  zigbee2mqtt:info 2018-11-24 11:24:55 Error while starting zigbee-shepherd, attemping to fix... (takes 60 seconds)
  zigbee2mqtt:info 2018-11-24 11:25:55 Starting zigbee-shepherd
  zigbee2mqtt:info 2018-11-24 11:26:11 zigbee-shepherd started
  zigbee2mqtt:info 2018-11-24 11:26:11 Coordinator firmware version: '20181024'
  zigbee2mqtt:info 2018-11-24 11:26:11 Currently 9 devices are joined:
  zigbee2mqtt:info 2018-11-24 11:26:11 Zigbee: disabling joining new devices.
  zigbee2mqtt:info 2018-11-24 11:26:11 Connecting to MQTT server at mqtt://
  zigbee2mqtt:info 2018-11-24 11:26:12 zigbee-shepherd ready
  zigbee2mqtt:info 2018-11-24 11:26:12 Connected to MQTT server
  zigbee2mqtt:info 2018-11-24 11:26:12 MQTT publish, topic: 'zigbee2mqtt/bridge/state', payload: 'online'
  zigbee2mqtt:info 2018-11-24 11:26:12 MQTT publish, topic: 'zigbee2mqtt/0x00xxxxxxxxxxxx', payload: 

zigbee2mqtt:info 2018-11-24 11:26:15
{“message”:“request timeout”,“stack”:“Error: request timeout\n at CcZnp. (/zigbee2mqtt-0.2.0/node_modules/cc-znp/lib/ccznp.js:255:22)\n at Object.onceWrapper (events.js:315:30)\n at emitOne (events.js:116:13)\n at CcZnp.emit (events.js:211:7)\n at Timeout. (/zigbee2mqtt-0.2.0/node_modules/cc-znp/lib/ccznp.js:234:18)\n at ontimeout (timers.js:498:11)\n at tryOnTimeout (timers.js:323:5)\n at Timer.listOnTimeout (timers.js:290:5)”}

I solved the issue of HASSIO crashing. Uninstall the add on, delete the configuration.yaml and database.db in the share/zigbee2mqtt folder and then everything seems to be fine. But after some time the issue is back again.

I am completely lost and don’t know what to do to permanently solve the issue.


Does anyone use the zwave stick and the zigbee sniffer at the same time?
Have not yet figured out the problem I previusly posted here: Zigbee2mqtt: getting rid of your proprietary Zigbee bridges (Xiaomi, Hue, TRADFRI)


Instead of using ttyACM# use the serial-id for the usb device. use

ls -al /dev/serial/by-id/

and find the serial name for the usb device.

Mine shows

usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0014D9D8D7-if00 -> …/…/ttyACM2

so I use


instead of


This way it doesn’t matter what the tty number is, it looks for the specific usb device.


Thank you, that was the old way I configured my zwave stick too. Unfortinatly, the zwave component stopped supporting that way of configuring the usb-path some versions ago, so I had to change it to the TTYACM-way. But maybe I can force the sniffer to be be mounted to TTYACM1 instead of TTYACM0? that could fix my problem.

EDIT: When changing usb places from the front to the back, and vica versa, the problem got solved.


I use the serial/by-id path for zwave using 0.82.1 with no problems. I also use it for zigbee2mqtt with no issues. There is also a way to use udev rules to create a symlink, but that is not as easy. But as long as you don’t change usb ports, it generally will keep it the same device name.


@creznikov thank you for the update. Didn’t know they changed back again the support for zwave by-id. Yes, everything is up and running now, switching the usb sticks did the trick. Thanks anyways :+1:


I too use zwave that way but I have not managed to run zigbee2mqtt that way. Can you provide details on how you have configured yours?



There are numerous articles on the net about persistent device naming, eg



I run zigbee2mqtt in docker, but that should’t matter. This is my docker-compose.yaml:

  version: '3'
      container_name: zigbee2mqtt
      image: koenkk/zigbee2mqtt:arm32v6
#      environment:
#        - DEBUG=*
        - /home/pi/.zigbee2mqtt/data:/app/data
        - /etc/localtime:/etc/localtime:ro
        - /etc/timezone:/etc/timezone:ro
        - /dev/serial/by-id/usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0014D9D8D7-if00:/dev/serial/by-id/usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0014D9D8D7-if00
      restart: always
      network_mode: host

That passes my zigbee usb device into the docker container. This is the relevant portion of configuration.yaml for zigbee2mqtt:

  port: >-


I am a little bit insecure about how to add the Trådfri Motion Sensor as a new device.
Do I just make the directory and the file in the share/zigbee2mqtt folder?
Like this:

Then add the devices.js in that folder (with the correct info) and then download and add this file in this folder:


Or should the folders be somewhere else?


No need to create any folder : they are created by the addon.


I must be missing something, when I go to share/zigbee2mqtt, there is no folder called node_modules. Am I looking in the wrong folder, or do I need to write something in the addon config to make it?


Here is my addon config:

  "data_path": "/share/zigbee2mqtt",
  "homeassistant": false,
  "permit_join": false,
  "mqtt_base_topic": "zigbee2mqtt",
  "mqtt_server": "mqtt://xxx.xxx.xxx.xxx:1883",
  "serial_port": "/dev/ttyACM1",
  "mqtt_user": "user",
  "mqtt_pass": "password",
  "disable_led": true


I got the same config. So don’t know why you got the folders automatically, and I don’t. But as long they are in the /share/zigbee2mqtt/ folder, I can just make them according to the guide.


Sorry for ignorance where do i put this script ?

best regards


You should make with it a file named mqtt_map.sh in /home/pi
Then you make a file



ExecStart=/usr/bin/env /home/pi/mqtt_map.sh


Finally you should enable it with

sudo systemctl daemon-reload
systemctl enable mqtt_map.service
systemctl start mqtt_map.service

according to:



many thanks


Does anyone have a suggestion for troubleshooting the cc debugger?

I can’t get that green light. I’ve installed drivers (manually, it shows correctly in device manager), I’ve flashed firmware (v 0044) via SmartRF Flash programmer (according to the troubleshooting guide) but still just a red light.

The CC2531 is powered (green LED2 on) when connected to the debugger (not plugged in itself).

I have tried both on OSX and Windows.


Make sure you press the “Reset” button on the debugger once it’s connected. Sometimes when I use it (not for this project) I have to hold the connector against the PCB juuuust right in order to make the connection, so I end up wiggling it around slowly while spamming the “Reset” button until I get a green light, then I hit “Program” as fast as I can while trying to hold the connector still.


I pressed that a few dozen times. But I’ll try wiggling the cables, thanks!