ZHA timeout failure when requesting update from asleep device

Configuration Zigbee
1

I’ve been getting zigbee timeout errors for my SNZB-04 based devices (Tuya offbrand). My zigbee network is strong and all software is latest.

It appears that HA is requesting status from these devices, but they are asleep and don’t reply causing the timeout. Sleepy devices should wake themselves up to provide a status update, not the other way around.

I know these Tuya devices are mongrel and non-standard, but there should be a way in zigbee tweaks to prevent HA from requesting any status updates, right?

Has anyone found a way to prevent HA requesting status updates from device that are asleep? If so, how did you do it?

Logger: zigpy.application
Source: /usr/local/lib/python3.13/site-packages/zigpy/application.py:111
First occurred: 5:53:54 AM (24 occurrences)
Last logged: 11:11:03 AM

Device <Device model='SNZB-04' manuf='_TZ3000_n2egfsli' nwk=0x3029 ieee=a4:c1:38:a0:7a:0d:2f:26 is_initialized=True> callback failed - DeliveryError('Failed to deliver message: <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074>')
Device <Device model='SNZB-04' manuf='eWeLink' nwk=0x6CBF ieee=a4:c1:38:14:46:cf:8e:3c is_initialized=True> callback failed - DeliveryError('Failed to deliver message: <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074>')
Device <CustomDeviceV2 model='SNZB-04P' manuf='eWeLink' nwk=0xF96F ieee=8c:73:da:ff:fe:01:17:8c is_initialized=True> callback failed - DeliveryError('Failed to deliver message: <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074>')
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/site-packages/zigpy/application.py", line 109, in _async_callback
    await callback(*args, **kwargs)
  File "/usr/local/lib/python3.13/site-packages/zigpy/device.py", line 364, in poll_control_checkin_callback
    await poll_control.checkin_response(
    ...<5 lines>...
    )
  File "/usr/local/lib/python3.13/site-packages/zigpy/zcl/__init__.py", line 686, in request
    return await self._endpoint.request(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<9 lines>...
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/zigpy/endpoint.py", line 229, in request
    return await self.device.request(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<11 lines>...
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/zigpy/device.py", line 571, in request
    await send_request()
  File "/usr/local/lib/python3.13/site-packages/zigpy/application.py", line 1013, in request
    await self.send_packet(
    ...<14 lines>...
    )
  File "/usr/local/lib/python3.13/site-packages/bellows/zigbee/application.py", line 1098, in send_packet
    raise zigpy.exceptions.DeliveryError(
        f"Failed to deliver message: {send_status!r}", send_status
    )
zigpy.exceptions.DeliveryError: Failed to deliver message: <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074>
2

Bump. I’m not sure this rises to the level of creating a bug report in the github repo.

5

@nasaj60174 ??

6

Did you get any feedback or learn more about this? All my motion sensors constantly show this every few hours and its really annoying

7

I found how to reduce the number of times this error occurs. You can set the checkin interval to some insanely large time (seconds). Then the error will only happen when that time elapses.

image
image1749×681 108 KB

To set the value, press the button on the device and then click “write attribute” immediately. You may need to read it back to ensure it was written properly. Reading back also requires a button push on the device to wake it up.

8

That value should be less than the default 6 hours for ZHA to check in:

image
image991×120 12 KB

If you set the value to be higher, then you’re going to keep running into the issue every time the 6 hours pass.
It might be easier to just change the default setting in ZHA from 6 hours to something a bit higher. For some perspective, the default polling for battery devices in Z2M is 25 hours.

9

The unavailable diagnostic is a global timeout and is different from the check-in interval.

I set the check-in to a week. The error only happens once a week.