I tried to join a new device, it failed.
The network/coordinator usb has been up for a about 1-1.5days now, joining new devices fail.
Physically unplugging and replugging the usb (with z2m stopped ofcourse) re allows joining of new devices.
I did a capture of one of those failed join requests:
https://pkg.blackdot.be/extras/zigbee/failed_join.pcapng
Not sure where it fails afterwards, it looks like z2m doesn't respond to the update device at all?
The device to be able to join.
I can always reproduce this after a about 1-3 days after plugging in/out the USB device (rebooting the server does not help)
zigbee2mqtt version: 1.12.0-dev (commit #d52d520)
CC253X firmware version: {"type":"zStack12","meta":{"transportrev":2,"product":0,"majorrel":2,"minorrel":6,"maintrel":3,"revision":20190608}}
Last time I did not have issues was around 1.6 I think.
Soft resetting seems to work as well! However no more message after that until I restart z2m.
@sjorge I can't join new devices either. How can I soft reset?
Or physically removing the USB and plugging it back in. (while z2m is stopped)
After te rest via MQTT, I had to restart z2m anyway. But that might be because I am running on illumos and not linux. At least it saved a phsyical trip down to the pantry.
It works after a soft reset (physically ;) )
thanks.
I've investigated and it seems to go wrong at the Transport key part.
Log of successful join:

Log of failed join (from OP), no transport key is done:

One thing I noticed is that the device joins via a router of the network, not the coordinator itself (Extended source is an ember stack device):

When it will join via the coordinator you will see that the extended source is a texas instrument device, like this:

00:0d:6f:ff:fe:8e:8d:4f? (you should be able to find that ieeeAddr in your database){"id":2,"type":"Router","ieeeAddr":"0x000d6ffffe8e8d4f","nwkAddr":47816,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Mains (single phase)","modelId":"TRADFRI signal repeater","epList":[1,242],"endpoints":{"1":{"profId":260,"epId":1,"devId":8,"inClusterList":[0,3,9,2821,4096,64636],"outClusterList":[25,32,4096],"clusters":{"genBasic":{"attributes":{"modelId":"TRADFRI signal repeater","manufacturerName":"IKEA of Sweden","powerSource":1,"zclVersion":3,"appVersion":33,"stackVersion":98,"hwVersion":1,"dateCode":"20190318","swBuildId":"2.2.005"}}},"binds":[{"cluster":0,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1}]},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[33],"outClusterList":[33],"clusters":{},"binds":[]}},"appVersion":32,"stackVersion":98,"hwVersion":1,"dateCode":"20190318","swBuildId":"2.2.005","zclVersion":3,"interviewCompleted":true,"meta":{"reporting":1,"configured":2},"lastSeen":1584920505606}
It's an ikea signal repeater, also the one that occasionally stops responding to pings.
I tried again with it unplugged, same result but it used:
{"id":3,"type":"Router","ieeeAddr":"0x000d6ffffe197fe9","nwkAddr":36186,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Mains (single phase)","modelId":"TRADFRI bulb E27 CWS opal 600lm","epList":[1],"endpoints":{"1":{"profId":49246,"epId":1,"devId":512,"inClusterList":[0,3,4,5,6,8,768,2821,4096],"outClusterList":[5,25,32,4096],"clusters":{"genBasic":{"attributes":{"modelId":"TRADFRI bulb E27 CWS opal 600lm","manufacturerName":"IKEA of Sweden","powerSource":1,"zclVersion":1,"appVersion":17,"stackVersion":87,"hwVersion":1,"dateCode":"20180410","swBuildId":"1.3.009"}},"genLevelCtrl":{"attributes":{"currentLevel":254}},"genOnOff":{"attributes":{"onOff":1}},"lightingColorCtrl":{"attributes":{"currentX":29969,"currentY":26869,"colorMode":1}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1},{"cluster":8,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1},{"cluster":768,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1}]}},"appVersion":17,"stackVersion":87,"hwVersion":1,"dateCode":"20180410","swBuildId":"1.3.009","zclVersion":1,"interviewCompleted":true,"meta":{"reporting":1},"lastSeen":1584920594485}
When I unscrew that one, the coordinator is out of range.
What if you pair the device in range of the coordinator?
I can try that tomorrow, but I wont be able to sniff the traffic at that location.
I can try on friday, I have an E27 Müller Light bulb coming in and I the sockets in that room are all E27, beets trying to mess around with the living room lamp.
@Koenkk might be off interest, I was looking omething up in database.db and noticed this:
{"id":1,"type":"Coordinator","ieeeAddr":"0x00124b001938a7e5","nwkAddr":0,"manufId":0,"epList":[1,2,3,4,5,6,8,11,12,110],"endpoints":{"1":{"profId":260,"epId":1,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"2":{"profId":257,"epId":2,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"3":{"profId":261,"epId":3,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"4":{"profId":263,"epId":4,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"5":{"profId":264,"epId":5,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"6":{"profId":265,"epId":6,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"8":{"profId":260,"epId":8,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"11":{"profId":260,"epId":11,"devId":1024,"inClusterList":[],"outClusterList":[1280],"clusters":{},"binds":[]},"12":{"profId":49246,"epId":12,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"110":{"profId":260,"epId":110,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]}},"interviewCompleted":false,"meta":{}}
{"id":9,"type":"Coordinator","ieeeAddr":"0x00124b001938a7e5","nwkAddr":0,"manufId":0,"epList":[1,2,3,4,5,6,8,11,12,110],"endpoints":{"1":{"profId":260,"epId":1,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"2":{"profId":257,"epId":2,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"3":{"profId":261,"epId":3,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"4":{"profId":263,"epId":4,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"5":{"profId":264,"epId":5,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"6":{"profId":265,"epId":6,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"8":{"profId":260,"epId":8,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"11":{"profId":260,"epId":11,"devId":1024,"inClusterList":[],"outClusterList":[1280],"clusters":{},"binds":[]},"12":{"profId":49246,"epId":12,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"110":{"profId":260,"epId":110,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]}},"interviewCompleted":false,"meta":{},"lastSeen":null}
I have 2 entries for the coordinator?! one has interviewCompleted: false... which is odd as it doesn't get interviewed right?
Thats indeed interesting, is your databse.db old? (could it come from an old herdsman bug?)
Around 1.10 I had to rebuild because I couldn't join any devices, so I wipe database.db and changed my netwerk key and pan. So It's from that time. Also I only have one C2xxx device... so not sure why it would even regonize it as a diffrent one.
https://pkg.blackdot.be/extras/zigbee/
Should be same as the previous one, I captures this with everything online... just to make sure the issue was back.
This time I moved the bulb next to the coordinator 2 rooms away
This time I unplugged the IKEA Trådfri Repeater, bulb was back in the room (where I also run wireshark)
Note: wireshark might not see all traffic, as it is not in the room with the coordinator, it's in the room where the bulb should go
Same as 03, but next to the coordinator
Note: wireshark might not see all traffic, as it is not in the room with the coordinator, it's in the room where the bulb should go
This time I took offline all IKEA Trådfri routers (repeater + bulbs), the bulb I tried to pair was back in the room it should end up in.
Note: wireshark might not see all traffic, as it is not in the room with the coordinator, it's in the room where the bulb should go
Same as 05, but I also took offline the hue innr bulb
Note: wireshark might not see all traffic, as it is not in the room with the coordinator, it's in the room where the bulb should go
Yeah I messed up the file naming, but whatever.... same as above but the bulb was near the coordinator.
Note: wireshark might not see all traffic, as it is not in the room with the coordinator, it's in the room where the bulb should go
@Koenkk a whole set of captures, pairning never succeeded. The last attempt was near the coordinator ~1cm away with all routers offline. Wireshark didn't capture much for that one as it was running on my desktop which is in the room the bulb should end up in.
zigbee2mqtt:debug 2020-03-25 14:34:22: Received MQTT message on 'zigbee2mqtt/bridge/config/permit_join' with data 'true'
zigbee2mqtt:info 2020-03-25 14:34:22: Zigbee: allowing new devices to join.
zigbee2mqtt:info 2020-03-25 14:34:22: MQTT publish: topic 'zigbee2mqtt/bridge/config', payload '{"version":"1.12.0-dev","commit":"d52d520","coordinator":{"type":"zStack12","meta":{"transportrev":2,"product":0,"majorrel":2,"minorrel":6,"maintrel":3,"revision":20190608}},"log_level":"debug","permit_join":true}'
zigbee2mqtt:info 2020-03-25 14:34:29: Device '0x00158d00038801e9' joined
zigbee2mqtt:info 2020-03-25 14:34:29: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"device_connected","message":{"friendly_name":"0x00158d00038801e9"}}'
zigbee2mqtt:info 2020-03-25 14:34:29: Starting interview of '0x00158d00038801e9'
zigbee2mqtt:info 2020-03-25 14:34:29: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"interview_started","meta":{"friendly_name":"0x00158d00038801e9"}}'
zigbee2mqtt:debug 2020-03-25 14:34:29: Device '0x00158d00038801e9' announced itself
zigbee2mqtt:info 2020-03-25 14:34:29: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"device_announced","message":"announce","meta":{"friendly_name":"0x00158d00038801e9"}}'
zigbee2mqtt:debug 2020-03-25 14:34:40: Received Zigbee message from '0x00158d00038801e9', type 'readResponse', cluster 'genBasic', data '{"modelId":"ZBT-ExtendedColor","manufacturerName":"MLI"}' from endpoint 1 with groupID 0
zigbee2mqtt:debug 2020-03-25 14:34:40: Received Zigbee message from '0x00158d00038801e9', type 'readResponse', cluster 'genBasic', data '{"powerSource":1,"zclVersion":2}' from endpoint 1 with groupID 0
zigbee2mqtt:debug 2020-03-25 14:34:40: Received Zigbee message from '0x00158d00038801e9', type 'readResponse', cluster 'genBasic', data '{"appVersion":1,"stackVersion":1}' from endpoint 1 with groupID 0
zigbee2mqtt:debug 2020-03-25 14:34:40: Received Zigbee message from '0x00158d00038801e9', type 'readResponse', cluster 'genBasic', data '{"hwVersion":1,"dateCode":"20180404-42"}' from endpoint 1 with groupID 0
zigbee2mqtt:debug 2020-03-25 14:34:40: Received Zigbee message from '0x00158d00038801e9', type 'readResponse', cluster 'genBasic', data '{"swBuildId":"2.0"}' from endpoint 1 with groupID 0
zigbee2mqtt:info 2020-03-25 14:34:40: Successfully interviewed '0x00158d00038801e9', device has successfully been paired
zigbee2mqtt:info 2020-03-25 14:34:40: Device '0x00158d00038801e9' is supported, identified as: M_ller Licht Tint LED bulb GU10/E14/E27 350/470/806 lumen, dimmable, color, opal white (404000/404005/404012)
zigbee2mqtt:info 2020-03-25 14:34:40: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"interview_successful","meta":{"friendly_name":"0x00158d00038801e9","model":"404000/404005/404012","vendor":"M_ller Licht","description":"Tint LED bulb GU10/E14/E27 350/470/806 lumen, dimmable, color, opal white","supported":true}}'
After ZNP Soft reset usingzigbee2mqtt/bridge/config/reset, the pairing works fine from in the room. See capture 08_after_reset_pair_ok if that is at all needed or not.
Thanks for the sniff, I don't know why the transport key is not occurring, I've asked TI for support (https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/892149)
digraph G {
node[shape=record];
"0x00124b001938a7e5" [style="bold, filled", fillcolor="#e04e5d", fontcolor="#ffffff", label="{Coordinator|0x00124b001938a7e5 (0)|2020-03-27T14:51:51+00:00}"];
"0x00124b001938a7e5" -> "0x000d6ffffe8e8d4f" [penwidth=0.5, weight=0, color="#994444", label="110"]
"0x00124b001938a7e5" -> "0x000d6ffffe197fe9" [penwidth=0.5, weight=0, color="#994444", label="14"]
"0x00124b001938a7e5" -> "0x14b457fffe2bd760" [penwidth=0.5, weight=0, color="#994444", label="32"]
"0x000d6ffffe8e8d4f" [style="rounded, filled", fillcolor="#4ea3e0", fontcolor="#ffffff", label="{masterbedroom/repeater|0x000d6ffffe8e8d4f (47816)|IKEA TRADFRI signal repeater (E1746)|2020-03-27T14:51:43+00:00}"];
"0x000d6ffffe8e8d4f" -> "0x00124b001938a7e5" [penwidth=0.5, weight=0, color="#994444", label="58"]
"0x000d6ffffe8e8d4f" -> "0x000d6ffffe197fe9" [penwidth=0.5, weight=0, color="#994444", label="58"]
"0x000d6ffffe8e8d4f" -> "0x14b457fffe2bd760" [penwidth=0.5, weight=0, color="#994444", label="138"]
"0x000d6ffffe197fe9" [style="rounded, filled", fillcolor="#4ea3e0", fontcolor="#ffffff", label="{bedroom/night_light/bulb|0x000d6ffffe197fe9 (1554)|IKEA TRADFRI LED bulb E14/E26/E27 600 lumen, dimmable, color, opal white (LED1624G9)|2020-03-27T14:51:11+00:00}"];
"0x000d6ffffe197fe9" -> "0x00124b001938a7e5" [penwidth=0.5, weight=0, color="#994444", label="1"]
"0x000d6ffffe197fe9" -> "0x000d6ffffe8e8d4f" [penwidth=0.5, weight=0, color="#994444", label="65"]
"0x000d6ffffe197fe9" -> "0x14b457fffe2bd760" [penwidth=0.5, weight=0, color="#994444", label="129"]
"0x14b457fffecc1315" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{bedroom/night_light/remote|0x14b457fffecc1315 (44663)|IKEA TRADFRI ON/OFF switch (E1743)|2020-03-26T23:53:01+00:00}"];
"0x14b457fffecc1315" -> "0x14b457fffe2bd760" [penwidth=1, weight=0, color="#994444", label="173"]
"0x14b457fffeca351b" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{bedroom/desk_lamp/remote|0x14b457fffeca351b (24931)|IKEA TRADFRI ON/OFF switch (E1743)|2020-03-27T06:24:54+00:00}"];
"0x14b457fffeca351b" -> "0x14b457fffe2bd760" [penwidth=1, weight=0, color="#994444", label="171"]
"0x00158d0004148f89" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{bedroom/motion|0x00158d0004148f89 (4263)|Xiaomi Aqara human body movement and illuminance sensor (RTCGQ11LM)|2020-03-27T14:49:47+00:00}"];
"0x00158d0004148f89" -> "0x00124b001938a7e5" [penwidth=1, weight=0, color="#994444", label="1"]
"0x00158d00033ddfaa" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{bedroom/sensor|0x00158d00033ddfaa (28407)|Xiaomi Aqara temperature, humidity and pressure sensor (WSDCGQ11LM)|2020-03-27T14:23:58+00:00}"];
"0x00158d00033ddfaa" -> "0x000d6ffffe8e8d4f" [penwidth=1, weight=0, color="#994444", label="211"]
"0x00158d0003f115c5" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{serverroom/sensor|0x00158d0003f115c5 (23324)|Xiaomi Aqara temperature, humidity and pressure sensor (WSDCGQ11LM)|2020-03-27T14:21:24+00:00}"];
"0x00158d0003f115c5" -> "0x00124b001938a7e5" [penwidth=1, weight=0, color="#994444", label="157"]
"0x00158d0001ffaffc" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{bedroom/radiator|0x00158d0001ffaffc (49490)|Eurotronic Spirit Zigbee wireless heater thermostat (SPZB0001)|2020-03-27T14:46:36+00:00}"];
"0x00158d0001ffaffc" -> "0x14b457fffe2bd760" [penwidth=1, weight=0, color="#994444", label="188"]
"0x04cf8cdf3c771820" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{bedroom/light_sensor|0x04cf8cdf3c771820 (24216)|Xiaomi MiJia light intensity sensor (GZCGQ01LM)|2020-03-27T14:51:38+00:00}"];
"0x04cf8cdf3c771820" -> "0x14b457fffe2bd760" [penwidth=1, weight=0, color="#994444", label="162"]
"0x14b457fffe2bd760" [style="rounded, filled", fillcolor="#4ea3e0", fontcolor="#ffffff", label="{bedroom/desk_lamp/bulb|0x14b457fffe2bd760 (18409)|Innr E14 bulb RGBW (RB 250 C)|2020-03-27T14:51:17+00:00}"];
"0x14b457fffe2bd760" -> "0x00124b001938a7e5" [penwidth=0.5, weight=0, color="#994444", label="1"]
"0x14b457fffe2bd760" -> "0x000d6ffffe8e8d4f" [penwidth=0.5, weight=0, color="#994444", label="114"]
"0x14b457fffe2bd760" -> "0x000d6ffffe197fe9" [penwidth=0.5, weight=0, color="#994444", label="98"]
}
I assume you're going to ask for this next :)
jup, thanks! replied in the thread.
@Koenkk I was reading the things the TI person posted... didn't we change something about polling frequency a while ago for the eurotronic trvs? Or am I miss remembering something.
No we didnt change anything related to that (some retry mechanism was added in herdsman but this for sure doesnt cause this issue as herdsman is not even aware of this).
What device are you trying to join?
Any device will do, I have had this problem with:
The pcaps from earlier were with a muller light tint E27... which I believe is a zigbee router?
Also 05_all_trådfri_offline_room would only have a hue bulb online as router at the time and a TRV as it is very annoying to remove.
Edit, I think there would have been 3 ZED and 1 ZR in that pcap active. I don't have a spare stick to make a 3 network mesh though and I can't really keep all my stuff offline for 3-6 days before the issues pops up.
Edit2: If the issue pops up again I do think I can do a ZC only with a ZR to pair... well the other device ZR would be unplugged and I can move all closeby ZED's far away.
Which device did you try to pair in: https://pkg.blackdot.be/extras/zigbee/failed_join.pcapng ?

That was the Innr E14 I wanted to use to replace the Hue E14 because genOnOff reporting was no longer supported on the Hue after the update.
All the numbered ones were with the Hue replaced with the Innr already, where I tried to pair a new Tiny E27 (https://www.zigbee2mqtt.io/devices/404000_404005_404012.html) to look into what it supported reporting wise as mentioned in https://github.com/Koenkk/zigbee2mqtt/issues/3177#issuecomment-602861258
And just to be sure, this Innr is marked as a Router in database.db right?
{
"id": 16,
"type": "Router",
"ieeeAddr": "0x14b457fffe2bd760",
"nwkAddr": 18409,
"manufId": 4454,
"manufName": "innr",
"powerSource": "Mains (single phase)",
"modelId": "RB 250 C",
"epList": [
1,
242
],
"endpoints": {
"1": {
"profId": 260,
"epId": 1,
"devId": 269,
"inClusterList": [
0,
3,
4,
5,
6,
8,
768,
2821,
4096
],
"outClusterList": [
25
],
"clusters": {
"genBasic": {
"attributes": {
"modelId": "RB 250 C",
"manufacturerName": "innr",
"powerSource": 1,
"zclVersion": 3,
"appVersion": 16,
"stackVersion": 98,
"hwVersion": 1,
"dateCode": "20190326-87",
"swBuildId": "2.1"
}
},
"lightingColorCtrl": {
"attributes": {
"currentHue": 0,
"currentSaturation": 254,
"colorMode": 1,
"currentX": 45914,
"currentY": 19615,
"colorTemperature": 153
}
},
"genLevelCtrl": {
"attributes": {
"currentLevel": 254
}
},
"genOnOff": {
"attributes": {
"onOff": 1
}
}
},
"binds": [
{
"cluster": 6,
"type": "endpoint",
"deviceIeeeAddress": "0x00124b001938a7e5",
"endpointID": 1
},
{
"cluster": 8,
"type": "endpoint",
"deviceIeeeAddress": "0x00124b001938a7e5",
"endpointID": 1
},
{
"cluster": 768,
"type": "endpoint",
"deviceIeeeAddress": "0x00124b001938a7e5",
"endpointID": 1
}
]
},
"242": {
"profId": 41440,
"epId": 242,
"devId": 97,
"inClusterList": [
],
"outClusterList": [
33
],
"clusters": {
},
"binds": [
]
}
},
"appVersion": 16,
"stackVersion": 98,
"hwVersion": 1,
"dateCode": "20190326-87",
"swBuildId": "2.1",
"zclVersion": 3,
"interviewCompleted": true,
"meta": {
"reporting": 1
},
"lastSeen": 1585152024465
}
Yep
Thanks, could you also provide a sniff with all the traffic when pairing close to the coordinator fails? (when the association response comes from the coordinator)
I'll have to get creative, but I can try. But since I reset the stick today to do the group thing for the other issue, currently pairing is working fine. So we have to wait a few days before it 'breaks' again.
I experience the same issue/symptoms. I'm following this issue with great interest.
What I noticed:
Version info:
{"version":"1.12.0","commit":"840b9d9",
"coordinator":{"type":"zStack12","meta":"transportrev":2,"product":0,"majorrel":2,"minorrel":6,"maintrel":3,"revision":20190619}}
* Forcing a reset of the stick using the mqtt topic either freezes everything or doesn't help
Yeah it freeze z2m for me too, but after the reset... I can just restart z2m and it starts working again including joining... so it does save me a physical trip to the server room
It also feels like devices are dropped from network more often then before. Maybe it is a problem for these devices to reconnect after a while. This happened to both wired as battery devices, but in my case most of them are battery devices. For instance all my smoke detectors are dropped. They normally only wake up and connect once per day. Never had issues with these devices, they were always able to connect even through other routers/routes without any issue.
It also feels like devices are dropped from network more often then before. Maybe it is a problem for these devices to reconnect after a while. This happened to both wired as battery devices, but in my case most of them are battery devices. For instance all my smoke detectors are dropped. They normally only wake up and connect once per day. Never had issues with these devices, they were always able to connect even through other routers/routes without any issue.
Oh yeah definately... my Aqara Motion sensor drops nearly every 3 days.
Thanks, could you also provide a sniff with all the traffic when pairing close to the coordinator fails? (when the association response comes from the coordinator)
OK I finally managed to get my laptop close enough to sniff... it took me a few tries...
But I accidently bumped my usb so it was working fine because it got unplugged :s
My only possible explenation for this behavior change would be that with the ssIasZone fixes we are now sending a default reply that somehow the sensor is not happy with, which we did not send in the past. But I saw nothing of that sort while sniffing traffic. That was for a differnet issue
I'll try to do a capture tomorrow, can't today but joining broke again!
I also noticed that currently all trådfri bulbs/repeaters are no longer reporting either!
I tried plug/unplug of a bulb but it fails to setup reporting!
zigbee2mqtt:error 2020-04-08 19:23:36: Failed to setup reporting for '0x90fd9ffffee77fcf' - Error: Bind 0x90fd9ffffee77fcf/1 genOnOff from '0x00124b001938a7e5/1' failed (Error: AREQ - ZDO - bindRsp after 10000ms)
at Endpoint.<anonymous> (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:244:23)
at Generator.throw (<anonymous>)
at rejected (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:6:65)
I wonder if it is related.
@Koenkk Good news! I had the issue again:
extra captures probably not needed:
This was on the dev branch from yesterday eveningish
Can you try with this firmware:
CC2531ZNP-Prod_Source_Routing_20200410.zip
It contains the fixes mentioned in https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/894198#pi320995=2
Does the fixes only apply to the source routing firmware? I'm using the default one currently.
I don't mind switching though, but the last time I tried I had issues when repairing my devices (after flashing I had to repair for some reason, although I thought the docs said that was not needed)
Reflashing shouldn't be needed indeed. But here is the default firmware:
CC2531ZNP-Prod_20200410_default.zip
I'll flash the default one later today, should give the best results to see if those changes help or not.
Done, I flashed the default one... will keep you posted.
{
"type": "zStack12",
"meta": {
"transportrev": 2,
"product": 0,
"majorrel": 2,
"minorrel": 6,
"maintrel": 3,
"revision": 20200410
}
}
I did figure out why I had to reflash last time! The instructions are incorrect!
https://www.zigbee2mqtt.io/getting_started/flashing_the_cc2531.html as I was using windows as that was easiest.
If do as the instructions say and copy the settings form the screenshot, you uncheck: Retain IEEE address when reprogramming the chip, which seems to then require repairing of all devices. This time I left it checked (default) and it worked, all devices are still here and working aside from the Trådfri repeater... I had to unplug it and it was fine.
Also noticed a new Coordinator entry in my database.db after flashing the newer firmware!
{"id":1,"type":"Coordinator","ieeeAddr":"0x00124b001938a7e5","nwkAddr":0,"manufId":0,"epList":[1,2,3,4,5,6,8,11,12,110],"endpoints":{"1":{"profId":260,"epId":1,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"2":{"profId":257,"epId":2,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"3":{"profId":261,"epId":3,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"4":{"profId":263,"epId":4,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"5":{"profId":264,"epId":5,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"6":{"profId":265,"epId":6,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"8":{"profId":260,"epId":8,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"11":{"profId":260,"epId":11,"devId":1024,"inClusterList":[],"outClusterList":[1280],"clusters":{},"binds":[]},"12":{"profId":49246,"epId":12,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"110":{"profId":260,"epId":110,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]}},"interviewCompleted":false,"meta":{},"lastSeen":null}
{"id":9,"type":"Coordinator","ieeeAddr":"0x00124b001938a7e5","nwkAddr":0,"manufId":0,"epList":[1,2,3,4,5,6,8,11,12,13,47,110],"endpoints":{"1":{"profId":260,"epId":1,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"2":{"profId":257,"epId":2,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"3":{"profId":261,"epId":3,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"4":{"profId":263,"epId":4,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"5":{"profId":264,"epId":5,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"6":{"profId":265,"epId":6,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"8":{"profId":260,"epId":8,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"11":{"profId":260,"epId":11,"devId":1024,"inClusterList":[],"outClusterList":[1280],"clusters":{},"binds":[]},"12":{"profId":49246,"epId":12,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"13":{"profId":260,"epId":13,"devId":5,"inClusterList":[25],"outClusterList":[],"clusters":{},"binds":[]},"47":{"profId":260,"epId":47,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]},"110":{"profId":260,"epId":110,"devId":5,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]}},"interviewCompleted":false,"meta":{},"lastSeen":null}
Two new endpoints showed up, 13 and 47?
New endpoints are expected, but duplicate entry not. Could you reproduce the issue and provide the herdsman debug logging of this?
Not sure how to reproduce, aside form flashing another firmware that has different endpoints maybe?
I could not reproduce:
I had manually cleaned up the dup entry already before.
You are right about the Retain IEEE, on a new stick it should be unchecked as it may not be initialized.
On updating an existing stick it must be checked.
On a long stretch, maybe the duplicate entries of the coordinator address had something to do with it?
I imagine something like, adding a new entry because of the new address, but later updating all the coordinator entries with the new address.
But that is just a wild guess.
Hmm yeah it might be from the last time I tried the source firmware and had retain IEEE unchecked. That was before the changes where database.db would update the coordinator's IEEE... so it could be that yeah.
@Koenkk is it me... or does the new firmware respond slower?
Ok yeah there is some very funckyness going on. Some commands take like 1-2 sec to come through. Others are instant.
Edit: I will try to catch some debug level logging, it's really bad when using groups.
Not sure, I don't expect this from the diff with your previous firmware. Please check if reverting to that the old firmware solves the issue.
I'll keep on this one until next weekend and try to joining a device again before reflashing, that should indicate if the changes fix the cannot join issues.
I was sniffing yesterday evening a bit and it seems to be slow when a lot of route discovery are done. Usually when a attReport overlaps with a msg send to a group. So the source routing firmware might also help.
Edit: old problem is back with trådfri repeater dropping from the network -_-
So good news, the slowness doesn't seem to have anything todo with the new firmware.
That seems to be because the trådfri repeater again. sfjhaskhf
@Koenkk bad news :(
I tried to join a device this morning and nothing again. After a usb reset, it worked fine.
After about ~30min (I wasn't watching the log) the ikea bulb behind the repeater came back online... As soon as I had reset the USB the repeater started responding to pings again.
And shortly thereafter the bulb did a deviceannounce and reconfigure of reporting!
I did not have any issues with these last week, but I did reset the usb stick every few days testing stuff... so it was never a 24 period where joining was broken. I suspect the issue with the trådfri stuff is a result of the coordinator issues. (I had already tried without any trådfri devices a few weeks ago, and the coordinator would still refuse device joins too.)
I will try flashing the source routing firmware you posted in tonight or tomorrow depending on when i have time to flash the stick. (Not that I expect it will make a difference, but it's worth a shot)
z2m does not start with the source routing firmware: https://gist.github.com/sjorge/df385a8cc8741b912dc4be9d53c127b7
When z2m starts the green led turns off, I verify the firmware with SmartRF and it was OK.
Edit: same result with unpatched source routing firmware : CC2531_SOURCE_ROUTING_20190619
Looks like the C2531 is now completely dead.
I tried:
All result in the same error.
Fixed by adding rtscts: false to my configuration.yaml visible confused
I am now running the patched firmware, I couldn't differentiate based on the firmware info. So I unplugged it and verified the CC2531 against both bins and the source routing one matched.
Summerized:
Sofar the patched source routiing firmware is working well... the network is much more responsive than before,... it certainly does not have the 'slowness' I experienced at times on the default one. (I have also not had the random ping failures a few times a day)
Lets see if I can still pair stuff a fter afew more days.
Some further observations:
digraph G {
node[shape=record];
"0x00124b001938a7e5" [style="bold, filled", fillcolor="#e04e5d", fontcolor="#ffffff", label="{0x00124b001938a7e5|0x00124b001938a7e5 (0)|2020-04-18T11:18:56+00:00}"];
"0x00124b001938a7e5" -> "0x000d6ffffe8e8d4f" [penwidth=0.5, weight=0, color="#994444", label="91"]
"0x00124b001938a7e5" -> "0x14b457fffe2bd760" [penwidth=0.5, weight=0, color="#994444", label="32"]
"0x000d6ffffe8e8d4f" [style="rounded, filled", fillcolor="#4ea3e0", fontcolor="#ffffff", label="{masterbedroom/repeater|0x000d6ffffe8e8d4f (46726)|IKEA TRADFRI signal repeater (E1746)|2020-04-18T11:17:23+00:00}"];
"0x000d6ffffe8e8d4f" -> "0x00124b001938a7e5" [penwidth=2, weight=1, color="#009900", label="46 (routes: 31787,49490)"]
"0x000d6ffffe8e8d4f" -> "0x90fd9ffffee77fcf" [penwidth=0.5, weight=0, color="#994444", label="48"]
"0x000d6ffffe8e8d4f" -> "0x14b457fffe2bd760" [penwidth=0.5, weight=0, color="#994444", label="119"]
"0x90fd9ffffee77fcf" [style="rounded, filled", fillcolor="#4ea3e0", fontcolor="#ffffff", label="{bedroom/bed_lamp/bulb|0x90fd9ffffee77fcf (31787)|IKEA TRADFRI LED bulb E14/E26/E27 600 lumen, dimmable, color, opal white (LED1624G9)|2020-04-18T11:17:05+00:00}"];
"0x90fd9ffffee77fcf" -> "0x00124b001938a7e5" [penwidth=0.5, weight=0, color="#994444", label="0"]
"0x90fd9ffffee77fcf" -> "0x000d6ffffe8e8d4f" [penwidth=0.5, weight=0, color="#994444", label="59"]
"0x90fd9ffffee77fcf" -> "0x14b457fffe2bd760" [penwidth=2, weight=1, color="#009900", label="123 (routes: 31787)"]
"0x14b457fffe2bd760" [style="rounded, filled", fillcolor="#4ea3e0", fontcolor="#ffffff", label="{bedroom/desk_lamp/bulb|0x14b457fffe2bd760 (39924)|Innr E14 bulb RGBW (RB 250 C)|2020-04-18T11:17:29+00:00}"];
"0x14b457fffe2bd760" -> "0x00124b001938a7e5" [penwidth=0.5, weight=0, color="#994444", label="1"]
"0x14b457fffe2bd760" -> "0x000d6ffffe8e8d4f" [penwidth=2, weight=1, color="#009900", label="98 (routes: 39924,31787)"]
"0x14b457fffe2bd760" -> "0x90fd9ffffee77fcf" [penwidth=0.5, weight=0, color="#994444", label="91"]
"0x14b457fffecc1315" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{bedroom/bed_lamp/remote|0x14b457fffecc1315 (44663)|IKEA TRADFRI ON/OFF switch (E1743)|2020-04-18T04:33:23+00:00}"];
"0x14b457fffecc1315" -> "0x90fd9ffffee77fcf" [penwidth=1, weight=0, color="#994444", label="255"]
"0x14b457fffeca351b" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{bedroom/desk_lamp/remote|0x14b457fffeca351b (24931)|IKEA TRADFRI ON/OFF switch (E1743)|2020-04-18T11:15:29+00:00}"];
"0x14b457fffeca351b" -> "0x90fd9ffffee77fcf" [penwidth=1, weight=0, color="#994444", label="255"]
"0x00158d0004148f89" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{bedroom/motion|0x00158d0004148f89 (12102)|Xiaomi Aqara human body movement and illuminance sensor (RTCGQ11LM)|2020-04-18T11:14:36+00:00}"];
"0x00158d0004148f89" -> "0x000d6ffffe8e8d4f" [penwidth=1, weight=0, color="#994444", label="134"]
"0x00158d00033ddfaa" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{bedroom/sensor|0x00158d00033ddfaa (2897)|Xiaomi Aqara temperature, humidity and pressure sensor (WSDCGQ11LM)|2020-04-18T11:16:34+00:00}"];
"0x00158d00033ddfaa" -> "0x000d6ffffe8e8d4f" [penwidth=1, weight=0, color="#994444", label="184"]
"0x00158d0003f115c5" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{serverroom/sensor|0x00158d0003f115c5 (23324)|Xiaomi Aqara temperature, humidity and pressure sensor (WSDCGQ11LM)|2020-04-18T11:16:21+00:00}"];
"0x00158d0003f115c5" -> "0x00124b001938a7e5" [penwidth=1, weight=0, color="#994444", label="140"]
"0x00158d0001ffaffc" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{bedroom/radiator|0x00158d0001ffaffc (49490)|Eurotronic Spirit Zigbee wireless heater thermostat (SPZB0001)|2020-04-18T11:18:53+00:00}"];
"0x00158d0001ffaffc" -> "0x000d6ffffe8e8d4f" [penwidth=1, weight=0, color="#994444", label="120"]
"0x04cf8cdf3c771820" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{bedroom/light_sensor|0x04cf8cdf3c771820 (24216)|Xiaomi MiJia light intensity sensor (GZCGQ01LM)|2020-04-18T11:18:37+00:00}"];
"0x04cf8cdf3c771820" -> "0x000d6ffffe8e8d4f" [penwidth=1, weight=0, color="#994444", label="169"]
}
@Koenkk sadly joining stopped working too now :(
So it looks like the chances have no effect with either the default or source routing firmware.
And the extra network stability was just from using source routing in general.
Any other ideas? Do you want me to do another capture with this firmware?
Well well this is new and interesting!
What I found weird though is that neither capture shows the broadcast where it allows joining, although I only send the mqtt message to allow join after I started the capture.
Ugggghh It got weirder...
I did a 2nd attempt to join from the bedroom, I wanted double check I did not see the zigbee join broadcast... and well... I still don't see it... but the bulb joined :|
https://pkg.blackdot.be/cores/zigbee/srcrouting_via_router_second.pcapng
So now I am wonder if I might have accidentally bumped the USB again because the spot where the coordinator is is very cramped.
As I did 3 attempts of joining from the bedroom before doing the capture in different locations (near a tradfri bulb, near the tradfri repeater, and near an innr bulb)
I guess we wait another few days repeat this, I'll have to be super careful not to bump the usb next time.
I did not see a coordinator disconnect in the logs though, those should show up on log_level info right?
When comparing the first (fail) and second (success) capture that I did from the bedroom I noticed a few differences:
I wonder if they are related, maybe for the first capture the coordinator buffer was still too overloaded for the transport key due to the device update messages?
Also is there a simple summary of what each message means.. e.g.:
Oh, looks like the flood of 'device update' is the trådfri repeaterinnr bulb spamming trådfri repeater (next hop) with the ZA unsecure join message without getting an answer... which I guess is the coordinators job to reply to? (with the Transport Key?)
but after the TK/unsecure join request from the bulb made it's way to the coordinator
e ZA unsecure join message without getting an answer... which I guess is the coordinators job to reply to? (with the Transport Key?)
I'm confused, did it finally join or not?
I'm confused, did it finally join or not?
4x (1 capped) attempts via a router, they failed
1x via coordinator, that worked but I might have bumped the USB, not sure
1x via router, also worked.
I was compare the first and last router join (one bad, one ok)
Good, so it seems that things are improved?
I've checked the failed attempt via the router, but it seems that the router is also acting strange here. If joining works directly via the coordinator I think the coordinator itself is not the issue?
Also, has this device previously been paired to this router? Otherwise I wouldn't expect the update device.
Also, has this device previously been paired to this router? Otherwise I wouldn't expect the update device.
Probably, as it is one of my test bulbs. But if it was, it was from when I was using the default firmware.
Depending on the router, I think it was the innr bulb --> trådfri repeater --> coordinator
{"id":2,"type":"Router","ieeeAddr":"0x000d6ffffe8e8d4f","nwkAddr":46726,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Mains (single phase)","modelId":"TRADFRI signal repeater","epList":[1,242],"endpoints":{"1":{"profId":260,"epId":1,"devId":8,"inClusterList":[0,3,9,2821,4096,64636],"outClusterList":[25,32,4096],"clusters":{"genBasic":{"attributes":{"modelId":"TRADFRI signal repeater","manufacturerName":"IKEA of Sweden","powerSource":1,"zclVersion":3,"appVersion":33,"stackVersion":98,"hwVersion":1,"dateCode":"20190318","swBuildId":"2.2.005"}}},"binds":[{"cluster":0,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1}]},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[33],"outClusterList":[33],"clusters":{},"binds":[]}},"appVersion":32,"stackVersion":98,"hwVersion":1,"dateCode":"20190318","swBuildId":"2.2.005","zclVersion":3,"interviewCompleted":true,"meta":{"reporting":1,"configured":2},"lastSeen":1586973921882}
{"id":4,"type":"Router","ieeeAddr":"0x14b457fffe2bd760","nwkAddr":39924,"manufId":4454,"manufName":"innr","powerSource":"Mains (single phase)","modelId":"RB 250 C","epList":[1,242],"endpoints":{"1":{"profId":260,"epId":1,"devId":269,"inClusterList":[0,3,4,5,6,8,768,2821,4096],"outClusterList":[25],"clusters":{"genBasic":{"attributes":{"modelId":"RB 250 C","manufacturerName":"innr","powerSource":1,"zclVersion":3,"appVersion":16,"stackVersion":98,"hwVersion":1,"dateCode":"20190326-87","swBuildId":"2.1"}},"genOnOff":{"attributes":{"onOff":1}},"genLevelCtrl":{"attributes":{"currentLevel":254}},"lightingColorCtrl":{"attributes":{"currentX":30199,"currentY":26096,"colorTemperature":374,"colorMode":1,"currentHue":21,"currentSaturation":197}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1},{"cluster":8,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1},{"cluster":768,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1}]},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[],"outClusterList":[33],"clusters":{},"binds":[]}},"appVersion":16,"stackVersion":98,"hwVersion":1,"dateCode":"20190326-87","swBuildId":"2.1","zclVersion":3,"interviewCompleted":true,"meta":{"reporting":1},"lastSeen":1586973977775}
I've checked the failed attempt via the router, but it seems that the router is also acting strange here. If joining works directly via the coordinator I think the coordinator itself is not the issue?
I wonder if something is missing on device removal? Maybe some message to tell all routers to forget the device too?
AFAIK routers should do this themselves upon receiving a DeviceLeave.
I'm now running OK using CC2531ZNP-Prod_20200410_default
I tried first with _CC2531ZNP-Prod_Source_Routing_20200410_ but it gave 'No network route' errors.
Thanks again!
So far 3 days ... and still working. I picked a very old bulb to test that has for certain never been in the network together with the repeated... wait a few more days and try again.
I am now also seeing the GP requests when sniffing that I only saw near the coordinator last time.
@Koenkk it failed again!
I was using a bulb I had used before, the innr bulb send the update device which you thought was odd last time.
So I moved it closer to a different router (I'm pretty sure this one has not been the parent of this bulb I was joining before), same thing... but this time the other router send the update device.
I'll edit this post once I uploaded the pcap.
[root@amethyst /opt/zigbee2mqtt]# grep 39924 /opt/zigbee2mqtt/data/database.db
{"id":4,"type":"Router","ieeeAddr":"0x14b457fffe2bd760","nwkAddr":39924,"manufId":4454,"manufName":"innr","powerSource":"Mains (single phase)","modelId":"RB 250 C","epList":[1,242],"endpoints":{"1":{"profId":260,"epId":1,"devId":269,"inClusterList":[0,3,4,5,6,8,768,2821,4096],"outClusterList":[25],"clusters":{"genBasic":{"attributes":{"modelId":"RB 250 C","manufacturerName":"innr","powerSource":1,"zclVersion":3,"appVersion":16,"stackVersion":98,"hwVersion":1,"dateCode":"20190326-87","swBuildId":"2.1"}},"genOnOff":{"attributes":{"onOff":0}},"genLevelCtrl":{"attributes":{"currentLevel":254}},"lightingColorCtrl":{"attributes":{"currentX":29786,"currentY":26830,"colorTemperature":364,"colorMode":1,"currentHue":25,"currentSaturation":199}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1},{"cluster":8,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1},{"cluster":768,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1}]},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[],"outClusterList":[33],"clusters":{},"binds":[]}},"appVersion":16,"stackVersion":98,"hwVersion":1,"dateCode":"20190326-87","swBuildId":"2.1","zclVersion":3,"interviewCompleted":true,"meta":{"reporting":1},"lastSeen":1587740726258}
[root@amethyst /opt/zigbee2mqtt]# grep 31787 /opt/zigbee2mqtt/data/database.db
{"id":3,"type":"Router","ieeeAddr":"0x90fd9ffffee77fcf","nwkAddr":31787,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Mains (single phase)","modelId":"TRADFRI bulb E27 CWS opal 600lm","epList":[1],"endpoints":{"1":{"profId":49246,"epId":1,"devId":512,"inClusterList":[0,3,4,5,6,8,768,2821,4096],"outClusterList":[5,25,32,4096],"clusters":{"genBasic":{"attributes":{"modelId":"TRADFRI bulb E27 CWS opal 600lm","manufacturerName":"IKEA of Sweden","powerSource":1,"zclVersion":1,"appVersion":17,"stackVersion":87,"hwVersion":1,"dateCode":"20180410","swBuildId":"1.3.009"}},"genOnOff":{"attributes":{"onOff":0}},"genLevelCtrl":{"attributes":{"currentLevel":254}},"lightingColorCtrl":{"attributes":{"currentX":29786,"currentY":26830,"colorCapabilities":8}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1},{"cluster":8,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1},{"cluster":768,"type":"endpoint","deviceIeeeAddress":"0x00124b001938a7e5","endpointID":1}]}},"appVersion":17,"stackVersion":87,"hwVersion":1,"dateCode":"20180410","swBuildId":"1.3.009","zclVersion":1,"interviewCompleted":true,"meta":{"reporting":1},"lastSeen":1587740702344}
Were the routers in play based from the pcap...
The pcap: https://pkg.blackdot.be/cores/zigbee/failed_join.pcapng
This is still with the source routing firmware, as it seems to result in a more stable network, I have not reset the stick yet. I am going to see if I can pilfer a bulb from a different room that is trådfri but not part of the network. It's out of range, but I can move it for a test.
Of note, the last time I use this bulb (last week for a test) I removed it from the network and it left nicely, no force remove.
100% sure this bulb was never in the network as it was installed in the garage and well out of range: https://pkg.blackdot.be/cores/zigbee/fail_new.pcapng also failed.
After a reset both bulbs pair immediately
Could you make such a sniff with all devices in your network powered off? (so only the coordinator is active). I think this input is required for Texas Instruments to investigate this further. Also make sure to capture the permit join requests on that sniff. (https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/892149/3299688#3299688)
Sure, will have to wait for joining to be broken again though... so give it take a week.
~ sjorge
On 30 Apr 2020, at 18:59, Koen Kanters notifications@github.com wrote:
Could you make such a sniff with all devices in your network powered off? (so only the coordinator is active). I think this input is required for Texas Instruments to investigate this further. Also make sure to capture the permit join requests on that sniff. (https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/892149/3299688#3299688)—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
:s it took me 2 hours to get all the breakers to get all routers offline:
After those I stopped z2m, unplugged the stick, plugged it back and started z2m... I was still unable to pair. After 1 attempt I also tried via touchlink, same result => https://pkg.blackdot.be/cores/zigbee/fail3_no_routers_touchlink_znc_maybe_stuck.pcapng
At this point I think the entire USB was acting weird, I powered on all breakers again and the network is super unstable and slow again like I had a while ago. After about 10 minutes it seems to stableize but I still can't pair anything. I did the stop/replug/start dance twice now.
Seeing some interesting things now.

According to https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/520679 it means that the association table is full. I will check if it's possible to expand. I think a re-power of the USB clears the association table which is filled again after some time.
Is that different from the routing table?
Investigated the source code and it's indeed different. Asked a few question to TI (https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/903323) (opened new thread because other one got closed).
wrt the reply from Ryna...

I'd expect only serverroom/sensor and masterbedroom/repeater to be in the list? Keeping it < 5 devices?
End devices can also be in that list so I think the behaviour is expected.
However I'm not sure if this is the same as the original issue (as in this sniff we get proper responses). Would it be possible to create a sniff with only the coordinator and 1 router powered on?
Sure, probably takes a few more days before pairing breaks again.
I also got a zzh stick comming soon, I wonder if the problem also exists there or if it is ZStack 1.2 specific
I don't know for sure, but I don't expect it (until now never experienced this and don't have any reports from other users).
Would be an interesting test case I guess. If I swap over and still experience it. It is almost certain a weird interaction with another device.
If it doesn’t happen, it might be a bug in zstack 1.2
Could still pair a device yesterday so haven’t got a new dump jet.
~ sjorge
On 14 May 2020, at 19:07, Koen Kanters notifications@github.com wrote:
I don't know for sure, but I don't expect it (until now never experienced this and don't have any reports from other users).—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
OK just tried to pair my new Hue Motion sensor and had the join fail.
I only saw 'Leave' messages from the router at my location. So will now go and try near the server.
One with everything powered to see if I see the assoc table reject and if I don't... I'll head out to the breaker box to disable all the lights to not have any routers aside one.
https://pkg.blackdot.be/cores/zigbee/src_route_full_network_leave.pcapng
first time every trying to pair a hue motion (Xiaomi not picking a new router is annoying so replacing my motion, light and temp/humidity senser... this one seems to do the first two, open for suggestions for a temp+humidity sensor)
It got blasted with leave requests (taken in my room so out of reach of coordinator)
https://pkg.blackdot.be/cores/zigbee/src_route_one_router_leaev.pcapng
after turning off all bulbs via the breaker and unplugging, this only left the trådfri repeater and Xiaomi sensors.
It got blasted with leave requests again (captured near the coordinator)
https://pkg.blackdot.be/cores/zigbee/src_route_no_router_nothing.pcapng
unplugged the repeated
Captured near the coordinator, it seems to at least respond to the beacon... but thats it I think? I wonder if the coordinator is out of memory or something and it can't even get the message out the table is full?
https://pkg.blackdot.be/cores/zigbee/src_route_full_after_reset.pcapng
Captured after issuing a znc reset via mqtt and then pairing again, works fine. Included for completeness.
Thanks! Especially interested in: https://pkg.blackdot.be/cores/zigbee/src_route_one_router_leaev.pcapng and the reason why the coordinator sends the "remove device" requests. Updated https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/903323/3348648#3348648
Some observation as I swapped out Xiami Motion and a Xiami light sensor to the new Hue Motion... the network is a lot more responsive.
I guess because the light sensor was super spamming... sometimes updating every second! The hue one does so every 5 minutes, on motion or I think on a 50lx change.
I wonder if we can configure the minimal reporting of the Xiami device to 5 min or something: https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/devices.js#L988
I only had one up for testing but was planning on having 3 (I already have them) but after too many issues with Xaimi I was looking for alternatives. I can imagine having 3 of those would just lock up the network.
For the illuminance sensor please try with something like:
await configureReporting.illuminance(
endpoint, {minimumReportInterval: 10, reportableChange: 100},
);
On the TI forum they now ask for the sniff. Perhaps you can put the network key online again at the location so they can take a look at it?
I'll give the reporting config a go during the long weekend.
Sure, let me upload the key again.
Edit: It's in the zigbee dir as '.key' so it doesn't show in the listing.
Re the ti thread... no, this was my new Hue Motion sensor that at the time of the captures had never been paired yet.
But you tried to pair it earlier before that attempt right? (https://pkg.blackdot.be/cores/zigbee/src_route_full_network_leave.pcapng)
Ah yeah, but it never made it into the network though?
I found a possible reason that this could fail (details: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/903323/3354720#3354720).
Previously we always called the permitJoin without a timeout (0xFF), since herdsman with (0xFE). Maybe something goes wrong with the internal timer of the adapter. This is also why this comment makes sense: https://github.com/Koenkk/zigbee2mqtt/issues/3177#issuecomment-602288259 (1.6.0 = first release of zigbee-herdsman).
Can you try replacing /opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/controller.js with https://gist.github.com/Koenkk/61ac011b3e682fb5e707db6b320ae76c?
Done, I'll avoid updating z2m for a bit and try to join a device after a few days.
I don't have any 'new' never joined devices, but if it is fixed a random bulb should be fine I think?
Yes should be good (assuming you were previously able to reproduce the bug with this)
Yeah it was with all pair attempts after a few days new or old device.
~ sjorge
On 22 May 2020, at 13:39, Koen Kanters notifications@github.com wrote:
Yes should be good (assuming you were previously able to reproduce the bug with this)—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
While I'm waiting a bit to test to see if it is fixed, Tho85 on discord seems to have a similar problem and that stated after pairing a Xiaomi Light Sensor...
Which I was also using up until a week ago, I wonder if the spammy nature of the sensor plays a part in breaking the Z-Stack firmwares timer or something.
https://pkg.blackdot.be/cores/zigbee/srctr_pair_fai.pcapng
The changes didn't help, the bulb gets kicked out immediately.
Please try with this firmware: CC2531ZNP-Prod_source_routing_20200530.hex.zip
It won't fix the issue, but during joining it will send leave request to non-existing addresses, this will help me to determine where in the code things go wrong. After flashing first check if you are still able to join a device (to make sure I didn't mess up).
I just realized something... I don't think unplugged the coordinator after applying the patch...
Would that have a possible effect on the result?
As it might have already set the timer, it expired. The new join doesn't set the timer but it may have had an expired timer value lingering around?
I'll try to flash the stick somewhere next week.
@sjorge yes, that could definitely cause an issue. So please make sure to do this. Nevertheless still try with that new firmware as it will provide extra information in case it still fails.
New firmware flashed, now we wait a bit and try too pair.
So if I understood correctly you added the equalivant of a debug print to the firmware bu sending a remove to a particular unique set of non existing devices in different paths of the code?
The firmware is not very responsive...
zigbee2mqtt:error 2020-05-31 19:14:13: Failed to ping 'bedroom/bed_lamp/bulb'
zigbee2mqtt:info 2020-05-31 19:14:13: MQTT publish: topic 'zigbee2mqtt/bedroom/desk_lamp/remote', payload '{"battery":74,"linkquality":42,"update_available":false,"click":"off"}'
zigbee2mqtt:info 2020-05-31 19:14:15: MQTT publish: topic 'zigbee2mqtt/bedroom/desk_lamp/remote', payload '{"battery":74,"linkquality":42,"update_available":false,"click":"on"}'
zigbee2mqtt:info 2020-05-31 19:14:27: MQTT publish: topic 'zigbee2mqtt/masterbedroom/lamp/bulb2/availability', payload 'online'
zigbee2mqtt:info 2020-05-31 19:14:27: MQTT publish: topic 'zigbee2mqtt/masterbedroom/lamp/bulb1/availability', payload 'online'
zigbee2mqtt:info 2020-05-31 19:14:28: MQTT publish: topic 'zigbee2mqtt/masterbedroom/lamp', payload '{"state":"OFF","brightness":254}'
zigbee2mqtt:info 2020-05-31 19:14:28: MQTT publish: topic 'zigbee2mqtt/masterbedroom/lamp/bulb2', payload '{"state":"OFF","linkquality":47,"update_available":false,"brightness":254}'
zigbee2mqtt:info 2020-05-31 19:14:28: MQTT publish: topic 'zigbee2mqtt/masterbedroom/lamp', payload '{"state":"OFF","brightness":254}'
zigbee2mqtt:info 2020-05-31 19:14:28: MQTT publish: topic 'zigbee2mqtt/masterbedroom/lamp/bulb1', payload '{"update_available":false,"state":"OFF","linkquality":31,"brightness":254}'
zigbee2mqtt:error 2020-05-31 19:14:35: Failed to read state of 'masterbedroom/lamp/bulb1' after reconnect
zigbee2mqtt:error 2020-05-31 19:14:36: Failed to read state of 'masterbedroom/lamp/bulb2' after reconnect
zigbee2mqtt:info 2020-05-31 19:14:48: MQTT publish: topic 'zigbee2mqtt/bathroom/lamp/bulb/availability', payload 'online'
zigbee2mqtt:info 2020-05-31 19:14:49: MQTT publish: topic 'zigbee2mqtt/bathroom/lamp', payload '{"state":"OFF","brightness":254,"color_temp":400,"color":{"x":0.4599,"y":0.4106}}'
zigbee2mqtt:info 2020-05-31 19:14:49: MQTT publish: topic 'zigbee2mqtt/bathroom/lamp/bulb', payload '{"state":"OFF","linkquality":42,"update_available":false,"brightness":254,"color_temp":400,"color":{"x":0.4599,"y":0.4106}}'
zigbee2mqtt:info 2020-05-31 19:14:58: MQTT publish: topic 'zigbee2mqtt/masterbedroom/repeater/availability', payload 'online'
zigbee2mqtt:info 2020-05-31 19:14:59: MQTT publish: topic 'zigbee2mqtt/masterbedroom/repeater', payload '{"linkquality":42,"update_available":false}'
zigbee2mqtt:error 2020-05-31 19:15:12: Failed to read state of 'bathroom/lamp/bulb' after reconnect
About 1/10 changes mode actually make it through
https://pkg.blackdot.be/cores/zigbee/errors.pcapng
There is one near packet 330 but a few before that, but they scrolled by to fast.
Note, this is not during pairing... this is just existing devices dropping and failing to rejoin after the device announcement... going to refresh the normal source routing firmware tomorrow morning as nothing is working atm.
Got my issue tabs messed up.
Back on the vanilla source routing firmware, network was back to normal/stable after ~5min or so.
Still have the diff to controller.js applied so 🤞 the first time it failed because I had not rest the stick, we'll know in a day or 5 I guess.
Tried to pair a device today, same issue :( so the change to non timer version didn't seem to help.
Adaptor was reset when I reflashed normal src routing firmware when the debug one broke everything.
Can you sniff the traffic of the debug one? (just to see where it fails)
https://pkg.blackdot.be/cores/zigbee/errors.pcapng was captures with the debug firmware when it was locking up. Which was almost immediately after a unplug, plug, start z2m
It seems that my changed indeed didn't work, I will try to figure out an alternative way to do debugging.
It seems that my changed indeed didn't work, I will try to figure out an alternative way to do debugging.
Is USART 0 or USART 1 still free in the software?
It would require a little soldering, but I believe you can route the Rx & Tx to the (tiny) extension header on the side of the CC2531 USB Dongle (Table 7-1. Peripheral I/O Pin Mapping) and the "Additional test pins" from the schematic
If you connect a FTDI cable to that you can do debug printing from the dongle.
It is a very common way to debug embedded software, so it would surprise me if there isn't something in the TI software stack for that already.
Soldering is a bit beyond my skill level... based on my succes rate.
~ sjorge
On 7 Jun 2020, at 11:52, FaBjE notifications@github.com wrote:
It seems that my changed indeed didn't work, I will try to figure out an alternative way to do debugging.Is USART 0 or USART 1 still free in the software?
It would require a little soldering, but I believe you can route the Rx & Tx to the (tiny) extension header on the side of the CC2531 USB Dongle (Table 7-1. Peripheral I/O Pin Mapping) and the "Additional test pins" from the schematic
If you connect a FTDI cable to that you can do debug printing from the dongle.It is a very common way to debug embedded software, so it would surprise me if there isn't something in the TI software stack for that already.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
If it is a feasible solution to help Koenkk debugging I can do some soldering and we can arrange some postage/shipping scheme
@FaBjE what is required for this? Iar workbench only?
@sjorge I've modified the firmware a bit, hopefully it doesn't crash now:
CC2531ZNP-Prod_source_routing_20200609.zip
@Koenkk Just some code. Compiler has nothing to do with it. (I'm well familiar with IAR, Not so much with the TI Z-Stack)
For debug printing, you just configure the uart in code at 115200 or anything. and put printf statements in the code.
https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/169089
The processor pins output uart at TTL level, so you need a converter from TTL to pc, something like this is the easiest to use.
https://www.antratek.nl/ftdi-usb-to-serial-ttl-cable-3-3v-ttl
This requires a little soldering on the CC2531 usb dongle pcb as it doesn't have a ready-to-use connector for it, But it has the appropriate processor pins on the pinheader pads at the side.
Than you just open a COM terminal on your PC an can see what is going on in the software ;)
@FaBjE thanks for sharing this, very interested in this and will probably will be useful in the future.
@FaBjE thanks for sharing this, very interested in this and will probably will be useful in the future.
Happy to help :)
If you need any assistance integrating this, let me know.
I’ll flash the new firmware this weekend
Flash the firmware but immediately the network fell apart.
I will upload a small capture later where I use a remote to toggle a group of bulbs, then try to change it via mqtt, then try to change a single bulb. Then turn them back on via the remote.
Going to reflash and get everything back up and running first.
https://pkg.blackdot.be/cores/zigbee/bad2.pcapng
I think I know what is causing the issue though, after every device announce from an actually device, e.g. the hue motion sensor. The firmware sends a flood of debug announcements and I think that trips up the network... so the device never rejoins.
I also noticed the ikea remotes don't send a announcement when I push a button so probably why they work fine. The first time A bulb sends some data (attReport) it also announces itself again but it gets met with a flood of messages and it never rejoins.
I flashed the std source routing firmware again and only the devices that had tried to rejoin, had issue. The once that had not yet send a message were fine.
It might slower but perhaps we could toggle the led to green and red at 2 most likely points where you think the issues is and turn it of at startup.
It's a lot less info to go on, but it would not send zigbee traffic that could cause other devices to be unhappy?
I don't understand yet why it doesn't work, your sniff doesn't contain any messages send from the coordinator, probably the code crashes or something.
Anyway, based on the idea of @FaBjE I found a way to output debug logging to zigbee-herdsman. Try with this firmware:
CC2531ZNP-Prod_20200614.zip , now run zigbee2mqtt with DEBUG=zigbee-herdsman:adapter:zStack:znp:AREQ npm start and when pairing a device you will see this logging:

I'll reflash later today.
So I just run z2m as normal, once I noticed joining no longer works I stop and start it manually with the debugging? (given only a znc reset or physical unplug/replug fixes it, and a z2m restart has no effect)
Always run with this logging (there won't be any overhead) and just check the log when joining fails for the first time.
Of to a good start, this firmware is stable!
I will adapt my init script to run with the extra debugging now.
Everything stopped working today, got a bit of the log. https://gist.github.com/sjorge/bcf51e3d4b8269788bf61aa8b927b339
Seems to be a memory issue on the ZNC, reset via mqtt did not work. Had to unplug and wait a bit before replugging.
Not sure this is due to the logging being added, or that his just highlighted the actually issue were some memory is never cleared. A full association table also sounds like a memory thing.
Forgot to deallocate the send debug message, should be fixed with:
CC2531ZNP-Prod.zip
Will flash tomorrow, just got home. Lets hope that one runs for a bit longer until the pairing issue manifests.
Updated the stick, now we wait
Still working, but looks like my CC got unplugged an replugged a day ago, probably while someone was loading the laundry :(
Been a bit AFK too, so no update for now.
Very odd, I was able to join a bulb today after 6 days of uptime. Were there any other changes aside from the debug printing?
@sjorge no there we no other changes. What debug logging did you got? Theoretically: the added debug statements increase the execution time, in case this bug turns out to be a race condition this could actually "solve" it.
On 2020-07-01 22:04, Koen Kanters wrote:
@sjorge [1] no there we no other changes. What debug logging did you got? Theoretically: the added debug statements increase the execution time, in case this bug turns out to be a race condition this could actually "solve" it.
--
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [2], or unsubscribe [3].
I already turned of my laptop, I'll pair the bulb again tomorrow and
capture the output to a file.
--
~ sjorge
[1] https://github.com/sjorge
[2]
https://github.com/Koenkk/zigbee2mqtt/issues/3177#issuecomment-652620178
[3]
https://github.com/notifications/unsubscribe-auth/AAC4WEMKHTXWOZSRQGT5UDTRZOJFXANCNFSM4LRO5I4Q
Still works fine after 10 days, so maybe it is some timing thing.
https://gist.github.com/sjorge/7bab8456eb865848db3e5ed9c4dd55fc here is the log, it wasn't fully scewed in so 2 device announces, but it joined fine after I tightened it in the socket without doing anything else.
Looks good, I also see the logging I've added. I'm not sure how to continue here yet. Maybe wait for some more days or see if anybody else can confirm it has been fixed with this FW?
If the firmware is "stable" I can give it a shot. I need to find a moment to do the initial setup though.
Edit: Can the debug log be enabled/logged in the docker container?
I noticed no difference in stability with this or the normal firmware, so I'd say it's stable.
Not sure about docker as I don't use it.
@Koenkk Do you know if I can enable the debug logging in the docker container?
@FaBjE yes, see https://www.zigbee2mqtt.io/information/debug.html#docker
I just got a new device to test delivered, so will have another go at pairing a totally new device today or tomorrow.
Uptime has been 2 weeks, still working fine with debug logging turned on!
Good, TI asked me to figure out how much delay has to be added, I will try to provide 2 new firmwares this weekend where debug logging is replaced with 2 fixed delays.
Just updated my coordinator to CC2531ZNP-Prod.zip.
I had to add pan_id: 0x1a63 to the config. Apparently the old one pan_id: 6755 was changed.
The zigbee network is online again and seems good.
I added "- DEBUG=zigbee-herdsman:adapter:zStack:znp:AREQ" to my docker-compose file. And I see the adapter debug messages (displaying all messages payload) to the console. But they are not saved to the log.txt file.
I will try to join a new device in a few days.
Can you try this firmware:
CC2531ZNP-Prod_20200720.zip (has some builtin sleeps without debug logging)
Mostly done moving stuff over to my new place now, once I have my ZNC back up and running, I'll flash and try the new firmware.
I flashed the new firmware, going to pair some bulbs now.
Pairing isn't working well, I managed to pair only 2 bulbs but now it's locked up.
I'm going to revert to vanilla source routing and finish pairing everything as I have lots of bulbs to go
It seems to mostly timeout in the interviewing/configuration steps
I didn't switch back to the stock firmware, pairing still hits the odd timeout during interviewing/configuration but seems to be better once a few more routers had joined.
Can you try this firmware:
CC2531ZNP-Prod_source_routing_20200728.zip
I’m back at my old place for the night, will try to flash the new firmware tomorrow.
Small update, I got most things paired. Seemed to work smoother once I could pair through a router. With about 26 bulbs online (trådfri and Innr) the network does seem stable.
I just updated to the new firmware, at first glance messages now seem to come in batches of 4-6 at a time per sec. Will give it a few days to see how it evolves but on first glance everything still works. If it stays table I'll try pairing a bulb in a week from now. Although I might need to reboot the server before that when I move it back into my rack.
Only been a few days, but I paired 6 TuYa TS0201 Temp + Humidity sensors in a row, without much issue. They timeouts in pairing/interviewing are definitely better with the latest iteration. Now we wait a few more days.
Also out of interest, is the special fix for Hue Motion sensors in this firmware? Mine seems to drop out of the network occasionally. But I vaguely remember it not being in the 1.2 source routing one, so I think that is normal.
Good! The fix for end devices not being reachable is only in the zstack 3.x.0 firmwares, I can look into porting it to zstack 1.2 once we know if this issue has been fixed.
Still working fine after 7 days so far.
We've passed 14 days now, I will retest once more time hopefully all still good.
Still looks good!
Zigbee2MQTT:info 2020-08-16 16:10:07: Device '0x0017880104259333' joined
Zigbee2MQTT:info 2020-08-16 16:10:07: Starting interview of '0x0017880104259333'
Zigbee2MQTT:info 2020-08-16 16:10:07: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":{"friendly_name":"0x0017880104259333"},"type":"device_connected"}'
Zigbee2MQTT:info 2020-08-16 16:10:07: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_started","meta":{"friendly_name":"0x0017880104259333"},"type":"pairing"}'
Zigbee2MQTT:info 2020-08-16 16:10:07: MQTT publish: topic 'zigbee2mqtt/0x0017880104259333/availability', payload 'online'
Zigbee2MQTT:info 2020-08-16 16:10:07: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"announce","meta":{"friendly_name":"0x0017880104259333"},"type":"device_announced"}'
Zigbee2MQTT:info 2020-08-16 16:10:09: Successfully interviewed '0x0017880104259333', device has successfully been paired
Zigbee2MQTT:info 2020-08-16 16:10:09: Device '0x0017880104259333' is supported, identified as: Philips Hue white and color ambiance E26/E27/E14 (9290012573A)
Zigbee2MQTT:error 2020-08-16 16:10:32: Failed to setup reporting for '0x0017880104259333' - Error: ConfigureReporting 0x0017880104259333/11 genOnOff([{"attribute":"onOff","minimumReportInterval":0,"maximumReportInterval":300,"reportableChange":0}], {"timeout":10000,"disableResponse":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) failed (Timeout - 46896 - 11 - 227 - 6 - 7 after 10000ms)
at Timeout.waiter.timer.setTimeout [as _onTimeout] (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:46:35)
at ontimeout (timers.js:425:11)
at tryOnTimeout (timers.js:289:5)
at listOnTimeout (timers.js:252:5)
at Timer.processTimers (timers.js:212:10)
Zigbee2MQTT:info 2020-08-16 16:10:32: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_successful","meta":{"description":"Hue white and color ambiance E26/E27/E14","friendly_name":"0x0017880104259333","model":"9290012573A","supported":true,"vendor":"Philips"},"type":"pairing"}'
The error here is to be expected, as the hue bulb is on the latest firmware, which sadly means no reporting at all (even genOnOff)
I did notice some weirdness though, I toggled the set of 4 panels again because they still were not all reporting genlevelCtrl... (#4109)
Zigbee2MQTT:info 2020-08-16 16:11:47: Successfully setup reporting for '0x14b457fffe2fee7a' - 1 - genOnOff
Zigbee2MQTT:info 2020-08-16 16:11:47: Successfully setup reporting for '0xec1bbdfffe189fde' - 1 - genOnOff
Zigbee2MQTT:info 2020-08-16 16:11:47: Successfully setup reporting for '0x14b457fffe301910' - 1 - genOnOff
Zigbee2MQTT:info 2020-08-16 16:11:47: Successfully setup reporting for '0xec1bbdfffe9f5f8f' - 1 - genOnOff
Zigbee2MQTT:info 2020-08-16 16:11:47: Successfully setup reporting for '0xec1bbdfffe189fde' - 1 - genLevelCtrl
Zigbee2MQTT:info 2020-08-16 16:11:47: Successfully setup reporting for '0x14b457fffe2fee7a' - 1 - genLevelCtrl
Zigbee2MQTT:info 2020-08-16 16:11:47: Successfully setup reporting for '0xec1bbdfffe9f5f8f' - 1 - genLevelCtrl
Zigbee2MQTT:info 2020-08-16 16:11:48: Successfully setup reporting for '0x14b457fffe301910' - 1 - genLevelCtrl
Zigbee2MQTT:info 2020-08-16 16:11:48: Successfully setup reporting for '0xec1bbdfffe189fde' - 1 - lightingColorCtrl
Zigbee2MQTT:info 2020-08-16 16:11:48: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"announce","meta":{"friendly_name":"office/lights/panel4"},"type":"device_announced"}'
Zigbee2MQTT:info 2020-08-16 16:11:48: Successfully setup reporting for '0xec1bbdfffe9f5f8f' - 1 - lightingColorCtrl
Zigbee2MQTT:info 2020-08-16 16:11:48: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"announce","meta":{"friendly_name":"office/lights/panel3"},"type":"device_announced"}'
Zigbee2MQTT:info 2020-08-16 16:11:48: Successfully setup reporting for '0x14b457fffe2fee7a' - 1 - lightingColorCtrl
Zigbee2MQTT:info 2020-08-16 16:11:48: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"announce","meta":{"friendly_name":"office/lights/panel2"},"type":"device_announced"}'
Zigbee2MQTT:info 2020-08-16 16:11:48: Successfully setup reporting for '0x14b457fffe301910' - 1 - lightingColorCtrl
Zigbee2MQTT:info 2020-08-16 16:11:48: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"announce","meta":{"friendly_name":"office/lights/panel1"},"type":"device_announced"}'
The network was pretty idle this time so I had hoped they might succeed, and they did. But the device_announcement and reporting setup log entries seem to be out of order?
Shouldn't we see the device_announcement first, then trigger the configuration of the device afterwards? Now this might be due to how the logging code works though, if we trigger the reporting in the onEvent for the device_accouncement we might do stuff before the later gets logged. Not super important, but confusing when going over logs none the less.
Anyway, I guess once you release a new official source_routing firmware, we can close this. (yay!)
It indeed depends on how the converters are called, the logging you see is from the bridgeLegacy extension. If you set the level to debug you should see it before.
I will try to release a new fw soon with this fix, thanks! (there is another issue but I forgot which, hope it pops up soon again)
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
unstale, as AFAIK no updated firmnware has been released
Today I tried to join a sensor. But it failed. I tried several times (Next to the coordinator stick)
After unplugging the coordinator stick it worked flawlessly the first time.
Unfortunately I was not logging debug information. I will try again in a week or so with debug logging.
Coordinator version: 20200728 (Source routing)
Zigbee2Mqtt version: 1.14.3
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
Unstale
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
Sjorge bump :-))
Not much I can do here, I think koenkk just needs to publish the firmware with this and the hue motion fix, seems to be working fine for a while now.
I knowing.
I was only liking the case not being closed :-)
@sjorge thanks, I will find some time to publish these firmwares soon since fixes appear to be stable now and no more changes are required.
Most helpful comment
@sjorge thanks, I will find some time to publish these firmwares soon since fixes appear to be stable now and no more changes are required.