Per spec (§7.2.6.2), if a node is temporarily unable to service a Get/Set command, it returns an ApplicationBusy response. The controller must wait and retry. Currently ApplicationCommandHandler extracts ReceivedStatus but never acts on it.
Scope:
- Parse
ApplicationBusy command (Status: 0=try later, 1=try in N seconds, 2=request queued) and ApplicationRejected command
- In the Driver's command send path, when a response is
ApplicationBusy:
- Extract the wait time (default 1s if not specified, cap at 30s)
- Delay further commands to that node for the wait period
- Re-send the original command after the delay
- Limit retries (e.g., max 3 attempts) to avoid infinite loops
- When a response is
ApplicationRejected, treat as a command failure (do not retry)
- Add
CommandClassId.ApplicationStatus to the NIF-excluded list (this CC is always advertised regardless of security)
Design notes: For this we need per-node send throttling - this dovetails with the existing single-pending-command-per-node constraint. Could be implemented as a retry wrapper around SendCommandAsync.
Per spec (§7.2.6.2), if a node is temporarily unable to service a Get/Set command, it returns an
ApplicationBusyresponse. The controller must wait and retry. CurrentlyApplicationCommandHandlerextractsReceivedStatusbut never acts on it.Scope:
ApplicationBusycommand (Status: 0=try later, 1=try in N seconds, 2=request queued) andApplicationRejectedcommandApplicationBusy:ApplicationRejected, treat as a command failure (do not retry)CommandClassId.ApplicationStatusto the NIF-excluded list (this CC is always advertised regardless of security)Design notes: For this we need per-node send throttling - this dovetails with the existing single-pending-command-per-node constraint. Could be implemented as a retry wrapper around
SendCommandAsync.