Closed theFork closed 3 years ago
Koenkk
commented
3 years ago Could you provide the herdsman debug logging of the moment it stops working?
To enable herdsman debug logging, see https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging
theFork
commented
3 years ago Sure, I will enable it and post the log as soon as the issue reoccurs.
middelink
commented
3 years ago I actually have a similar issue ongoing, although I'm on a CC2531 stick. This morning I've burned the source-routing code as I saw that was advised in earlier issues. A few hours later my zigbee netmap shows the coordinator with the a number of routers still attached and a sea of devices floating around without any connection. This started like 3 days ago. Restarting the zigbee2mqtt HA container does not help, I really had to pull the stick and re-insert it (before it was migrated to source-routing; I will try this now with the SR version). (stick: 20190619 source routing, z2m: 1.14.4) If it looses connectivity again, I shall enable hardsman debugging and try to find anything Edit: Interesting observation is that the coordinator still receives updates, it just can't talk to most of them
aBaDDoNNL
commented
3 years ago I also have a similar issue since I've switched to 1.14.4 (hassio add-on).
My CC2531 sticks work for let's say max 2 days and then z2m becomes unresponsive. A reboot, restart of z2m or reconnect/re-seat of the USB stick doesn't seem to help. The only thing that helps is to actually reflash the stick with the latest firmware (20190619 default - so not source routing). Then it works for a few days and stops.
Nothing has changed to the set-up and no devices have been added. I have multiple CC2531 lying around and I am now rotating the sticks. If Z2M fails I stop the service, replace it with a reflashed CC2531 and start the service and all zigbee devices are back doing their things.
I just feels like they are overrun by something and then stop working. I read somewhere some old comment about nvram and reflashing it only helps. So I tried that and that helped for now.
I have seen several errors:
while the system was running happily "failed (Cannot request when znp has not been initialized yet)"
the typical no network route to host (probably some errors before - no logging anymore)
timeouts like:
error 2020-09-07 19:26:39: Publish 'set' 'state' to '0xec1bbdfffeef2c76' failed: 'Error: Command 0xec1bbdfffeef2c76/1 genOnOff.off({}, {"timeout":10000,"disableResponse":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) failed (Timeout - 2562 - 1 - 203 - 6 - 11 after 10000ms)'
tonight
2020-09-09 18:29:04: Publish 'set' 'state' to '0x7cb03eaa0a0597b9' failed: 'Error: Command 0x7cb03eaa0a0597b9/3 genOnOff.off({}, {"timeout":10000,"disableResponse":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) failed (SREQ '--> ZDO - extRouteDisc - {"dstAddr":30162,"options":0,"radius":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)'))'
I've just enabled herdsman debugging because I expect it to break anytime soon within two days, but maybe this already helps a bit.
Cheers,
Ramon
Koenkk
commented
3 years ago @aBaDDoNNL
aBaDDoNNL
commented
3 years ago @Koenkk
Thanks for the quick response.
Sorry, for the confusing. Currently I am back to the default 20190608 firmware:
{'meta': {'maintrel': 3, 'majorrel': 2, 'minorrel': 6, 'product': 0, 'revision': 20190608, 'transportrev': 2}, 'type': 'zStack12'}
The source routing version I used a while ago, but that (as far as I recall caused me some issues when pairing/joining zigbee devices to the network).
It would be awkward to hit the limit just now after months not having added a new (or old device).
I have 10 routers and 15 other devices.
Koenkk
commented
3 years ago @aBaDDoNNL I would recommend switching to the source routing fw in that case, in case you run into any pairing issues let me know if it cannot be fixed by stopping z2m, disconnect stick for a few seconds and replug.
This issue also happens earlier when using the availability feature: https://www.zigbee2mqtt.io/information/availability.html or when sending many commands at once.
aBaDDoNNL
commented
3 years ago @Koenkk Ok I will look into the source routing firmware again.
But tbh I still find it awkward that it is happening now and a "clean" stick solves it for me. No changes to the sensors/zigbee device set-up. No changes in automation or configuration. And it happens even when actually nothing extra is happening (read it as ... motion sensors for example being triggered by a lot of movement / hitting/bashing switches).
I've enabled the extra debugging so let's see if I can get logging of the issue occurring again and then switch to the source routing fw. I'll report back when running into it with some logging and will move to the source routing fw after that.
BTW: I haven't enabled the availability feature which if I read correctly gets triggered by setting the availability_timeout, but I do notice that availability_blacklist: [] is there and probably came with a default hassio add-on config at some point. Not sure if this can also have influence although I guess not. I don't see these messages in the logs.
Thank you for responding and helping so far.
middelink
commented
3 years ago @aBaDDoNNL I'm supprised switching sticks works without re-pairing. It would change the MAC address of the coordinator, and I think that is used in all kind of bindings.
aBaDDoNNL
commented
3 years ago @middelink Nope it is not an issue as documented here:
https://www.zigbee2mqtt.io/information/what_does_and_doesnt_require_repairing.html
That's why I have a bunch of the same coordinators just in case lying around.
Claude2666
commented
3 years ago I have the same issue after upgrade to the latest dev branch last 1.14.4-dev. My coordinator is 2530+2591 with source routing firmware. It stopped after a few hours and the only way to get z2m back on line is unplug the coordinator and plug it back in. It happened twice. So I went back to release that I had running before 1.14.2-dev and it has been rock solid for more than a week.
aBaDDoNNL
commented
3 years ago @Koenkk just for the sake of "might be interesting/useful". Here is logging of my Zigbee stopped working this afternoon. This is with the default firmware.
I will now plug in a stick with the source routing fw.
Koenkk
commented
3 years ago @aBaDDoNNL please provide the herdsman debug logging (provides much more insight in what is happening).
To enable herdsman debug logging, see https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging
aBaDDoNNL
commented
3 years ago @Koenkk Super sorry about this. I had the debug option set in the config yaml, but I most likely forgot to restart z2m. Because I never turned it on before I didn't notice extra prefix of herdsman in the logs which I do see know.
Currentl herdsman logging is turned on, but with the stick with source routing fw. Would you like me to go back to the default firmware or see for the time being how the source routing fw is behaving?
Koenkk
commented
3 years ago Let's see how the source routing fw behaves.
int2001
commented
3 years ago I have the same issue after upgrade to the latest dev branch last 1.14.4-dev. My coordinator is 2530+2591 with source routing firmware. It stopped after a few hours and the only way to get z2m back on line is unplug the coordinator and plug it back in. It happened twice. So I went back to release that I had running before 1.14.2-dev and it has been rock solid for more than a week.
How? Pulling 1.14.2 or 1.14.1 doesn't start because json-stable-stringify is missing (installed it by hand - but uuuuh).
Same issue here. Updated to 1.14.4 and everything stops after half an hour.
@Koenkk: Do you have any workaround available downgrading Z2M to the last stable Version, until this bug is fixed?
Koenkk
commented
3 years ago @int2001 do you use the availabilty feature? If so try disabling that, it seems to be the cause of the issue.
JHurk
commented
3 years ago Same issue here, since upgrading to 1.14.4 my Zigbee2MQTT has become very unstable en becomes unresponsive once or twice a day. Unplugging the CC2531 works sometimes, but sometimes I need to restart my NAS (Zigbee2MQTT on Docker).
I get the same error as OP, and eventually when Z2M starts I also get a lot of 'Failed to execute...' errors on almost all of my devices (17 devices in total and for around 13 devices Z2M gives this error). Besides that I get regular errors like: Publish 'set' 'state' to 'Garageverlichting' failed: 'Error: Command 0x00158d00040d30b3/2
Searching the issue-list it seems I get a mixure of three issues: the one from OP, the LQI and Error: Command 0x00
Don't use the availability feature. Tried downgrading to 1.14.3 but this did help Tried using the source firmware, this made my network even more unstable (all connections to coordinator are very weak and nothing works or with a lot of delay) Rolled back to default firmware, this kept the connections to coordinator weak and also made the connections from the devices to the router weak, only device to device connections are strong).
I ordered a stronger, better USB (slaesh’s CC2652RB stick) but this will take a few weeks to get here, so following this thread hoping a solution becomes available.
int2001
commented
3 years ago availabilty
Tried both during the past 2 days. With availability_timeout: 60 and without. --> Doesn't matter. Always stops after 30min.
I'll try with my manually downgraded Z2M (1.14.1) and the "hand-installed" json-stable-stringify. It's now running for about 2h without any issue.
PS: Ordered a ConBee II because i thought it is a hardware-issue. Will try the Conbee II tomorrow with most recent Z2M
Koenkk
commented
3 years ago Please provide more logging of this, otherwise I have no clue what is going on (https://github.com/Koenkk/zigbee2mqtt/issues/4307#issuecomment-690601441)
Claude2666
commented
3 years ago I tried yesterday again with the latest 1.14.4-dev version and after about 12 hours z2m started failing, Unfortunately I don't have a complete log yet. I am now running it again with debug logging and the herdsman debug logs. I have noticed that it seems to deteriorate. Some door and motion sensors failed sporadically and it got worse over time. Attached the partial log, I am not sure it is useful. At that time z2m did not respond properly anymore. The only way to get z2m running again was disconnect the coordinator and reconnect it again. My coordinator is a 2530+2591. Coordinator firmware version: '{"type":"zStack12","meta":{"transportrev":2,"product":0,"majorrel":2,"minorrel":6,"maintrel":3,"revision":20190619}}'
I do use the availability_timeout: 30 which does not cause any issues in the 1.14.2-dev I was running before.
Koenkk
commented
3 years ago @Claude2666 can you disable availability for the time being to see if that fixes the issue?
Claude2666
commented
3 years ago @Koenkk I have disabled the availability and I am running z2m now with the debug options. Lets see what happens.
alexanv1
commented
3 years ago Having the same issue, network mostly goes down (timeout errors or huge delays before devices respond) within ~12 hours of upgrading to 1,14,4 hassio add-on. Removing and reinserting CC2531 adapter and restarting the add-on resolves the issue for 0-12 hours.
Everything was stable on 1.14.3 and is stable again after going back. I don't have availability settings configured.
I should be able to get debug logging within a couple of days if it's not figured out by then.
Claude2666
commented
3 years ago After disabling the availability, z2m is stable so far. It's already running 24 hours without problems. Not sure if it is the availability feature itself or the extra network traffic it causes. Anyway, I'll keep the debug running for a few more days.
Claude2666
commented
3 years ago @Koenkk I spoke too soon. Z2M just stopped working again, this time with availability disabled.
Attached 25 hours log. zigbee2-log.zip
Koenkk
commented
3 years ago @Claude2666 please try again with the latest dev branch, did some fixes
Changes will be available in the latest dev branch in a few hours (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html)
@ptvoinfo while looking at the logs of @Claude2666, it seems that a lot of commands are send to the cc2530 router. This is because the router reports its children via genBinaryInput every minute, every child is a separate message. Since the disableDefaultReponse flag is set to false, Zigbee2MQTT has to send a defaultResponse for every received message! Could you set the disableDefaultReponse to true for these messages?
yellowonblack
commented
3 years ago The same problem for me, when after updating to 1.14.4-dev (commit #24a7250) few days ago, the whole system freezes after 12-24h and only restarting the docker container solves the problem. See below the versions I used.
Zigbee2MQTT:info 2020-09-14 12:23:10: Logging to console and directory: '/app/data/log/2020-09-14.12-23-10' filename: log.txt
Zigbee2MQTT:info 2020-09-14 12:23:12: Starting Zigbee2MQTT version 1.14.4-dev (commit #24a7250)
Zigbee2MQTT:info 2020-09-14 12:23:12: Starting zigbee-herdsman...
Zigbee2MQTT:info 2020-09-14 12:23:15: zigbee-herdsman started
Zigbee2MQTT:info 2020-09-14 12:23:15: Coordinator firmware version: '{"meta":{"maintrel":3,"majorrel":2,"minorrel":6,"product":0,"revision":20190619,"transportrev":2},"type":"zStack12"}'Now, I just updated to version 1.14.4-dev (commit #ff37b4f) and I will let you know if problem is solved.
Claude2666
commented
3 years ago I have been running the latest dev since last night around 19:00h with availability enabled. So far so good.
ptvoinfo
commented
3 years ago @Claude2666 @Koenkk I would recommend using Standard firmware, not the Diag (diagnostics) one. Standard firmware does not send these messages.
Koenkk
commented
3 years ago @Claude2666 please dont use availability yet, I have not fixed tis yet.
theFork
commented
3 years ago I hope it still helps but my system (still running 1.14.4 654817a-master) finally failed a few hours ago. I still had availability with 10s timeout enabled. The issue occured in log1.txt at about 2020-09-14, 12:08:xx:
As @Koenkk suggested I will now switch to the dev branch, disable availabitity and see what happens.
Claude2666
commented
3 years ago @Koenkk . I did switch off the availability, and I noticed that sometimes the network became unresponsive. Some motion sensors did not report motion and switches did not respond to commands. The network did not stop, and it seems to have recovered, but it took a while. I tried over a period of 20 min to switch a light on and nothing happened. This morning, the switches were responding again, but not always or slow.
HeimdallMidgard
commented
3 years ago Iam having same problem. Running 1.14.4 in Hass.io / Homeassistant Supervised. For me I can't get the adapter running at all anymore. In the last few days it was a little bit unresponsibly. Some sensors didn't update or updated the state later. Now I can't get it even started anymore. I get two logs. First one is when I unplug the stick and plug it back in and than start the addon. The other one is when I than try to restart the addon. new.txt running.txt
Edit: Same error on 1.14.4-dev / zigbee2mqtt-edge
data_path: /share/zigbee2mqtt devices: devices.yaml groups: groups.yaml homeassistant: true permit_join: false mqtt: base_topic: zigbee2mqtt server: 'mqtt://core-mosquitto:1883' user: xxx password: xxx serial: port: /dev/ttyACM0 advanced: report: false availability_timeout: 0 pan_id: 6754 channel: 11 log_level: debug network_key:
- 1
- 3
- 5
- 7
- 9
- 11
- 13
- 15
- 0
- 2
- 4
- 6
- 8
- 10
- 12
- 13 availability_blacklist: [] ban: [] whitelist: [] queue: {} socat: enabled: false master: 'pty,raw,echo=0,link=/dev/ttyZ2M,mode=777' slave: 'tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5' restartdelay: 1 initialdelay: 1 options: '-d -d' log: true zigbee_herdsman_debug: true
Erickclee
commented
3 years ago I have the same problem of everything described here.
Now I am living with resetting the Pi power daily. Is there a way to downgrade the firmware temporary while waiting for the fixes?
Koenkk
commented
3 years ago @Erickclee please check if it has been fixed in the latest dev branch. (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html)
Erickclee
commented
3 years ago @Erickclee please check if it has been fixed in the latest dev branch. (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html)
Thanks @Koenkk for your help, appreciated. I am trying ndev-branch now, lets see how it goes. Just for feedback, there seems to be many issue being raise at the same time, with different topic title. But when I read them, the synptoms sounds like very similar to this case. example #4369 , #4296
Koenkk
commented
3 years ago Fixed the availability (should be safe to use again) and added some more debug logging.
In case of issues, first update to latest dev branch again (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html) and provide the herdsman debug logging of this.
To enable herdsman debug logging, see https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging
Erickclee
commented
3 years ago Just tried teh dev-branch for a few minutes.
switches changing state still sluggish, slight dely sometime, check the Z2M log file, there is a few red, fail to pulish state sometime, but recover later when it retry i think.
In Z2MAssistant, the lqi for all the devices still missing, and the network map also shows all devices floating in the air without interconnector.
Still need to monitor if the daily breakdown still happens...need 24hr....
sjorge
commented
3 years ago Fixed the availability (should be safe to use again) and added some more debug logging.
This also seems to have to have fixed the slowdowns and delays that would pop up every so often
ALaDoffe
commented
3 years ago Hi
Since the last night Z2M update regarding availability, it seems there is a new issue. My devices become sporadically unvailable.
availability_failed.txt Herdsman_Debug_availability_failed.txt
Update done at 09:25PM
And after a while, networks crashes.
Claude2666
commented
3 years ago I have noticed the same. Sometimes I see 'Failed to ping' in the logfile. I did have this in the previous version that I was running zigbee2mqtt version 1.14.2-dev (commit #44b26f9)
Erickclee
commented
3 years ago Fixed the availability (should be safe to use again) and added some more debug logging.
In case of issues, first update to latest dev branch again (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html) and provide the herdsman debug logging of this.
To enable herdsman debug logging, see https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging
Hi @Koenkk I have tried dev-branch, after 15 hours, Z2M crashes again. I cold reboot my Pi to reset. As per your instruction, I try to reinstall the latest dev branch again.
Issue is still similar,
Zigbee switches are not responsive, some time ok and somtimes delay response.
And after 12-24hour, it will totally crash again.
I will run the dev-branch for the 2nd round to try it out.
Attached is my Herdsman Log
zigbee-herdsman_log.txt
It just crashed again, after just less than an hour, I capture the log file again, zigbee-herdsman_crash_log.txt
Koenkk
commented
3 years ago @Erickclee thanks for the logs, but they are very short so I'm unable to see what is going on. Please provide the complete logs from starting zigbee2mqtt till the crash.
theFork
commented
3 years ago My system also crashed tonight. Here are the log files: 2020-09-16.09-31-08.zip Unfortunately, when starting Z2M as a hassio addon, the log does not contain the commit ID. I installed Z2M-edge (aka dev-branch) on tuesday evening, so the commit ID should be b1bf87f845faee931357d3ef6c70103d27ca8a29. Is there another way of checking the commit id?
Koenkk
commented
3 years ago @theFork unfortunately does not contain the herdsman debug logging. Note that this is only logged to the STDOUT (hassio addon webpage), so it's very hard to get al the logging here. Therefore in your case I would recommend disabling availability for now.
theFork
commented
3 years ago @Koenkk Damn, I was almost sure, that the files looked somehow different then the output of the web interface. Thanks for the clarification. Maybe I should spend the time moving my Z2M away from hassio to be able to collect the log.
middelink
commented
3 years ago @theFork you can add zigbee_herdsman_debug: true to the config of your hassio module. This will enable herdsman logging. No need to redo your installation.
theFork
commented
3 years ago @middelink: I already have enabled zigbee_herdsman_debug. The herdsman lines only appear on STDOUT which is - in my case - the hassio supervisor web interface. Do you know a way of redirecting this?
phuongnd01904
commented
3 years ago Hi @Koenkk,
I have the same problem. This is my zigbee2mqtt log file.
2020-09-17T18:00:00.093Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- ZDO - mgmtLqiReq - {"status":0} 2020-09-17T18:00:00.093Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] 2020-09-17T18:00:00.100Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,28,69,177,0,0,0,1,0,1,221,221,221,221,221,221,221,221,240,150,184,20,0,75,18,0,131,134,21,2,1,0,104] 2020-09-17T18:00:00.100Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,28,69,177,0,0,0,1,0,1,221,221,221,221,221,221,221,221,240,150,184,20,0,75,18,0,131,134,21,2,1,0,104] 2020-09-17T18:00:00.100Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 28 - 2 - 5 - 177 - [0,0,0,1,0,1,221,221,221,221,221,221,221,221,240,150,184,20,0,75,18,0,131,134,21,2,1,0] - 104 2020-09-17T18:00:00.103Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - mgmtLqiRsp - {"srcaddr":0,"status":0,"neighbortableentries":1,"startindex":0,"neighborlqilistcount":1,"neighborlqilist":[{"extPandId":"0xdddddddddddddddd","extAddr":"0x00124b0014b896f0","nwkAddr":34435,"deviceType":1,"rxOnWhenIdle":1,"relationship":1,"permitJoin":2,"depth":1,"lqi":0}]} 2020-09-17T18:00:00.103Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] 2020-09-17T18:00:00.106Z zigbee-herdsman:adapter:zStack:znp:SREQ --> ZDO - mgmtLqiReq - {"dstaddr":34435,"startindex":0} 2020-09-17T18:00:00.106Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,3,37,49,131,134,0,18] 2020-09-17T18:00:00.118Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,101,49,0,85] 2020-09-17T18:00:00.119Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,101,49,0,85] 2020-09-17T18:00:00.119Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 5 - 49 - [0] - 85 2020-09-17T18:00:00.119Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- ZDO - mgmtLqiReq - {"status":0} 2020-09-17T18:00:00.119Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] Zigbee2MQTT:error 2020-09-18 01:00:10: Failed to execute LQI for '0x00124b0014b896f0' Zigbee2MQTT:info 2020-09-18 01:00:10: Network scan finished Zigbee2MQTT:info 2020-09-18 01:00:10: MQTT publish: topic 'zigbee2mqtt/bridge/networkmap/graphviz', payload 'digraph G { node[shape=record]; "0x00124b0018e20a48" [style="bold, filled", fillcolor="#e04e5d", fontcolor="#ffffff", label="{Coordinator|0x00124b0018e20a48 (0)|0 seconds ago}"]; "0x00124b0014b896f0" [style="rounded, filled", fillcolor="#4ea3e0", fontcolor="#ffffff", label="{0x00124b0014b896f0|0x00124b0014b896f0 (34435)failed: lqi|Custom devices (DiY) [CC2530 router](http://ptvo.info/cc2530-based-zigbee-coordinator-and-router-112/) (CC2530.ROUTER)|4 days, 7 hours ago}"]; "0x00124b0014b896f0" -> "0x00124b0018e20a48" [penwidth=0.5, weight=0, color="#994444", label="0"] "0x00158d000103d9bb" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{0x00158d000103d9bb|0x00158d000103d9bb (58001)|Xiaomi MiJia human body movement sensor (RTCGQ01LM)|4 days, 6 hours ago}"]; "0x00158d000119e658" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{0x00158d000119e658|0x00158d000119e658 (5225)|Xiaomi MiJia door & window contact sensor (MCCGQ01LM)|4 days, 6 hours ago}"]; "0x00158d00010f40c1" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{0x00158d00010f40c1|0x00158d00010f40c1 (47768)|Xiaomi MiJia wireless switch (WXKG01LM)|4 days, 6 hours ago}"]; }' 2020-09-17T18:00:30.433Z zigbee-herdsman:controller:log Permit joining 2020-09-17T18:00:30.435Z zigbee-herdsman:adapter:zStack:znp:SREQ --> ZDO - mgmtPermitJoinReq - {"addrmode":15,"dstaddr":65532,"duration":254,"tcsignificance":0} 2020-09-17T18:00:30.435Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,5,37,54,15,252,255,254,0,228] 2020-09-17T18:00:30.449Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,101,54,0,82] 2020-09-17T18:00:30.450Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,101,54,0,82] 2020-09-17T18:00:30.450Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 5 - 54 - [0] - 82 2020-09-17T18:00:30.450Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- ZDO - mgmtPermitJoinReq - {"status":0} 2020-09-17T18:00:30.451Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] 2020-09-17T18:00:30.454Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequestExt - {"dstaddrmode":2,"dstaddr":"0x000000000000fffd","destendpoint":242,"dstpanid":0,"srcendpoint":242,"clusterid":33,"transid":3,"options":0,"radius":30,"len":6,"data":{"type":"Buffer","data":[25,4,2,11,254,0]}} 2020-09-17T18:00:30.455Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,26,36,2,2,253,255,0,0,0,0,0,0,242,0,0,242,33,0,3,0,30,6,0,25,4,2,11,254,0,236] 2020-09-17T18:00:30.468Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,69,182,0,0,0,240] 2020-09-17T18:00:30.469Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,69,182,0,0,0,240] 2020-09-17T18:00:30.469Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 5 - 182 - [0,0,0] - 240 2020-09-17T18:00:30.469Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - mgmtPermitJoinRsp - {"srcaddr":0,"status":0} 2020-09-17T18:00:30.469Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] 2020-09-17T18:00:30.470Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,2,0,103] 2020-09-17T18:00:30.471Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,2,0,103] 2020-09-17T18:00:30.471Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 2 - [0] - 103 2020-09-17T18:00:30.471Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequestExt - {"status":0} 2020-09-17T18:00:30.472Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] 2020-09-17T18:00:30.475Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,0,242,3,54] 2020-09-17T18:00:30.475Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,0,242,3,54] 2020-09-17T18:00:30.476Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,242,3] - 54 2020-09-17T18:00:30.476Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":242,"transid":3} 2020-09-17T18:00:30.476Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] 2020-09-17T18:03:50.438Z zigbee-herdsman:controller:log Permit joining 2020-09-17T18:03:50.440Z zigbee-herdsman:adapter:zStack:znp:SREQ --> ZDO - mgmtPermitJoinReq - {"addrmode":15,"dstaddr":65532,"duration":254,"tcsignificance":0} 2020-09-17T18:03:50.440Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,5,37,54,15,252,255,254,0,228] 2020-09-17T18:03:50.454Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,101,54,0,82] 2020-09-17T18:03:50.455Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,101,54,0,82] 2020-09-17T18:03:50.455Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 5 - 54 - [0] - 82 2020-09-17T18:03:50.455Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- ZDO - mgmtPermitJoinReq - {"status":0} 2020-09-17T18:03:50.456Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] 2020-09-17T18:03:50.459Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequestExt - {"dstaddrmode":2,"dstaddr":"0x000000000000fffd","destendpoint":242,"dstpanid":0,"srcendpoint":242,"clusterid":33,"transid":4,"options":0,"radius":30,"len":6,"data":{"type":"Buffer","data":[25,5,2,11,254,0]}} 2020-09-17T18:03:50.460Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,26,36,2,2,253,255,0,0,0,0,0,0,242,0,0,242,33,0,4,0,30,6,0,25,5,2,11,254,0,234] 2020-09-17T18:03:50.475Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,69,182,0,0,0,240] 2020-09-17T18:03:50.475Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,69,182,0,0,0,240] 2020-09-17T18:03:50.475Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 5 - 182 - [0,0,0] - 240 2020-09-17T18:03:50.476Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - mgmtPermitJoinRsp - {"srcaddr":0,"status":0} 2020-09-17T18:03:50.476Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] 2020-09-17T18:03:50.477Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,2,0,103] 2020-09-17T18:03:50.477Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,2,0,103] 2020-09-17T18:03:50.478Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 2 - [0] - 103 2020-09-17T18:03:50.478Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequestExt - {"status":0} 2020-09-17T18:03:50.478Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] 2020-09-17T18:03:50.480Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,0,242,4,49] 2020-09-17T18:03:50.480Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,0,242,4,49] 2020-09-17T18:03:50.481Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,242,4] - 49 2020-09-17T18:03:50.481Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":242,"transid":4} 2020-09-17T18:03:50.481Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] 2020-09-17T18:07:10.438Z zigbee-herdsman:controller:log Permit joining 2020-09-17T18:07:10.439Z zigbee-herdsman:adapter:zStack:znp:SREQ --> ZDO - mgmtPermitJoinReq - {"addrmode":15,"dstaddr":65532,"duration":254,"tcsignificance":0} 2020-09-17T18:07:10.440Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,5,37,54,15,252,255,254,0,228] 2020-09-17T18:07:10.454Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,101,54,0,82] 2020-09-17T18:07:10.455Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,101,54,0,82] 2020-09-17T18:07:10.455Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 5 - 54 - [0] - 82 2020-09-17T18:07:10.456Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- ZDO - mgmtPermitJoinReq - {"status":0} 2020-09-17T18:07:10.456Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] 2020-09-17T18:07:10.459Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequestExt - {"dstaddrmode":2,"dstaddr":"0x000000000000fffd","destendpoint":242,"dstpanid":0,"srcendpoint":242,"clusterid":33,"transid":5,"options":0,"radius":30,"len":6,"data":{"type":"Buffer","data":[25,6,2,11,254,0]}} 2020-09-17T18:07:10.460Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,26,36,2,2,253,255,0,0,0,0,0,0,242,0,0,242,33,0,5,0,30,6,0,25,6,2,11,254,0,232] 2020-09-17T18:07:10.473Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,69,182,0,0,0,240] 2020-09-17T18:07:10.474Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,69,182,0,0,0,240] 2020-09-17T18:07:10.474Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 5 - 182 - [0,0,0] - 240 2020-09-17T18:07:10.474Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - mgmtPermitJoinRsp - {"srcaddr":0,"status":0} 2020-09-17T18:07:10.474Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] 2020-09-17T18:07:10.475Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,2,0,103] 2020-09-17T18:07:10.476Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,2,0,103] 2020-09-17T18:07:10.476Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 2 - [0] - 103 2020-09-17T18:07:10.476Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequestExt - {"status":0} 2020-09-17T18:07:10.476Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] 2020-09-17T18:07:10.479Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,0,242,5,48] 2020-09-17T18:07:10.480Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,0,242,5,48] 2020-09-17T18:07:10.480Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,242,5] - 48 2020-09-17T18:07:10.480Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":242,"transid":5} 2020-09-17T18:07:10.481Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
thank so much
Abstract:
After some days of operation, my entire Zigbee system fails. No devices report and none can be controlled. Reconnecting the zzh coordinator (CC2652R) fixes the problem for a while.
System:
Version of Zigbee2Mqtt: 1.14.4 (Homeassistant Add-On) Coordinator: zig-a-zig-ah! (CC2652R) Coordinator version: 20200417 Host: NUC with Homeassisant
What happens:
In the Z2M log, I only see lines that look like that: No usual zigbee activity can be seen here:
When I restart Z2M using the Homeassistant supervisor, I see this:
And so on. This would repeat forever, until I disconnect and reconnect my ZZH coordinator. After this, the network comes up again.
Config
Maybe I should mention, that both features reporting and availability are enabled:
I`m afraid, that this is not enough information to analyze the issue. Is there anything I could fetch when the problem shows up the next time?