Zigbee2mqtt: Philips Hue Motion sensors disconnect from the network
Bug Report
What happened
I have 10+ philips hue motion sensors paired to my network. I move them all from a philips hue bridge (along with some light bulbs) where them have been working for a while without any problem.
Some of the motion sensors disconnect from time to time from the network now; sometimes they reconnect without doing anything, sometimes not.
This happen even with a hue motion sensor very close to the coordinator.
If they don't, I have to force remove them from the network and pair them again.
The network support more than 100 devices and those are the only devices with this behaviour.
What did you expect to happen
Once a hue motion sensor connect, it should keep connected.
How to reproduce it (minimal and precise)
Difficult to reproduce, as the disconnections are random.
Debug Info
philips hue motion sensors with latest firmware version from Philips
zigbee2mqtt version: 1.8.0 latest dev
CC253X firmware version: P-2 coordinator, latest firmware
2 CC2530+CC2591 on the network running latest routing firmware
ccorderod
All 102 comments
I'm having the same problem (https://github.com/Koenkk/zigbee2mqtt/issues/2518#issuecomment-569132387), currently waiting for the problem to manifest itself again, then I can start looking into it.
Koenkk
on 8 Jan 2020
Same issue here with Hue Switches and Motion Sensor.
WouterJN
on 10 Jan 2020
Same issue here with Hue outdoor motion sensors. At the moment I am still unable to repair two of them. I removed them from the database of zigbee2mqtt and tried to repair them, but the only thing happening is that there is a line in the log that the device announced itself, without the usual pairing procedure.
Looking forward to any fix - many thanks in advance!
papanirual
on 10 Jan 2020
Update from my side, right before it stops working it seems that the devices leaves the network:
debug 2020-01-11 10:30:40: Device 'veranda_occupancy_sensor' announced itself
warn 2020-01-11 10:30:40: Device '0x001788010644f56d' left the network
Then it joins again:
info 2020-01-11 10:30:40: Device 'veranda_occupancy_sensor' joined
info 2020-01-11 10:30:40: Starting interview of 'veranda_occupancy_sensor'
But this fails:
error 2020-01-11 10:32:01: Failed to interview 'veranda_occupancy_sensor', device has not successfully been paired
Going to dive further into it.
Question to all: what coordinators and coordinator firmware do you use?
Koenkk
on 11 Jan 2020
Coordinator: CC1352P_2 firmware: 20191106
Most of my hue motion sensors are able to join again, but leave randomly again.
@Koenkk : is there is any way to log with DEBUG=* npm start but only logging one sensor? My network is too big to run zb2m with Debug enabled as it create enormous log files :-(.
ccorderod
on 12 Jan 2020
Thats not possible, but setting it to DEBUG=zigbee-herdsman:controller* should give the required info.
Koenkk
on 12 Jan 2020
CC253X firmware version: 20190608
Philips Hue (9290012607) firmware version: 6.1.0.18912 and 6.1.1.27575
Bugs: After reboot the coordinator, cannot receive Philips motion sensor's message
Log File:
2020-01-13.15-39-50/log.txt:1/13/2020, 3:41:50 PM - warn: Failed to configure r_MotionD1 (0x0017880104b78b01) ('Error: Timed out after 10000 ms') (attempt #1)
2020-01-13.15-39-50/log.txt:1/13/2020, 3:41:50 PM - warn: This can be ignored if the device is working properly
hi1000
on 13 Jan 2020
CC26X2R1_20191106, Coordinator firmware version:
'{"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20191106}}'
zigbee2mqtt version 1.8.0-dev (commit #f04e01f)
Koen Kanters schrieb am 11.01.2020 um 22:41:
>
Update from my side, right before it stops working it seems that the
devices leaves the network:|debug 2020-01-11 10:30:40: Device 'veranda_occupancy_sensor'
announced itself warn 2020-01-11 10:30:40: Device '0x001788010644f56d'
left the network |Then it joins again:
|info 2020-01-11 10:30:40: Device 'veranda_occupancy_sensor' joined
info 2020-01-11 10:30:40: Starting interview of
'veranda_occupancy_sensor' |But this fails:
|error 2020-01-11 10:32:01: Failed to interview
'veranda_occupancy_sensor', device has not successfully been paired |Going to dive further into it.
Question to all: what coordinators and coordinator firmware do you use?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Koenkk/zigbee2mqtt/issues/2693?email_source=notifications&email_token=ALFQYXOUTQSGBPNQMEAT5B3Q5I4J7A5CNFSM4KEFQ5EKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIWLXII#issuecomment-573356961,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALFQYXIT3BSEEL4US2Q4ULDQ5I4J7ANCNFSM4KEFQ5EA.
papanirual
on 13 Jan 2020
Did you have some Osram plugs in your network? In https://github.com/Koenkk/zigbee2mqtt/issues/1474 it's described that Osram plugs prevent a re-join of some devices (maily Hue motion sensors). By myself I got two Osram plugs in the network and Hue motion and Hue dimmer are randomly disconnected. After I removed the plugs from the network it seems to be stable.
sti0
on 17 Jan 2020
CC1352P-2
Coordinator firmware version: '{"type":"zStack3x0","meta":
{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20191106}}'
same problem, no Osram devices.
GJT
on 18 Jan 2020
I was experiencing this same problem with the Hue Dimmer Switches, as described here.
A week ago I tried changing the channel of my coordinator to use Zigbee channel 25. After searching for interfering WiFi access points near my apartment, I found that the default channel was quite populated.
So it seems to be an issue with interference, from my best guess. Can anyone verify this?
emilklindt
on 18 Jan 2020
Mine dropped off again today, pushed a possible fix in the latest dev branch, fingers crossed 🤞
Koenkk
on 18 Jan 2020
Running on latest (not -dev), saw this:
[...]
zigbee2mqtt:info 2020-01-24 18:18:40: MQTT publish: topic 'zigbee2mqtt-beneden/motion_tuin', payload '{"battery":96,"linkquality":33,"occupancy":false,"temperature":3.34,"illuminance":3242,"device":{"friendlyName":"motion_tuin","model":"9290019758","ieeeAddr":"0x001788010644892e","networkAddress":43045,"type":"EndDevice","manufacturerID":4107,"manufacturerName":"Philips","powerSource":"Battery","applicationVersion":2,"stackVersion":1,"zclVersion":1,"hardwareVersion":1,"dateCode":"20180828","softwareBuildID":"6.1.0.25261"}}'
zigbee2mqtt:info 2020-01-24 18:19:04: Device 'motion_tuin' joined
zigbee2mqtt:info 2020-01-24 18:19:04: MQTT publish: topic 'zigbee2mqtt-beneden/bridge/log', payload '{"type":"device_connected","message":{"friendly_name":"motion_tuin"}}'
zigbee2mqtt:info 2020-01-24 18:19:04: Starting interview of 'motion_tuin'
zigbee2mqtt:info 2020-01-24 18:19:04: MQTT publish: topic 'zigbee2mqtt-beneden/bridge/log', payload '{"type":"pairing","message":"interview_started","meta":{"friendly_name":"motion_tuin"}}'
zigbee2mqtt:error 2020-01-24 18:20:24: Failed to interview 'motion_tuin', device has not successfully been paired
zigbee2mqtt:info 2020-01-24 18:20:24: MQTT publish: topic 'zigbee2mqtt-beneden/bridge/log', payload '{"type":"pairing","message":"interview_failed","meta":{"friendly_name":"motion_tuin"}}'
Updated to latest-dev now and will pair again. Let's see how long it will last this time ;-)
peterforeman
on 25 Jan 2020
I setup three zigbee coordinators in the same big room. They are use the different channels and different keys but the same pan_id and ext_pan_id.
hi1000
on 29 Jan 2020
Mine dropped off again today, pushed a possible fix in the latest dev branch, fingers crossed 🤞
When will this be released in the main branch?
WouterJN
on 1 Feb 2020
@WouterJN in Zigbee2mqtt 1.10 scheduled for Wednesday/Thursday.
Koenkk
on 1 Feb 2020
Mine hasn't dropped of since 2 weeks so things seem to have improved.
Koenkk
on 1 Feb 2020
I have reconnected my two philips hue motion sensor yesterday with latest dev and they are lost again during the evening.
Sorry - my fault. My HA System did not show the right value.
pepp86
on 6 Feb 2020
@Koenkk Hue motion sensors started to drop off the network again yesterday after upgrading to 1.10.0-dev yesterday. Unfortunatly I can't tell wich version I was running previously (it was dev, but I do not know the build #). Will restart z2m with DEBUG=zigbee-herdsman:controller* trying to catch a drop.
ccorderod
on 21 Feb 2020
@Koenkk Not sure if this will help you in any way, but here you go an extract:
2020-02-21T08:20:30.487Z zigbee-herdsman:controller:log Starting with options '{"network":{"networkKeyDistribute":false,"networkKey":[x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,],"panID":7100,"extendedPanID":[y,y,y,y,y,y,y,y,y,y],"channelList":[20]},"serialPort":{"baudRate":115200,"rtscts":true,"path":"/dev/ttyACM0"},"databasePath":"/opt/zigbee2mqtt/data/database.db","databaseBackupPath":"/opt/zigbee2mqtt/data/database.db.backup","backupPath":"/opt/zigbee2mqtt/data/coordinator_backup.json"}'
2020-02-21T08:20:31.884Z zigbee-herdsman:controller:log Disable joining
2020-02-21T08:21:57.627Z zigbee-herdsman:controller:endpoint DefaultResponse 0x0017880104b4e792/2 1030(10, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":null,"disableDefaultResponse":true})
2020-02-21T08:21:57.671Z zigbee-herdsman:controller:endpoint DefaultResponse 0x0017880104b4e792/2 1024(10, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":null,"disableDefaultResponse":true})
2020-02-21T10:29:48.443Z zigbee-herdsman:controller:endpoint DefaultResponse 0x0017880104b4e792/2 1024(10, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":null,"disableDefaultResponse":true})
2020-02-21T10:29:51.724Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' joined
2020-02-21T10:29:51.725Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' accepted by handler
2020-02-21T10:29:51.725Z zigbee-herdsman:controller:log Not interviewing '0x0017880104b4e792', completed 'true', in progress 'false'
2020-02-21T10:29:51.736Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T10:29:58.155Z zigbee-herdsman:controller:endpoint DefaultResponse 0x0017880104b4e792/2 1030(10, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":null,"disableDefaultResponse":true})
2020-02-21T10:34:05.249Z zigbee-herdsman:controller:endpoint DefaultResponse 0x0017880104b4e792/2 1024(10, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":null,"disableDefaultResponse":true})
2020-02-21T10:34:08.874Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T10:39:04.785Z zigbee-herdsman:controller:endpoint DefaultResponse 0x0017880104b4e792/2 1024(10, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":null,"disableDefaultResponse":true})
Please note this is only an extract. there are hundreds of records with DefaultResponse, as well as many device announcement records. The hue motion sensor also joined and was accepted a few more times than what I have included on the post.
Let me know if you need anything else on my side.
By the way, I have moved the hue motion sensors to a hue bridge but the one showed on the log in the meantime as my setup is mostly useless without them. Thank you.
ccorderod
on 21 Feb 2020
@Koenkk Apologies for so much post, but I just got a drop :-). Hue motion sensor keeps announcing itself, join, is accepted, not interviewed, join again ...
2020-02-21T11:01:59.354Z zigbee-herdsman:controller:endpoint DefaultResponse 0x0017880104b4e792/2 1030(10, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":null,"disableDefaultResponse":true})
2020-02-21T11:01:59.443Z zigbee-herdsman:controller:endpoint DefaultResponse 0x0017880104b4e792/2 1024(10, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":null,"disableDefaultResponse":true})
2020-02-21T11:02:04.384Z zigbee-herdsman:controller:endpoint DefaultResponse 0x0017880104b4e792/2 1024(10, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":null,"disableDefaultResponse":true})
2020-02-21T11:02:07.651Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:02:09.341Z zigbee-herdsman:controller:endpoint DefaultResponse 0x0017880104b4e792/2 1024(10, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":null,"disableDefaultResponse":true})
2020-02-21T11:02:14.282Z zigbee-herdsman:controller:endpoint DefaultResponse 0x0017880104b4e792/2 1024(10, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":null,"disableDefaultResponse":true})
2020-02-21T11:02:19.252Z zigbee-herdsman:controller:endpoint DefaultResponse 0x0017880104b4e792/2 1024(10, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":null,"disableDefaultResponse":true})
2020-02-21T11:02:22.505Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:03:22.900Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:04:22.306Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:05:56.998Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:05:56.999Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' joined
2020-02-21T11:05:57.000Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' accepted by handler
2020-02-21T11:05:57.000Z zigbee-herdsman:controller:log Not interviewing '0x0017880104b4e792', completed 'true', in progress 'false'
2020-02-21T11:07:01.082Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' joined
2020-02-21T11:07:01.082Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' accepted by handler
2020-02-21T11:07:01.082Z zigbee-herdsman:controller:log Not interviewing '0x0017880104b4e792', completed 'true', in progress 'false'
2020-02-21T11:07:01.089Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:17:34.210Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:22:00.076Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:27:21.481Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' joined
2020-02-21T11:27:21.481Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' accepted by handler
2020-02-21T11:27:21.482Z zigbee-herdsman:controller:log Not interviewing '0x0017880104b4e792', completed 'true', in progress 'false'
2020-02-21T11:27:21.483Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' joined
2020-02-21T11:27:21.483Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' accepted by handler
2020-02-21T11:27:21.483Z zigbee-herdsman:controller:log Not interviewing '0x0017880104b4e792', completed 'true', in progress 'false'
2020-02-21T11:27:21.484Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:35:47.820Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:37:30.182Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:50:35.146Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:52:46.654Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' joined
2020-02-21T11:52:46.655Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' accepted by handler
2020-02-21T11:52:46.655Z zigbee-herdsman:controller:log Not interviewing '0x0017880104b4e792', completed 'true', in progress 'false'
2020-02-21T11:52:47.392Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:53:09.056Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T11:58:37.810Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' joined
2020-02-21T11:58:37.810Z zigbee-herdsman:controller:log Device '0x0017880104b4e792' accepted by handler
2020-02-21T11:58:37.811Z zigbee-herdsman:controller:log Not interviewing '0x0017880104b4e792', completed 'true', in progress 'false'
2020-02-21T11:58:39.007Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
2020-02-21T12:03:54.281Z zigbee-herdsman:controller:log Device announce '0x0017880104b4e792'
ccorderod
on 21 Feb 2020
same for me after upgrade, when i try to reconfigure I get this:
zigbee2mqtt:error 2020-02-21 19:12:32: Failed to configure 'zb_sensor_kueche', attempt 1 (Error: Bind 0x001788010213f153/2 genPowerCfg from '0x00124b001ca61201/1' failed (Error: AREQ - ZDO - bindRsp after 10000ms)
at Endpoint.(/zigbee2mqtt-1.10.0/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:235:23)
at Generator.throw ()
at rejected (/zigbee2mqtt-1.10.0/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:6:65))
GJT
on 21 Feb 2020
I've tweaked the route discovery a bit therefore it could be a one-time thing (and afterwards it should improve).
Could you try repairing it once for now and monitor if it drops off again?
Koenkk
on 23 Feb 2020
Hi @Koenkk I upgraded to latest dev a few minutes ago. The motion sensor has been working just a few minutes and dropped again. The funny thing is come to live again from time to time, and drop again :-(.
ccorderod
on 23 Feb 2020
@ccorderod can you update to the latest dev branch and sniff the traffic when this happens? https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html
Koenkk
on 24 Feb 2020
For CC26xR1 and CC1352-P2 users, I believe this is an issue with the firmware itself, I've asked TI for support: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/883629
Koenkk
on 26 Feb 2020
Thank you @Koenkk. I use a cc1352-P2 coordinator. Let's see TI answer to your ticket. Thank you for the update.
ccorderod
on 26 Feb 2020
TI has provided a possible fix, which I'm going to test now. ~Firmware: https://drive.google.com/open?id=1Ls8H3R8n2nUxyh9fq-l7hdwdPWg-UD5h~
https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin
Koenkk
on 28 Feb 2020
CC1352P_2 with CC1352P_2_20200229.zip firmware and zigbee2mqtt-1.11.0
Sadly still experiencing hue sensor drop outs.
Had 2 out 6 of sensors go dark, one never came back and one after about 30-60 minutes two times.
I don't have a stick to sniff traffic, but got one ordered.
GJT
on 2 Mar 2020
I upgraded to the new firmware 6 days ago as per my other issue (linked immediately above this post).
Everything has been perfect until a few hours ago.
My kitchen sensor went offline at 2008 hours, came back of its own accord 62 minutes later at 2110. The last reported link quality was 102 when it dropped off, which is slightly higher than average for that sensor.
Then my bathroom sensor went offline at 2107. Link quality was 96 (which is bang on average for that sensor) when it dropped off. It is now 2346 hours here and the sensor is still offline.
I'm noting the times specifically because you'll note that they're almost 'in order', kitchen goes off, then kitchen comes back and bathroom goes off within minutes of each other (could have actually been the exact same time and it's just the next update times).
Hope this helps diagnose the issue.
I'm off to bed now, if the bathroom one isn't back online in the morning I'll let you know whether a quick press of the button works or whether a full re-pair is required.
No obvious issues in the logs for any of the relevant time points, but I'm not currently logging debug or herdsman so :man_shrugging:
Ooooh, should mention. I don't have any osram bulbs but I do have 3 innr bulbs. All 3 are in the kitchen, and the bathroom is above the kitchen so it's possible that both affected motion sensors are using an innr bulb as a router - I'll run a map in the morning and see.
mf-social
on 10 Mar 2020
Mine also dropped off/shows red led on motion detection, I've found 2 other issues:
- Updated firmware (small change): https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin
- Zigbee2mqtt was sending the default responses to the wrong network address after the motion sensors changed it's network address. This causes the sensor to think it's not connected to the network anymore ending in a reconnect loop (and also causing the red lights). This was actually quite a big Zigbee2mqtt bug which was not only affecting this device (!!).
Changes are available in the latest zigbee2mqtt dev branch.
Koenkk
on 10 Mar 2020
Just a quick update to say that I've had intermittent issues all day and out of sheer curiosity I unplugged the CC26X2R1 from the USB port, and then plugged it back in.
Everything seems to be working fine again, but I'm going to see how it goes through the evening. I've been taking screenshots of the sensor history to show how it's been behaving, which I'll upload when I'm happy (or not!) that they're behaving properly.
Thinking out loud - Could this be some sort of memory leak in the on board memory of the device?
mf-social
on 10 Mar 2020
@mf-social I don't think the issue is on the CC26x2R1 side, when replugging, Zigbee2mqtt is also restarted which actually is a workaround for point 2 of https://github.com/Koenkk/zigbee2mqtt/issues/2693#issuecomment-597271715 (which I believe is the (biggest) cause of this issue). Anyway, this has been fixed now in the latest dev branch.
Koenkk
on 10 Mar 2020
I got distracted half way through typing that, and during my distraction you posted the above. So I guess that replugging the USB is just rediscovering the routes, which fixes the problem?
I'm using the homeassistant addon so I'll have to wait for the fix to filter through. I'll update the firmware tomorrow though :slightly_smiling_face:
mf-social
on 10 Mar 2020
Hi @Koenkk My hue motion sensors keep dropping. I am running z2m 1.11.0 (commit 31e5678). Using cc1352-p2 coordinator with firmware 20200229.
And I found a weird thing; let me try to explain:
- I have 2 ZB networks, both supported by a cc1352-p2 coordinator, running z2m and firmware as above. One network support 100 devices (with load of routers) and the other around 60 devices (with load of routers too).
- both have permit_join to false, one on channel 11 the other on channel 20, each with a different pan_id BUT the same network key.
- some of the motion when dropping connect to the other zb network (they have always been on the same network and never joined the other)
- Those are extracts of the devices.yaml:
'0x0017880104b63528': friendly_name: HueMotionPP1 '0x0017880104b6d8d7': friendly_name: HueMotionBano '0x0017880104b52717': friendly_name: HueMotionDormitorio '0x0017880104b5a7c7': friendly_name: HueMotionEscalera2
'0x0017880104b63528': friendly_name: '0x0017880104b63528' '0x0017880104b6d8d7': friendly_name: '0x0017880104b6d8d7' '0x0017880104b52717': friendly_name: '0x0017880104b52717' '0x0017880104b5a7c7': friendly_name: '0x0017880104b5a7c7'
This is an extract of both database.db:
{"id":96,"type":"EndDevice","ieeeAddr":"0x0017880104b52717","nwkAddr":43921,"manufId":4107,"manufName":"Philips","powerSource":"Battery","modelId":"SML001","epList":[1,2],"endpoints":{"1":{"profId":49246,"epId":1,"devId":2128,"inClusterList":[0],"outClusterList":[0,3,4,6,8,768,5],"clusters":{"genBasic":{"attributes":{"modelId":"SML001","manufacturerName":"Philips","powerSource":3,"zclVersion":1,"appVersion":2,"stackVersion":1,"hwVersion":1,"dateCode":"20190219","swBuildId":"6.1.1.27575"}}},"binds":[]},"2":{"profId":260,"epId":2,"devId":263,"inClusterList":[0,1,3,1030,1024,1026],"outClusterList":[25],"clusters":{"genPowerCfg":{"attributes":{"batteryPercentageRemaining":200}},"msOccupancySensing":{"attributes":{"occupancy":0}},"msTemperatureMeasurement":{"attributes":{"measuredValue":1992}},"msIlluminanceMeasurement":{"attributes":{"measuredValue":7236}}},"binds":[{"cluster":1,"type":"endpoint","deviceIeeeAddress":"0x00124b001ca6049b","endpointID":1},{"cluster":1024,"type":"endpoint","deviceIeeeAddress":"0x00124b001ca6049b","endpointID":1},{"cluster":1026,"type":"endpoint","deviceIeeeAddress":"0x00124b001ca6049b","endpointID":1},{"cluster":1030,"type":"endpoint","deviceIeeeAddress":"0x00124b001ca6049b","endpointID":1}]}},"appVersion":2,"stackVersion":1,"hwVersion":1,"dateCode":"20190219","swBuildId":"6.1.1.27575","zclVersion":1,"interviewCompleted":true,"meta":{"configured":1},"lastSeen":1583868099875} {"id":99,"type":"EndDevice","ieeeAddr":"0x0017880104b5a7c7","nwkAddr":39971,"manufId":4107,"manufName":"Philips","powerSource":"Battery","modelId":"SML001","epList":[1,2],"endpoints":{"1":{"profId":49246,"epId":1,"devId":2128,"inClusterList":[0],"outClusterList":[0,3,4,6,8,768,5],"clusters":{"genBasic":{"attributes":{"modelId":"SML001","manufacturerName":"Philips","powerSource":3,"zclVersion":1,"appVersion":2,"stackVersion":1,"hwVersion":1,"dateCode":"20190219","swBuildId":"6.1.1.27575"}}},"binds":[]},"2":{"profId":260,"epId":2,"devId":263,"inClusterList":[0,1,3,1030,1024,1026],"outClusterList":[25],"clusters":{"genPowerCfg":{"attributes":{"batteryPercentageRemaining":200}},"msOccupancySensing":{"attributes":{"occupancy":0}},"msTemperatureMeasurement":{"attributes":{"measuredValue":2363}},"msIlluminanceMeasurement":{"attributes":{"measuredValue":0}}},"binds":[{"cluster":1,"type":"endpoint","deviceIeeeAddress":"0x00124b001ca6049b","endpointID":1},{"cluster":1024,"type":"endpoint","deviceIeeeAddress":"0x00124b001ca6049b","endpointID":1},{"cluster":1026,"type":"endpoint","deviceIeeeAddress":"0x00124b001ca6049b","endpointID":1},{"cluster":1030,"type":"endpoint","deviceIeeeAddress":"0x00124b001ca6049b","endpointID":1}]}},"appVersion":2,"stackVersion":1,"hwVersion":1,"dateCode":"20190219","swBuildId":"6.1.1.27575","zclVersion":1,"interviewCompleted":true,"meta":{"configured":1},"lastSeen":1583867919456}
{"id":52,"type":"EndDevice","ieeeAddr":"0x0017880104b52717","nwkAddr":47680,"manufId":4107,"manufName":"Philips","powerSource":"Battery","modelId":"SML001","epList":[1,2],"endpoints":{"1":{"profId":49246,"epId":1,"devId":2128,"inClusterList":[0],"outClusterList":[0,3,4,6,8,768,5],"clusters":{"genBasic":{"attributes":{"modelId":"SML001","manufacturerName":"Philips","powerSource":3,"zclVersion":1,"appVersion":2,"stackVersion":1,"hwVersion":1,"dateCode":"20190219"}}},"binds":[]},"2":{"epId":2,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[]}},"appVersion":2,"stackVersion":1,"hwVersion":1,"dateCode":"20190219","zclVersion":1,"interviewCompleted":false,"meta":{},"lastSeen":1583754171373}{"id":53,"ieeeAddr":"0x0017880104b5a7c7","nwkAddr":23854,"epList":[],"endpoints":{},"interviewCompleted":false,"meta":{},"lastSeen":1583781361268}
Is this expected because of both networks having the same key?
I understand the interview fail because join is disabled.
I do not understand why the devices try to join a network which is far away from their original one.
Anyway, there is still something wrong with firmware and/or z2m as devices should not drop from the network (2 of the motion sensors are very close to the coordinator).
Let mw know if you require more details. Thanks.
ccorderod
on 10 Mar 2020
Mine also dropped off/shows red led on motion detection, I've found 2 other issues:
- Updated firmware (small change): https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin
- Zigbee2mqtt was sending the default responses to the wrong network address after the motion sensors changed it's network address. This causes the sensor to think it's not connected to the network anymore ending in a reconnect loop (and also causing the red lights). This was actually quite a big Zigbee2mqtt bug which was not only affecting this device (!!).
Changes are available in the latest zigbee2mqtt dev branch.
@Koenkk Apologies. I miss previous posts. Will update firmware and will upgrade to dev.
ccorderod
on 10 Mar 2020
I've added another improvement in the latest dev branch so please also test with that.
Koenkk
on 10 Mar 2020
I have updated the controller and z2m to latest dev release and powered my hue motion sensors again. Will test and update this issue if they drop again or my zigbee networks goes crazy again
pepp86
on 11 Mar 2020
@Koenkk I installed latest dev, but it does not work for me (see #3110). Upgraded to firmware 20200306. Switched to master (1.11.0 commit e140cf5). My network is terribly unstable now.
error 2020-03-11 23:51:41: Failed to read state of 'LuzTorre1' after reconnect
error 2020-03-11 23:51:41: Failed to read state of 'LuzTorre2' after reconnect
error 2020-03-11 23:51:42: Publish 'set' 'state' to 'LuzTechoDespacho3' failed: 'Error: Command 0x00178801041557bf/11 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: SREQ '--> AF - dataRequest - {"dstaddr":22280,"destendpoint":11,"srcendpoint":1,"clusterid":6,"transid":136,"options":0,"radius":30,"len":3,"data":{"type":"Buffer","data":[1,190,0]}}' failed with status '17' (expected '0'))'
error 2020-03-11 23:51:43: Failed to read state of 'LuzTechoPasilloPlanta1' after reconnect
error 2020-03-11 23:51:54: Publish 'set' 'state' to 'LuzMesaDespacho2' failed: 'Error: Command 0x0017880102c5ae2a/11 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Data request failed with error: 'MAC channel access failure' (225))'
error 2020-03-11 23:52:02: Publish 'set' 'state' to 'LuzTechoDespacho3' failed: 'Error: Command 0x00178801041557bf/11 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Data request failed with error: 'No network route' (205))'
error 2020-03-11 23:52:15: Publish 'set' 'state' to 'LuzTechoDespacho1' failed: 'Error: Command 0x0017880104c0fdcd/11 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Timeout - 16020 - 11 - 196 - 6 - 11 after 6000ms)'
error 2020-03-11 23:52:16: Publish 'set' 'state' to 'LuzTorre2' failed: 'Error: Command 0x001788010230af80/11 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Data request failed with error: 'No network route' (205))'
error 2020-03-11 23:52:32: Publish 'set' 'state' to 'LuzTorre2' failed: 'Error: Command 0x001788010230af80/11 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Data request failed with error: 'No network route' (205))'
error 2020-03-11 23:53:01: Failed to ping 'LuzMesaDespacho2'
error 2020-03-11 23:53:02: Failed to ping 'LuzLavaboBanoJuan3'
error 2020-03-11 23:53:22: Failed to ping 'LuzLavaboBanoJuan1'
error 2020-03-11 23:53:26: Publish 'set' 'state' to 'LuzTorre2' failed: 'Error: Command 0x001788010230af80/11 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Data request failed with error: 'No network route' (205))'
error 2020-03-11 23:53:31: Failed to ping 'LuzRoperoDJ1'
error 2020-03-11 23:53:37: Failed to ping 'LuzTorre2'
error 2020-03-11 23:53:47: Failed to ping 'LuzTechoDespacho3'
error 2020-03-11 23:53:48: Failed to ping 'LuzTorre1'
error 2020-03-11 23:54:14: Publish 'set' 'state' to 'LuzTorre1' failed: 'Error: Command 0x001788010372c624/11 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Data request failed with error: 'No network route' (205))'
error 2020-03-11 23:54:17: Publish 'set' 'state' to 'LuzTechoBanoDespacho' failed: 'Error: Command 0x90fd9ffffe292303/1 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Timeout - 54444 - 1 - 23 - 6 - 11 after 6000ms)'
error 2020-03-11 23:54:28: Publish 'set' 'state' to 'LuzTorre1' failed: 'Error: Command 0x001788010372c624/11 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Data request failed with error: 'No network route' (205))'
error 2020-03-11 23:54:36: Failed to ping 'LuzTechoBanoDespacho'
error 2020-03-11 23:54:53: Failed to ping 'LuzMesaDespacho1'
error 2020-03-11 23:54:56: Failed to ping 'LuzMesaMamaDP'
error 2020-03-11 23:55:29: Publish 'set' 'state' to 'LuzRoperoDespacho' failed: 'Error: Command 0x90fd9ffffe298e81/1 genOnOff.on({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Data request failed with error: 'MAC channel access failure' (225))'
error 2020-03-11 23:55:56: Failed to ping 'LuzTorre1'
error 2020-03-11 23:56:01: Publish 'set' 'state' to 'LuzTechoDespacho1' failed: 'Error: Command 0x0017880104c0fdcd/11 genOnOff.on({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Timeout - 16020 - 11 - 74 - 6 - 11 after 6000ms)'
error 2020-03-11 23:56:04: Failed to read state of 'LuzTechoDespacho3' after reconnect
error 2020-03-11 23:56:20: Failed to read state of 'LuzTorre2' after reconnect
error 2020-03-11 23:56:29: Failed to ping 'LuzDerLavaboBanoDespacho'
error 2020-03-11 23:57:24: Failed to ping 'LuzMesaDespacho2'
error 2020-03-11 23:57:27: Failed to read state of 'HuePlay2' after reconnect
error 2020-03-11 23:58:16: Failed to ping 'LuzRoperoDJ1'
error 2020-03-11 23:58:25: Failed to ping 'LuzTechoSaladeEstar'
error 2020-03-11 23:58:49: Publish 'set' 'state' to 'g-lucesvestidor' failed: 'Error: Command 2 genLevelCtrl.moveToLevelWithOnOff({"level":0,"transtime":0}) failed (Error: Data request failed with error: 'MAC channel access failure' (225))'
error 2020-03-11 23:59:36: Failed to ping 'HuePlay2'
error 2020-03-11 23:59:55: Failed to read state of 'LuzTorre1' after reconnect
error 2020-03-12 00:00:14: Publish 'set' 'state' to 'LuzTechoPasilloPlanta1' failed: 'Error: Command 0x90fd9ffffe29d372/1 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Data request failed with error: 'MAC channel access failure' (225))'
error 2020-03-12 00:02:18: Failed to read state of 'HuePlay2' after reconnect
error 2020-03-12 00:03:50: Failed to ping 'LuzTechoDespacho1'
error 2020-03-12 00:05:13: Failed to ping 'LuzTechoBanoPrincipal2'
zigbee2mqtt:error 2020-03-12 00:05:13: Failed to ping 'LuzTechoBanoPrincipal2'
(node:1049) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 85)
(node:1049) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 84)
(node:1049) UnhandledPromiseRejectionWarning: Error: Timeout - 22650 - 1 - 112 - 0 - 1 after 6000ms
at Timeout._onTimeout (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)
at listOnTimeout (internal/timers.js:549:17)
at processTimers (internal/timers.js:492:7)
(node:1049) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag--unhandled-rejections=strict(see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 86)
(node:1049) UnhandledPromiseRejectionWarning: Error: Timeout - 14048 - 1 - 114 - 0 - 1 after 6000ms
at Timeout._onTimeout (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)
at listOnTimeout (internal/timers.js:549:17)
at processTimers (internal/timers.js:492:7)
(node:1049) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag--unhandled-rejections=strict(see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 87)
(node:1049) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 86)
(node:1049) UnhandledPromiseRejectionWarning: Error: Timeout - 22280 - 11 - 120 - 0 - 1 after 6000ms
at Timeout._onTimeout (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)
at listOnTimeout (internal/timers.js:549:17)
at processTimers (internal/timers.js:492:7)
(node:1049) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag--unhandled-rejections=strict(see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 88)
(node:1049) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 88)
(node:1049) UnhandledPromiseRejectionWarning: Error: Timeout - 48532 - 11 - 121 - 0 - 1 after 6000ms
at Timeout._onTimeout (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)
at listOnTimeout (internal/timers.js:549:17)
at processTimers (internal/timers.js:492:7)
(node:1049) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag--unhandled-rejections=strict(see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 89)
(node:1049) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 89)
zigbee2mqtt:error 2020-03-12 00:06:42: Failed to ping 'HuePlay2'
(node:1049) UnhandledPromiseRejectionWarning: Error: Timeout - 11500 - 1 - 123 - 0 - 1 after 6000ms
at Timeout._onTimeout (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)
at listOnTimeout (internal/timers.js:549:17)
at processTimers (internal/timers.js:492:7)
(node:1049) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag--unhandled-rejections=strict(see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 90)
(node:1049) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 90)
zigbee2mqtt:error 2020-03-12 00:06:53: Failed to ping 'LuzDerLavaboBanoDespacho'
(node:1049) UnhandledPromiseRejectionWarning: Error: Timeout - 11500 - 1 - 123 - 0 - 1 after 6000ms
at Timeout._onTimeout (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)
at listOnTimeout (internal/timers.js:549:17)
at processTimers (internal/timers.js:492:7)
(node:1049) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag--unhandled-rejections=strict(see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 91)
zigbee2mqtt:error 2020-03-12 00:06:55: Failed to ping 'LuzRoperoDespacho'
(node:1049) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 91)
ccorderod
on 12 Mar 2020
This update will be in the 1.12.0 release? As my network is stable on the 1.7.0 version except the Hue motion giving me the red finger...
trekker25
on 12 Mar 2020
@ccorderod when reflashing did you make sure that you executed step 5 of: https://www.zigbee2mqtt.io/information/flashing_via_uniflash.html?
@trekker25 it will be part of 1.12.0
Koenkk
on 12 Mar 2020
Yes @Koenkk . I always follow the guide when flashing. All steps with no warnings. Do you think I should reflash?
ccorderod
on 12 Mar 2020
@ccorderod yes, lets try that, looks like some issue at the adapter side.
Koenkk
on 12 Mar 2020
I assume it’s a routing problem. I have 3 hue motion. And 2 disconnect and are quit far away of usb module. And one never disconnects and is really short to usb module and has a direct connection.
trekker25
on 12 Mar 2020
@Koenkk Just to be on the safe side, I downloaded the firmware again, then reflashed. Upgraded to 1.11.0-dev commit 97a4b6b. Network is stable again. Let's see if the hue motion sensors do not drop now. May I ask you how did you figure out it was an adapter issue? Txs.
ccorderod
on 12 Mar 2020
@ccorderod the errors shown were timeouts coming from the adapter (e.g. Error: Timeout - 14048 - 1 - 114 - 0 - 1 after 6000ms)
Koenkk
on 12 Mar 2020
Understood. Thank you @Koenkk
ccorderod
on 12 Mar 2020
One of my hue motion sensor dropped again (and created a lot of trouble again in my network - did not had a chance to sniff the traffic as my lights where not working properly and my wife was not amused...) Looks as it is sending lots of data when it drops... Red light was flashing at motion.
The other one dropped, but came back.
So I am ending the hue motion sensor adventure now as it took my woman acceptance factor nearly to zero....
pepp86
on 16 Mar 2020
I've added another improvement in the latest dev branch so please also test with that.
Since this I've only got once temporary disconnect, it restored automatically after that and seems to works stable now.
Note that with Zigbee2mqtt 1.12.0-dev you can also OTA update this device (https://www.zigbee2mqtt.io/information/ota_updates.html), before the update mine was on "dateCode":"20180828","swBuildId":"6.1.0.25261" now on {"softwareBuildID":"6.1.1.27575","dateCode":"20190219"}.
Koenkk
on 18 Mar 2020
I tested again with latest z2m dev release and latest CC2652 dev firmware.
Firmware Update of hue motion sensor went well (took 30-40 minutes) and after that the motion sensor was working for 10 minutes. After that, it was completely silence again (flashing red light when motion was detected, but only announcing itself - no data in z2m logs.
debug 2020-03-19 07:38:57: Received Zigbee message from '0x0017880106f731c9', type 'attributeReport', cluster 'msIlluminanceMeasurement', data '{"measuredValue":16244}' from endpoint 2 with groupID 0
info 2020-03-19 07:38:57: MQTT publish: topic 'zigbee2mqtt_DE/0x0017880106f731c9', payload '{"battery":43.5,"linkquality":9,"last_seen":"2020-03-19T07:38:57+01:00","occupancy":false,"temperature":22.24,"illuminance":16244,"illuminance_lux":41,"update_available":false,"elapsed":297957,"device":{"friendlyName":"0x0017880106f731c9","model":"9290012607","ieeeAddr":"0x0017880106f731c9","networkAddress":47498,"type":"EndDevice","manufacturerID":4107,"manufacturerName":"Philips","powerSource":"Battery","applicationVersion":2,"stackVersion":1,"zclVersion":1,"hardwareVersion":1,"dateCode":"20190219","softwareBuildID":"6.1.1.27575"}}'
debug 2020-03-19 07:39:25: Device '0x0017880106f731c9' announced itself
info 2020-03-19 07:39:25: MQTT publish: topic 'zigbee2mqtt_DE/bridge/log', payload '{"type":"device_announced","message":"announce","meta":{"friendly_name":"0x0017880106f731c9"}}'
debug 2020-03-19 07:41:44: Device '0x0017880106f731c9' announced itself
info 2020-03-19 07:41:44: MQTT publish: topic 'zigbee2mqtt_DE/bridge/log', payload '{"type":"device_announced","message":"announce","meta":{"friendly_name":"0x0017880106f731c9"}}'
debug 2020-03-19 07:42:53: Device '0x0017880106f731c9' announced itself
info 2020-03-19 07:42:53: MQTT publish: topic 'zigbee2mqtt_DE/bridge/log', payload '{"type":"device_announced","message":"announce","meta":{"friendly_name":"0x0017880106f731c9"}}'
debug 2020-03-19 07:38:57: Received Zigbee message from '0x0017880106f731c9', type 'attributeReport', cluster 'msIlluminanceMeasurement', data '{"measuredValue":16244}' from endpoint 2 with groupID 0
info 2020-03-19 07:38:57: MQTT publish: topic 'zigbee2mqtt_DE/0x0017880106f731c9', payload '{"battery":43.5,"linkquality":9,"last_seen":"2020-03-19T07:38:57+01:00","occupancy":false,"temperature":22.24,"illuminance":16244,"illuminance_lux":41,"update_available":false,"elapsed":297957,"device":{"friendlyName":"0x0017880106f731c9","model":"9290012607","ieeeAddr":"0x0017880106f731c9","networkAddress":47498,"type":"EndDevice","manufacturerID":4107,"manufacturerName":"Philips","powerSource":"Battery","applicationVersion":2,"stackVersion":1,"zclVersion":1,"hardwareVersion":1,"dateCode":"20190219","softwareBuildID":"6.1.1.27575"}}'
debug 2020-03-19 07:39:25: Device '0x0017880106f731c9' announced itself
info 2020-03-19 07:39:25: MQTT publish: topic 'zigbee2mqtt_DE/bridge/log', payload '{"type":"device_announced","message":"announce","meta":{"friendly_name":"0x0017880106f731c9"}}'
debug 2020-03-19 07:41:44: Device '0x0017880106f731c9' announced itself
info 2020-03-19 07:41:44: MQTT publish: topic 'zigbee2mqtt_DE/bridge/log', payload '{"type":"device_announced","message":"announce","meta":{"friendly_name":"0x0017880106f731c9"}}'
debug 2020-03-19 07:42:53: Device '0x0017880106f731c9' announced itself
info 2020-03-19 07:42:53: MQTT publish: topic 'zigbee2mqtt_DE/bridge/log', payload '{"type":"device_announced","message":"announce","meta":{"friendly_name":"0x0017880106f731c9"}}'
pepp86
on 19 Mar 2020
@pepp86 please sniff the traffic when this happens (https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html)
Koenkk
on 19 Mar 2020
Hi @Koenkk. I setup everything for sniffing now and I can see data from my network. At the moment I power up the hue motion sensor I can see a lot of more traffic happening (my network has more than 30 devices, so normal level is even a lot of communication). What I don't see is, what you exactly need to investigate further. I don't have a clue how to filter in wireshark for example.
pepp86
on 19 Mar 2020
Don't worry about the filtering, if you have a sniff send it to me on telegram (@koenkk).
Koenkk
on 19 Mar 2020
@Koenkk Update: I upgraded both ZB networks to z2m 1.12.0-dev commit a7e38b6 as well as cc2652-p2 coordinators to firmware dev 20200312
Hue motion keep dropping :(. Sometimes they get back in again, sometimes they don't.
I also found a weird thing: my ZB networks have different channels and different panids, BUT the same network key. Sometimes, a sensor drop from ZB network 1 and move to ZB network 2 (permit_join is false always). So, I went to edit configuration.yaml files to ban ALL the addresses of the other ZB network, to avoid this weird effect.
Believe it or not, it does not work!. Sensors still move from one network to the other from time to time.
So, I need some advise now: I have in total 3 ZB networks, 2 z2m using cc2652-p2 as coordinators, and the third with a hue bridge. You can guess it is a pain to manage all this stuff even under HA.
In total, I should have 250+ devices (most of them are hue and ikea lights hence routers). Should I try to move ALL of them to only one ZB network? (please note this is going to be a painful task). Do you think z2m with cc2552-p2 will be able to handle such a massive network? Thank you
ccorderod
on 29 Mar 2020
250 devices is a lot, I have no clue tbh it has never been tested.
I would recommend to use a different network_key for every instance to avoid them hopping.
Koenkk
on 29 Mar 2020
Same here!
But I'm on a coordinator CC1352P-2
Stack3x0"evision":20191106
Is it enough to try the HomeAssistant edge version or do i need a newer one?
upwindanderl
on 29 Mar 2020
@Koenkk I sent to your discord account a couple of pcapng files. Hopefuly they will help with the hue motion sensor drop issue.
ccorderod
on 1 Apr 2020
250 devices is a lot, I have no clue tbh it has never been tested.
I would recommend to use a different network_key for every instance to avoid them hopping.
But I do not understand why they hopp to the other network; the ban directive should prohibit that, right?
ccorderod
on 1 Apr 2020
@ccorderod zigbee has no ban mechanism, what we basically do is remove the device from the network when it connects, but this doesn't prevent the hop.
Koenkk
on 1 Apr 2020
shame on me ... you are absolutely right!.
ccorderod
on 1 Apr 2020
don't what changed, but suddenly no more red lights from the Hue sensor. Docker container still running for 2 months and suddenly it doesn't disconnect any more. I'm still on a old Nov 2019 release.
So i just keep it running until problems arrive!
trekker25
on 2 Apr 2020
Have the same issue too.
Just tried to remove the device and re pair it.
got an error :
debug 2020-04-06 19:37:25: Received Zigbee message from '0x0017880106471ee8', type 'readResponse', cluster 'genBasic', data '{"modelId":"SML002","manufacturerName":"Philips"}' from endpoint 1 with groupID 0
debug 2020-04-06 19:37:25: No converter available for '9290019758' with cluster 'genBasic' and type 'readResponse' and data '{"modelId":"SML002","manufacturerName":"Philips"}'
debug 2020-04-06 19:37:25: Received Zigbee message from '0x0017880106471ee8', type 'readResponse', cluster 'genBasic', data '{"powerSource":3,"zclVersion":1}' from endpoint 1 with groupID 0
debug 2020-04-06 19:37:25: No converter available for '9290019758' with cluster 'genBasic' and type 'readResponse' and data '{"powerSource":3,"zclVersion":1}'
debug 2020-04-06 19:37:26: Received Zigbee message from '0x0017880106471ee8', type 'readResponse', cluster 'genBasic', data '{"appVersion":2,"stackVersion":1}' from endpoint 1 with groupID 0
debug 2020-04-06 19:37:26: No converter available for '9290019758' with cluster 'genBasic' and type 'readResponse' and data '{"appVersion":2,"stackVersion":1}'
debug 2020-04-06 19:37:26: Received Zigbee message from '0x0017880106471ee8', type 'readResponse', cluster 'genBasic', data '{"hwVersion":1,"dateCode":"20190219"}' from endpoint 1 with groupID 0
debug 2020-04-06 19:37:26: No converter available for '9290019758' with cluster 'genBasic' and type 'readResponse' and data '{"hwVersion":1,"dateCode":"20190219"}'
debug 2020-04-06 19:37:27: Received Zigbee message from '0x0017880106471ee8', type 'readResponse', cluster 'genBasic', data '{"swBuildId":"6.1.1.27575"}' from endpoint 1 with groupID 0
debug 2020-04-06 19:37:27: No converter available for '9290019758' with cluster 'genBasic' and type 'readResponse' and data '{"swBuildId":"6.1.1.27575"}'
info 2020-04-06 19:37:27: Successfully interviewed '0x0017880106471ee8', device has successfully been paired
info 2020-04-06 19:37:27: Device '0x0017880106471ee8' is supported, identified as: Philips Hue motion outdoor sensor (9290019758)
info 2020-04-06 19:37:27: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"interview_successful","meta":{"friendly_name":"0x0017880106471ee8","model":"9290019758","vendor":"Philips","description":"Hue motion outdoor sensor","supported":true}}'
info 2020-04-06 19:37:27: Configuring '0x0017880106471ee8'
debug 2020-04-06 19:37:41: Device '0x0017880106471ee8' announced itself
info 2020-04-06 19:37:41: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"device_announced","message":"announce","meta":{"friendly_name":"0x0017880106471ee8"}}'
error 2020-04-06 19:37:44: Failed to configure '0x0017880106471ee8', attempt 1 (Error: ConfigureReporting 0x0017880106471ee8/2 msOccupancySensing([{"attribute":"occupancy","minimumReportInterval":0,"maximumReportInterval":3600,"reportableChange":0}], {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":true}) failed (Error: AREQ - AF - dataConfirm after 5000ms)
at Endpoint.<anonymous> (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:316:23)
at Generator.throw (<anonymous>)
at rejected (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:6:65))
running
{"version":"1.12.0-dev","commit":"d73bcf3","coordinator":{"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20191106}},"log_level":"debug","permit_join":true}
on a CC26X2R1 with "CC26X2R1_20191106" firmware
toremick
on 6 Apr 2020
I have the same issue. Running with zStack3x0 20191106 and zigbee2mqtt 1.10 (I think). After upgrading to 20200312 and 1.12.2 I got the same within a few hours.
Since the upgrade other sensors or bulbs are very slow. It take seconds from walking in a room till the light goes on. Not sure if this is related to Zigbee or some other software like HA/NodeRed. Just figuring out...
choeflake
on 13 Apr 2020
I'm surprised by the recent additions to this thread. Since updating the firmware and the homeassistant addon update to 1.12+ I've not had a single drop out.
/me knocks on wood and crosses fingers!
mf-social
on 13 Apr 2020
Please try with the 20200328 firmware: https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin (and make sure you are on zigbee2mqtt 1.12.2)
Since running this firmware I didn't have any dropouts anymore for 2 weeks. I've seen the red light flash once, but this didn't cause any further issues. Occupancy was still detected and after the next occupancy detection it didn't show a red light anymore.
Koenkk
on 13 Apr 2020
I flashed both coordinators with 20200328 a few days ago. Both networks are running with their own network key; motion sensor are no more hoping from one network to the other. I moved all the rest of devices from the hue bridge to one of the networks, hence I do have now only 2 ZB networks, on channel 20 and 25 running on Z2M 1.12.2-dev commit 7824f10.
Some of the hue sensors show red light flashing from time to time but seem to detect motion.
FYI, one of the network support 114 devices and the other around 100. Both have been stable for the last couple of days.
One more thing: availability is on (60 seconds). From time to time some of the routers (lights, ikea and philips) do not answer the ping and show unavailable in home assistant, but this last only for a minute as they use to reply the next ping.
@Koenkk let me know if you need me to log anything on any of the networks, as I think there is a lot to learn on such a big setup :-).
Thanks for your hard work,
ccorderod
on 13 Apr 2020
Please try with the
20200328firmware: https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin (and make sure you are on zigbee2mqtt 1.12.2)Since running this firmware I didn't have any dropouts anymore for 2 weeks. I've seen the red light flash once, but this didn't cause any further issues. Occupancy was still detected and after the next occupancy detection it didn't show a red light anymore.
will i need to do anything else with the philips sensor? re-pair?
toremick
on 14 Apr 2020
@ccorderod ping can fail for many reason but I guess its some temporary connection issue. I think we should only make the device as offline when pail fails for e.g. 3 times, a downside for this is that it takes longer for a device to be marked offline
@toremick no thats not needed
Koenkk
on 14 Apr 2020
I updated my CC2652R1 controller with 20200328 firmware, I had to re-pair two out of three Hue motion sensors as they left the network a few days ago, will let you know in a few days if this FW is fixing the issue for me too.
Fabiancrg
on 17 Apr 2020
I've released a new firmware (because a new version of TI sdk has been released), more info; https://github.com/Koenkk/zigbee2mqtt/issues/1429#issuecomment-615329408
Koenkk
on 17 Apr 2020
I updated my coordinator with this new release, will let you know in a few days how it goes.
Fabiancrg
on 17 Apr 2020
Also updated to 20200417, still monitoring...
choeflake
on 17 Apr 2020
I've bought Hue motion sensor 9290019758 and it keeps disconnecting. I've read up on this thread and was wondering:
Any chance this will run on a CC2531 controller. I'm running:
- Version of Zigbee2Mqtt: 1.12.2
- Coordinator version: 20190608 on CC2531
Kind regards,
Bas
basmeerman
on 19 Apr 2020
I had several like that on a CC2531 and they were working fine but you might have to use the source routing firmware CC2531_SOURCE_ROUTING_20190619.zip
Fabiancrg
on 19 Apr 2020
I am having dreadful difficulties with a HUE motion sensor Model 9290012607 (other devices work fine):
Coordinator : '{"type":"zStack12","meta":{"transportrev":2,"product":0,"majorrel":2,"minorrel":6,"maintrel":3,"revision":20190608}
Docker image on an Rpi3 for thh bridge: { "version" : "1.12.2", "commit" : "7d27a54", ,,, }
I was able to do an OTA update of the device (took ~ 60 minutes), but the device doesn't send any luminance data and the device seems to sporadically send messages but no message is sent when a motion happens, This is an example of what it sends:
zigbee_1 | zigbee2mqtt:debug 2020-04-19 16:14:19: Received Zigbee message from '0x001788010863c62a', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":0,"manufacturerCode":4107,"imageType":269,"fileVersion":1107323831}' from endpoint 2 with groupID 0
zigbee_1 | zigbee2mqtt:debug 2020-04-19 16:14:19: No converter available for '9290012607' with cluster 'genOta' and type 'commandQueryNextImageRequest' and data '{"fieldControl":0,"manufacturerCode":4107,"imageType":269,"fileVersion":1107323831}'
zigbee_1 | zigbee2mqtt:debug 2020-04-19 16:14:19: Check if update available for '0x001788010863c62a' (SML001)
zigbee_1 | zigbee2mqtt:debug 2020-04-19 16:14:22: Is new image available for '0x001788010863c62a', current '{"fieldControl":0,"manufacturerCode":4107,"imageType":269,"fileVersion":1107323831}', latest meta '{"fileVersion":1107323831,"fileSize":240760,"url":"https://github.com/Koenkk/zigbee-OTA/raw/master/images/Hue/Sensor-ATmega_6.1.1.27575_0012.sbl-ota"}'
zigbee_1 | zigbee2mqtt:debug 2020-04-19 16:14:22: Update available for '0x001788010863c62a': NO
zigbee_1 | zigbee2mqtt:info 2020-04-19 16:14:22: MQTT publish: topic 'zigbee2mqtt/0x001788010863c62a', payload '{"battery":100,"linkquality":52,"update_available":false,"occupancy":true,"temperature":23.96,"illuminance":0,"illuminance_lux":0}'
zigbee_1 | zigbee2mqtt:debug 2020-04-19 16:14:29: Received Zigbee message from '0x001788010863c62a', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":0,"manufacturerCode":4107,"imageType":269,"fileVersion":1107323831}' from endpoint 2 with groupID 0
zigbee_1 | zigbee2mqtt:debug 2020-04-19 16:14:29: No converter available for '9290012607' with cluster 'genOta' and type 'commandQueryNextImageRequest' and data '{"fieldControl":0,"manufacturerCode":4107,"imageType":269,"fileVersion":1107323831}'
zigbee_1 | zigbee2mqtt:debug 2020-04-19 16:14:39: Received Zigbee message from '0x001788010863c62a', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":0,"manufacturerCode":4107,"imageType":269,"fileVersion":1107323831}' from endpoint 2 with groupID 0
zigbee_1 | zigbee2mqtt:debug 2020-04-19 16:14:39: No converter available for '9290012607' with cluster 'genOta' and type 'commandQueryNextImageRequest' and data '{"fieldControl":0,"manufacturerCode":4107,"imageType":269,"fileVersion":1107323831}'
zigbee_1 | zigbee2mqtt:debug 2020-04-19 16:14:49: Received Zigbee message from '0x001788010863c62a', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":0,"manufacturerCode":4107,"imageType":269,"fileVersion":1107323831}' from endpoint 2 with groupID 0
zigbee_1 | zigbee2mqtt:debug 2020-04-19 16:14:49: No converter available for '9290012607' with cluster 'genOta' and type 'commandQueryNextImageRequest' and data '{"fieldControl":0,"manufacturerCode":4107,"imageType":269,"fileVersion":1107323831}'
zigbee_1 | zigbee2mqtt:debug 2020-04-19 16:14:59: Received Zigbee message from '0x001788010863c62a', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":0,"manufacturerCode":4107,"imageType":269,"fileVersion":1107323831}' from endpoint 2 with groupID 0
zigbee_1 | zigbee2mqtt:debug 2020-04-19 16:14:59: No converter available for '9290012607' with cluster 'genOta' and type 'commandQueryNextImageRequest' and data '{"fieldControl":0,"manufacturerCode":4107,"imageType":269,"fileVersion":1107323831}'
Any ideas what is possibly going wrong?
Kind regards and many thanks for this fantastic project!
Stephan
stepgilb
on 19 Apr 2020
@stepgilb For me, when I was using the CC2531 coordinator, the source routing firmware was the only one working with my Hue outdoor motion sensors (CC2531_SOURCE_ROUTING_20190619.zip).
I had the same issue with the illumination not being reported but it was fixed after the FW upgrade of the sensor. So maybe the indoor and outdoor sensors are very similar and it might help you do do the same (upgrade CC2531 + remove and add the motion sensor).
Fabiancrg
on 20 Apr 2020
Ok I made the leap to CC2652R1 and It joins the Hue sensors. Running the latest dev branch and latest firmware on the CC2652R1.
I'm living in a house build with solid concrete walls, floors and ceilings and over time used the following setups:
a) single coordinator, 5 routers spread across the house (CC2531s). That got me stability issues with 80+ zigbee devices
b) last year I've been running multiple coordinators (z2m instances) on RPI0 with CC2531 and no routers. Been stable until now. Ocassionaly I had to upgrade the RPI0's and the SD cards ran defect. Last week I bought the Hue Motion sensors and couldn't get them paired.
Decided to move on to:
c) I've moved on to a CC2652R1 Launch board yesterday evening. Removed all CC2531 routers and installed Ikea Tradfri Plugs (4). Migrated all sensors.
All is running stable the last 12 hours and seem to respond faster. The Zigbee network is more stable now than in scenario A.
Thanks all for pointing me to the new firmware and versions of z2m.
Kind regards.
Bas
basmeerman
on 22 Apr 2020
Unfortunately, the Hue outdoor motion sensor is unresponsive again with latest firmware on CC2652R1, latest Hue motion firmware and latest z2m dev branch 😢 I paired it again after the latest CC firmware update since it keeps disappearing. It ran for about 1.5 day...
peterforeman
on 22 Apr 2020
On my side my three Hue motion sensors are up for nearly six days.
Only issue I see, one of the sensor did not repport any data (temp and illumination) during two hours but I went in front of it and it reported the motion, after that started to report again the temp and illumination.
Fabiancrg
on 22 Apr 2020
I also noticed this behaviour with my Philips Hue Motion Sensor:
- Red light appears
- No detection
I updated my cc2531 to source-routing-firmware and updated also my zigbee2mqtt to the latest version - no difference. Removed and paired 10 times, no difference.
BUT what helped was to trigger the second button on the Hue Motion Sensor... it's marked with a little "T" and can also be pressed with a needle or similar, only visible if you remove the battery cover. I haven't found a documentation that clearly explains the function of this "T"-Button, but as soon as I pressed it, the sensor flashed red.
I removed the sensor from zigbee2mqtt, held the setup-Button 10 seconds and voilà : It appears and sends everything perfectly.
I have no clue what this "T"-Button does... but maybe it helps you too?
MyNameIsRatchet
on 28 Apr 2020
@MyNameIsRatchet Thank you, that worked for me, too. Finally! I thought it was because I had too many devices (~22), and I already bought a cc1352 (but can't use it yet). I'm wondering though why the sensor was disconnected in the first place, and whether this will happen again.
markuspeter
on 28 Apr 2020
It worked for three days until the sensor decided to freeze and now it shows the same behaviour as before.
This is really annoying... nobody knows how to fix it?
MyNameIsRatchet
on 1 May 2020
I reflashed my CC1352P-2 roughly 14 days ago and from there I have no problems anymore. Just sometimes the red light flashing issue, but motion is triggered well.
Directly after flashing the new firmware I had to re-pair two of my three sensors to make them available again. Until now no sensor got lost and the connection was reliable....
MrLight
on 1 May 2020
Which firmware did you use? 1.2/3.0 and basic/source routing?
MyNameIsRatchet
on 1 May 2020
see the following two comments. I'm using Z-Stack 3.0 with the latest zigbee2mqtt release (no dev)
https://github.com/Koenkk/zigbee2mqtt/issues/2693#issuecomment-612957791
https://github.com/Koenkk/zigbee2mqtt/issues/1429#issuecomment-615329408
MrLight
on 1 May 2020
I upgraded to the latest coordinator FW on my CC2652 with Zstack 3.0 14 days ago.
Since, two out of three Hue motion sensors are working fine, the third is giving me some issues.
Two days ago it was again not reporting anything so I decided to remove it from Z2M and paired it agian, this time I pressed also the switch 'T' near the battery. It's OK for two days, let's see if this will continue to work.
Fabiancrg
on 1 May 2020
Unfortunately, the motion sensor is still disappearing with the latest firmware. I changed the network_key and channel (25) and repaired all devices (including the motion sensor) which went fine. After 3 days the motion sensor was gone again.
This is really getting annoying now. Any ideas where to look / debug etc.?
peterforeman
on 27 May 2020
@peterforeman On my side, it's stable since the 3rd of May, no disconnection anymore.
Can I ask you which version of Z2M and FW you are running ?
On my side I am running Z2M 1.13.1 (dev) and Firmware 20200417 on CC2652 board.
Fabiancrg
on 27 May 2020
Also 1.13.1-dev (commit #49df575) with 20200417 on a CC1352 board.
device:{"model":"9290012607","type":"EndDevice","manufacturerID":4107,"manufacturerName":"Philips","powerSource":"Battery","applicationVersion":2,"stackVersion":1,"zclVersion":1,"hardwareVersion":1,"dateCode":"20190219","softwareBuildID":"6.1.1.27575"}
I checked logs and saw some messages about every 30 minutes without movement. It stopped working when someone was in the room and it sensing continuous movement for some minutes. Different messages with occupancy true/false/true/false etc. Last message was occupancy: true. Then it went silent.
peterforeman
on 27 May 2020
I had comparable problems.
Zigbee2mqtt Version 1.12.2 with 20200328 Firmware.
I had a lot of disappearing motion sensors in the past. The update to the actual (not latest) firmware gave me a huge improvement. Normally the sensors are not disappearing. I can confirm that the sensor is always failing with occupancy:true when it is disappearing.
I had another observation: I could always repair the sensor without pressing the pairing button. I just had to activate that devices "can join the network". After a few hours the sensor was back in operation.
All my problems are linked with a power-cycle of the cc1352p-2 board. But it it took up to a day that the problem occurred. After the sensor was paired again it was stable. It was always only one sensor affected. (but different ones over time)
Can anyone confirm that you can force the problem by repowering the cc1352?
MrLight
on 27 May 2020
Did anyone find a solution or work around for this problem?
Martinmlarsen
on 4 Jul 2020
I haven't had this problem for a long time with the latest firmware.
mf-social
on 4 Jul 2020
I haven't had this problem for a long time with the latest firmware.
Same here!
choeflake
on 4 Jul 2020
@mf-social @choeflake Lucky you! :-)
Latest firmware (P2 stick) has been a big improvement ... but did not fix the problem. I have 2 ZB networks managing together over 200 devices (@Koenkk told this was going to be too big to managed in only one network). They work on channels 20 and 25, each with a different pan-id and their own network key. Sticks are attached to a pi4 and cabled to the home ethernet network.
Both sticks crash after a few days of operation; z2m keeps running but no zb messages are received/sent. Only rebooting the pi fix the issue (stopping and starting z2m does not). My feeling is the stick gets corrupted and usb communication stop working. When I restart one network, some of the hue motion sensors (i have a bunch) try to connect to the other one ... fail to do so but do not reconnect to their own network unless forced to do so (reset button to repair). This happen also from time to time even when both networks are running (because the hue motion sensors keep disconnecting by themselves and try to connect to the other network).
ZB networks are by far the weakest point of my HA setup, as most of the sensors are "critical" (motion, doors, windows, water leak, vibration and metering).
If I have the time (and courage), I will give a try with ZHA (metering is not supported as of today), but honestly I think the problem is on the firmware, not on z2m software, hence unless I setup ZHA running on xbee or conbee I will probably run into the same problem.
ccorderod
on 4 Jul 2020
This is getting worst :-(. Pi4 was rebooted at 3am today, and just crashed.
Debug Log when starting Z2M (after waiting for long a systemctl stop zigbee2mqtt):
`> [email protected] start /opt/zigbee2mqtt
node index.js
[32mzigbee2mqtt:info [39m 2020-07-04 13:22:23: Logging to console and directory: 'data/log/2020-07-04.13-22-23' filename: log.txt
[32mzigbee2mqtt:info [39m 2020-07-04 13:22:24: Starting zigbee2mqtt version 1.14.0-dev (commit #95208a1)
[32mzigbee2mqtt:info [39m 2020-07-04 13:22:24: Starting zigbee-herdsman...
2020-07-04T11:22:24.643Z zigbee-herdsman:controller:log Starting with options '{"network":{"networkKeyDistribute":false,"networkKey":[1,2,3,4,5,6,7,8,9,0,1,2,3],"panID":666,"extendedPanID":[2,2,2,2,2,2,2,2],"channelList":[25]},"serialPort":{"baudRate":115200,"rtscts":true,"path":"/dev/ttyACM0"},"databasePath":"/opt/zigbee2mqtt/data/database.db","databaseBackupPath":"/opt/zigbee2mqtt/data/database.db.backup","backupPath":"/opt/zigbee2mqtt/data/coordinator_backup.json","adapter":{"concurrent":null}}'
[31mzigbee2mqtt:error[39m 2020-07-04 13:22:31: Error while starting zigbee-herdsman
[31mzigbee2mqtt:error[39m 2020-07-04 13:22:31: Failed to start zigbee
[31mzigbee2mqtt:error[39m 2020-07-04 13:22:31: Exiting...
[31mzigbee2mqtt:error[39m 2020-07-04 13:22:31: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
at ZStackAdapter.
at Generator.throw (
at rejected (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:6:65)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] start: node index.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2020-07-04T11_22_31_747Z-debug.log
`
Had to reboot the pi as usual.
ccorderod
on 4 Jul 2020
I've recently only took all of my Hue bulbs and motion sensors to Zigbee2MQTT (~70 Bulbs, 4 Motion Sensors and 1 Switch) but I'm experiencing the same issues as others have seen here.
My motion sensors worked for a couple of days and then leave the network. When pressing the reset button short, I see an announce message but none of the actual values (illuminance, occupancy) or anything else is being transmitted and I need to remove and rejoin the sensor before anything works again.
I'm using a CC2531 with the latest source routing FW and running the latest dev branch Zigbee2MQTT updated every couple of days.
Other than that, I have 6 BR30 Osram bulbs, a couple of Xiaomi sensors and devices and a second CC2531 as router to extend the network.
EfficientSetting
on 7 Jul 2020
@EfficientSetting the CC2531 source routing firmware does not contain this fix, it should work with the default firmware. However given that you are running with so much devices I will recommend a more powerful adapter (CC2652R or CC1352P2 based https://www.zigbee2mqtt.io/information/supported_adapters.html#electrolama-zig-a-zig-ah-zzh)
Koenkk
on 7 Jul 2020
@Koenkk Thanks for the answer, almost as I expected.
I long thought I would need a more powerful Zigbee adapter, but so far, my network has been pretty reliable which is why I refrained from going that route.
Before I bring out the Hue hub for those motion sensors again, is there a chance that the fix might make it into the CC2531 source routing firmware or is this rather unlikely?
Thanks!
EfficientSetting
on 8 Jul 2020
@EfficientSetting I will check if it's possible to backport the fix
Koenkk
on 8 Jul 2020
Very interesting behavior I've seen with my hue sensors in the last days.
Tried to connect the hue motion sensors to a standalone CC2531 instead which was running well, but then, the motion sensor where trying to connect to my main z2m instance (CC2562) which is running on a different channel and joining not permitted. Put all devices on the blacklist on my main instance then, ended up with loosing the device completely as it was not able to connect to the main instance it stopped working and did not come back.
My conclusion is, all that issues are based on the hue device themself, maybe they have some problems within their firmware?
pepp86
on 31 Jul 2020
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
![github-actions[bot] picture](https://avatars2.githubusercontent.com/in/15368?v=4&s=40)
github-actions[bot]
on 31 Aug 2020
Same issue here. Yesterday I migrated from a CC2531 to a LAUNCHXL-CC26X2R1.
The freeze happened once with the CC2531 and yesterday within 4 hours after the migration. Annoying issue this..
BarBaar44
on 12 Oct 2020
Related issues
CodeFinder2
·
4Comments
andreasbrett
·
3Comments
LCerebo
·
3Comments
jerrychong25
·
4Comments
z4rn0x
·
3Comments
Most helpful comment
@EfficientSetting I will check if it's possible to backport the fix