Is there a native way to buffer device commands and replay on reconnect?

Help
,
1

Here’s a clean forum post:

Title: Is there a native way to buffer device commands and replay on reconnect?

Body:

Hi Losant community,

Is there any native capability in Losant to buffer commands sent to a device while it is offline and automatically replay/deliver them once the device reconnects to the MQTT broker?

If yes, would love to know how to set it up. Any documentation or examples would be helpful.

Thanks!

2

Hi @Surya_Kapisetti,

Commands are published on a device’s command topic immediately on invocation, regardless of if the device is connected to the broker or is subscribed to the topic at the time. So no, there is no native way to replay/deliver queued commands on reconnection.

That said, you could build such a queue in your Losant application. At a high level the solution would look like the following …

  • Whenever you wish to publish a command to a device, you first write a row to a data table that serves as the queue. That table should include columns for the device ID, command name, payload, and whether the command was acknowledged.
  • Using a Data Table Trigger, you can fire a workflow whenever a row is added to the table. That workflow would then send the command to the specified device using a Device: Command Node.
    • If payload consumption is a concern, you could use a Device: Get Node to determine if the device is currently connected to the broker and not send the command if the device is not currently connected.
    • I would recommend including the data table row ID in the command’s payload so that the device can use that to acknowledge that the specific command was received.
  • On the device side, you would have the device publish a message on a custom MQTT topic to tell the broker that the command was received by the device. You would include the data table row ID in the message body.
  • Back in a cloud workflow, an MQTT Trigger is subscribed to the custom topic the device published to and, using a Table: Update Row Node, updates the data table row to mark the command as received by that device.

That takes care of the queueing and acknowledgment. As for sending commands once the device reconnects …

  • You can fire a workflow using the Device: Connect Trigger to fire a workflow when the device reconnects to the broker.
  • In that workflow, you can use a Table: Get Rows Node to look up any unacknowledged commands for the device.
  • You can then iterate over those commands using a Loop Node and, within the loop, send them to the device using a Device: Command Node.

That’s a high level architecture, but your solution would also need to include …

  • Deduplicating commands queued for the device - or removing unreceived commands that are no longer relevant (i.e. “turn off the lights”, “turn on the lights”, and “turn off the lights” all in the queue).
  • Delaying commands sent to the device to ensure you do not exceed rate limits.
  • Handling cases (retrying) where commands are sent to a device but are never acknowledged.

Hope this helps. Let us know if you have any questions!