search

Koenkk / Z-Stack-firmware

Compilation instructions and hex files for Z-Stack firmwares
MIT License
2.4k stars 651 forks source link

Z-Stack_3.x.0 coordinator 20230507 feedback #439

Closed Koenkk closed 1 year ago

Koenkk commented 1 year ago

Please provide your feedback to the Z-Stack_3.x.0 coordinator 20230507 firmware here.

I hope this solves the NWK_TABLE_FULL many people were experiencing.

Changelog

20230507

  • Enable child aging to fix issues like #13478 (but not for older Xiaomi devices as they do not implement child aging correctly which gets them kicked out of the network)
  • Increase message timeout from 7 to 8 seconds to increase message delivery success rate for devices using a 7.5 seconds poll interval (#13478)
  • Improve performance with larger network
    • Optimize table sizes
    • Increase stack_size from 1024 to 8192
  • Add firmware for CC1352P7
  • SimpleLink SDK 7.10.00.98

Download

johnlento commented 1 year ago

So downgrading to 122022 enabled me to update my inovelli’s and then I upgraded back to 410. The inovelli update has really made my network more stable but I’m still getting a boat load of watchdog failures and dongle disconnects. Light automations fail because the dongle is disconnected.it’s of timeouts too. Not sure what it is.

lux73 commented 1 year ago

updated from 20230401 to 20230410 without problems

with 401 firmware (CC2652RB updated 3 weeks ago) since yesterday two aqara battery devices from basement was missing

after upgrade to 410 both of them came online after few minutes

messani commented 1 year ago

Feedback:

I have network with 1x TS011F_plug_1 and 5x Danfoss ally eTRV0103. Coordinator is cc2652p bought from Aliexpress. Using zigbee2mqtt 1.30.3 [commit 24c6b2e]. Firmware 20221226 did not work well. Pairing was ok but after few hours/days, I was not able to control some Danfoss devices. I tried this firmware (20230410) with no luck - only changed fimware of ccordinator - no device repairing. State was still the same and I was not able to control some of the devices.

FYI: I captured zigbee data by wireshark and I saw that Danfoss is communicating well but there were no packets with commands from coordinator to device there. So if I changed setpoint manually, I could see it in zigbee2mqtt. (I do not understand zigbee protocol - there were no data which looked like request to change)

After that I switched back.

Later (on sunday) I gave second chance to this firmware and completely reseted my network (changed network key, repaired every device, deleted configuration/database of zigbee2mqtt). Since then everything works well (5 days)

Since then I connected 2 new devices (button SNZB-01 and bulb 07002L) and everything is working well.

From my point of view - it is good.

lvanjaarsveld commented 1 year ago

For me, I'm still unstable. Few times a day unavailable due to restarts. I'm thinking of going back to one before xx26 since I have it since then. Got a zigstar v4.

Koenkk commented 1 year ago

@guillaume042 @lvanjaarsveld can you both provide the herdsman debug logging starting from the point where starting z2m until the errors?

See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable the herdsman debug logging. Note that this is only logged to STDOUT and not to log files.

messani commented 1 year ago

Hi.

1) Today (after almost two weeks) one of my eTRV0103 left the network. I don't know wny. What should I change to be able to see the reason in the log?

Apr 28 09:49:02 raspberrypi npm[4346]: Zigbee2MQTT:warn  2023-04-28 09:49:02: Device 'livingroom/thermostat' left the network
Apr 28 09:49:03 raspberrypi npm[4346]: Zigbee2MQTT:info  2023-04-28 09:49:03: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"livingroom/thermostat","ieee_address":"0xf082c0fffe9dcb88"},"type":"device_leave"}'

2) After few days my button SNZB-01 stopped communicating. I could see it in web interface of zigbee2mqtt, but "last seen" value was high (10 hours or something like that)

sjorge commented 1 year ago

Just a update, still more or less stable with infrequent moments where everything is a bit slower to respond. But that usually seems to resolve itself after a few minutes.

johnlento commented 1 year ago

I’m still getting constant disconnects from the watch sog

Get Outlook for iOShttps://aka.ms/o0ukef

From: Jorge Schrauwen @.> Sent: Saturday, April 29, 2023 2:19:13 PM To: Koenkk/Z-Stack-firmware @.> Cc: johnlento @.>; Mention @.> Subject: Re: [Koenkk/Z-Stack-firmware] Z-Stack_3.x.0 coordinator 20230410 feedback (Issue #439)

Just a update, still more or less stable with infrequent moments where everything is a bit slower to respond. But that usually seems to resolve itself after a few minutes.

— Reply to this email directly, view it on GitHubhttps://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1528844125, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGHSRTZIS3P35I7FTVNCXA3XDVLSDANCNFSM6AAAAAAWPPN23Q. You are receiving this because you were mentioned.Message ID: @.***>

guillaume042 commented 1 year ago

@guillaume042 @lvanjaarsveld can you both provide the herdsman debug logging starting from the point where starting z2m until the errors?

See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable the herdsman debug logging. Note that this is only logged to STDOUT and not to log files.

Sorry was off for a few days. I've splitted my devices in two networks. I've migrated some devices in the first to recreate the issue

log.txt

End devices: 40
Router: 26
Zigbee2MQTT version
    [1.30.3](https://github.com/Koenkk/zigbee2mqtt/releases/tag/1.30.3) commit: [24c6b2e](https://github.com/Koenkk/zigbee2mqtt/commit/24c6b2e)

Coordinator type
    zStack3x0

Coordinator revision
    20230410

Coordinator IEEE Address
    0x00124b002a2f25e9

Frontend version
    0.6.127

For information, after getting the logs saved,, i ve switch back 2 devices to the other network and the table full error stop occuring.

Regards

deviantintegral commented 1 year ago

I was having trouble with device drops after adding a new device as I reported at https://github.com/Koenkk/zigbee2mqtt/discussions/17488.

I upgraded to this firmware, and it's been 24 hours without any problems. Is there any way to know if one of the specific changes in this firmware fixed my issue? I'm curious if I can determine if the increased stack size or the changes to the routing tables was it.

Koenkk commented 1 year ago

I upgraded to this firmware, and it's been 24 hours without any problems.

@deviantintegral from which fw did you upgrade?

For information, after getting the logs saved,, i ve switch back 2 devices to the other network and the table full error stop occuring.

@guillaume042 which devices? What is also strange it that this seems to happen very quickly after startup. Does it also happen that fast when: stopping z2m, taking the adapter out of the usb port for 10 sec (such that it doesn't have power anymore), start z2m

lux73 commented 1 year ago

running 20230410 since 1 Week - no Problem's so far in my Setup (50+ Devices)

guillaume042 commented 1 year ago

I upgraded to this firmware, and it's been 24 hours without any problems.

@deviantintegral from which fw did you upgrade?

For information, after getting the logs saved,, i ve switch back 2 devices to the other network and the table full error stop occuring.

@guillaume042 which devices? What is also strange it that this seems to happen very quickly after startup. Does it also happen that fast when: stopping z2m, taking the adapter out of the usb port for 10 sec (such that it doesn't have power anymore), start z2m

Hello,

To make that happens quickly, i toogle 5 light bulbs on/off very quicly at the same time.

Devices added for the test (2 of the same model), do you want me to try with another model ? 

Friendly name
    sdb_bas_plafond
Description

Last seen
    N/A
Availability
    Online
Device type
    Router
Zigbee Model
    TLSR82xx
Zigbee Manufacturer
    AwoX
Description
    LED light with color temperature
Support status

    Supported
IEEE Address
    0xa4c138c307fdfdfe
Network address
    0x8040
Firmware version
    0122052017
Manufacturer
    [AwoX](https://www.zigbee2mqtt.io/supported-devices/#v=AwoX)
Model
    [33957](https://www.zigbee2mqtt.io/devices/33957.html#awox-33957)
guillaume042 commented 1 year ago

I upgraded to this firmware, and it's been 24 hours without any problems.

@deviantintegral from which fw did you upgrade?

For information, after getting the logs saved,, i ve switch back 2 devices to the other network and the table full error stop occuring.

@guillaume042 which devices? What is also strange it that this seems to happen very quickly after startup. Does it also happen that fast when: stopping z2m, taking the adapter out of the usb port for 10 sec (such that it doesn't have power anymore), start z2m

Hello,

To make that happens quickly, i toogle 5 light bulbs on/off very quicly at the same time.

Devices added for the test (2 of the same model), do you want me to try with another model ?

Friendly name
    sdb_bas_plafond
Description

Last seen
    N/A
Availability
    Online
Device type
    Router
Zigbee Model
    TLSR82xx
Zigbee Manufacturer
    AwoX
Description
    LED light with color temperature
Support status

    Supported
IEEE Address
    0xa4c138c307fdfdfe
Network address
    0x8040
Firmware version
    0122052017
Manufacturer
    [AwoX](https://www.zigbee2mqtt.io/supported-devices/#v=AwoX)
Model
    [33957](https://www.zigbee2mqtt.io/devices/33957.html#awox-33957)

Okay that's tricky. Added other model of devices and so far so good. (leaving the 3 Awox alone on the other network as it seems issue come from these). Network is a little 'laggy' when i stress test it. No issue with normal usage. End devices: 42 Router: 27 ̀ I'm looking in my stock to see if i can add more devices.

johnlento commented 1 year ago

So I noticed about every 7 days the network stops responding. I have to boot HA and let it come back and after about 30 minutes the network is responsive again. Also, some devices fall off, like Jasco outlets and they need killed at the breaker to come back.

Get Outlook for iOShttps://aka.ms/o0ukef

From: guillaume042 @.> Sent: Sunday, April 30, 2023 4:49:21 AM To: Koenkk/Z-Stack-firmware @.> Cc: johnlento @.>; Mention @.> Subject: Re: [Koenkk/Z-Stack-firmware] Z-Stack_3.x.0 coordinator 20230410 feedback (Issue #439)

I upgraded to this firmware, and it's been 24 hours without any problems.

@deviantintegralhttps://github.com/deviantintegral from which fw did you upgrade?

For information, after getting the logs saved,, i ve switch back 2 devices to the other network and the table full error stop occuring.

@guillaume042https://github.com/guillaume042 which devices? What is also strange it that this seems to happen very quickly after startup. Does it also happen that fast when: stopping z2m, taking the adapter out of the usb port for 10 sec (such that it doesn't have power anymore), start z2m

Hello,

To make that happens quickly, i toogle 5 light bulbs on/off very quicly at the same time.

Devices added for the test (2 of the same model), do you want me to try with another model ?

Friendly name sdb_bas_plafond Description

Last seen N/A Availability Online Device type Router Zigbee Model TLSR82xx Zigbee Manufacturer AwoX Description LED light with color temperature Support status

Supported

IEEE Address 0xa4c138c307fdfdfe Network address 0x8040 Firmware version 0122052017 Manufacturer AwoX Model 33957

Okay that's tricky. Added other model of devices and so far so good. (leaving the 3 Awox alone on the other network as it seems issue come from these). Network is a little 'laggy' when i stress test it. No issue with normal usage. End devices: 42 Router: 27̀ I'm looking in my stock to see if i can add more devices.

— Reply to this email directly, view it on GitHubhttps://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1528972917, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGHSRT5TWXS25FEMSDCXZRLXDYRRDANCNFSM6AAAAAAWPPN23Q. You are receiving this because you were mentioned.Message ID: @.***>

deviantintegral commented 1 year ago

@Koenkk I was on the stable release 20221226 previously.

Also, some devices fall off, like Jasco outlets and they need killed at the breaker to come back.

@johnlento It's unlikely, but I recently had one that did this and when it was unresponsive it also didn't work at the physical switch until I flipped the breaker. I contacted Jasco and they said that shouldn't happen and sent a replacement.

Koenkk commented 1 year ago

@deviantintegral this is probably due to the TI SDK update (from 6.10 to 6.40)

@guillaume042 AwoX devices are known to cause problems. I've previously investigated and some DDOS the network. I recommend to keep them off the network if you are having stability issues.

guillaume042 commented 1 year ago

@deviantintegral this is probably due to the TI SDK update (from 6.10 to 6.40)

@guillaume042 AwoX devices are known to cause problems. I've previously investigated and some DDOS the network. I recommend to keep them off the network if you are having stability issues.

Ok. so i will try to put everything else on a network, leaving them alone. But till now with Awox away it works.

sjorge commented 1 year ago

First time sinds upgrade since this happened, it happened a lot more frequent before.

warn  2023-04-27 17:46:47: Device 'trv/livingroom' left the network
info  2023-04-27 17:46:47: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"trv/livingroom","ieee_address":"0x001fee00000098be"},"type":"device_leave"}'
info  2023-04-27 17:46:47: Device 'trv/livingroom' joined
info  2023-04-27 17:46:47: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"trv/livingroom","ieee_address":"0x001fee00000098be"},"type":"device_joined"}'
info  2023-04-27 17:46:47: Starting interview of 'trv/livingroom'
info  2023-04-27 17:46:48: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"trv/livingroom","ieee_address":"0x001fee00000098be","status":"started"},"type":"device_interview"}'
debug 2023-04-27 17:46:48: Device 'trv/livingroom' announced itself
info  2023-04-27 17:46:48: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"trv/livingroom","ieee_address":"0x001fee00000098be"},"type":"device_announce"}'
debug 2023-04-27 17:46:48: Received Zigbee message from 'trv/livingroom', type 'commandCheckIn', cluster 'genPollCtrl', data '{}' from endpoint 1 with groupID 0
debug 2023-04-27 17:46:50: Retrieving state of 'trv/livingroom' after reconnect
debug 2023-04-27 17:46:55: Received Zigbee message from 'trv/livingroom', type 'commandCheckIn', cluster 'genPollCtrl', data '{}' from endpoint 1 with groupID 0
debug 2023-04-27 17:46:56: Received Zigbee message from 'trv/livingroom', type 'readResponse', cluster 'genPollCtrl', data '{"checkinInterval":3600}' from endpoint 1 with groupID 0
info  2023-04-27 17:46:56: Successfully interviewed 'trv/livingroom', device has successfully been paired

I only noticed today it was offline, sadly the last line is a lie. It didn't seem to have joined successful again. It's only this TRV too the other 4 of the kind are solid. What's even weirder is that joining wasn't enabled at that time, nor where any actions taken on the device.

messani commented 1 year ago

First time sinds upgrade since this happened, it happened a lot more frequent before.

warn  2023-04-27 17:46:47: Device 'trv/livingroom' left the network
info  2023-04-27 17:46:47: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"trv/livingroom","ieee_address":"0x001fee00000098be"},"type":"device_leave"}'
info  2023-04-27 17:46:47: Device 'trv/livingroom' joined
info  2023-04-27 17:46:47: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"trv/livingroom","ieee_address":"0x001fee00000098be"},"type":"device_joined"}'
info  2023-04-27 17:46:47: Starting interview of 'trv/livingroom'
info  2023-04-27 17:46:48: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"trv/livingroom","ieee_address":"0x001fee00000098be","status":"started"},"type":"device_interview"}'
debug 2023-04-27 17:46:48: Device 'trv/livingroom' announced itself
info  2023-04-27 17:46:48: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"trv/livingroom","ieee_address":"0x001fee00000098be"},"type":"device_announce"}'
debug 2023-04-27 17:46:48: Received Zigbee message from 'trv/livingroom', type 'commandCheckIn', cluster 'genPollCtrl', data '{}' from endpoint 1 with groupID 0
debug 2023-04-27 17:46:50: Retrieving state of 'trv/livingroom' after reconnect
debug 2023-04-27 17:46:55: Received Zigbee message from 'trv/livingroom', type 'commandCheckIn', cluster 'genPollCtrl', data '{}' from endpoint 1 with groupID 0
debug 2023-04-27 17:46:56: Received Zigbee message from 'trv/livingroom', type 'readResponse', cluster 'genPollCtrl', data '{"checkinInterval":3600}' from endpoint 1 with groupID 0
info  2023-04-27 17:46:56: Successfully interviewed 'trv/livingroom', device has successfully been paired

I only noticed today it was offline, sadly the last line is a lie. It didn't seem to have joined successful again. It's only this TRV too the other 4 of the kind are solid. What's even weirder is that joining wasn't enabled at that time, nor where any actions taken on the device.

I think that it happend too in my case. Something happpened to TRV, which was fully functional - probably left network too and joined again, but interview was not successfull. I can see red triangle with "interview failed" tooltip at TRV in zigbee2mqttt. But TRV is fully functional (even with the red triangle).

guillaume042 commented 1 year ago

@deviantintegral this is probably due to the TI SDK update (from 6.10 to 6.40) @guillaume042 AwoX devices are known to cause problems. I've previously investigated and some DDOS the network. I recommend to keep them off the network if you are having stability issues.

Ok. so i will try to put everything else on a network, leaving them alone. But till now with Awox away it works.

No table full but some erros like this one : 

error 2023-05-02 21:47:49Publish 'set' 'color_temp' to 'salon-ampoule-plafond' failed: 'Error: Command 0xa4c13819c3ce7ca2/1 lightingColorCtrl.moveToColorTemp({"colortemp":450,"transtime":10}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 1213 - 1 - 59 - 768 - 11 after 10000ms)'
slugzero commented 1 year ago

@messani @sjorge the device should not have been interviewed again on rejoin if it was interviewed successfully previously, which I assume it was. I found a small bug that might cause this behavior. Can you check if you find a 'Delete device XYZ joined, undeleting' entry somewhere in your logs (might be anytime before the actual issue occurred)

@BartRuSec fyi, could be the same issue as yours

sjorge commented 1 year ago

Not seeing that in de logs, I just see the device leave and join multiples times being interviewed every time, which if it is indeed doing a proper leave, is not incorrect. I just don't understand how it could join again without the network being open.

But it does look like something is odd, as after a few leave-join cycles I think it finally gets kicked out because the device's bind table is now full... which means it probably did not do a 'full leave' as far as the device it self is concerned because then it's bind table would be empty. 🤷

Not ruling out some device issue though, but only 1/5 has this behavior though and they were bought at the same time.

okastl commented 1 year ago

I just don't understand how it could join again without the network being open.

Not directly related, but I have seen devices (re-)join without opening the network, no idea how this is possible: https://github.com/Koenkk/zigbee2mqtt/issues/17038

johnlento commented 1 year ago

The watchdog check still fails, coordinator disconnects, and lights go on off or fall off. Only unplugging power and rebooting help for about a week. Is there a better version to try or a dongle that doesn’t get watchdogged? Sometimes it says too much RF to form but it’s on a extension cable and I think it’s just the actual end devices causing the interference. There was none until I moved them all to 25 from 20.

Get Outlook for iOShttps://aka.ms/o0ukef

From: okastl @.> Sent: Wednesday, May 3, 2023 8:48:29 AM To: Koenkk/Z-Stack-firmware @.> Cc: johnlento @.>; Mention @.> Subject: Re: [Koenkk/Z-Stack-firmware] Z-Stack_3.x.0 coordinator 20230410 feedback (Issue #439)

I just don't understand how it could join again without the network being open.

Not directly related, but I have seen devices (re-)join without opening the network, no idea how this is possible: Koenkk/zigbee2mqtt#17038https://github.com/Koenkk/zigbee2mqtt/issues/17038

— Reply to this email directly, view it on GitHubhttps://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1532972515, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGHSRT5VIDHJPJNZAKK5WYDXEJHZ3ANCNFSM6AAAAAAWPPN23Q. You are receiving this because you were mentioned.Message ID: @.***>

Venom84 commented 1 year ago

@Koenkk Since using FW 20230410 my NWK_TABLE_FULL errors have significantly decreased but i have been seeing a few of my IKEA lights and motion sensors just drop off the network and i get the "Failed to Ping" or Device Unavailable log message even though the lights are definitely on. If i turn the light switch off and on again the light becomes available again. For the IKEA motion sensors i have to pres the button a few times to rejoin the network.

messani commented 1 year ago

@messani @sjorge the device should not have been interviewed again on rejoin if it was interviewed successfully previously, which I assume it was. I found a small bug that might cause this behavior. Can you check if you find a 'Delete device XYZ joined, undeleting' entry somewhere in your logs (might be anytime before the actual issue occurred)

@BartRuSec fyi, could be the same issue as yours

Sorry, I lost my logs with herdsman logging enabled (using raspberry pi with overlayfs). In logs without herdsman logging, there is no word delete/Delete anywhere (I can see messages about leaving/rejoining there).

I am trying to get the logs with herdsman logging enabled, but it take a few days when this happens. Unfortunatelly we have to wait.

slugzero commented 1 year ago

Not seeing that in de logs, I just see the device leave and join multiples times being interviewed every time, which if it is indeed doing a proper leave, is not incorrect. I just don't understand how it could join again without the network being open.

hm. I don't think that it really left the network. From your logs and from what I know about these devices, my guess is that the coordinator issued a leave/rejoin request. In that case, my understanding is that the coordinator will keep the device in its device table and allow a rejoin even without the network being open. Also, in that case, a fresh interview should not be necessary.

When comparing your log with the code, it also looks like the device is neither completely new, nor deleted (the respective log entries are missing).

@messani thanks for checking. It would be best if you could also switch to the latest development build to see if the issue still occurs.

lvanjaarsveld commented 1 year ago

@Koenkk Late to this party but finally been able to setup ssh access to pull logs. Here is one of today, at 7:34 7:46 9:18 9:21 9:24 9:26 today I saw that my sensors became unavailable for a short moment.

log.txt

taugusti commented 1 year ago

I installed 7 AvoX based led lights a few days ago - and immediately saw the NWK_TABLE_FULL error. I upgraded my coordinator to a Sonoff zbdongle-p and upgraded it to the 20230410 firmware. And the problem is unchanged - still errors and the network becomes slow or completely unresponsive for all other devices when I introduce the Awox parts.

I see that @Koenkk recommend leaving them out of the network - and currently that seems to be the best option. I assume that the led-driver can be changed for something with better zigbee2mqtt support.

But - before I start throwing money out, is there anything I can do to support a resolution of the issue?

Here a log from the user interface: debuglog z2m.txt

Thanks Update: I found out that I could update the firmware of the AwoX lights over bluetooth - and it seems to have improved the situation - at least a bit. I will update you when I have done more testing. The new AwoX fw is version 2.0.34 and lists "improved compatability with third-party ZigBee products" as "whats new".

KHV8 commented 1 year ago

In regards to AWOX, I do not see this as a coordinator problem. The AWOX bulbs (at least the type I have tried) will update every 2 seconds, spamming the zigbee network. I was in contact with AWOX support, and their answer is "use a AWOX hub and our app".

My personal conclusion. I do not use AWOX

taugusti commented 1 year ago

It seems that the new AwoX firmware solves the NWK_TABLE_FULL - but the network still becomes unresponsive. So - unfortunately, it seems like I have to agree with you that AwoX is out.

messani commented 1 year ago

Hi, finally i got delete message in log.

zigbee2mqtt.zip

deviantintegral commented 1 year ago

I just had my zzh! crash out with this firmware. I had to unplug it to get it functional again.

May 09 11:01:11 zigbee2mqtt npm[18175]: Zigbee2MQTT:error 2023-05-09 11:01:11: Publish 'set' 'brightness' to 'Main Floor Hallway' failed: 'Error: Command 1 genLevelCtrl.moveToLevelWithOnOff({"level":254,"transtime":450}) failed (SRSP - AF - dataRequestExt after 6000ms)'

Reading https://github.com/Koenkk/zigbee2mqtt/issues/17548#issuecomment-1535160962, is it possible to have memory usage logged even if debug logging is turned off? If memory is an issue, I imagine it would be very helpful to log high memory use on the adapter as a warning.

jyvern commented 1 year ago

running 20230410 since 3 days - no Problem's so far in my Setup (15 Devices) with my Slaesh adapter

Koenkk commented 1 year ago

I just published the 20230507 firmware (see OP for link). This includes the 7.10 SDK which was released on 5 May by Texas Instruments. I also optimised some more parameters. ~I'm also working on adding support for the CC1352P7 (got a launchpad from TI)~ UPDATE: CC1352P7 firmware is available now.

sjorge commented 1 year ago

Flashed on my zzhp-lite, previous one was already a huge improvement aside from the latancy so let's see if it's better now.

petergebruers commented 1 year ago

Upgraded to CC2652R_coordinator_20230507.hex with minor issues. Two devices required "clicking the button", a RTCGQ13LM precision motion sensor and a WSDCGQ01LM temp sensor. Out of 4 FP1 RTCZCGQ11LM radar sensors, one stoped reporting and I had to power cycle.

I was running dev, sorry, forgot to note its version. ... have updated z2m to this version right now:

commit dddd2bca88e762357b7bef5b88cbe0ffab394cb3 (HEAD -> dev, origin/dev)
Author: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Date:   Tue May 9 17:51:07 2023 +0000

    Update zigbee-herdsman-converters to 15.0.109 (#17620)
Venom84 commented 1 year ago

Just installed 20230507 onto my zzh Electrolama coordinator and so far so good. the network seems much more snappy and fast to respond. I had to power cycle a few of my lights but other than that the rest of the network all came back really quickly. Thank you @Koenkk :-) Ill monitor and report back if i have/see any issues.

lux73 commented 1 year ago

upgraded my CC2652RB (~50 Devices) from 20230410 to 20230507 few Minutes ago

messani commented 1 year ago

Yesterday I installed 20230507. Today I found out that I can control TRV from zigbee2mqtt, but if I change temperature setpoint on TRV, zigbee2mqtt is not informed back (I see old value there). I have herdsman logging enabled and there is nothing at that time.

messani commented 1 year ago

zigbee2mqtt.zip Here is my log. The device I wrote about is: livingroom/thermostat 0xf082c0fffe9dcb88 (0x446B) Danfoss 014G2461

I set manually setpoint today at 06:34:33, but there is nothing in log.

alexruffell commented 1 year ago

@Koenkk I have quietly been testing your development releases and with the last two (but it may be a pure coincidence) I have been getting a lot of zigbee related errors in the logs. The latest error seems to affect Samjin Outlets sold by ST (I am using Home Assistant / ZHA) and a ZHA developer told me the errors indicate a broken connection with the coordinator. Could it have anything to do with the latest 2 development releases of the coordinator firmware?

This is a subset of the repeating error and all the IDs I checked are for the same type of outlet. The devices appear to work correctly though. For a while response time was very bad but in the last couple days it seems to be better maybe thanks to 0507.

2023-05-09 19:13:51.557 ERROR (MainThread) [zigpy.zcl] [0xEFAE:1:0x0b04] Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/zigpy/zcl/__init__.py", line 365, in reply
return await self._endpoint.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/endpoint.py", line 273, in reply
return await self.device.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 388, in reply
return await self.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 300, in request
await self._application.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/application.py", line 825, in request
await self.send_packet(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 1050, in send_packet
response = await self._send_request_raw(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 936, in _send_request_raw
response = await asyncio.shield(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1056, in request_callback_rsp
await self.request(request, timeout=timeout, **response_params)
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1010, in request
self._uart.send(frame)
AttributeError: 'NoneType' object has no attribute 'send'
2023-05-09 19:13:51.558 ERROR (MainThread) [zigpy.zcl] [0x60AF:1:0x0b04] Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/zigpy/zcl/__init__.py", line 365, in reply
return await self._endpoint.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/endpoint.py", line 273, in reply
return await self.device.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 388, in reply
return await self.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 300, in request
await self._application.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/application.py", line 825, in request
await self.send_packet(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 1050, in send_packet
response = await self._send_request_raw(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 936, in _send_request_raw
response = await asyncio.shield(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1056, in request_callback_rsp
await self.request(request, timeout=timeout, **response_params)
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1010, in request
self._uart.send(frame)
AttributeError: 'NoneType' object has no attribute 'send'
2023-05-09 19:13:51.559 ERROR (MainThread) [zigpy.zcl] [0x01BF:1:0x0b04] Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/zigpy/zcl/__init__.py", line 365, in reply
return await self._endpoint.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/endpoint.py", line 273, in reply
return await self.device.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 388, in reply
return await self.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 300, in request
await self._application.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/application.py", line 825, in request
await self.send_packet(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 1050, in send_packet
response = await self._send_request_raw(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 936, in _send_request_raw
response = await asyncio.shield(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1056, in request_callback_rsp
await self.request(request, timeout=timeout, **response_params)
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1010, in request
self._uart.send(frame)
AttributeError: 'NoneType' object has no attribute 'send'
2023-05-09 19:13:51.561 ERROR (MainThread) [zigpy.zcl] [0x01BF:1:0x0b04] Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/zigpy/zcl/__init__.py", line 365, in reply
return await self._endpoint.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/endpoint.py", line 273, in reply
return await self.device.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 388, in reply
return await self.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 300, in request
await self._application.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/application.py", line 825, in request
await self.send_packet(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 1050, in send_packet
response = await self._send_request_raw(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 936, in _send_request_raw
response = await asyncio.shield(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1056, in request_callback_rsp
await self.request(request, timeout=timeout, **response_params)
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1010, in request
self._uart.send(frame)
AttributeError: 'NoneType' object has no attribute 'send'
2023-05-09 19:13:51.563 ERROR (MainThread) [zigpy.zcl] [0xCF9C:1:0x0b04] Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/zigpy/zcl/__init__.py", line 365, in reply
return await self._endpoint.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/endpoint.py", line 273, in reply
return await self.device.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 388, in reply
return await self.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 300, in request
await self._application.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/application.py", line 825, in request
await self.send_packet(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 1050, in send_packet
response = await self._send_request_raw(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 936, in _send_request_raw
response = await asyncio.shield(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1056, in request_callback_rsp
await self.request(request, timeout=timeout, **response_params)
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1010, in request
self._uart.send(frame)
AttributeError: 'NoneType' object has no attribute 'send'
2023-05-09 19:13:51.564 ERROR (MainThread) [zigpy.zcl] [0xEFAE:1:0x0b04] Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/zigpy/zcl/__init__.py", line 365, in reply
return await self._endpoint.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/endpoint.py", line 273, in reply
return await self.device.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 388, in reply
return await self.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 300, in request
await self._application.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/application.py", line 825, in request
await self.send_packet(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 1050, in send_packet
response = await self._send_request_raw(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 936, in _send_request_raw
response = await asyncio.shield(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1056, in request_callback_rsp
await self.request(request, timeout=timeout, **response_params)
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1010, in request
self._uart.send(frame)
AttributeError: 'NoneType' object has no attribute 'send'
2023-05-09 19:13:51.566 ERROR (MainThread) [zigpy.zcl] [0xB111:1:0x0b04] Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/zigpy/zcl/__init__.py", line 365, in reply
return await self._endpoint.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/endpoint.py", line 273, in reply
return await self.device.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 388, in reply
return await self.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 300, in request
await self._application.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/application.py", line 825, in request
await self.send_packet(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 1050, in send_packet
response = await self._send_request_raw(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 936, in _send_request_raw
response = await asyncio.shield(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1056, in request_callback_rsp
await self.request(request, timeout=timeout, **response_params)
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1010, in request
self._uart.send(frame)
AttributeError: 'NoneType' object has no attribute 'send'
2023-05-09 19:13:51.567 ERROR (MainThread) [zigpy.zcl] [0x9377:1:0x0b04] Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/zigpy/zcl/__init__.py", line 365, in reply
return await self._endpoint.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/endpoint.py", line 273, in reply
return await self.device.reply(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 388, in reply
return await self.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/device.py", line 300, in request
await self._application.request(
File "/usr/local/lib/python3.10/site-packages/zigpy/application.py", line 825, in request
await self.send_packet(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 1050, in send_packet
response = await self._send_request_raw(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 936, in _send_request_raw
response = await asyncio.shield(
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1056, in request_callback_rsp
await self.request(request, timeout=timeout, **response_params)
File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 1010, in request
self._uart.send(frame)
AttributeError: 'NoneType' object has no attribute 'send'
Koenkk commented 1 year ago

@alexruffell this logging doesn't mention any zstack specific things (like coordinator calls) so I cannot debug based on this (ZHA/zigpy logging only it seems)

messani commented 1 year ago

One of my TRV (kitchen/thermostat) left the network without no reason:

Zigbee2MQTT version 1.30.4 commit: b2dd21e

Coordinator type zStack3x0

Coordinator revision 20230507

May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.155Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,30,68,129,0,0,1,2,226,85,1,1,0,98,0,18,153,141,0,0,10,12,70,18,68,10,21,64,41,242,7,226,85,29,52]
May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.156Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,30,68,129,0,0,1,2,226,85,1,1,0,98,0,18,153,141,0,0,10,12,70,18,68,10,21,64,41,242,7,226,85,29,52]
May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.156Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 30 - 2 - 4 - 129 - [0,0,1,2,226,85,1,1,0,98,0,18,153,141,0,0,10,12,70,18,68,10,21,64,41,242,7,226,85,29] - 52
May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.156Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":513,"srcaddr":21986,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":98,"securityuse":0,"timestamp":9279762,"transseqnumber":0,"len":10,"data":{"type":"Buffer","data":[12,70,18,68,10,21,64,41,242,7]}}
May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.160Z zigbee-herdsman:controller:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":0,"manufacturerSpecific":true,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":68,"manufacturerCode":4678,"commandIdentifier":10},"Payload":[{"attrId":16405,"dataType":41,"attrData":2034}],"Command":{"ID":10,"name":"report","parameters":[{"name":"attrId","type":33},{"name":"dataType","type":32},{"name":"attrData","type":1000}]}},"address":21986,"endpoint":1,"linkquality":98,"groupID":0,"wasBroadcast":false,"destinationEndpoint":1}'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:debug 2023-05-11 10:34:00: Received Zigbee message from 'kitchen/thermostat', type 'attributeReport', cluster 'hvacThermostat', data '{"danfossExternalMeasuredRoomSensor":2034}' from endpoint 1 with groupID 0
May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.165Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/last_seen', payload '2023-05-11T10:34:00+01:00'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/mounted_mode_active', payload 'false'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/battery', payload '77'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/local_temperature', payload '21.05'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/window_open_feature', payload 'true'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/window_open_external', payload 'false'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/day_of_week', payload 'thursday'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/trigger_time', payload '660'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/mounted_mode_control', payload 'false'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/external_measured_room_sensor', payload '2034'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/radiator_covered', payload 'false'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/algorithm_scale_factor', payload '1'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/heat_available', payload 'true'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/load_balancing_enable', payload 'true'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/load_room_mean', payload '-8000'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/adaptation_run_settings', payload 'true'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/adaptation_run_control', payload 'none'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/load_estimate', payload '197'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/system_mode', payload 'heat'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/keypad_lockout', payload 'unlock'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/linkquality', payload '98'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/occupied_heating_setpoint', payload '28'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/setpoint_change_source', payload 'manual'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/occupied_heating_setpoint_scheduled', payload '28'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/pi_heating_demand', payload '1'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/update-state', payload 'idle'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/update-installed_version', payload ''
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/update-latest_version', payload ''
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/heat_required', payload 'false'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/running_state', payload 'idle'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/window_open_internal', payload 'open'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/adaptation_run_status', payload 'found'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/preheat_status', payload 'false'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/thermostat_vertical_orientation', payload 'false'
May 11 10:34:00 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:00: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/viewing_direction', payload 'false'
May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.540Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0xf082c0fffe99e6db:21986/1 (0,1,6)
May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.540Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":21986,"destendpoint":1,"srcendpoint":1,"clusterid":513,"transid":137,"options":0,"radius":30,"len":5,"data":{"type":"Buffer","data":[24,202,11,4,0]}}
May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.541Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,15,36,1,226,85,1,1,1,2,137,0,30,5,24,202,11,4,0,209]
May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.547Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100]
May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.547Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.547Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.548Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
May 11 10:34:00 raspberrypi npm[16465]: 2023-05-11T09:34:00.548Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.165Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,33,68,129,0,0,1,2,226,85,1,1,0,87,0,195,143,142,0,0,13,12,70,18,70,10,0,64,48,3,49,64,16,0,226,85,29,100]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.165Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,33,68,129,0,0,1,2,226,85,1,1,0,87,0,195,143,142,0,0,13,12,70,18,70,10,0,64,48,3,49,64,16,0,226,85,29,100]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.165Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 33 - 2 - 4 - 129 - [0,0,1,2,226,85,1,1,0,87,0,195,143,142,0,0,13,12,70,18,70,10,0,64,48,3,49,64,16,0,226,85,29] - 100
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.166Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":513,"srcaddr":21986,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":87,"securityuse":0,"timestamp":9342915,"transseqnumber":0,"len":13,"data":{"type":"Buffer","data":[12,70,18,70,10,0,64,48,3,49,64,16,0]}}
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.168Z zigbee-herdsman:controller:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":0,"manufacturerSpecific":true,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":70,"manufacturerCode":4678,"commandIdentifier":10},"Payload":[{"attrId":16384,"dataType":48,"attrData":3},{"attrId":16433,"dataType":16,"attrData":0}],"Command":{"ID":10,"name":"report","parameters":[{"name":"attrId","type":33},{"name":"dataType","type":32},{"name":"attrData","type":1000}]}},"address":21986,"endpoint":1,"linkquality":87,"groupID":0,"wasBroadcast":false,"destinationEndpoint":1}'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:debug 2023-05-11 10:34:01: Received Zigbee message from 'kitchen/thermostat', type 'attributeReport', cluster 'hvacThermostat', data '{"danfossHeatRequired":0,"danfossWindowOpenInternal":3}' from endpoint 1 with groupID 0
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.174Z zigbee-herdsman:controller:endpoint DefaultResponse 0xf082c0fffe99e6db/1 513(10, {"sendWhen":"fastpoll","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":1,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.175Z zigbee-herdsman:controller:endpoint Request Queue (0xf082c0fffe99e6db/1): send defaultRsp request immediately (sendWhen=fastpoll)
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.175Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/last_seen', payload '2023-05-11T10:34:01+01:00'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/mounted_mode_active', payload 'false'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/battery', payload '77'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/local_temperature', payload '21.05'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/window_open_feature', payload 'true'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/window_open_external', payload 'false'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/day_of_week', payload 'thursday'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/trigger_time', payload '660'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/mounted_mode_control', payload 'false'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/external_measured_room_sensor', payload '2034'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/radiator_covered', payload 'false'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/algorithm_scale_factor', payload '1'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/heat_available', payload 'true'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/load_balancing_enable', payload 'true'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/load_room_mean', payload '-8000'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/adaptation_run_settings', payload 'true'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/adaptation_run_control', payload 'none'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/load_estimate', payload '197'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/system_mode', payload 'heat'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/keypad_lockout', payload 'unlock'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/linkquality', payload '87'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/occupied_heating_setpoint', payload '28'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/setpoint_change_source', payload 'manual'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/occupied_heating_setpoint_scheduled', payload '28'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/pi_heating_demand', payload '1'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/update-state', payload 'idle'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/update-installed_version', payload ''
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/update-latest_version', payload ''
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/heat_required', payload 'false'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/running_state', payload 'idle'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/window_open_internal', payload 'open'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/adaptation_run_status', payload 'found'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/preheat_status', payload 'false'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/thermostat_vertical_orientation', payload 'false'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/kitchen/thermostat/viewing_direction', payload 'false'
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.538Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,240,1,137,191]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.538Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,240,1,137,191]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.538Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [240,1,137] - 191
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.538Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":240,"endpoint":1,"transid":137}
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.539Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.539Z zigbee-herdsman:adapter:zStack:adapter Data confirm error (0xf082c0fffe99e6db:21986,240,1)
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.539Z zigbee-herdsman:adapter:zStack:znp:SREQ --> UTIL - assocGetWithAddress - {"extaddr":"0xf082c0fffe99e6db","nwkaddr":21986}
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.539Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,10,39,74,219,230,153,254,255,192,130,240,226,85,199]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.548Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,36,103,74,226,85,6,0,1,104,1,0,0,1,91,0,122,214,4,0,0,0,0,0,60,0,0,0,60,0,0,1,255,0,0,0,0,0,0,0,220]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.549Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,36,103,74,226,85,6,0,1,104,1,0,0,1,91,0,122,214,4,0,0,0,0,0,60,0,0,0,60,0,0,1,255,0,0,0,0,0,0,0,220]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.549Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 36 - 3 - 7 - 74 - [226,85,6,0,1,104,1,0,0,1,91,0,122,214,4,0,0,0,0,0,60,0,0,0,60,0,0,1,255,0,0,0,0,0,0,0] - 220
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.549Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- UTIL - assocGetWithAddress - {"nwkaddr":21986,"addridx":6,"noderelation":1}
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.549Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.550Z zigbee-herdsman:adapter:zStack:adapter assocRemove(0xf082c0fffe99e6db)
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.550Z zigbee-herdsman:adapter:zStack:znp:SREQ --> UTIL - assocRemove - {"ieeeadr":"0xf082c0fffe99e6db"}
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.550Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,8,39,99,219,230,153,254,255,192,130,240,91]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.557Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,103,99,0,5]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.557Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,103,99,0,5]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.557Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 7 - 99 - [0] - 5
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.557Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- UTIL - assocRemove - {"status":0}
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.558Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.558Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0xf082c0fffe99e6db:21986/1 (0,2,7)
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.558Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":21986,"destendpoint":1,"srcendpoint":1,"clusterid":513,"transid":138,"options":0,"radius":30,"len":5,"data":{"type":"Buffer","data":[24,202,11,4,0]}}
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.558Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,15,36,1,226,85,1,1,1,2,138,0,30,5,24,202,11,4,0,210]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.577Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.578Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.578Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.578Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.578Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.664Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,13,69,201,226,85,219,230,153,254,255,192,130,240,0,0,1,32]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.664Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,13,69,201,226,85,219,230,153,254,255,192,130,240,0,0,1,32]
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.665Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 13 - 2 - 5 - 201 - [226,85,219,230,153,254,255,192,130,240,0,0,1] - 32
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.665Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - leaveInd - {"srcaddr":21986,"extaddr":"0xf082c0fffe99e6db","request":0,"removechildren":0,"rejoin":1}
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.666Z zigbee-herdsman:controller:log Device leave '0xf082c0fffe99e6db'
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.667Z zigbee-herdsman:controller:log Removing device from database '0xf082c0fffe99e6db'
May 11 10:34:01 raspberrypi npm[16465]: 2023-05-11T09:34:01.668Z zigbee-herdsman:controller:database:log Writing database to '/mnt/data/sys/opt/zigbee2mqtt/data/database.db'
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:warn  2023-05-11 10:34:01: Device 'kitchen/thermostat' left the network
May 11 10:34:01 raspberrypi npm[16465]: Zigbee2MQTT:info  2023-05-11 10:34:01: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"kitchen/thermostat","ieee_address":"0xf082c0fffe99e6db"},"type":"device_leave"}'
Koenkk commented 1 year ago

One of my TRV (kitchen/thermostat)

@messani what device is this? Can you provide the data/database.db entry of it

alexruffell commented 1 year ago

@alexruffell this logging doesn't mention any zstack specific things (like coordinator calls) so I cannot debug based on this (ZHA/zigpy logging only it seems)

The same dev just messaged be this:

No, it's with the UART. Either the firmware crashed, or something with your VM setup (if you're running one) caused it to disconnect.

sjorge commented 1 year ago

Responsiveness is definitely improved over the last one.

Venom84 commented 1 year ago

Yeah i agree with @sjorge Since the 20230507 FM my network has been responding much faster and i have had no disconnects which is great! almost 2 days up time.

I will report back after the weekend.

messani commented 1 year ago

database.zip @Koenkk: it is "kichen/thermostat". This is database file from yesterday. But I dont know if it was backed up at the right time.

I tried to re-pair TRV and got opposite problem - I was not able to control it from zigbee2mqtt. I sniffed zigbee communication and it looked to me that TRV did not send data about setpoint change (unfortunatelly I do not understand zigbee protocol, so I can only guess). So I decided to erase everything, change network key and re-pair it again. I had the same problem when I switched to 20230401 and it helped me.

So yesterday I re-paired everything again and since then I have no problem. I will keep you informed. Thank you.

If you are interested, I can send you sniffed data in wireshark format with network key if something similar happens.