fix: deCONZ: Disable APS ACKs to not block queues for now

[manup]

Disable APS ACKs until better solution is found.

There are multiple reports of No ACK status code (0xA7) and Busy status code. This PR reverts the default global setting of using APS ACKs. The old adapter also didn't have them enabled.

Future perspective: The more I think about it a better way could be to emulate APS ACKs at the driver level. Which means still sending without APS ACKs so we don't block the firmware. But in case no response is received automatically retry within the timeout period. That allows a high number of parallel requests since on the host we aren't bound to memory restrictions.

Related issue:

• Nous Modell B3Z - reporting of power delayed after upgrade to 2.5.1 zigbee2mqtt#27886
• Lot of errors "Error: Command ApsDataRequest failed with status: Busy" zigbee2mqtt#27883

Perhaps related:

• TS011F_plug_3 are offline after updating 2.5.0-1 zigbee2mqtt#27887

@Koenkk currently marked as draft until the ZGP PR is ready (shouldn't take long)

[Nerivec]

Sounds like something that should be fixed in the firmware. Others all have APS ACKing (per ZigBee spec, a requirement for most requests) without problems.

---

By the way, you can get rid of NwkBroadcastAddress enum, it's already available in the ZSpec.

[manup]

Sounds like something that should be fixed in the firmware. Others all have APS ACKing (per ZigBee spec, a requirement for most requests) without problems.

Yes and no, upcoming firmware versions will have more APS slots (hopefully a lot more), but this can only scale so far regardless of the controller. I don't know how many buffers are available in other firmware implementations but they are all limited by RAM. Iirc the SiLabs EFR32MG21 has 96 kB, ATSAMR21B18 iirc 32 kB and CC2652RB 88 kB.

With route discovery and APS retries + timeouts a APS request slot could be occupied for quite some time. For large networks with enough unreachable nodes this hits sooner or later.

Ideally in future the Zigbee stack runs NWK and APS layers on the host which would scale pretty well even in large networks of 500 nodes and more.

[manup]

By the way, you can get rid of NwkBroadcastAddress enum, it's already available in the ZSpec.

Thanks, good to know will make a follow up PR.

[Nerivec]

Is deconz implementing concentrator mode for routing?

Might be more about the handling of the APS ACKing (kept too long, not fast enough, etc.) than the memory allocation (unless deconz currently wastes too much in that area)? There are a lot of really bad networks out there (offline routers, awful routers, massive interference), we'd have seen a lot more issues before with TI or Silabs stacks if it was just a RAM limitation I think.
FYI: Silabs firmware currently have 64 max in-flight unicast for MG21, and 128 for MG24, but it wasn't a problem even back when it was 32.

Also worth mentioning, Silabs coordinators had some issues with delivery failures a while back that were due to CCA problems (required configuration tweaking). That was mainly for broadcasts, but I figure you may want to check on that, just in case.

Ideally in future the Zigbee stack runs NWK and APS layers on the host

https://github.com/Nerivec/zigbee-on-host/ 😉
Works well already on Silabs & TI chips.
Not sure deconz hw has support for OT RCP firmware though?

[Koenkk]

Thanks!

[Timsche2210]

in my z2m config.yaml is no
advanced: disable_aps_ack: true

so it should be disabled by default, correct?
I still have the issues with the TS011F_plug_3 plugs :/