Downlink command lifecycle

A queued command is not a confirmed physical outcome.

Separate intent from delivery

Our proposed command service records who requested a change, what it means, which device it targets and when it expires. It then translates an approved command into the vendor’s payload format. The uplink library does not send downlinks.

requested → authorized → queued → sent → acknowledged
                      ↘ expired / failed / cancelled

Provider boundary

The Things Stack supports webhook-associated downlink queue operations. Its documentation distinguishes appending to a queue from replacing it and requires an appropriately authorized API key. Use provider documentation for your exact deployment and device class.

Safe application design

• Authorize commands against tenant, site and device ownership.
• Use an allowlist of model-specific operations and value ranges.
• Apply expiry, rate limits and an auditable operator identity.
• Track provider acknowledgement separately from observed device state.
• Require additional review for operations that can affect physical equipment.

A transport acknowledgement alone must not become a claim that equipment changed safely. Validate state feedback and define manual fallback for the specific application.