Hi @Koenkk, I turned on the zigbee-herdsman debugging and this is what I got.
2022-08-02T01:43:05.155Z zigbee-herdsman:adapter:zStack:znp:SREQ --> SYS - osalNvLength - {"id":71}
2022-08-02T01:43:05.155Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,2,33,19,71,0,119]
2022-08-02T01:43:05.166Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,2,97,19,8,0,120]
2022-08-02T01:43:05.166Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,2,97,19,8,0,120]
2022-08-02T01:43:05.166Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 2 - 3 - 1 - 19 - [8,0] - 120
2022-08-02T01:43:05.167Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- SYS - osalNvLength - {"length":8}
2022-08-02T01:43:05.167Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-02T01:43:05.167Z zigbee-herdsman:adapter:zStack:znp:SREQ --> SYS - osalNvReadExt - {"id":71,"offset":0}
2022-08-02T01:43:05.168Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,4,33,28,71,0,0,0,126]
2022-08-02T01:43:05.183Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,10,97,28,0,8,0,0,0,0,0,0,0,0,127]
2022-08-02T01:43:05.184Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,10,97,28,0,8,0,0,0,0,0,0,0,0,127]
2022-08-02T01:43:05.184Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 10 - 3 - 1 - 28 - [0,8,0,0,0,0,0,0,0,0] - 127
2022-08-02T01:43:05.184Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- SYS - osalNvReadExt - {"status":0,"len":8,"value":{"type":"Buffer","data":[0,0,0,0,0,0,0,0]}}
2022-08-02T01:43:05.184Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-02T01:43:05.185Z zigbee-herdsman:adapter:zStack:znp:SREQ --> SYS - osalNvLength - {"id":71}
2022-08-02T01:43:05.185Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,2,33,19,71,0,119]
2022-08-02T01:43:05.195Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,2,97,19,8,0,120]
2022-08-02T01:43:05.196Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,2,97,19,8,0,120]
2022-08-02T01:43:05.196Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 2 - 3 - 1 - 19 - [8,0] - 120
2022-08-02T01:43:05.196Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- SYS - osalNvLength - {"length":8}
2022-08-02T01:43:05.196Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-02T01:43:05.197Z zigbee-herdsman:adapter:zStack:znp:SREQ --> SYS - osalNvWriteExt - {"id":71,"offset":0,"len":8,"value":{"type":"Buffer","data":[27,73,193,36,0,75,18,0]}}
2022-08-02T01:43:05.197Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,14,33,29,71,0,0,0,8,0,27,73,193,36,0,75,18,0,147]
2022-08-02T01:43:05.213Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,97,29,0,125]
2022-08-02T01:43:05.214Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,97,29,0,125]
2022-08-02T01:43:05.214Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 1 - 29 - [0] - 125
2022-08-02T01:43:05.214Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- SYS - osalNvWriteExt - {"status":0}
2022-08-02T01:43:05.214Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-02T01:43:05.215Z zigbee-herdsman:adapter:zStack:znp:SREQ --> SYS - osalNvLength - {"id":99}
2022-08-02T01:43:05.215Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,2,33,19,99,0,83]
2022-08-02T01:43:05.225Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,2,97,19,1,0,113]
2022-08-02T01:43:05.226Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,2,97,19,1,0,113]
2022-08-02T01:43:05.226Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 2 - 3 - 1 - 19 - [1,0] - 113
2022-08-02T01:43:05.226Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- SYS - osalNvLength - {"length":1}
2022-08-02T01:43:05.227Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-02T01:43:05.227Z zigbee-herdsman:adapter:zStack:znp:SREQ --> SYS - osalNvReadExt - {"id":99,"offset":0}
2022-08-02T01:43:05.227Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,4,33,28,99,0,0,0,90]
2022-08-02T01:43:05.243Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,97,28,0,1,0,127]
2022-08-02T01:43:05.244Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,97,28,0,1,0,127]
2022-08-02T01:43:05.244Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 3 - 1 - 28 - [0,1,0] - 127
2022-08-02T01:43:05.245Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- SYS - osalNvReadExt - {"status":0,"len":1,"value":{"type":"Buffer","data":[0]}}
2022-08-02T01:43:05.245Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-02T01:43:05.245Z zigbee-herdsman:adapter:zStack:znp:SREQ --> SYS - osalNvLength - {"id":98}
2022-08-02T01:43:05.246Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,2,33,19,98,0,82]
2022-08-02T01:43:05.252Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,2,97,19,16,0,96]
2022-08-02T01:43:05.252Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,2,97,19,16,0,96]
2022-08-02T01:43:05.252Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 2 - 3 - 1 - 19 - [16,0] - 96
2022-08-02T01:43:05.252Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- SYS - osalNvLength - {"length":16}
2022-08-02T01:43:05.253Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-02T01:43:05.253Z zigbee-herdsman:adapter:zStack:znp:SREQ --> SYS - osalNvReadExt - {"id":98,"offset":0}
2022-08-02T01:43:05.254Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,4,33,28,98,0,0,0,91]
2022-08-02T01:43:05.262Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,18,97,28,0,16,27,212,251,224,235,195,181,112,128,124,33,66,56,49,43,33,218]
2022-08-02T01:43:05.262Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,18,97,28,0,16,27,212,251,224,235,195,181,112,128,124,33,66,56,49,43,33,218]
2022-08-02T01:43:05.262Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 18 - 3 - 1 - 28 - [0,16,27,212,251,224,235,195,181,112,128,124,33,66,56,49,43,33] - 218
2022-08-02T01:43:05.263Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- SYS - osalNvReadExt - {"status":0,"len":16,"value":{"type":"Buffer","data":[27,212,251,224,235,195,181,112,128,124,33,66,56,49,43,33]}}
2022-08-02T01:43:05.263Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-02T01:43:05.264Z zigbee-herdsman:adapter:zStack:znp:SREQ --> SYS - osalNvLength - {"id":98}
2022-08-02T01:43:05.264Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,2,33,19,98,0,82]
2022-08-02T01:43:05.270Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,2,97,19,16,0,96]
2022-08-02T01:43:05.270Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,2,97,19,16,0,96]
2022-08-02T01:43:05.270Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 2 - 3 - 1 - 19 - [16,0] - 96
2022-08-02T01:43:05.270Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- SYS - osalNvLength - {"length":16}
2022-08-02T01:43:05.271Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-02T01:43:05.271Z zigbee-herdsman:adapter:zStack:znp:SREQ --> SYS - osalNvWriteExt - {"id":98,"offset":0,"len":16,"value":{"type":"Buffer","data":[1,3,5,7,9,11,13,15,0,2,4,6,8,10,12,13]}}
2022-08-02T01:43:05.272Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,22,33,29,98,0,0,0,16,0,1,3,5,7,9,11,13,15,0,2,4,6,8,10,12,13,91]
2022-08-02T01:43:05.280Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,97,29,0,125]
2022-08-02T01:43:05.281Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,97,29,0,125]
2022-08-02T01:43:05.281Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 1 - 29 - [0] - 125
2022-08-02T01:43:05.281Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- SYS - osalNvWriteExt - {"status":0}
2022-08-02T01:43:05.281Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-02T01:43:05.281Z zigbee-herdsman:adapter:zStack:startup:commissioning beginning network commissioning
2022-08-02T01:43:05.282Z zigbee-herdsman:adapter:zStack:znp:SREQ --> APP_CNF - bdbSetChannel - {"isPrimary":1,"channel":2048}
2022-08-02T01:43:05.283Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,5,47,8,1,0,8,0,0,43]
2022-08-02T01:43:05.288Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,111,8,0,102]
2022-08-02T01:43:05.292Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,111,8,0,102]
2022-08-02T01:43:05.292Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 15 - 8 - [0] - 102
2022-08-02T01:43:05.292Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- APP_CNF - bdbSetChannel - {"status":0}
2022-08-02T01:43:05.292Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-02T01:43:05.293Z zigbee-herdsman:adapter:zStack:znp:SREQ --> APP_CNF - bdbSetChannel - {"isPrimary":0,"channel":0}
2022-08-02T01:43:05.293Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,5,47,8,0,0,0,0,0,34]
2022-08-02T01:43:05.299Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,111,8,0,102]
2022-08-02T01:43:05.300Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,111,8,0,102]
2022-08-02T01:43:05.300Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 15 - 8 - [0] - 102
2022-08-02T01:43:05.300Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- APP_CNF - bdbSetChannel - {"status":0}
2022-08-02T01:43:05.300Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-02T01:43:05.302Z zigbee-herdsman:adapter:zStack:znp:SREQ --> APP_CNF - bdbStartCommissioning - {"mode":4}
2022-08-02T01:43:05.303Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,1,47,5,4,47]
2022-08-02T01:43:08.030Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,111,5,0,107,254,3,79,128,1,2,4,203]
2022-08-02T01:43:08.031Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,111,5,0,107,254,3,79,128,1,2,4,203]
2022-08-02T01:43:08.031Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 15 - 5 - [0] - 107
2022-08-02T01:43:08.031Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- APP_CNF - bdbStartCommissioning - {"status":0}
2022-08-02T01:43:08.034Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,79,128,1,2,4,203]
2022-08-02T01:43:08.034Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 15 - 128 - [1,2,4] - 203
2022-08-02T01:43:08.035Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- APP_CNF - bdbComissioningNotifcation - {"status":1}
2022-08-02T01:43:08.037Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-02T01:43:08.355Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,69,192,8,140]
2022-08-02T01:43:08.355Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,69,192,8,140]
2022-08-02T01:43:08.356Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 2 - 5 - 192 - [8] - 140
2022-08-02T01:43:08.356Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - stateChangeInd - {"state":8}
2022-08-02T01:43:08.357Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
Содержание
- Error while starting zigbee-herdsman #2928
- Comments
- Error while starting zigbee-herdsman. failed to start zigbee #322
- Comments
- # Zigbee2MQTT fails to start
- # Error: SRSP — SYS — ping after 6000ms
- # Verify that you put the correct port in configuration.yaml
- # Which port should I use for Texas Instruments LAUNCHXL-CC26X2R1/CC1352P-2, /dev/ttyACM0 or /dev/ttyACM1?
- # Verify that the user you run Zigbee2MQTT as has write access to the port
- # Method 1: Give your user permissions on every reboot.
- # Method 2: Add your user to specific groups
- # Error: Coordinator failed to start, probably the panID is already in use, try a different panID or channel
- # Error: Resource temporarily unavailable Cannot lock port
- # Raspberry Pi users: use a good power supply
- # Make sure the extension cable works
- # For Openhab users: disable zwave binding
- # In case of a CC2530 or CC2531 adapter, verify that don’t have a CC2540
- # ModemManager
- # hciuart is running
- # Texas Instruments LAUNCHXL-CC1352P-2/CC26X2R1 only: press the reset button on the device
- # CC2531 coordinators only: press the reset button on the device
- # Texas Instruments LAUNCHXL-CC26X2R1 coordinator only: verify that you have the correct revision
Error while starting zigbee-herdsman #2928
Every raspberry startup zigbe2mqtt process don’t startup, zigbe2mqtt process need three attempts fort startup, in the third attemp starts correctly. after raspberry reboot again the same problem appears I paste the info from logs:
zigbe2mqtt log:
Log from .npm, folder
Log from opt—>zigbe—>data
i«`
nfo 2020-02-10 14:54:31: Logging to console and directory: ‘/opt/zigbee2mqtt/data/log/2020-02-10.14-54-31’ filename: log.txt
info 2020-02-10 14:54:31: Starting zigbee2mqtt version 1.10.0-dev (commit #13b996e)
info 2020-02-10 14:54:31: Starting zigbee-herdsman.
error 2020-02-10 14:55:21: Error while starting zigbee-herdsman
The text was updated successfully, but these errors were encountered:
Got the same issue, only mine doesn’t start at all. Happend after upgrading to 1.10.0
Same here, also running zigbee2mqtt version: version 1.10.0 and happens at random times when it is running, need to stop zigbee2mqtt and unplug the usb and plug in it and start zigbee2mqtt to get it to work again.
Already tried the stuff in the FAQ?
I apologize for reopening a repeated issue, I was looking before opening it but I didn’t find it. You were right, with the tests I was doing I put the zigbe2mqtt dongle in another usb port. Thank you very much for all the support you are giving to everyone with problems that are coming out, it is very kind. Best regards
For anyone coming here with this issue when running the IOTstack zigbee2mqtt docker image, change the docker-compose.yml to use a different port. By default the port mapping is — /dev/ttyAMA0:/dev/ttyACM0 but changing it to — /dev/ttyACM0:/dev/ttyACM0 solved this issue for me.
as described here
Sorry to react on a repeated issue, but I tried everything discussed before.
Keep getting error with starting zigbee-herdsman.
Started with a CC2531 USB stick and initially all ok. After updating zigbee2mqtt the issue started with the zigbee-herdman not starting up.
Since I also had an issue with the limited number of devices and the range of the CC2531 USB stick, I bought a Texas Instruments CC26X2R1. Also in the hope this would solve the issue with the zigbee-herdsman.
At first connection the new adapter worked, but after trying to connect the third device (xiaomi plug) it stopped working.
Trying to restart the zigbee2mqtt gave again the error with the zigbee-herdsman.
This is what I get when trying to start:
pi@DOMOTICZ:/opt/zigbee2mqtt $ DEBUG=zigbee-herdsman* npm start
zigbee2mqtt@1.12.0 start /opt/zigbee2mqtt
node index.js
zigbee2mqtt:info 2020-04-08 00:49:32: Logging to console and directory: ‘/opt/zigbee2mqtt/data/log/2020-04-08.00-49-32’ filename: log.txt
zigbee2mqtt:debug 2020-04-08 00:49:32: Loaded state from file /opt/zigbee2mqtt/data/state.json
zigbee2mqtt:info 2020-04-08 00:49:32: Starting zigbee2mqtt version 1.12.0 (commit #840b9d9)
zigbee2mqtt:info 2020-04-08 00:49:32: Starting zigbee-herdsman.
zigbee2mqtt:debug 2020-04-08 00:49:32: Using zigbee-herdsman with settings: ‘<«network»:<«panID»:6754,»extendedPanID»:[221,221,221,221,221,221,221,221],»channelList»:[11],»networkKey»:»HIDDEN»>,»databasePath»:»/opt/zigbee2mqtt/data/database.db»,»databaseBackupPath»:»/opt/zigbee2mqtt/data/database.db.backup»,»backupPath»:»/opt/zigbee2mqtt/data/coordinator_backup.json»,»serialPort»:<«baudRate»:115200,»rtscts»:true,»path»:»/dev/ttyACM0″>>’
zigbee-herdsman:adapter Path ‘/dev/ttyACM0’ is valid for ‘ZStackAdapter’ +0ms
zigbee-herdsman:controller:log Starting with options ‘<«network»:<«networkKeyDistribute»:false,»networkKey»:[1,3,5,7,9,11,13,15,0,2,4,6,8,10,12,13],»panID»:6754,»extendedPanID»:[221,221,221,221,221,221,221,221],»channelList»:[11]>,»serialPort»:<«baudRate»:115200,»rtscts»:true,»path»:»/dev/ttyACM0″>,»databasePath»:»/opt/zigbee2mqtt/data/database.db»,»databaseBackupPath»:»/opt/zigbee2mqtt/data/database.db.backup»,»backupPath»:»/opt/zigbee2mqtt/data/coordinator_backup.json»>’ +0ms
zigbee-herdsman:adapter:zStack:znp:log Opening SerialPort with /dev/ttyACM0 and <«baudRate»:115200,»rtscts»:true,»autoOpen»:false>+0ms
zigbee2mqtt:error 2020-04-08 00:49:32: Error while starting zigbee-herdsman
zigbee2mqtt:error 2020-04-08 00:49:32: Failed to start zigbee
zigbee2mqtt:error 2020-04-08 00:49:32: Exiting.
zigbee2mqtt:error 2020-04-08 00:49:32: Error: Error while opening serialport ‘Error: Error Resource temporarily unavailable Cannot lock port’
at Znp. (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/znp/znp.js:113:32)
at Generator.next ()
at /opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/znp/znp.js:8:71
at new Promise ()
at __awaiter (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/znp/znp.js:4:12)
at SerialPort. (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/znp/znp.js:111:49)
at SerialPort._error (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/node_modules/@serialport/stream/lib/index.js:198:14)
at /opt/zigbee2mqtt/node_modules/zigbee-herdsman/node_modules/@serialport/stream/lib/index.js:242:12
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! zigbee2mqtt@1.12.0 start: node index.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the zigbee2mqtt@1.12.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /home/pi/.npm/_logs/2020-04-07T22_49_32_661Z-debug.log
Really hope that this makes sense and there is support.
Источник
Error while starting zigbee-herdsman. failed to start zigbee #322
Description of problem:
after installing and edit the config. the conbee2 does not properly start-up with the zigbee2mqtt addon. There is no specific error code show in the logs.
Zigbee2mqtt add-on version (if edge, please report commit hash):
Your entire configuration from the frontend (with sensitive fields redacted):
Running platform (details from Suypervisor > System)
Your logs from Home Assistant Supervisor
The text was updated successfully, but these errors were encountered:
I got same exact issue running Current version: 1.25.0-1
Version core-2022.4.2 Version supervisor-2022.04.0
I have the same problem.
It looks database.db file has some problem. I want to open the file and edit it.
But, I cannot open it.
Is there the way to edit it?
any update on this?
Also same issue here
same issue. have not ZHA
. 4 hours later
solved. (in my case) with just edit the z2m config:
- port is the same as dev/ttyUSB0 in my case I think both will works
- I have HAOS on nettop Chatreey AC1-Z with intel Celeron J4125
- also I tried to reflash my zigbee stick cc2652p (https://aliexpress.ru/item/1005002875838019.html) but wasted time
- user and password is the same in mosquitto add-on, mqtt integration and the additional HA user (didn’t check if it matters or not)
Question, I have paired a non supported Zigbee light is there any way to get it working in z2m, it works in zha.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
any update on this?
I still waiting for a fix 🙂
@kathodion can you provide the herdsman debug logging when starting z2m?
See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable the herdsman debug logging. Note that this is only logged to STDOUT and not to log files.
@Koenkk I would need a few days but I will provide the information
@Koenkk I believe I have the same issue although I’m not seeing the Failed to connect to the adapter (Error: SRSP — SYS — ping after 6000ms) error like in @dyarfaradj’s log. @kathodion’s error log looks very much the same as posted in #348 (comment) , maybe related?
I’m using haos_ova-8.2.vmdk running in VMware workstation, the adapter is a «CC2652P2 Based Zigbee to PoE Coordinator 2022» and works fine with Z2H but yet to see Zigbee2MQTT start successfully on this installation.
Home Assistant Core 2022.6.7
Home Assistant Supervisor 2022.05.3
Home Assistant OS 8.2
I experience the same issue with both the current and edge branch, below is using Zigbee2MQTT Edge
Config:
I’m not sure if this is relevant but I notice in the log multiple files are mentioned in /config/zigbee2mqtt/ e.g. /config/zigbee2mqtt/database.db but I only see two files in this folder
@Ricardo-0101 your config looks wrong to me, under the serial section you have to fill in just:
@Ricardo-0101 your config looks wrong to me, under the serial section you have to fill in just:
@Koenkk You are exactly right, can’t believe I didn’t notice this in the yaml, Tubes GitHub references adding below to the yaml however as I had added it via the serial field in the config page serial: was duplicated.
Interestingly after correcting this I got an error similar to @dyarfaradj i.e. Error: Failed to connect to the adapter (Error: SRSP — SYS — ping after 6000ms) but this cleared once I had disabled ZHA in the integrations so all is well now. Thank you.
I have got version 1.26.0-1 installed. However, still getting the same issue.
I’ve got version 1.26.0-1 installed.
INFO: Handing over control to Zigbee2MQTT Core .
zigbee2mqtt@1.26.0 start
node index.js
Zigbee2MQTT:info 2022-07-26 17:45:46: Logging to console and directory: ‘/config/zigbee2mqtt/log/2022-07-26.17-45-46’ filename: log.txt
Zigbee2MQTT:info 2022-07-26 17:45:46: Starting Zigbee2MQTT version 1.26.0 (commit #unknown)
Zigbee2MQTT:info 2022-07-26 17:45:46: Starting zigbee-herdsman (0.14.40)
Zigbee2MQTT:error 2022-07-26 17:45:47: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2022-07-26 17:45:47: Failed to start zigbee
Zigbee2MQTT:error 2022-07-26 17:45:47: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
Zigbee2MQTT:error 2022-07-26 17:45:47: Exiting.
Zigbee2MQTT:error 2022-07-26 17:45:47: Error: Struct length mismatch (expected=16/16, got=32)
at Struct.build (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/structs/struct.ts:334:23)
at nwkKey (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/structs/entries/nwk-key.ts:12:6)
at AdapterNvMemory.readItem (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/adapter-nv-memory.ts:73:21)
at AdapterBackup.createBackup (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/adapter-backup.ts:104:67)
at Controller.backup (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:302:28)
at Controller.start (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:158:13)
at Zigbee.start (/app/lib/zigbee.ts:58:27)
at Controller.start (/app/lib/controller.ts:101:27)
at start (/app/index.js:109:5)
Have the same issue. 😐
Zigbee2mqtt version: 1.26.0
Upgraded to version 1.27.0-1. Still getting the same issue.
Источник
# Zigbee2MQTT fails to start
Most of the time this is caused by Zigbee2MQTT not being able to communicate with your Zigbee adapter.
# Error: SRSP — SYS — ping after 6000ms
4 common reasons of this error:
- The port of your serial adapter changed. Check this to find out the port of your adapter.
- If you are using a CC2530 or CC2531; it is a common issue for this adapter to crash (due to its outdated hardware). Reflashing the firmware should fix the problem. If it happens often consider flashing the source routing firmware
open in new window or upgrade to a more powerful adapter.
# Verify that you put the correct port in configuration.yaml
Execute the following command to find out the correct path:
In this example the correct port would be /dev/ttyACM0 .
# Which port should I use for Texas Instruments LAUNCHXL-CC26X2R1/CC1352P-2, /dev/ttyACM0 or /dev/ttyACM1?
The Texas Instruments launchpad has a build in debugger. This debugger also registers a port next to the device data port. Of course this is not necessarily number 0 and 1. But normally the lowest number is the device data port and the other the debugger.
To find the correct port, execute:
The device with id ending with if00 is for device data. Use this port in your configuration.
# Verify that the user you run Zigbee2MQTT as has write access to the port
This can be tested by executing: test -w [PORT] && echo success || echo failure ( e.g. test -w /dev/ttyACM0 && echo success || echo failure ).
If it outputs failure it could mean your user does not have access to the port. To test assign write access by executing: sudo chown [USER] [PORT] (e.g. sudo chown pi /dev/ttyACM0 ).
if it outputs failure , then you need to permanently give your user permission to the device.
# Method 1: Give your user permissions on every reboot.
You can create a ‘udev’ rule to give your user permissions after every reboot:
udevadm info -a -n /dev/ttyACM0 | grep ‘serial’ get the serial to your device YOURSERIAL
Create the rule file with: sudo nano /etc/udev/rules.d/99-usb-serial.rules
add this line: SUBSYSTEM==»tty», ATTRS==»0451″, ATTRS==»16a8″, ATTRS==»YOURSERIAL», SYMLINK=»ttyUSB.CC2531-01″, OWNER=»pi»
modify your Zigbee2MQTT config to adjust new SYMLINK name: nano /opt/zigbee2mqtt/data/configuration.yaml
… serial: port: /dev/ttyUSB.CC2531-01 …
After reboot your device will have the right permissions and always the same name.
# Method 2: Add your user to specific groups
As mentioned on https://github.com/esp8266/source-code-examples/issues/26 , depending on your linux installation, various groups could have ownership of the device.
Add your user to the uucp , tty , dialout groups:
Reboot your device and now your user should have access to the device.
# Error: Coordinator failed to start, probably the panID is already in use, try a different panID or channel
- If you still get this error after increasing the panID (as explained here) and you are using a Raspberry Pi with other USB devices
- In case you are getting this after first starting successfully and pairing a device it might be that the firmware has been flashed incorrectly. Try flashing the stick on a different computer (detailed info
open in new window ). This issue mainly occurs in combination with a Slaesh’s CC2652RB stick.
# Error: Resource temporarily unavailable Cannot lock port
This error occurs when another program is already using (and thus locking) the adapter. You can find out which via the following command: ls -l /proc/[0-9]/fd/ |grep /dev/ttyACM0 (replace /dev/ttyACM0 with your adapter port).
# Raspberry Pi users: use a good power supply
A bad power supply can make your system and its USB devices unstable. Make sure to use a good power supply.
In case you see message like below when running dmesg -w you are using a bad power supply.
When you have a SSD connected to the Pi, try connecting the adapter via a powered USB hub.
# Make sure the extension cable works
A bad extension cable can lead to connection issues between the system and the adapter. Symptoms of this are disconnection messages in the dmesg -w log like below.
# For Openhab users: disable zwave binding
The Openhab zwave binding interferes with Zigbee2MQTT, click here
# In case of a CC2530 or CC2531 adapter, verify that don’t have a CC2540
The CC2540 can be confused easily with the CC2531 as it looks (almost) exactly the same. However, this device does not support zigbee but bluetooth. This can be verified by looking at the chip.
# ModemManager
ModemManager, which is default installed on e.g. Ubuntu, is known to cause problems. It can easily be fixed by removing ModemManager through sudo apt-get purge modemmanager .
# hciuart is running
hciuart can be disabled by executing: sudo systemctl disable hciuart .
# Texas Instruments LAUNCHXL-CC1352P-2/CC26X2R1 only: press the reset button on the device
If Zigbee2MQTT fails to start with a Texas Instruments LAUNCHXL-CC1352P-2/CC26X2R1 with Error: SRSP — SYS — version after 6000ms , you most probably have connected your device to a system that requires pressing the reset button (the one next to the USB connector) momentarily/shortly after connecting the USB cable. This issue has primarily been observed on x86 architectures only ( e.g., Intel NUC, HPE Microserver, i7 laptop), see also #2162
open in new window . The procedure has to be repeated every time the adapter is re-connected and it’s not clear yet, whether this can be fixed at all. It does not seem to occur on ARM based boards (Raspberry Pi, ODROID XU4).
Something that can also solve the issue is to replug the USB cable.
# CC2531 coordinators only: press the reset button on the device
When you plug the CC2531 in your computer, the green LED should go on. By pressing the reset button on the CC2531 the green LED should go off. The CC2531 has 2 buttons on it, the reset button is the one which is closest to the USB port. Now try starting Zigbee2MQTT again.
# Texas Instruments LAUNCHXL-CC26X2R1 coordinator only: verify that you have the correct revision
The revision of your board can be seen in UniFlash by clicking more info in the top, now press Read device info.
The correct revision is: E like shown below.
All earlier version are not supported (these are development boards). Return this board to the seller immediately.
Источник
EDIT: It’s working now. Thanks to all who helped.
My setup: Home Assistant core-2022.4.5 running on Debian.
Following Mark Watt’s video, last night I flashed this launchpad coordinator to my SONOFF Zigbee 3.0 USB Dongle. No issues.
Both Configuration | Host | Hardware and ls -l /dev/serial/by-id report that the Sonoff dongle is on /dev/ttyUSB0:
$ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Apr 19 05:41 usb-0658_0200-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Apr 19 13:26 usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_169749bd0986ec11a369631719c2d21c-if00-port0 -> ../../ttyUSB0
Here’s my Zigbee2mqtt configuration:
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:
base_topic: zigbee2mqtt
user: mqtt_user
password: mqtt_password
server: mqtt://localhost:1883
serial:
port: /dev/ttyUSB0
homeassistant: true
frontend:
port: 8099
Zigbee2mqtt just won’t start. The log reports «Failed to connect to the adapter»:
[14:14:48] INFO: Handing over control to Zigbee2mqtt Core ...
> zigbee2mqtt@1.25.0 start
> node index.js
Zigbee2MQTT:info 2022-04-19 14:14:52: Logging to console and directory: '/config/zigbee2mqtt/log/2022-04-19.14-14-51' filename: log.txt
Zigbee2MQTT:info 2022-04-19 14:14:52: Starting Zigbee2MQTT version 1.25.0 (commit #unknown)
Zigbee2MQTT:info 2022-04-19 14:14:52: Starting zigbee-herdsman (0.14.20)
Zigbee2MQTT:error 2022-04-19 14:15:13: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2022-04-19 14:15:13: Failed to start zigbee
Zigbee2MQTT:error 2022-04-19 14:15:13: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
Zigbee2MQTT:error 2022-04-19 14:15:13: Exiting...
Zigbee2MQTT:error 2022-04-19 14:15:13: 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:102:27)
at Controller.start (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:123:29)
at Zigbee.start (/app/lib/zigbee.ts:58:27)
at Controller.start (/app/lib/controller.ts:100:27)
at start (/app/index.js:101:5)
Thinking that maybe my USB extension cable might be at fault, I also tried plugging the dongle directly into the USB port. No change.
Also re-flashed. Also no change.
Can anyone spot what might be going on?
Error while starting zigbee-herdsman #2928
Bug Report
Every raspberry startup zigbe2mqtt process don’t startup, zigbe2mqtt process need three attempts fort startup, in the third attemp starts correctly. after raspberry reboot again the same problem appears I paste the info from logs:
zigbe2mqtt log:
Log from .npm, folder
Log from opt—>zigbe—>data
i«`
nfo 2020-02-10 14:54:31: Logging to console and directory: ‘/opt/zigbee2mqtt/data/log/2020-02-10.14-54-31’ filename: log.txt
info 2020-02-10 14:54:31: Starting zigbee2mqtt version 1.10.0-dev (commit #13b996e)
info 2020-02-10 14:54:31: Starting zigbee-herdsman.
error 2020-02-10 14:55:21: Error while starting zigbee-herdsman
The text was updated successfully, but these errors were encountered:
Got the same issue, only mine doesn’t start at all. Happend after upgrading to 1.10.0
Same here, also running zigbee2mqtt version: version 1.10.0 and happens at random times when it is running, need to stop zigbee2mqtt and unplug the usb and plug in it and start zigbee2mqtt to get it to work again.
Already tried the stuff in the FAQ?
I apologize for reopening a repeated issue, I was looking before opening it but I didn’t find it. You were right, with the tests I was doing I put the zigbe2mqtt dongle in another usb port. Thank you very much for all the support you are giving to everyone with problems that are coming out, it is very kind. Best regards
For anyone coming here with this issue when running the IOTstack zigbee2mqtt docker image, change the docker-compose.yml to use a different port. By default the port mapping is — /dev/ttyAMA0:/dev/ttyACM0 but changing it to — /dev/ttyACM0:/dev/ttyACM0 solved this issue for me.
as described here
Sorry to react on a repeated issue, but I tried everything discussed before.
Keep getting error with starting zigbee-herdsman.
Started with a CC2531 USB stick and initially all ok. After updating zigbee2mqtt the issue started with the zigbee-herdman not starting up.
Since I also had an issue with the limited number of devices and the range of the CC2531 USB stick, I bought a Texas Instruments CC26X2R1. Also in the hope this would solve the issue with the zigbee-herdsman.
At first connection the new adapter worked, but after trying to connect the third device (xiaomi plug) it stopped working.
Trying to restart the zigbee2mqtt gave again the error with the zigbee-herdsman.
This is what I get when trying to start:
pi@DOMOTICZ:/opt/zigbee2mqtt $ DEBUG=zigbee-herdsman* npm start
zigbee2mqtt@1.12.0 start /opt/zigbee2mqtt
node index.js
zigbee2mqtt:info 2020-04-08 00:49:32: Logging to console and directory: ‘/opt/zigbee2mqtt/data/log/2020-04-08.00-49-32’ filename: log.txt
zigbee2mqtt:debug 2020-04-08 00:49:32: Loaded state from file /opt/zigbee2mqtt/data/state.json
zigbee2mqtt:info 2020-04-08 00:49:32: Starting zigbee2mqtt version 1.12.0 (commit #840b9d9)
zigbee2mqtt:info 2020-04-08 00:49:32: Starting zigbee-herdsman.
zigbee2mqtt:debug 2020-04-08 00:49:32: Using zigbee-herdsman with settings: ‘<«network»:<«panID»:6754,»extendedPanID»:[221,221,221,221,221,221,221,221],»channelList»:[11],»networkKey»:»HIDDEN»>,»databasePath»:»/opt/zigbee2mqtt/data/database.db»,»databaseBackupPath»:»/opt/zigbee2mqtt/data/database.db.backup»,»backupPath»:»/opt/zigbee2mqtt/data/coordinator_backup.json»,»serialPort»:<«baudRate»:115200,»rtscts»:true,»path»:»/dev/ttyACM0″>>’
zigbee-herdsman:adapter Path ‘/dev/ttyACM0’ is valid for ‘ZStackAdapter’ +0ms
zigbee-herdsman:controller:log Starting with options ‘<«network»:<«networkKeyDistribute»:false,»networkKey»:[1,3,5,7,9,11,13,15,0,2,4,6,8,10,12,13],»panID»:6754,»extendedPanID»:[221,221,221,221,221,221,221,221],»channelList»:[11]>,»serialPort»:<«baudRate»:115200,»rtscts»:true,»path»:»/dev/ttyACM0″>,»databasePath»:»/opt/zigbee2mqtt/data/database.db»,»databaseBackupPath»:»/opt/zigbee2mqtt/data/database.db.backup»,»backupPath»:»/opt/zigbee2mqtt/data/coordinator_backup.json»>’ +0ms
zigbee-herdsman:adapter:zStack:znp:log Opening SerialPort with /dev/ttyACM0 and <«baudRate»:115200,»rtscts»:true,»autoOpen»:false>+0ms
zigbee2mqtt:error 2020-04-08 00:49:32: Error while starting zigbee-herdsman
zigbee2mqtt:error 2020-04-08 00:49:32: Failed to start zigbee
zigbee2mqtt:error 2020-04-08 00:49:32: Exiting.
zigbee2mqtt:error 2020-04-08 00:49:32: Error: Error while opening serialport ‘Error: Error Resource temporarily unavailable Cannot lock port’
at Znp. (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/znp/znp.js:113:32)
at Generator.next ()
at /opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/znp/znp.js:8:71
at new Promise ()
at __awaiter (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/znp/znp.js:4:12)
at SerialPort. (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/znp/znp.js:111:49)
at SerialPort._error (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/node_modules/@serialport/stream/lib/index.js:198:14)
at /opt/zigbee2mqtt/node_modules/zigbee-herdsman/node_modules/@serialport/stream/lib/index.js:242:12
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! zigbee2mqtt@1.12.0 start: node index.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the zigbee2mqtt@1.12.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /home/pi/.npm/_logs/2020-04-07T22_49_32_661Z-debug.log
Really hope that this makes sense and there is support.
Источник
Error while starting zigbee-herdsman #9518
What happened
Error while starting zigbee-herdsman
Failed to start zigbee
It happens on both ConBee II and CC2531
There is nothing specific in the log. Just entries I shared above. 
What did you expect to happen
How to reproduce it (minimal and precise)
Debug info
Zigbee2MQTT version: 1.22.0-2
Adapter hardware: CC2531, Conbee II
Adapter firmware version:
The text was updated successfully, but these errors were encountered:
a similar problem appeared two weeks ago, the SNZB-02 sensor stopped responding
guys, I need help 
Zigbee2MQTT version: 1.22.0
Adapter hardware: CC2531
Adapter firmware version: CC2531_DEFAULT_20190608
same here cc2531, coordinator 1.2. It happens in two different computers (different locations and networks). Both after updating zigbee2mqtt yesterday.
Error starting herdsman and something about json end of file.
Edit: Went back using HA backups to:
HA core: 2021.11.1 downgrade to 2021.10.1
zigbee2mqtt: 1.22.0-2 downgraded to 1.21.1-1 —> START WORKING OK.
. and suddenly all log lines green again. And all devices connected.
Edit2: I have downgraded on my other HA instance. Same solution. This tiime this are the backups I have available:
HA core: 2021.10.6 —-> downgraded to 2021.10.2
zigbee2mqtt 1.22.0-2 ——> downgraded to 1.21.2-1 —-> NOT WORKING YET (same errors when starting in logs —> Downgraded to 1.18.3-1 —-> Started with all green lines, and devices connected.
With this two installations, I can see the problem appears when updating zigbee2mqtt to version 1.21.2-1, that shows the error, because 1.21.1-1 seems working in the first HA.
Capture with lines filling endlessly the log when trying to start on 1.21.2-1 or later 
:
same here exactly after updating from 1.17.0 to 1.22.0 on my raspberry.
how can I go back to 1.21.1 if above guys writing it works
how can I go back to 1.21.1 if above guys writing it works
Not sure in your case. I can tell you that when you update to 1.22 home assistant asks you to save a backup of your current version of zigbee2mqtt (1.17) and config files. If you answered yes when asked, then you could go to:
SUPERVISOR -> Backups (top menu) -> And search for that backup which will be called with the name of zigbee2mqtt 1.17. Open it, check marks on addon and config files and hit RESTORE. You will go back to your previous version. Comment us if that fixed your problem (temporaly of course). I’m the only one by now confirming it with the downgrade to 1.21.1-1 or previous. My guess is that 1.21.2 introduces the problem we are having.
I think it is not easy to downgrade to certain version if you dont have the backup. The only thing that I found was about trying zigbee2mqtt edge, here: https://community.home-assistant.io/t/how-to-downgrade-zigbee2mqtt/231273/7 but I guess that would not fix the issue because edge will be even newer than 1.22 and nobody has said anything about fixing this problem on edge version so.
@sanyafifa is using cc2531 dongle with coordinator firmware: CC2531_DEFAULT_20190608
@user514 is using cc2531 dongle with coordinator firmware: CC2531_DEFAULT_20190608
@belet-pl is using cc2531 dongle . unknown firmware
@evilmumi is using . dongle with . firmware
. if we all are using same dongle, with same old firmware and no other people are complaining about latest updates of zigbee2mqtt, maybe problem could be solved updating our coordinator dongle to version CC2531_DEFAULT_20201127, which I think could be the last one available.
@belet-pl and @evilmumi could you please check which version of coordinator firmware you installed in your usb dongle on your zigbee network?.
Having similar/but different issues with my CC2531 adapter. A few days after the upgrade of HASS to core-2021.10.6 and Zigbee2mqtt v1.22.0-2 my adapter would be «Removed» after the addon started. Fixed by switching firmware from Z-Stack_Home_1.2 (default) to Z-Stack_Home_1.2 (source_routing).
@user514 cc2531 dongle with unknown firmware — can you tell how i can read out version and how to update — i bought it fully flashed on private base
Fixed by switching firmware from Z-Stack_Home_1.2 (default) to Z-Stack_Home_1.2 (source_routing).
Thank you Mike. Good information. That goes in the direction of fixing it by updating coordinator firmware. This is just a guess, but I think it could be solved by flashing again 1.2 DEFAULT but with the last version 2020-11-27. I think that because if not, much more people would be complaining with zigbee2mqtt last updates.
I will let you know here if I have time to update coordinator dongle with 2020 version and test.
@user514 did you have Sonoff devices on your network?
I started with periodically disconnecting the sensor, to fix it I switched the CC2531 stick
This is just a guess, but I think it could be solved by flashing again 1.2 DEFAULT but with the last version 2020-11-27.
We are waiting for information from the dear @Koenkk
@user514 cc2531 dongle with unknown firmware — can you tell how i can read out version and how to update — i bought it fully flashed on private base
In my case I bought the dongle clean and have to upload the firmware that was available at that time. CC2531_DEFAULT_20190608. I don’t know if there is any way to know which firm is on the dongle easily. I know because that was the one I upload to it.
To update, you need a cc degugger. Try to search at aliexpress ‘cc debugger’ and you will see the kit everyone has. You install the windows drivers for the debugger, install the texas instruments flash programmer, connect the USB dongle to the debugger with the included cable, download the proper firmware (for our dongles probably this one:
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_Home_1.2/bin/default ) and upload to the dongle. Should me much better explained with pictures at zigbee2mqtt page. ‘Flashing the coordinator’ or something like that. Yes, this one if you have a cc2531 as I do: https://www.zigbee2mqtt.io/guide/adapters/flashing/flashing_the_cc2531.html
. now I see that coordinator version could be seen at zigbee2mqtt startup. The problem is that the line is just the first one after the line ‘Starting zigbee-herdsman. » which is the one with the error in this thread. So probably you could not see it if you don’t downgrade zigbee2mqtt to some previous version older than 1.21.1-1 or previous. If you do and fix addon start you will see it here:
@user514 did you have Sonoff devices on your network?
. if you mean, sonoff in general (wifi switch basic model), yes. But I think you mean sonoff zigbee devices: Not on any of the two networks that I have. Some xiaomi and a cc2530 router (as repeater). Keep thinking is a problem with old coordinator firmware (exactly with 20190608 coordinator, unless somebody says something different)
@user514 i have this line on 1.20.0 : info 2021-11-08 13:16:53: Coordinator firmware version: ‘<«meta»:<«maintrel»:0,»majorrel»:2,»minorrel»:0,»product»:0,»revision»:»»,»transportrev»:2>,»type»:»zStack12″>’
I tested 1.21.0 and it throws the same error as 1.22.0. I will ask guy where i bought stick if he know which firmware i have on it
Don’t know why yours is not giving it.
I tested 1.21.0 and it throws the same error as 1.22.0.
Please, check the complete version numbers you are trying, because I have two versions of 1.21. once starts ok, and the other throws the error as:
1.21.1-1 zigbee2mqtt starts without errors.
1.21.2-1 won’t start. Throws error to me.
(1.22.xx of course, the error continues.)
Please check if the version 1.21 that throws error to you is 1.21.2-1 (or I will be mistaken about the version that introduces the failure).
i just got information that my stick has SBL so I can update to new firmware from here:
#320
I will test it next 24h.
i just checkedout 1.20 it is 1.2.0 not 1.21.
Я только что получил информацию, что у моей флешки есть SBL, поэтому я могу обновить прошивку отсюда:
# 320
Hey! @evilmumi
I could not flash it in this way! When I received my CC2531, I flashed it through the raspberry.
If you succeed, let us know
let us know how it goes. thanks.
@user514 doing some stuff like this https://www.marrold.co.uk/2019/12/flashing-cc2530-cc2591-zigbee-module.html i think i crashed my 2531.
i have an sonoff 3.0 stick and will test it with 1.22.0 perhaps new pairing everything
You are linking to a page where they flash a cc2530-cc2591. and then you say you have a 2531. It’s important to flash to a compatible version with your hardware. In this same page, same guy links to a page where he flash a 2531, here:
https://www.marrold.co.uk/2019/09/flashing-cc2531-zigbee-dongle-with.html
This one seems more correct than the one you are linking having in mind you have a 2531 dongle.
i have an sonoff 3.0 stick and will test it with 1.22.0 perhaps new pairing everything
Be careful too with writing firmware that is not made for 3.0 like your sonoff. USB cc2531 uses version 1.2, at least mine. There are two different versions of coordinator firmware, one for 1.2 and other for 3.0. In the sonoff 3.0 I suppose should go the 3.0 version, don’t know exactly which one 3.0 or 3.x, check that. I link you to the home directory where you select which firmware you like to download, 1.2 or 3.0 (some folders prior of the link I post earlier):
Check which is the right firmware for your sonoff 3.0 before proceeding.
@user514: For me everything is now working. leave my 2530/2531 crashed away so long as i will get answer from seller .
Now I flashed with fw from https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin
which link me correct version for my sonoff stick and updating was very easy.
. ok, so you flashed with 3.x.0, version —> coordinator_20210708.zip right?. Good to know. Probably I will be updating to coordinator 20201127 which is the last version for out 2531 and hope everything get solved too then.
If somebody updates 2531 to actual version and get the problem solved, let us know here. Thanks.
@user514 i flashed CC1352P2_CC2652P_launchpad_coordinator_20210708.zip
@user514
flashed CC2531 and started Z2M!
but SNZB-02 still does not transmit data
but SNZB-02 still does not transmit data
. maybe because of new coordinator writen on dongle, SNZB-02 needs a new re-pair?.
SOLVED:
Would like to update, that today, I upgraded my usb dongle cc2531 from CC2531_DEFAULT_20190608.zip and now I installed (.hex file) from CC2531_DEFAULT_20201127.zip on my coordinator dongle.
With that. zigbee2mqtt starts without the zigbee-herdsman error. Everything went smooth, but I went the careful way and did it as clean as possible:
-remove old devices (force remove on some)
-supervisor -> reboot to stay on clean HA.
-One thing I learned here. Previously I have problems with devices connecting with coordinator directly, but they have a router closer to them. To avoid that, This time I enable ‘Permit Join’ only over the device I want to function as entering gate. For example:
Permit pair (router-garage) -> click pairing door sensor of garage
This way, I got the sensor get connected and create route through the correct router. Not directly to coordinator.
I re-pair every device. I renamed every device, forcing update HA entities (thanks for that k.)
Everything goes normal. And the paths in zigbee map seems better thant before. Now testing everything is ok.
Источник
Most of the time this is caused by Zigbee2MQTT not being able to communicate with your Zigbee adapter.
Error: SRSP - SYS - ping after 6000ms
4 common reasons of this error:
- The port of your serial adapter changed. Check this to find out the port of your adapter.
- If you are using a CC2530 or CC2531; it is a common issue for this adapter to crash (due to its outdated hardware). Reflashing the firmware should fix the problem. If it happens often consider flashing the source routing firmwareopen in new window or upgrade to a more powerful adapter.
- Your adapter requires additional configuration parameters. Check supported Adapters section to find out if your adapter requires extra parameters (eg. ConBee II / RaspBee II).
- Home Assistant’s «Zigbee Home Automation» (ZHA) integration is enabled. Try to disable the ZHA integration and restart the Zigbee2MQTT add-on.
Verify that you put the correct port in configuration.yaml
Execute the following command to find out the correct path:
pi@raspberry:/ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx. 1 root root 13 Oct 19 19:26 usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0018ED3DDF-if00 -> ../../ttyACM0
In this example the correct port would be /dev/ttyACM0.
Which port should I use for Texas Instruments LAUNCHXL-CC26X2R1/CC1352P-2, /dev/ttyACM0 or /dev/ttyACM1?
The Texas Instruments launchpad has a build in debugger. This debugger also registers a port next to the device data port. Of course this is not necessarily number 0 and 1. But normally the lowest number is the device data port and the other the debugger.
To find the correct port, execute:
pi@raspberry:/ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Jan 6 19:07 usb-Texas_Instruments_XDS110__03.00.00.05__Embed_with_CMSIS-DAP_L1100BTD-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 6 19:07 usb-Texas_Instruments_XDS110__03.00.00.05__Embed_with_CMSIS-DAP_L1100BTD-if03 -> ../../ttyACM1
The device with id ending with if00 is for device data. Use this port in your configuration.
Verify that the user you run Zigbee2MQTT as has write access to the port
This can be tested by executing: test -w [PORT] && echo success || echo failure ( e.g. test -w /dev/ttyACM0 && echo success || echo failure).
If it outputs failure it could mean your user does not have access to the port. To test assign write access by executing: sudo chown [USER] [PORT] (e.g. sudo chown pi /dev/ttyACM0).
if it outputs failure, then you need to permanently give your user permission to the device.
Method 1: Give your user permissions on every reboot.
You can create a ‘udev’ rule to give your user permissions after every reboot:
-
udevadm info -a -n /dev/ttyACM0 | grep 'serial'get the serial to your deviceYOURSERIAL -
Create the rule file with:
sudo nano /etc/udev/rules.d/99-usb-serial.rules -
add this line:
SUBSYSTEM=="tty", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="16a8", ATTRS{serial}=="YOURSERIAL", SYMLINK="ttyUSB.CC2531-01", OWNER="pi" -
modify your Zigbee2MQTT config to adjust new SYMLINK name:
nano /opt/zigbee2mqtt/data/configuration.yaml
… serial: port: /dev/ttyUSB.CC2531-01 …
After reboot your device will have the right permissions and always the same name.
Method 2: Add your user to specific groups
As mentioned on https://github.com/esp8266/source-code-examples/issues/26 , depending on your linux installation, various groups could have ownership of the device.
Add your user to the uucp , tty , dialout groups:
sudo usermod -a -G uucp $USER
sudo usermod -a -G tty $USER
sudo usermod -a -G dialout $USER
Reboot your device and now your user should have access to the device.
Error: Coordinator failed to start, probably the panID is already in use, try a different panID or channel
- If you still get this error after increasing the panID (as explained here) and you are using a Raspberry Pi with other USB devices
- In case you are getting this after first starting successfully and pairing a device it might be that the firmware has been flashed incorrectly. Try flashing the stick on a different computer (detailed infoopen in new window). This issue mainly occurs in combination with a Slaesh’s CC2652RB stick.
Error: Resource temporarily unavailable Cannot lock port
This error occurs when another program is already using (and thus locking) the adapter. You can find out which via the following command: ls -l /proc/[0-9]/fd/ |grep /dev/ttyACM0 (replace /dev/ttyACM0 with your adapter port).
Raspberry Pi users: use a good power supply
A bad power supply can make your system and its USB devices unstable. Make sure to use a good power supply.
In case you see message like below when running dmesg -w you are using a bad power supply.
[44870.355590] Under-voltage detected! (0x00050005)
[44874.515618] Voltage normalised (0x00000000)
[44880.755718] Under-voltage detected! (0x00050005)
[44889.075627] Voltage normalised (0x00000000)
When you have a SSD connected to the Pi, try connecting the adapter via a powered USB hub.
Make sure the extension cable works
A bad extension cable can lead to connection issues between the system and the adapter. Symptoms of this are disconnection messages in the dmesg -w log like below.
[44929.156957] usb 1-1.5: USB disconnect, device number 119
[44929.455555] usb 1-1.5: new full-speed USB device number 120 using dwc_otg
[44929.604582] usb 1-1.5: New USB device found, idVendor=0451, idProduct=16a8, bcdDevice= 0.09
[44929.604596] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[44929.604606] usb 1-1.5: Product: TI CC2531 USB CDC
[44929.604615] usb 1-1.5: Manufacturer: Texas Instruments
For Openhab users: disable zwave binding
The Openhab zwave binding interferes with Zigbee2MQTT, click hereopen in new window for more information.
In case of a CC2530 or CC2531 adapter, verify that don’t have a CC2540
The CC2540 can be confused easily with the CC2531 as it looks (almost) exactly the same. However, this device does not support zigbee but bluetooth. This can be verified by looking at the chip.
ModemManageropen in new window is installed
ModemManager, which is default installed on e.g. Ubuntu, is known to cause problems. It can easily be fixed by removing ModemManager through sudo apt-get purge modemmanager.
hciuart is running
hciuart can be disabled by executing: sudo systemctl disable hciuart.
Texas Instruments LAUNCHXL-CC1352P-2/CC26X2R1 only: press the reset button on the device
If Zigbee2MQTT fails to start with a Texas Instruments LAUNCHXL-CC1352P-2/CC26X2R1 with Error: SRSP - SYS - version after 6000ms, you most probably have connected your device to a system that requires pressing the reset button (the one next to the USB connector) momentarily/shortly after connecting the USB cable. This issue has primarily been observed on x86 architectures only ( e.g., Intel NUC, HPE Microserver, i7 laptop), see also #2162open in new window. The procedure has to be repeated every time the adapter is re-connected and it’s not clear yet, whether this can be fixed at all. It does not seem to occur on ARM based boards (Raspberry Pi, ODROID XU4).
Something that can also solve the issue is to replug the USB cable.
CC2531 coordinators only: press the reset button on the device
When you plug the CC2531 in your computer, the green LED should go on. By pressing the reset button on the CC2531 the green LED should go off. The CC2531 has 2 buttons on it, the reset button is the one which is closest to the USB port. Now try starting Zigbee2MQTT again.
Texas Instruments LAUNCHXL-CC26X2R1 coordinator only: verify that you have the correct revision
The revision of your board can be seen in UniFlash by clicking more info in the top, now press Read device info.
The correct revision is: E like shown below.
All earlier version are not supported (these are development boards). Return this board to the seller immediately.