Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.88k stars 1.66k forks source link

question about ti cc1352p-2 #2162

Closed flower87lucky closed 4 years ago

flower87lucky commented 4 years ago

) zigbee2mqtt:info 2019-10-19T12:50:02: Starting zigbee-herdsman... zigbee2mqtt:error 2019-10-19T12:50:09: Error while starting zigbee-herdsman zigbee2mqtt:error 2019-10-19T12:50:09: Failed to start zigbee zigbee2mqtt:error 2019-10-19T12:50:09: Exiting... zigbee2mqtt:error 2019-10-19T12:50:09: Error: SRSP - SYS - version after 6000ms at Timeout.object.timer.setTimeout [as _onTimeout] (/app/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24) at ontimeout (timers.js:436:11) at tryOnTimeout (timers.js:300:5) at listOnTimeout (timers.js:263:5) at Timer.processTimers (timers.js:223:10) npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! zigbee2mqtt@1.6.0 start: node index.js npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the zigbee2mqtt@1.6.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! /root/.npm/_logs/2019-10-19T12_50_09_649Z-debug.log 2019-10-19T20:50:09: PM2 log: App [npm:0] exited with code [1] via signal [SIGINT] 2019-10-19T20:50:09: PM2 log: App [npm:0] starting in -fork mode- 2019-10-19T20:50:09: PM2 log: App

flower87lucky commented 4 years ago

serial: /dev/ttyACM1 /dev/ttyACM0 /dev/serial/by-id/usb-Texas_Instruments_XDS11002.03.00.18Embed_with_CMSIS-DAP_L43000GM-if03 /dev/ttyAMA0 /dev/serial/by-id/usb-Texas_Instruments_XDS11002.03.00.18Embed_with_CMSIS-DAP_L43000GM-if00 input:

flower87lucky commented 4 years ago

"serial": { "port": "/dev/ttyACM0" }, "advanced": { "pan_id": 6758, "channel": 15,

hdo commented 4 years ago

I got the same error message with my 2652R board :-( I also tried to change panid and channel in my configuration.

https://pastebin.com/KuNRvwnG

bertran1 commented 4 years ago

-

Koenkk commented 4 years ago

Can you try with

"serial": {
"port": null,
},
flower87lucky commented 4 years ago

Can you try with

"serial": {
"port": null,
},

Thanks.null is not allowed in Zigbee2mqtt Hass.io Add-on .I used Zigbee2mqtt Hass.io Add-on,maybe it may not support at present. I try to install ZigBee 2mqtt directly

flower87lucky commented 4 years ago

Can you try with

"serial": {
"port": null,
},

I'm worried if I flash the firmware in the wrong way? After cc1352p-2 flashed the firmware, I press reset key and it has no effect.

Koenkk commented 4 years ago
hdo commented 4 years ago

@Koenkk

I still have the problem that i need to soft reset first (via button press) to start the firmware.

Do you know how to disable this behaviour?

Little change request:

Let the green LED light up when firmware has loaded for quick check ;-)

flower87lucky commented 4 years ago

Image 2

pi@raspberrypi:~ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Oct 21 14:23 usb-Texas_Instruments_XDS110__02.03.00.18__Embed_with_CMSIS-DAP_L43000GM-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Oct 21 14:23 usb-Texas_Instruments_XDS110__02.03.00.18__Embed_with_CMSIS-DAP_L43000GM-if03 -> ../../ttyACM1
pi@raspberrypi:~ $ test -w /dev/ttyACM0 && echo success || echo failure
success
pi@raspberrypi:~ $ test -w /dev/ttyACM1 && echo success || echo failure
success
pi@raspberrypi:~ $ 
flower87lucky commented 4 years ago

DE2C8A3E876723407674E0E21AA6EAD3 When I connect to raspiberry pi 4b+ ,only the green led on.

Koenkk commented 4 years ago

@fredrikgk chip revision C is an older revision, right? Is it binary compatible with the E revision?

flower87lucky commented 4 years ago

@fredrikgk chip revision C is an older revision, right? Is it binary compatible with the E revision?

@Koenkk How to fix binary to compatible,thanks.

fredrikgk commented 4 years ago

@flower87lucky , @Koenkk , IC revision C is deprecated and not supported. SW is not binary compatible between rev. C and rev. E.

The only alternative is to order a new LaunchPad.

hdo commented 4 years ago

@fredrikgk

BTW Do you have an idea why i need to soft reset (via button press) each time after USB plug to start the firmware?

flower87lucky commented 4 years ago

@fredrikgk

BTW Do you have an idea why i need to soft reset (via button press) each time after USB plug to start the firmware?

I agree you.

Koenkk commented 4 years ago

@fredrikgk thanks, I will close this.

james-fry commented 4 years ago

@fredrikgk

BTW Do you have an idea why i need to soft reset (via button press) each time after USB plug to start the firmware?

I got caught out with the need for soft reset too. (and thanks for your assistance with this in the z2m issue @hdo)

I agree with your suggestion that either/both of the following would be good:

@Koenkk are either of these doable? should I raise an issue on the zstack fw repo?

hdo commented 4 years ago

@james-fry

This is not a simple task. I compiled a custom firmware version with LED support and that is also not a good indicator for this problem. I learned the firmware is loading correctly. However the culprit is the onbard debugger of the launchpad. On my Intel NUC i need the soft reset but not on my raspberry pi. There seems to be an issue with the usb handshake or something like this. I don't have any issues using the UART so that's why i think it's the usb part. The UART have other issues though (sending leading ZERO in some circumstances).

james-fry commented 4 years ago

Thanks for the info @hdo I am also on intel so maybe that is why I also need the reset, but its not a big deal when you know you need to do this.

fredrikgk commented 4 years ago

@hdo Do you have to press the reset button also when the USB cable has been disconnected for a long time?

fredrikgk commented 4 years ago

I compiled a custom firmware version with LED support and that is also not a good indicator for this problem. I learned the firmware is loading correctly. However the culprit is the onbard debugger of the launchpad. On my Intel NUC i need the soft reset but not on my raspberry pi. There seems to be an issue with the usb handshake or something like this. I don't have any issues using the UART so that's why i think it's the usb part. The UART have other issues though (sending leading ZERO in some circumstances).

This is strange, as the reset button only resets the CC1352P, not the debugger.

How is your LaunchPad configured (jumpers) when you are "using UART"?

hdo commented 4 years ago

@hdo Do you have to press the reset button also when the USB cable has been disconnected for a long time?

I have to soft reset each time i plug in the usb power cable.

This is strange, as the reset button only resets the CC1352P, not the debugger.

I not sure about that.

How is your LaunchPad configured (jumpers) when you are "using UART"?

I removed the TX/RX jumpers.

It could also work without removing those jumpers but i noticed some preceeding '0'-byte which disturbs the communication, at least in my environment.

I'm currently working on a zigbee-herdsmann modification to use my tcp2serial adapter without socat (not working with docker) and this (0-byte) happens with the tcp2serial adapter.

Also see: 0-byte

a-bailey commented 4 years ago

I seem to have a B revision of the launchpad board is this supposed to work?

pi@raspberrypi:~ $ test -w /dev/ttyACM0 && echo success || echo failure failure pi@raspberrypi:~ $ test -w /dev/ttyACM1 && echo success || echo failure failure

getting failure on both write tests.

dariuszqrek commented 4 years ago

I have board revision B, chip revision E and have same error - zigbee2mqtt won't start. what could be a problem ?

timdonovanuk commented 4 years ago

How do you know what revision board you've got? Going to be a bit annoyed if I wasted $50 on a board that isn't supported when the z2m docs don't mention that only certain revs work :(

dariuszqrek commented 4 years ago

It looks like i was wrong, everything is working well now. There was need to change pan_id in configuration. As far as i know TI is sending only correct revision now (Board revision B with chip revision E)

niedz., 22 gru 2019, 18:39 użytkownik timdonovanuk notifications@github.com napisał:

How do you know what revision board you've got? Going to be a bit annoyed if I wasted $50 on a board that isn't supported when the z2m docs don't mention that only certain revs work :(

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/2162?email_source=notifications&email_token=AN7QRNMKLWF4HXPQMZH4MLLQZ6Q4VA5CNFSM4JCPVVB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHPVW3I#issuecomment-568286061, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN7QRNMT6UHMZBUAIYBKKELQZ6Q4VANCNFSM4JCPVVBQ .

CodeFinder2 commented 4 years ago

I am also having the "need to push the board's reset button before I can start Z2M" issue (CC1352P-2) with my laptop (Intel i7, Xubuntu 16.04) but not on my Odroid XU4 (Ubuntu 18.04). Both connected via USB, jumpers are on their factory defaults.

Am I right that there's nothing we can do about it now? Does anyone know whether it can be fixed at all?

For posterity, this is my working config:

homeassistant: false
permit_join: true
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://localhost'
  user: YOUR_USERNAME
  password: YOUR_PASSWORD
serial:
  port: null
advanced:
  pan_id: 6755
  baudrate: 115200
  report: true
  rtscts: false
  channel: 20
  log_level: debug
  network_key:
    - 1
    - 3
    - 5
    - 7
    - 9
    - 11
    - 13
    - 15
    - 0
    - 2
    - 4
    - 6
    - 8
    - 10
    - 12
    - 13

Hardware (board revision B, printed on both sides of my board):

$ ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Dez 24 01:39 usb-Texas_Instruments_XDS110__03.00.00.05__Embed_with_CMSIS-DAP_L43001PF-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Dez 24 01:39 usb-Texas_Instruments_XDS110__03.00.00.05__Embed_with_CMSIS-DAP_L43001PF-if03 -> ../../ttyACM1

$ test -w /dev/ttyACM0 && echo success || echo failure
success
$ test -w /dev/ttyACM1 && echo success || echo failure
success

$ npm start

> zigbee2mqtt@1.8.0-dev start /opt/zigbee2mqtt
> node index.js

zigbee2mqtt:info  2019-12-24 01:50:50: Logging to console and directory: '/opt/zigbee2mqtt/data/log/2019-12-24.01-50-50'
zigbee2mqtt:debug 2019-12-24 01:50:50: Removing old log directory '/opt/zigbee2mqtt/data/log/2019-12-24.01-11-43'
zigbee2mqtt:debug 2019-12-24 01:50:50: Loaded state from file /opt/zigbee2mqtt/data/state.json
zigbee2mqtt:info  2019-12-24 01:50:50: Starting zigbee2mqtt version 1.8.0-dev (commit #66b3bcb)
zigbee2mqtt:info  2019-12-24 01:50:50: Starting zigbee-herdsman...
zigbee2mqtt:debug 2019-12-24 01:50:50: Using zigbee-herdsman with settings: '{"network":{"panID":6755,"extendedPanID":[221,221,221,221,221,221,221,221],"channelList":[20],"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":false,"path":null}}'
zigbee2mqtt:info  2019-12-24 01:50:51: zigbee-herdsman started
zigbee2mqtt:info  2019-12-24 01:50:51: Coordinator firmware version: '{"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20191106}}'
zigbee2mqtt:debug 2019-12-24 01:50:51: Zigbee network parameters: {"panID":6755,"extendedPanID":"0xdddddddddddddddd","channel":20}
zigbee2mqtt:info  2019-12-24 01:50:51: Currently 1 devices are joined:
zigbee2mqtt:info  2019-12-24 01:50:51: 0x086bd7fffee976a6 (0x086bd7fffee976a6): 2AJZ4KPKEY - Konke Multi-function button (EndDevice)
zigbee2mqtt:warn  2019-12-24 01:50:51: `permit_join` set to  `true` in configuration.yaml.
zigbee2mqtt:warn  2019-12-24 01:50:51: Allowing new devices to join.
zigbee2mqtt:warn  2019-12-24 01:50:51: Set `permit_join` to `false` once you joined all devices.
zigbee2mqtt:info  2019-12-24 01:50:51: Zigbee: allowing new devices to join.
zigbee2mqtt:info  2019-12-24 01:50:51: Connecting to MQTT server at mqtt://localhost
zigbee2mqtt:info  2019-12-24 01:50:51: Connected to MQTT server
zigbee2mqtt:info  2019-12-24 01:50:51: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload 'online'
zigbee2mqtt:info  2019-12-24 01:50:51: MQTT publish: topic 'zigbee2mqtt/0x086bd7fffee976a6', payload '{"linkquality":99}'
zigbee2mqtt:info  2019-12-24 01:50:51: MQTT publish: topic 'zigbee2mqtt/bridge/config', payload '{"version":"1.8.0-dev","commit":"66b3bcb","coordinator":{"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20191106}},"log_level":"debug","permit_join":true}'

Note: the reset button is the button next to the micro USB port and port: null correctly auto-detected my board.

TASSDevon commented 4 years ago

How do you know what revision board you've got? Going to be a bit annoyed if I wasted $50 on a board that isn't supported when the z2m docs don't mention that only certain revs work :(

The board revision is printed on the back of the board "HW Rev", the chip version can be read out using the Uniflash tool.

For reference, I bought mine on Mouser (Dutch version of the site, but the board came from Texas). I have a HW Rev B and Chip Rev E (2.1).

Still need to test it. I read that you need to re-pair all devices because of the bump to Zigbee stack version 3, is this correct? Perhaps this should be stated on the supported adapters page.

Currently I have a CC2531 hooked up to a Beaglebone Black running native zigbee2mqtt, other than changing the serial:port to whatever the TI board enumerates as, anything else I should know or take into consideration before doing the big ol' switcharoo (re-pair-a-roo?)

Also, does the board auto-detect when you attach an antenna? I have two antenna's connected to 2 CC2531's which I can obviously do without if this board is up and running.

CodeFinder2 commented 4 years ago

@TASSDevon: no, it does not auto-detect an external antenna. You have to resolder a tiny capacitor on the board (CC1352P-2) to use the external antenna...unfortunately.

This is how it must look like to use the SMA connector: cc1352p-2lp_explained__01__01__01

See: https://e2e.ti.com/support/wireless-connectivity/other-wireless/f/667/t/791444?LAUNCHXL-CC1352P-Clarification-of-ports-for-external-antennas

I can report an increased signal strength (compared with the PCB antenna), raised from 53.77 to 87.58 on average over 25 measurements (Wifi and Bluetooth nearby, through 2 walls, ~5-6m, hand/finger close to the device for button pressing to generate messages). Tested with a single device (HEIMAN HS2SK smart metering plug, a router).

Comparison (signal strength, out of 255, all in my locally "best" channel 11):

=> A shielded CC1352P-2 in a case for protection purposes with an external antenna seems to be the best option (also showed less deviations in the signal quality) :see_no_evil:

Nothing special that I am aware of, you should consider when moving to this chip, except for the re-pairing. And even re-pairing may not be necessary.

timdonovanuk commented 4 years ago

See https://github.com/Koenkk/zigbee-herdsman/issues/113#issuecomment-569619621 - there is hope that repairing all devices is not necessary. I'm holding off moving to the CC1352P-2 until confirmed. I have 60+ devices and repairing will take an entire weekend :)

CodeFinder2 commented 4 years ago

@Koenkk may (some of) these information be relevant for the docs (=> update)?

james-fry commented 4 years ago

See Koenkk/zigbee-herdsman#113 (comment) - there is hope that repairing all devices is not necessary. I'm holding off moving to the CC1352P-2 until confirmed. I have 60+ devices and repairing will take an entire weekend :)

Unless something changed, moving from a z-stack 1.2.x to z-stack 3.x coordinator requires a re-pair of all devices.

CodeFinder2 commented 4 years ago

See Koenkk/zigbee-herdsman#113 (comment) - there is hope that repairing all devices is not necessary. I'm holding off moving to the CC1352P-2 until confirmed. I have 60+ devices and repairing will take an entire weekend :)

Unless something changed, moving from a z-stack 1.2.x to z-stack 3.x coordinator requires a re-pair of all devices.

Have you actually tried this yourself (and failed)? As it is still said in the linked issue by Koenkk ("I think this can already be done without any code changes [...]."), it may be possible ...

TASSDevon commented 4 years ago

Indeed, has anyone actually already tried this so they can confirm it works or not (and perhaps for which devices it does not work).

I will give it a try on Saturday and report back.

jrhansen commented 4 years ago

What is the solution to the problem? I have the exact same error with a brand new CC1352P-2 (board rev. B, chip rev. E):

pi@rpi4:~/zigbee2mqtt $ npm start

> zigbee2mqtt@1.8.0 start /home/pi/zigbee2mqtt
> node index.js

zigbee2mqtt:info  2020-01-14 18:07:33: Logging to console and directory: '/home/pi/zigbee2mqtt/data/log/2020-01-14.18-07-33'
zigbee2mqtt:info  2020-01-14 18:07:34: Starting zigbee2mqtt version 1.8.0 (commit #da4d26a)
zigbee2mqtt:info  2020-01-14 18:07:34: Starting zigbee-herdsman...
zigbee2mqtt:error 2020-01-14 18:07:41: Error while starting zigbee-herdsman
zigbee2mqtt:error 2020-01-14 18:07:41: Failed to start zigbee
zigbee2mqtt:error 2020-01-14 18:07:41: Exiting...
zigbee2mqtt:error 2020-01-14 18:07:41: Error: SRSP - SYS - version after 6000ms
    at Timeout._onTimeout (/home/pi/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)
    at listOnTimeout (internal/timers.js:531:17)
    at processTimers (internal/timers.js:475:7)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! zigbee2mqtt@1.8.0 start: `node index.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the zigbee2mqtt@1.8.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-01-14T17_07_41_611Z-debug.log

The ports are writeable, and I changed the pan ID. The setup works perfectly, if I re-connect the CC2531.

The mentioned log file contains:

0 info it worked if it ends with ok
1 verbose cli [ '/usr/bin/node', '/usr/bin/npm', 'start' ]
2 info using npm@6.13.4
3 info using node@v12.14.1
4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle zigbee2mqtt@1.8.0~prestart: zigbee2mqtt@1.8.0
6 info lifecycle zigbee2mqtt@1.8.0~start: zigbee2mqtt@1.8.0
7 verbose lifecycle zigbee2mqtt@1.8.0~start: unsafe-perm in lifecycle true
8 verbose lifecycle zigbee2mqtt@1.8.0~start: PATH: /usr/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/home/pi/zigbee2mqtt/node_modules/.bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
9 verbose lifecycle zigbee2mqtt@1.8.0~start: CWD: /home/pi/zigbee2mqtt
10 silly lifecycle zigbee2mqtt@1.8.0~start: Args: [ '-c', 'node index.js' ]
11 silly lifecycle zigbee2mqtt@1.8.0~start: Returned: code: 1  signal: null
12 info lifecycle zigbee2mqtt@1.8.0~start: Failed to exec start script
13 verbose stack Error: zigbee2mqtt@1.8.0 start: `node index.js`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:332:16)
13 verbose stack     at EventEmitter.emit (events.js:223:5)
13 verbose stack     at ChildProcess.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:223:5)
13 verbose stack     at maybeClose (internal/child_process.js:1021:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)
14 verbose pkgid zigbee2mqtt@1.8.0
15 verbose cwd /home/pi/zigbee2mqtt
16 verbose Linux 4.19.75-v7l+
17 verbose argv "/usr/bin/node" "/usr/bin/npm" "start"
18 verbose node v12.14.1
19 verbose npm  v6.13.4
20 error code ELIFECYCLE
21 error errno 1
22 error zigbee2mqtt@1.8.0 start: `node index.js`
22 error Exit status 1
23 error Failed at the zigbee2mqtt@1.8.0 start script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

Any help is really appreciated! :-)

CodeFinder2 commented 4 years ago

@jrhansen connect the board and then press the reset button...

jrhansen commented 4 years ago

@CodeFinder2 Already tried it, but tried it again with the same error. The correct sequence is to power the board, and THEN momentarily press the button close to the USB connector, right? Not press the button while connecting the board? Should I see any activity on the LEDs when resetting the board?

TASSDevon commented 4 years ago

I just did the switch, used port 'null' for autodetect, with the database restore 'trick' and changing the pan_id as stated on the config page, here's what I found:

The signal quality before:

Screenshot 2020-01-02 at 18 36 23

The signal quality after:

Screenshot 2020-01-14 at 20 37 07

So a nice little bit of improvement there, I should get an SMA antenna to increase that even more, anyone can recommend me one?

If anyone else has questions about switching to the TI hardware, let me know. Aside from the 3 tradfri outlets and figuring out how to solve the situation that they didn't want to repair, it took me perhaps an hour or so to do everything.

jrhansen commented 4 years ago

“database restore 'trick'”? :-)

CodeFinder2 commented 4 years ago

“database restore 'trick'”? :-)

https://github.com/Koenkk/zigbee-herdsman/issues/113#issuecomment-569619621

CodeFinder2 commented 4 years ago

[...] So a nice little bit of improvement there, I should get an SMA antenna to increase that even more, anyone can recommend me one? [...]

I bought this one (because it was also labeled "Zigbee") and it works good, see my post above: https://www.digikey.de/product-detail/de/linx-technologies-inc/ANT-2.4-CW-HW-SMA/ANT-2.4-CW-HW-SMA-ND/2391322 (8€)

Don't know if any similar (Cheap Chinese 😂) SMA 2.4 GHz antenna would do the same job. 😁

remkolems commented 4 years ago

What is the solution to the problem? I have the exact same error with a brand new CC1352P-2 (board rev. B, chip rev. E):

pi@rpi4:~/zigbee2mqtt $ npm start

> zigbee2mqtt@1.8.0 start /home/pi/zigbee2mqtt
> node index.js

zigbee2mqtt:info  2020-01-14 18:07:33: Logging to console and directory: '/home/pi/zigbee2mqtt/data/log/2020-01-14.18-07-33'
zigbee2mqtt:info  2020-01-14 18:07:34: Starting zigbee2mqtt version 1.8.0 (commit #da4d26a)
zigbee2mqtt:info  2020-01-14 18:07:34: Starting zigbee-herdsman...
zigbee2mqtt:error 2020-01-14 18:07:41: Error while starting zigbee-herdsman
zigbee2mqtt:error 2020-01-14 18:07:41: Failed to start zigbee
zigbee2mqtt:error 2020-01-14 18:07:41: Exiting...
zigbee2mqtt:error 2020-01-14 18:07:41: Error: SRSP - SYS - version after 6000ms
    at Timeout._onTimeout (/home/pi/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)
    at listOnTimeout (internal/timers.js:531:17)
    at processTimers (internal/timers.js:475:7)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! zigbee2mqtt@1.8.0 start: `node index.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the zigbee2mqtt@1.8.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-01-14T17_07_41_611Z-debug.log

The ports are writeable, and I changed the pan ID. The setup works perfectly, if I re-connect the CC2531.

The mentioned log file contains:

0 info it worked if it ends with ok
1 verbose cli [ '/usr/bin/node', '/usr/bin/npm', 'start' ]
2 info using npm@6.13.4
3 info using node@v12.14.1
4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle zigbee2mqtt@1.8.0~prestart: zigbee2mqtt@1.8.0
6 info lifecycle zigbee2mqtt@1.8.0~start: zigbee2mqtt@1.8.0
7 verbose lifecycle zigbee2mqtt@1.8.0~start: unsafe-perm in lifecycle true
8 verbose lifecycle zigbee2mqtt@1.8.0~start: PATH: /usr/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/home/pi/zigbee2mqtt/node_modules/.bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
9 verbose lifecycle zigbee2mqtt@1.8.0~start: CWD: /home/pi/zigbee2mqtt
10 silly lifecycle zigbee2mqtt@1.8.0~start: Args: [ '-c', 'node index.js' ]
11 silly lifecycle zigbee2mqtt@1.8.0~start: Returned: code: 1  signal: null
12 info lifecycle zigbee2mqtt@1.8.0~start: Failed to exec start script
13 verbose stack Error: zigbee2mqtt@1.8.0 start: `node index.js`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:332:16)
13 verbose stack     at EventEmitter.emit (events.js:223:5)
13 verbose stack     at ChildProcess.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:223:5)
13 verbose stack     at maybeClose (internal/child_process.js:1021:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)
14 verbose pkgid zigbee2mqtt@1.8.0
15 verbose cwd /home/pi/zigbee2mqtt
16 verbose Linux 4.19.75-v7l+
17 verbose argv "/usr/bin/node" "/usr/bin/npm" "start"
18 verbose node v12.14.1
19 verbose npm  v6.13.4
20 error code ELIFECYCLE
21 error errno 1
22 error zigbee2mqtt@1.8.0 start: `node index.js`
22 error Exit status 1
23 error Failed at the zigbee2mqtt@1.8.0 start script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

Any help is really appreciated! :-)

I also have the same issues...

Started out with 2x CC2531 w/ SMA antenna (coordinator and router), but signal strength was far from ideal. Therefore, "upgraded" to a brand new CC1352P-2 (in future with the SMA antenna). Upgrade part seems to be very tricky to say the least. Platform: Home-Assistant w/ add-on ZigBee2MQTT (dev branch also tested) and Mosquitto broker (official). No luck until now. IMHO: hold off the upgrade part until it is/has been resolved. BTW the null (even with quotes) trick or using two serial ports is not permitted with the Home-Assistant ZigBee2MQTT addon.

Will update this post if solved.

SOLVED! See the 2 comments beneath from CodeFinder2: https://github.com/Koenkk/zigbee2mqtt/issues/2162#issuecomment-574414860 https://github.com/Koenkk/zigbee2mqtt/issues/2162#issuecomment-574416110

CodeFinder2 commented 4 years ago

@remkolems I got it working already with HA and hassio addon (just as a test / proof of concept before I really use the CC1352 as my daily driver).

This should give you a working start (Hassio addon zigbee2mqtt):

{
  "data_path": "/share/zigbee2mqtt-edge",
  "devices": "devices.yaml",
  "groups": "groups.yaml",
  "homeassistant": true,
  "permit_join": false,
  "mqtt": {
    "base_topic": "zigbee2mqtt",
    "server": "mqtt://core-mosquitto",
    "user": "YOUR_USERNAME",
    "password": "YOUR_PASSWORD"
  },
  "serial": {
    "port": "/dev/ttyACM0"
  },
  "advanced": {
    "baudrate": 115200,
    "log_level": "info",
    "rtscts": false,
    "report": true,
    "pan_id": 6755,
    "last_seen": "ISO_8601",
    "channel": 25,
    "availability_blacklist": [],
    "network_key": [ YOUR_KEY_HERE ]
  },
  "ban": [],
  "whitelist": [],
  "queue": {},
  "socat": {
    "enabled": false,
    "master": "pty,raw,echo=0,link=/dev/ttyZ2M,mode=777",
    "slave": "tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5",
    "restartdelay": 1,
    "initialdelay": 1,
    "options": "-d -d",
    "log": false
  }
}

PS: the CC2531s are really cheap/simple boards, see my post here regarding signal strength.

EDIT: only tested with -edge variant yet.

CodeFinder2 commented 4 years ago

@CodeFinder2 Already tried it, but tried it again with the same error. The correct sequence is to power the board, and THEN momentarily press the button close to the USB connector, right? Not press the button while connecting the board? Should I see any activity on the LEDs when resetting the board?

Exactly:

This is working for me (tested with dev branch but should also work with v1.8.0).

remkolems commented 4 years ago

@CodeFinder2 Thank you! It is working now! Looks like we almost had the same config! I copied some missing items from your advanced section and pressed the reset button once!

For reference purposes: my previous ZigBee2MQTT Home-Assistant addon config.

Note: don't use what I did before mqtt://YOUR_BROKER:1883. In the end it causes random connections issues with MQTT server. Use what @CodeFinder2 suggested: mqtt://core-mosquitto.

{
  "data_path": "/share/zigbee2mqtt",
  "devices": "devices.yaml",
  "groups": "groups.yaml",
  "homeassistant": true,
  "permit_join": false,
  "mqtt": {
    "base_topic": "zigbee2mqtt",
    "server": "mqtt://YOUR_BROKER:1883",
    "user": "YOUR_USERNAME",
    "password": "YOUR_PASSWORD"
  },
  "serial": {
    "port": "/dev/ttyACM1"
  },
  "advanced": {
    "pan_id": 6755,
    "channel": 25,
    "network_key": [
      1,
      3,
      5,
      7,
      9,
      11,
      13,
      15,
      0,
      2,
      4,
      6,
      8,
      10,
      12,
      13
    ],
    "availability_blacklist": []
  },
  "ban": [],
  "whitelist": [],
  "queue": {},
  "socat": {
    "enabled": false,
    "master": "pty,raw,echo=0,link=/dev/ttyZ2M,mode=777",
    "slave": "tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5",
    "restartdelay": 1,
    "initialdelay": 1,
    "options": "-d -d",
    "log": false
  }
}

My current config that works wonders. Thanks to @CodeFinder2. Hugely appreciated!

{
  "data_path": "/share/zigbee2mqtt",
  "devices": "devices.yaml",
  "groups": "groups.yaml",
  "homeassistant": true,
  "permit_join": false,
  "mqtt": {
    "base_topic": "zigbee2mqtt",
    "server": "mqtt://core-mosquitto",
    "user": "YOUR_USERNAME",
    "password": "YOUR_PASSWORD"
  },
  "serial": {
    "port": "/dev/ttyACM1"
  },
  "advanced": {
    "baudrate": 115200,
    "log_level": "info",
    "rtscts": false,
    "report": true,
    "pan_id": 6755,
    "last_seen": "ISO_8601",
    "channel": 25,
    "network_key": [
      1,
      3,
      5,
      7,
      9,
      11,
      13,
      15,
      0,
      2,
      4,
      6,
      8,
      10,
      12,
      13
    ],
    "availability_blacklist": []
  },
  "ban": [],
  "whitelist": [],
  "queue": {},
  "socat": {
    "enabled": false,
    "master": "pty,raw,echo=0,link=/dev/ttyZ2M,mode=777",
    "slave": "tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5",
    "restartdelay": 1,
    "initialdelay": 1,
    "options": "-d -d",
    "log": false
  }
}

Oh to find out which ACM to use (in my case ttyACM1). Use command: ls -l /dev/serial/by-id

YOUR_USERNAME@YOUR_HOSTNAME:~$ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Jan 15 00:28 usb-0658_0200-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 15 00:28 usb-FTDI_FT232R_USB_UART_AL1MWEYZ-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 15 00:28 usb-RFXCOM_RFXtrx433_A12HDMML-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 15 00:28 usb-Texas_Instruments_XDS110__03.00.00.05__Embed_with_CMSIS-DAP_L43001DM-if00 -> ../../ttyACM1
lrwxrwxrwx 1 root root 13 Jan 15 00:28 usb-Texas_Instruments_XDS110__03.00.00.05__Embed_with_CMSIS-DAP_L43001DM-if03 -> ../../ttyACM2
docBliny commented 4 years ago

I'm in the middle of a broken setup, too. I was getting the Error: SRSP - SYS - version after 6000ms error until I made the following changes (not sure if all were needed):

Since "null" isn't supported via HA, I'm running with "port": "/dev/ttyACM1" and I got a connection in the end. However, I still haven't managed to get any traffic to show up. I restored the database.db and it looks like they're all getting loaded, but nothing past that yet.

Edit: Well, I tried reconnecting one of my Xiaomi buttons and it started working after I did the reconnect. This won't be fun if I need to reconnect them all (~70 devices).

remkolems commented 4 years ago

I'm in the middle of a broken setup, too. I was getting the Error: SRSP - SYS - version after 6000ms error until I made the following changes (not sure if all were needed):

  • I'm running in Proxmox, so I changed from USB Vendor Device ID to USB port assignment
  • Rebooted the whole Proxmox computer
  • Hit the reset button on board

Since "null" isn't supported via HA, I'm running with "port": "/dev/ttyACM1" and I got a connection in the end. However, I still haven't managed to get any traffic to show up. I restored the database.db and it looks like they're all getting loaded, but nothing past that yet.

Edit: Well, I tried reconnecting one of my Xiaomi buttons and it started working after I did the reconnect. This won't be fun if I need to reconnect them all (~70 devices).

That is what I had to do also (still doing to be honest). A real pain in the a s s ....

docBliny commented 4 years ago

Yup, just spent the evening resetting everything. Found several water sensors that had run out of battery while I was at it, so something positive. Also looked like the Aqara water sensors would connect just by activating them twice (short press). The first connect would fail with Failed to interview 'water_leak_15', device has not successfully been paired but the second attempt would register it (without the long hold to "reset").

Now I just need to get my IKEA remotes to work via groups. I guess I'll need to do the whole network sniffing thing to get them connected again.

Edit: Thank goodness. You can get the group ID by turning on debug logging now instead of building a sniffer USB stick etc...

jrhansen commented 4 years ago
  1. Powered up an old RPi3 with a fresh Raspbian lite SD card.
  2. Installed Mosquitto.
  3. Followed the Z2M installation instructions.
  4. Setup the correct port (and initially forgot to set a different pan_id than my existing Zigbee network).
  5. On first 'npm start' I got the 'SRSP - SYS - version after 6000ms' error.
  6. Pushed the reset button.
  7. 'npm start' again -> Same error.
  8. Disconnected the CC1352P-2 from the USB port.
  9. Reconnected the board.
  10. 'npm start' again -> Same error.
  11. Pushed the reset button.
  12. 'npm start' -> Error saying that the pan_is already in use!
  13. Changed the pan_id.
  14. 'npm start' -> Z2M now starts up correctly :-)

So, it seems that things have started to work now even though I tried the reset button and all kinds of other stuff yesterday to no avail. I tried to break it again by reconnecting the board (in different USB ports), rebooting, pressing the reset button, changing the pan_id, going from '/dev/ACM0' to 'null' in the port setup, but it seems unbreakable now. I can join new devices without trouble, and I don't have to press the reset button again - even after a power cycle (??).

Now, I will go back to implementing the board in my existing setup with the risk of having the rejoin everything.

When I did experiments yesterday with my existing network, when the CC1352P-2 failed I had to go back to the CC2531, and I had to rejoin all devices even though I had backed up the 'data' folder. So...

Should I backup other folders than the 'data' folder? The entire Z2M folder, or something else in the system?