JLFN
commented
5 years ago @Koenkk can this board be bought from inside of Europe? I need to pay extra taxes if bought outside.
Closed Koenkk closed 3 years ago
JLFN
commented
5 years ago @Koenkk can this board be bought from inside of Europe? I need to pay extra taxes if bought outside.
Koenkk
commented
5 years ago @JLFN mine shipped from the Netherlands.
lolorc
commented
5 years ago mine too I was able to flash it with uniflash on linux.
JLFN
commented
5 years ago @JLFN mine shipped from the Netherlands.
Can you please give me link of the page where you bought it from that shipped from the NL.
Koenkk
commented
5 years ago @JLFN just from TI.
Koenkk
commented
5 years ago The Xiaomi end device undefined model ID issue had nothing to do with the CC2652R, it was actually a zigbee2mqtt bug, fixed in latest dev branch.
dh-harald
commented
5 years ago I've got mine today morning (from NL as well). Today, there will be a big migration project :)
tunip
commented
5 years ago Before I also "jump on the adventure train", I have 2 questions.
Range Could someone rate the range of this device? Could we connect a antenna to increase the range?
Router Is this device only for a coordinator role? Or would we see also in the future a router firmware?
Thx
salopette
commented
5 years ago Hello, does that part have an antenna? What is the range of that? and pays off the switch from cc2531 to cc2652r ????
lolorc
commented
5 years ago @salopette it has a pcb antenna and an unconnected connector, see https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/723337
lolorc
commented
5 years ago I only have osram plugs and aqara devices, aqara temp/humidity sensors are mostly ok to rebind, but it's not as straightforward for the other ones. for instance, I haven't been able to pair MCCGQ01LM, MFKZQ01LM and DJT11LM devices yet.
dh-harald
commented
5 years ago I'm done with re-pairing... Looks good... Re-pairing done with QBKG11LM, QBKG04LM, RTCGQ11LM, GL-C-008, E1746. Link qualities are better than CC2531.
lolorc
commented
5 years ago i've been able to pair MCCGQ01LM, MFKZQ01LM and DJT11LM, but still there's something very wrong with aqara devices. With the aqara gateway and another alternative gw (zigate), the pairing action is very straightforward, it only needs one action on the device, with those 3 models I had to do something like pressing the pairing button several times per second after the initial long press action, worst was DJT11LM
Koenkk
commented
5 years ago @dh-harald do you see big improvements in link quality?
dh-harald
commented
5 years ago @Koenkk with CC2531, I had 50-70 link quality, not I've 100-120.
lolorc
commented
5 years ago This morning it looked like my cc2652 had crashed. z2m wasn't able to use its serial port anymore. Had to restart rpi. Most of the pairings have been lost.
Link quality looks also better than what I had with cheap cc2530+cc2591.
lolorc
commented
5 years ago @tunip range looks better, antenna should be possible as there's a connector. router should be doable, but currently the changes to build a router firmware are closed-source.
dh-harald
commented
5 years ago This morning it looked like my cc2652 had crashed. z2m wasn't able to use its serial port anymore. Had to restart rpi. Most of the pairings have been lost.
I've something similar ATM... All devices are offline, can't ping by the controller. I had it yesterday, I needed to disconnect it from usb (poweroff)... Now I'm not at home, so I need to figure out, how I can disconect it from remote :(
lolorc
commented
5 years ago @dh-harald if it was connected to a PC, I would try to use uniflash to reset the board. Myself i need to find a way to program the board on the rpi from my linux pc, I'll give a try to ser2net+socat.
dh-harald
commented
5 years ago @dh-harald if it was connected to a PC, I would try to use uniflash to reset the board. Myself i need to find a way to program the board from my linux pc, I'll give a try to ser2net+socat.
It's an arm64 box, so I'm afraid, I can't run uniflash on it :( But if you can figure out, please share the solution :)
tunip
commented
5 years ago @dh-harald Maybe this could help you: https://askubuntu.com/questions/1036341/unplug-and-plug-in-again-a-usb-device-in-the-terminal https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line https://unix.stackexchange.com/questions/165447/turning-off-power-to-usb-port-or-turn-off-power-to-entire-usb-subsystem
dh-harald
commented
5 years ago @tunip I already tried them, but it didn't work.
Koenkk
commented
5 years ago Mine also crashed after 2 days (Request timeout errors)
lolorc
commented
5 years ago the mqtt messages with empty action are not related to cc2652, are they ?
serialport/stream binding.read finished +1ms
cc-znp { sof: 254,
cc-znp len: 28,
cc-znp type: 'AREQ',
cc-znp subsys: 'AF',
cc-znp cmd: 'incomingMsg',
cc-znp payload:
cc-znp { groupid: 0,
cc-znp clusterid: 18,
cc-znp srcaddr: 64732,
cc-znp srcendpoint: 2,
cc-znp dstendpoint: 1,
cc-znp wasbroadcast: 0,
cc-znp linkquality: 108,
cc-znp securityuse: 0,
cc-znp timestamp: 5007337,
cc-znp transseqnumber: 0,
cc-znp len: 8,
cc-znp data: <Buffer 18 38 0a 55 00 21 02 00> },
cc-znp fcs: 97,
cc-znp csum: 97 } +21ms
serialport/stream _read reading +18ms
serialport/binding-abstract read +19ms
serialport/bindings/unixRead Starting read +18ms
cc-znp:AREQ <-- AF:incomingMsg, { groupid: 0, clusterid: 18, srcaddr: 64732, srcendpoint: 2, dstendpoint: 1, wasbroadcast: 0, linkquality: 108, securityuse: 0, timestamp: 5007337, transseqnumber: 0, len: 8, data: <Buffer 18 38 0a 55 00 21 02 00> } +35ms
zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: {"groupid":0,"clusterid":18,"srcaddr":64732,"srcendpoint":2,"dstendpoint":1,"wasbroadcast":0,"linkquality":108,"securityuse":0,"timestamp":5007337,"transseqnumber":0,"len":8,"data":{"type":"Buffer","data":[24,56,10,85,0,33,2,0]}} +126ms
zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +39ms
serialport/bindings/unixRead waiting for readable because of code: EAGAIN +6ms
serialport/bindings/poller Polling for "readable" +27ms
zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: {"groupid":0,"clusterid":18,"srcaddr":64732,"srcendpoint":2,"dstendpoint":1,"wasbroadcast":0,"linkquality":108,"securityuse":0,"timestamp":5007337,"transseqnumber":0,"len":8,"data":{"0":24,"1":56,"2":10,"3":85,"4":0,"5":33,"6":2,"7":0},"zclMsg":{"frameCntl":{"frameType":0,"manufSpec":0,"direction":1,"disDefaultRsp":1},"manufCode":0,"seqNum":56,"cmdId":"report","payload":[{"attrId":85,"dataType":33,"attrData":2}]}} +5ms
zigbee2mqtt:debug 4/16/2019, 8:13:05 PM Received zigbee message of type 'attReport' with data '{"cid":"genMultistateInput","data":{"presentValue":2}}' of device 'lumi.sensor_cube' (cube_02) of endpoint 2
zigbee2mqtt:info 4/16/2019, 8:13:05 PM MQTT publish: topic 'zigbee2mqtt/cube_02', payload '{"action":"wakeup","linkquality":108,"last_seen":1555438385033,"elapsed":813581}'
zigbee2mqtt:info 4/16/2019, 8:13:05 PM MQTT publish: topic 'zigbee2mqtt/cube_02', payload '{"action":""}'another funny issue with a door window sensor, and I haven't touched the pair button, I was just playing with a magnet. In the end the device is removed from the network
serialport/stream binding.read finished +10ms │
cc-znp { sof: 254, │
cc-znp len: 27, │
cc-znp type: 'AREQ', │
cc-znp subsys: 'AF', │
cc-znp cmd: 'incomingMsg', │
cc-znp payload: │
cc-znp { groupid: 0, │
cc-znp clusterid: 6, │
cc-znp srcaddr: 33589, │
cc-znp srcendpoint: 1, │
cc-znp dstendpoint: 1, │
cc-znp wasbroadcast: 0, │
cc-znp linkquality: 135, │
cc-znp securityuse: 0, │
cc-znp timestamp: 7527883, ┤
cc-znp transseqnumber: 0, │
cc-znp len: 7, │
cc-znp data: <Buffer 18 12 0a 00 00 10 00> }, │
cc-znp fcs: 49, │
cc-znp csum: 49 } +18ms │
cc-znp { sof: 254, │
cc-znp len: 27, │
cc-znp type: 'AREQ', │
cc-znp subsys: 'AF', │
cc-znp cmd: 'incomingMsg', │
cc-znp payload: │
cc-znp { groupid: 0, │
cc-znp clusterid: 6, │
cc-znp srcaddr: 33589, │
cc-znp srcendpoint: 1, │
cc-znp dstendpoint: 1, │
cc-znp wasbroadcast: 0, │
cc-znp linkquality: 126, │
cc-znp securityuse: 0, │
cc-znp timestamp: 7574573, │
cc-znp transseqnumber: 0, │
cc-znp len: 7, │
cc-znp data: <Buffer 18 13 0a 00 00 10 01> }, │
cc-znp fcs: 102, │
cc-znp csum: 102 } +8ms │
cc-znp { sof: 254, │
cc-znp len: 27, │
cc-znp type: 'AREQ', │
cc-znp subsys: 'AF', │
cc-znp cmd: 'incomingMsg', │
cc-znp payload: │
cc-znp { groupid: 0, │
cc-znp clusterid: 6, │
cc-znp srcaddr: 33589, │
cc-znp srcendpoint: 1, │
cc-znp dstendpoint: 1, │
cc-znp wasbroadcast: 0, │
cc-znp linkquality: 117, │
cc-znp securityuse: 0, │
cc-znp timestamp: 7594239, │
cc-znp transseqnumber: 0, │
cc-znp len: 7, │
cc-znp data: <Buffer 18 14 0a 00 00 10 00> }, │
cc-znp fcs: 205, ┤
cc-znp csum: 205 } +15ms ┤
serialport/stream _read reading +31ms │
serialport/binding-abstract read +42ms │
serialport/bindings/unixRead Starting read +33ms │
zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: {"groupid":0,"clusterid":1030,"srcaddr":28406,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":117,"securityuse":0,"timestamp"│
zigbee2mqtt:debug 4/16/2019, 8:43:08 PM Received zigbee message of type 'attReport' with data '{"cid":"msOccupancySensing","data":{"occupancy":1}}' of device 'lumi.sensor_motion' (0xmotion_sensor_01) of endpoi│
zigbee2mqtt:info 4/16/2019, 8:43:08 PM MQTT publish: topic 'zigbee2mqtt/motion_sensor_01', payload '{"occupancy":true,"linkquality":117,"last_seen":1555440188148,"elapsed":82240}' │
cc-znp:AREQ <-- AF:incomingMsg, { groupid: 0, clusterid: 6, srcaddr: 33589, srcendpoint: 1, dstendpoint: 1, wasbroadcast: 0, linkquality: 135, securityuse: 0, timestamp: 7527883, transseqnumber: 0, len: 7, dat│
zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: {"groupid":0,"clusterid":6,"srcaddr":33589,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":135,"securityuse":0,"timestamp":75278│
zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +54ms │
cc-znp:AREQ <-- AF:incomingMsg, { groupid: 0, clusterid: 6, srcaddr: 33589, srcendpoint: 1, dstendpoint: 1, wasbroadcast: 0, linkquality: 126, securityuse: 0, timestamp: 7574573, transseqnumber: 0, len: 7, dat│
zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: {"groupid":0,"clusterid":6,"srcaddr":33589,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":126,"securityuse":0,"timestamp":75745│
zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +7ms │
cc-znp:AREQ <-- AF:incomingMsg, { groupid: 0, clusterid: 6, srcaddr: 33589, srcendpoint: 1, dstendpoint: 1, wasbroadcast: 0, linkquality: 117, securityuse: 0, timestamp: 7594239, transseqnumber: 0, len: 7, dat│
zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: {"groupid":0,"clusterid":6,"srcaddr":33589,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":117,"securityuse":0,"timestamp":75942│
zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +7ms │
serialport/bindings/unixRead Finished read 74 bytes +38ms │
serialport/stream binding.read finished +39ms │
cc-znp { sof: 254, │
cc-znp len: 37, │
cc-znp type: 'AREQ', ┤
cc-znp subsys: 'AF', │
cc-znp cmd: 'incomingMsg', │
cc-znp payload: │
cc-znp { groupid: 0, │
cc-znp clusterid: 0, │
cc-znp srcaddr: 33589, │
cc-znp srcendpoint: 1, │
cc-znp dstendpoint: 1, │
cc-znp wasbroadcast: 0, │
cc-znp linkquality: 120, │
cc-znp securityuse: 0, │
cc-znp timestamp: 7594503, │
cc-znp transseqnumber: 0, │
cc-znp len: 17, │
cc-znp data: <Buffer 1c 5f 11 15 0a 01 ff 42 09 04 21 a8 13 0a 21 00 00> }, │
cc-znp fcs: 79, │
cc-znp csum: 79 } +48ms │
cc-znp { sof: 254, │
cc-znp len: 27, │
cc-znp type: 'AREQ', │
cc-znp subsys: 'AF', │
cc-znp cmd: 'incomingMsg', │
cc-znp payload: │
cc-znp { groupid: 0, │
cc-znp clusterid: 6, │
cc-znp srcaddr: 33589, │
cc-znp srcendpoint: 1, │
cc-znp dstendpoint: 1, │
cc-znp wasbroadcast: 0, │
cc-znp linkquality: 123, │
cc-znp securityuse: 0, │
cc-znp timestamp: 7599348, │
cc-znp transseqnumber: 0, │
cc-znp len: 7, │
cc-znp data: <Buffer 18 16 0a 00 00 10 01> }, │
cc-znp fcs: 223, │
cc-znp csum: 223 } +9ms │
serialport/stream _read reading +18ms │
serialport/binding-abstract read +56ms │
serialport/bindings/unixRead Starting read +18ms │
zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: {"groupid":0,"clusterid":6,"srcaddr":33589,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":135,"securityuse":0,"timestamp":75┤
zigbee2mqtt:debug 4/16/2019, 8:43:08 PM Received zigbee message of type 'attReport' with data '{"cid":"genOnOff","data":{"onOff":0}}' of device 'lumi.sensor_magnet.aq2' (0xdoor_window_sensor_04) of endpoint 1 │
zigbee2mqtt:info 4/16/2019, 8:43:08 PM MQTT publish: topic 'zigbee2mqtt/door_window_sensor_04', payload '{"contact":true,"linkquality":135,"last_seen":1555440188206,"elapsed":23558}' │
zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: {"groupid":0,"clusterid":6,"srcaddr":33589,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":126,"securityuse":0,"timestamp":75│
zigbee2mqtt:debug 4/16/2019, 8:43:08 PM Received zigbee message of type 'attReport' with data '{"cid":"genOnOff","data":{"onOff":1}}' of device 'lumi.sensor_magnet.aq2' (0xdoor_window_sensor_04) of endpoint 1 │
zigbee2mqtt:info 4/16/2019, 8:43:08 PM MQTT publish: topic 'zigbee2mqtt/door_window_sensor_04', payload '{"contact":false,"linkquality":126,"last_seen":1555440188217,"elapsed":11}' │
zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: {"groupid":0,"clusterid":6,"srcaddr":33589,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":117,"securityuse":0,"timestamp":75│
zigbee2mqtt:debug 4/16/2019, 8:43:08 PM Received zigbee message of type 'attReport' with data '{"cid":"genOnOff","data":{"onOff":0}}' of device 'lumi.sensor_magnet.aq2' (0xdoor_window_sensor_04) of endpoint 1 │
zigbee2mqtt:info 4/16/2019, 8:43:08 PM MQTT publish: topic 'zigbee2mqtt/door_window_sensor_04', payload '{"contact":true,"linkquality":117,"last_seen":1555440188229,"elapsed":12}' │
cc-znp:AREQ <-- AF:incomingMsg, { groupid: 0, clusterid: 0, srcaddr: 33589, srcendpoint: 1, dstendpoint: 1, wasbroadcast: 0, linkquality: 120, securityuse: 0, timestamp: 7594503, transseqnumber: 0, len: 17, da│
zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: {"groupid":0,"clusterid":0,"srcaddr":33589,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":120,"securityuse":0,"timestamp":75945│
zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +62ms │
cc-znp:AREQ <-- AF:incomingMsg, { groupid: 0, clusterid: 6, srcaddr: 33589, srcendpoint: 1, dstendpoint: 1, wasbroadcast: 0, linkquality: 123, securityuse: 0, timestamp: 7599348, transseqnumber: 0, len: 7, dat│
zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: {"groupid":0,"clusterid":6,"srcaddr":33589,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":123,"securityuse":0,"timestamp":75993│
zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +4ms │
zigbee2mqtt:debug 4/16/2019, 8:43:08 PM Received zigbee message of type 'devChange' with data '{"cid":"genOnOff","data":{"onOff":0}}' of device 'lumi.sensor_magnet.aq2' (0xdoor_window_sensor_04) of endpoint 1 │
zigbee2mqtt:debug 4/16/2019, 8:43:08 PM Received zigbee message of type 'devChange' with data '{"cid":"genOnOff","data":{"onOff":0}}' of device 'lumi.sensor_magnet.aq2' (0xdoor_window_sensor_04) of endpoint 1 │
serialport/bindings/unixRead waiting for readable because of code: EAGAIN +52ms │
serialport/bindings/poller Polling for "readable" +161ms │
zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: {"groupid":0,"clusterid":0,"srcaddr":33589,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":120,"securityuse":0,"timestamp":75│
zigbee2mqtt:debug 4/16/2019, 8:43:08 PM Received zigbee message of type 'attReport' with data '{"cid":"genBasic","data":{"65281":{"4":5032,"10":0}}}' of device 'lumi.sensor_magnet.aq2' (0xdoor_window_sensor_04┤
zigbee2mqtt:info 4/16/2019, 8:43:08 PM MQTT publish: topic 'zigbee2mqtt/door_window_sensor_04', payload '{"contact":false,"linkquality":120,"last_seen":1555440188255,"elapsed":26}' │
zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: {"groupid":0,"clusterid":6,"srcaddr":33589,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":123,"securityuse":0,"timestamp":75│
zigbee2mqtt:debug 4/16/2019, 8:43:08 PM Received zigbee message of type 'attReport' with data '{"cid":"genOnOff","data":{"onOff":1}}' of device 'lumi.sensor_magnet.aq2' (0xdoor_window_sensor_04) of endpoint 1 │
zigbee2mqtt:info 4/16/2019, 8:43:08 PM MQTT publish: topic 'zigbee2mqtt/door_window_sensor_04', payload '{"contact":false,"linkquality":123,"last_seen":1555440188264,"elapsed":9}' │
zigbee2mqtt:debug 4/16/2019, 8:43:08 PM Received zigbee message of type 'devChange' with data '{"cid":"genBasic","data":{"65281":[null,null,null,null,5032,null,null,null,null,null,0]}}' of device 'lumi.sensor_│
zigbee2mqtt:debug 4/16/2019, 8:43:08 PM Received zigbee message of type 'devChange' with data '{"cid":"genOnOff","data":{"onOff":1}}' of device 'lumi.sensor_magnet.aq2' (0xdoor_window_sensor_04) of endpoint 1 │
serialport/bindings/poller received "readable" +357ms │
serialport/binding-abstract read +409ms │
serialport/bindings/unixRead Starting read +357ms │
serialport/bindings/unixRead Finished read 8 bytes +0ms │
serialport/stream binding.read finished +409ms │
serialport/stream _read reading +1ms │
serialport/binding-abstract read +1ms │
serialport/bindings/unixRead Starting read +1ms │
serialport/bindings/unixRead Finished read 10 bytes +0ms │
serialport/stream binding.read finished +0ms │
cc-znp { sof: 254, │
cc-znp len: 13, │
cc-znp type: 'AREQ', │
cc-znp subsys: 'ZDO', │
cc-znp cmd: 'leaveInd', │
cc-znp payload: │
cc-znp { srcaddr: 33589, │
cc-znp extaddr: '0xdoor_window_sensor_04', │
cc-znp request: 0, │
cc-znp removechildren: 0, │
cc-znp rejoin: 1 }, │
cc-znp fcs: 244, │
cc-znp csum: 244 } +415ms │
serialport/stream _read reading +4ms │
serialport/binding-abstract read +5ms │
serialport/bindings/unixRead Starting read +5ms │
cc-znp:AREQ <-- ZDO:leaveInd, { srcaddr: 33589, extaddr: '0xdoor_window_sensor_04', request: 0, removechildren: 0, rejoin: 1 } +374ms │
zigbee-shepherd Device: 0xdoor_window_sensor_04 leave the network. +1m │
zigbee2mqtt:debug 4/16/2019, 8:43:08 PM Received zigbee message of type 'devLeaving' with data '"0xdoor_window_sensor_04"' of endpoint undefined │
zigbee2mqtt:warn 4/16/2019, 8:43:08 PM Message without device! │
zigbee-shepherd:msgHdlr IND <-- ZDO:leaveInd +373ms │
serialport/bindings/unixRead waiting for readable because of code: EAGAIN +4ms │looks like it happens very often :-(
zigbee2mqtt:debug 4/16/2019, 8:22:47 PM Received zigbee message of type 'devLeaving' with data '"switch_square_01"' of endpoint undefined
zigbee2mqtt:debug 4/16/2019, 8:42:06 PM Received zigbee message of type 'devLeaving' with data '"0xdoor_window_sensor_05"' of endpoint undefined
zigbee2mqtt:debug 4/16/2019, 8:43:08 PM Received zigbee message of type 'devLeaving' with data '"0xdoor_window_sensor_04"' of endpoint undefined
zigbee2mqtt:debug 4/16/2019, 8:50:59 PM Received zigbee message of type 'devLeaving' with data '"aqara_07"' of endpoint undefined
zigbee2mqtt:debug 4/16/2019, 8:57:26 PM Received zigbee message of type 'devLeaving' with data '"aqara_05"' of endpoint undefined
zigbee2mqtt:debug 4/16/2019, 9:32:16 PM Received zigbee message of type 'devLeaving' with data '"0xdoor_window_sensor_06"' of endpoint undefined
zigbee2mqtt:debug 4/16/2019, 9:33:26 PM Received zigbee message of type 'devLeaving' with data '"0xdoor_window_sensor_07"' of endpoint undefined
zigbee2mqtt:debug 4/16/2019, 9:50:50 PM Received zigbee message of type 'devLeaving' with data '"cube_01"' of endpoint undefined
zigbee2mqtt:debug 4/16/2019, 9:56:36 PM Received zigbee message of type 'devLeaving' with data '"motion_lum_02"' of endpoint undefined
zigbee2mqtt:debug 4/16/2019, 10:01:48 PM Received zigbee message of type 'devLeaving' with data '"switch_02"' of endpoint undefined
zigbee2mqtt:debug 4/16/2019, 10:42:33 PM Received zigbee message of type 'devLeaving' with data '"door_window_sensor_03"' of endpoint undefined
zigbee2mqtt:debug 4/16/2019, 10:57:39 PM Received zigbee message of type 'devLeaving' with data '"cube_03"' of endpoint undefined
zigbee2mqtt:debug 4/16/2019, 11:02:43 PM Received zigbee message of type 'devLeaving' with data '"switch_01"' of endpoint undefined@lolorc the empty actions are probably some converter bug. I haven't seen the dev leaving yet (and I have many Xiaomi devices)
Mine crashed again this morning, but I was able to get it working again by only replugging the CC2652R (no restart of zigbee2mqtt). Trying to catch a DEBUG=* log now.
lolorc
commented
5 years ago mine crashed as well this morning, it can't stay more than 12h without crashing. Is there a way to debug or get a crash stack from the second serial port for example ?
replugging cc2652r is not a solution when not at home, but hey it's the early alpha tests with cc2652r.
I've been running with 'DEBUG=* | tee /tmp/something' for a while now, but it's lost when rebooting, I'm now logging to a nfs server.
lolorc
commented
5 years ago the leaveind issues might be related to https://github.com/fairecasoimeme/ZiGate/issues/38#issuecomment-397001660
it wasn't happening with cc2530+firmware from end of 2018.
if you look at my logs, the leaveInd message has rejoin:1, is it normal to consider it gone ? (unfortunatly I don't have any log from before with my cc2530)
Koenkk
commented
5 years ago @lolorc good catch, can you check if this still happens with 20190417 firmware?
lolorc
commented
5 years ago I'll try tomorrow, I've just seen your message and it's a bit too late :-) in the mean time I've repaired everything but the routers to see if it could be related to the routers.
lolorc
commented
5 years ago Without any router I haven't lost a device during the night. The 6 routers (5 osram plug + 1 cc2531) and some more important devices are paired to my old cc2530. Will wait for my cc2652 to crash or for some devices to disappear before upgrading the firmware.
lolorc
commented
5 years ago grmbl, still no devices gone, still no crash. I will reintroduce routers one by one to reproduce, then I will try your latest firmware to confirm it's a good workaround, gonna take ages.. ;-)
Koenkk
commented
5 years ago https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/794106/2937749#2937749 that probably answers our stability problems. Will publish a new firmware tonight.
Koenkk
commented
5 years ago Status update:
lolorc
commented
5 years ago ace ! other hints here : https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/759868/2808276#2808276 a bit sad the issue is still not resolved since nov 2018.
antst
commented
5 years ago Did someone tried already to solder external antenna connector on those boards?
Koenkk
commented
5 years ago Crashed again, reduced device tables further, new firmware is up: 20190419.
lolorc
commented
5 years ago mine without any router hasn't crashed yet, had to restart z2m to pair more devices.... (still running 20190415) will add routers by the end of the week end.
lolorc
commented
5 years ago @dh-harald I was able to flash my cc2652 connected on my raspberry. I used usbip on both my rpi and my linux laptop, and used uniflash to flash. The programming was slower (using wifi) but it worked. Don't know If I used the correct options, but I had to unplug/plug the cc2652 to have its serial port working again.
haven't had time to add routers with old firmware and wait for devLeaving messages from devices. I upgraded to latest 20190419 firmware.
lolorc
commented
5 years ago serialport/stream binding.read finished +0ms
cc-znp { sof: 254,
cc-znp len: 13,
cc-znp type: 'AREQ',
cc-znp subsys: 'ZDO', cc-znp cmd: 'leaveInd', cc-znp payload:
cc-znp { srcaddr: 62610,
cc-znp extaddr: '0xaqara_03',
cc-znp request: 0, cc-znp removechildren: 0,
cc-znp rejoin: 1 }, cc-znp fcs: 166, cc-znp csum: 166 } +520ms
serialport/stream _read reading +6ms
serialport/binding-abstract read +6ms
serialport/bindings/unixRead Starting read +6ms
cc-znp:AREQ <-- ZDO:leaveInd, { srcaddr: 62610, extaddr: '0xaqara_03', request: 0, removechildren: 0, rejoin: 1 } +518ms zigbee-shepherd Device: 0xaqara_03 leave the network. +35s zigbee2mqtt:debug 4/21/2019, 8:27:04 PM Received zigbee message of type 'devLeaving' with data '"0xaqara_03"' of endpoint undefined zigbee2mqtt:warn 4/21/2019, 8:27:04 PM Message without device! zigbee-shepherd:msgHdlr IND <-- ZDO:leaveInd +509ms serialport/bindings/unixRead waiting for readable because of code: EAGAIN +5msit just happened, the only router connected is a cc2531 (cc2531_1.2.2a.44539_firmware) in the mean time this device was working but shown as unconnected on the network map, as all my devices after the usbip tests and upgrade. I've removed the router, it might not be related to the router. will see quite quickly
lolorc
commented
5 years ago just happened without a router, it's probably an issue after the upgrade. my devices probably want to rejoin the network after the usbip/upgrade break. (rejoin=1) I guess I'll have to repair everything again, I'm a bit lost :)
Am I supposed to find references to my devices in coordinator_backup.json ? I don't see anything like it.
Koenkk
commented
5 years ago Did you set permit_join: true after flashing the device? (maybe this is needed for the first start?). coordinator_backup.json should contain a list of devices, but this is hidden in the NIB.
My status:
lolorc
commented
5 years ago every time the cc2652 crashes or I restart it I loose the pairing with most of my devices. I've just repaired 10ish devices and the coordinator crashed few minutes after. I had to unplugged it, z2m did not re-open the serial port. Once restarted, all devices are show as unconnected in the network map. In the next hours all my devices will send a ZDO:leaveInd with rejoin=1, rejoin=1 is not handled (https://github.com/Koenkk/zigbee-shepherd/blob/master/lib/components/event_handlers.js#L341)
I thought z2m was supposed to maintain the paired device list in the cc2652.
Koenkk
commented
5 years ago If I understand right, when you stop zigbee2mqtt, replug CC2652R, start zigbee2mqtt, you lose pairings?
lolorc
commented
5 years ago yep. I will try to reproduce again this evening with only one aqara device and a sniffer recording the traffic. edit: it crashed this morning, the 21 aqara devices I paired yesterday evening have all left the network during the day. result: no more paired device :)
Koenkk
commented
5 years ago New firmware is up, should improve stability and I've managed to completely disable the child ageing mechanism.
lolorc
commented
5 years ago will try it right now, thanks !
lolorc
commented
5 years ago I've paired 1 aqara device, stopped z2m, replug cc2562R, the aqara device is still there. it hasn't left the network after 12hours, but the network map shows it disconnected from the coord. So I guess the disabled child ageing is working but it's probably just a workaround.
Koenkk
commented
5 years ago Is it an end device (battery powered)?
NOTE 2020-12-11 locked, please continue here: https://github.com/Koenkk/zigbee2mqtt/discussions/5266
Texas Instruments has recently released a new high performance Zigbee chip: the CC2652R. This chip is much faster and contains much more memory than the CC2530/CC2531.
This issue is created in order to gather feedback of users using the CC2652R AND Z-Stack 3.0 (= Zigbee 3.0)
Notes
data/coordinator_backup.json. This backup is automatically restored when starting with a new flashed CC2652R.