Currently, pretty much all zigbee calls done in setupThing() fail because the stack is still starting at startup.
Now that plugins are reworked to also better query the device states on a reconnect, this starts to show in failing calls. This pull request does two things:
a) It queues up calls in zigbeenetworkdeconz while the network is starting so they can be sent once the backend comes up. The TI backend already does this. I'm not sure what happens in the NXP backend, it queues up calls but also passes it down to the controller as long as it is not Offline (i.e. also when it's Starting). Depends on the firmware if those are queued up or failing/being discarded.
b) it also finishes the incomplete implementation of the apsFreeSlotsAvailable controller state in that it marks it as full when we get the Busy status reply and resend the command once we get the controller state notification with freeSlotsAvailable being set to true.
Currently, pretty much all zigbee calls done in setupThing() fail because the stack is still starting at startup.
Now that plugins are reworked to also better query the device states on a reconnect, this starts to show in failing calls. This pull request does two things: a) It queues up calls in zigbeenetworkdeconz while the network is starting so they can be sent once the backend comes up. The TI backend already does this. I'm not sure what happens in the NXP backend, it queues up calls but also passes it down to the controller as long as it is not Offline (i.e. also when it's Starting). Depends on the firmware if those are queued up or failing/being discarded.
b) it also finishes the incomplete implementation of the apsFreeSlotsAvailable controller state in that it marks it as full when we get the Busy status reply and resend the command once we get the controller state notification with freeSlotsAvailable being set to true.