puddly

Your coordinator has two chips, an ESP32 for the network side and a SiLabs EFR32 for the Zigbee side. The Zigbee chip is resetting and causing ZHA to reload, which...

Here's an annotated snippet of your log: ```python # Receive a `messageSentHandler` command 2025-02-23 20:15:24.554 DEBUG (MainThread) [bellows.ash] Received frame DataFrame(frm_num=2, re_tx=0, ack_num=1, ezsp_frame=b'\x17\x90\x01?\x00\x00\xcb,\x04\x01\x02\x04\x01\x01@\x00\x00\x00\xa6\xbf\x00\x00') 2025-02-23 20:15:24.554 DEBUG (MainThread) [bellows.ash] Sending...

That's on a layer that Home Assistant Core likely doesn't work with. I think your only real sources of delays would be: 1. The hypervisor acting up. 2. The network...

I'm not sure how Z2M deals with coordinator resets (and with entity state residing on the MQTT broker) so it's hard to say if it's not also seeing the same...

@MDrollette this issue is tracking a problem where the coordinator itself breaks. If you can communicate with some devices but not others, you have a different problem.

ZHA communicates with the coordinator every 30s, no matter what, as a keepalive. If the entities go unavailable then either your coordinator's TCP server disconnects ZHA (in which case the...

Indeed, the node descriptor for the device has `is_receiver_on_when_idle=False` and `logical_type=`. There's no way to change the way the device itself functions on the network, unfortunately.

I think I agree with @MattWestb here. The Identify button is present on every device right now, including sleepy end devices, and people have never had issues with it. Removing...

@kbalint @ramondm-esp (and anyone else commenting) please enable ZHA debug logging, reload the integration, let it run for 15 minutes (and try controlling devices to generate traffic), and disable debug...

@maarten-emilsen All of the devices you're having problems with are Tuya. From the logs, the Tuya devices join and then immediately leave. If you can, downgrade back to 2024.9.x and...