search

Koenkk / Z-Stack-firmware

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

Reduce the APS ack wait duration #389

Closed pipiche38 closed 1 year ago

pipiche38 commented 2 years ago

here https://github.com/Koenkk/Z-Stack-firmware/blob/3406c6a0cd2b755f302f4cacd07b37497a86cc08/coordinator/Z-Stack_3.x.0/firmware.patch#L350 it looks like the APS Ack timeout as been reduced from 6s to 1s. What was driving this request ?

The question is related to ZED like eTRV which are configured on a 6s polling interval (default Zigbee). In such cases we will have a high probablility to get Ack timeout when send a new Setpoint to an eTRV type of devices !

Koenkk commented 2 years ago

This makes the recovery mechanism kick in faster (route discovery/network address retrieval). Could you check if settings this back to 6s indeed fixes your issue?

pipiche38 commented 2 years ago

This was more a question rather than an existing issue. I've integrated a number of eTRV Tuya and Danfoss/Popp and I know they rely on the polling mecanism (which is done on a 6 secondes window), so I'm trying to understand the impact of the 6 to 1 .

WIll see If I can set a test bed for that.

Side question:

Is z2m rely on the 6 seconds, or do you do retry when getting Ack ? I know that zigpy-znp is doing 5 retries with different ways, which for me doesn't make sense, as we should retry on the firmware stack for that which is doing the proper retry during the 6 seconds timeout windows

Koenkk commented 2 years ago

Is z2m rely on the 6 seconds, or do you do retry when getting Ack ?

z2m doesn't do this, this is handled in the stack. But z2m will retry requests when it fails (route discovery, network address retrieval)

pipiche38 commented 1 year ago

Because the plugin on my side is not doing the retry (except what is done by zigpy layer), I believe that I'm just in middle of this issue when doing OTA to a batterie based device.

While here , there is no reason to do route discovery, network address retrieval, the only thing is to wait that the end device is polling request.

We are using the zigpy stack which is then doing the all mechanism that you just mentioned here, and such without success as it is doing the retry around 5 seconds, which is not large enough.

While I would say that the change to 1s makes a lot of sense for main powered devices, for battery devices, then I really do not understand, and especially because we do not rely anymore on the firmware stack to do the retrys

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days