Pass through sleepy_destination for extended APS ACKs

[puddly]

This PR implements Zigpy's extended_timeout packet send option, which helps properly timeout APS ACKs when communicating with sleeping end devices parented to other routers.

[MattWestb]

I think its one step of fixing this error ??

Logger: zigpy_ziggurat.zigbee.application
Source: runner.py:289
First occurred: 09:13:26 (143 occurrences)
Last logged: 19:40:42

Delivery failed after transmission: aps_ack_timeout: aps ack timeout

Im missing the possibility identify the device with long an / or short network address and perhaps liked to HAs device name.
Can being good putting it in for debugging but i shall not being needed then being released ad GA.

And as normal GWDP !!!!!

[puddly]

143 occurrences? That's a lot...

Do you know what devices this is related to?

[MattWestb]

I think that was from IKEA test network over night (its ticking all the time).
I have spinning up one more RCP (backup for OTBR) with Ziggurat and adding the light and styrbar remote and it was paring OK and in the night i was getting:

2026-07-13 13:27:23.613 DEBUG (MainThread) [zha.application.platforms] 0c:43:14:ff:fe:17:e7:4f-1: transition complete - future attribute reports will write HA state
2026-07-13 13:27:25.892 DEBUG (MainThread) [zha.decorators] [<Task pending name='device-availability-checker_DeviceAvailabilityChecker' coro=<periodic.<locals>.scheduler.<locals>.wrapper() running at /usr/local/lib/python3.14/site-packages/zha/decorators.py:75> cb=[set.remove()]>] executing periodic task [zha.application.helpers::DeviceAvailabilityChecker.check_device_availability]
2026-07-13 13:27:25.894 DEBUG (MainThread) [zha.application.helpers] Device availability checker interval starting
2026-07-13 13:27:25.894 DEBUG (MainThread) [zha.application.helpers] Checking device availability
2026-07-13 13:27:25.895 DEBUG (MainThread) [zha.zigbee.device] [0x889F](Remote Control N2): Device seen - marking the device available and resetting counter
2026-07-13 13:27:25.896 DEBUG (MainThread) [zha.zigbee.device] [0x889F](Remote Control N2): Update device availability -  device available: True - new availability: True - changed: False
2026-07-13 13:27:25.897 DEBUG (MainThread) [zha.zigbee.device] [0x5236](TRADFRIbulbE27WSglobeopal1055lm): Device seen - marking the device available and resetting counter
2026-07-13 13:27:25.898 DEBUG (MainThread) [zha.zigbee.device] [0x5236](TRADFRIbulbE27WSglobeopal1055lm): Update device availability -  device available: True - new availability: True - changed: False
2026-07-13 13:27:25.902 DEBUG (MainThread) [zha.application.helpers] Device availability checker interval finished
2026-07-14 01:29:50.154 WARNING (MainThread) [zigpy_ziggurat.zigbee.application] Delivery failed after transmission: aps_ack_timeout: aps ack timeout
2026-07-14 01:29:50.164 WARNING (MainThread) [zigpy_ziggurat.zigbee.application] Delivery failed after transmission: aps_ack_timeout: aps ack timeout

Was taking with some more line before then it can being interesting but the 2 last is the error and its 12 hours + some minutes.
So only 3 devices coordinator, light and remote and i think its the remote (= not knowing).

PS the remote is bound to the light as device but it shall not making problems and shall working if the host system is down.

And IKEA test (23 devices) was retested with the first Java and is still ticking (12 in around 2 hours):

Logger: zigpy_ziggurat.zigbee.application
Source: runner.py:289
First occurred: 08:06:59 (12 occurrences)
Last logged: 08:55:00

Delivery failed after transmission: aps_ack_timeout: aps ack timeout

No device was flagged offline in HA in both instances and in the zha-network-card.js listings.

[MattWestb]

New from the Mini RCP instance:
HA log:

Logger: zigpy_ziggurat.zigbee.application
Source: runner.py:289
First occurred: 13:27:38 (2 occurrences)
Last logged: 13:27:38

Delivery failed after transmission: aps_ack_timeout: aps ack timeout

Log from portainer (timestamp = UTC so minus 2 > stamp 11:27:38).
_addon_3ccd9485_ziggurat_logs.txt

Is debug OK or do you need trace ??

[MattWestb]

@ line 382/383:

2026-07-14T11:27:38.278877Z  WARN request{id=3329 method=send_aps}: ziggurat_driver::zigbee_stack::aps: APS ACK timed out for ApsAckData { src: Nwk(0x889f), destination_endpoint: Some(1), cluster_id: Some(32), profile_id: Some(260), source_endpoint: Some(1), counter: 79 }

0x889f = Styrbar remote so one sleeper

And @ 395/399:

2026-07-14T11:27:39.281872Z DEBUG ziggurat_driver::zigbee_stack::aps: Received APS ack: ApsAckData { src: Nwk(0x889f), destination_endpoint: Some(1), cluster_id: Some(32), profile_id: Some(260), source_endpoint: Some(1), counter: 79 }

So looks getting the ack but to late then both have the same command counter 79.