Additional Metadata & Methods for Device Commands

In order to fully take advantage of Device Commands, I believe a few additional pieces of metadata are needed in the Device Command/s Schema.

  • UUID
  • Target Device ID
  • Status (mutable)

Additionally it would be ideal to include a Patch method for updating the status of a command. This would allow execution state to stay with the command instead of needing to handle it elsewhere. Along with the other feature I’ve requested (here), this would allow fine-grained control of peripheral commands including queuing and introspection.

Of course most of this I can manage via payload properties, but it’s extra work that likely should just be included in the schema IMO.

Thoughts? I’m concerned that perhaps a stream/log object is being used on the backend rendering this whole object immutable…which would invalidate the state tracking for commands probably. But you’ll have to tell me :slight_smile:

@Frederick_Loucks,

I just want to take a second to explain how we’re sending/receiving device commands. In our documentation, we explain that device commands are sent with the following payload:

{
  "name": "the-command-name",
  "payload": {
    "key": "value",
    "another-key": "another-value"
  }
}

They can be sent via MQTT, the Losant API, or through a workflow output node. All three options, though, leverage the Losant specific topic for the MQTT broker, losant/<device-id>/command (which you can read more about here). The payload of that command message is mutable, too.

So, after explaining this, I’ll address your points:

  • UUID

Do you mean a UUID for the command itself? Or are you looking for a UUID of something that already exists? If you are using a workflow to send device commands, you could create a random string or make a request to a UUID API or our Generate ID Node and include it in the payload of the command.

  • Target Device ID

As I mentioned, if you are using MQTT or the workflow output node to send device commands, the Target Device ID is a part of the topic. Again, if you are using a workflow, you can add this value to the command payload by getting this value either from the workflow or with a Device: Get Node and can send the ID along in the payload of the Device Command message.

  • Status (mutable)

I’m interested in what you ultimately would like to see here. Are you looking for something like sending a device command from the cloud, then being able to see somewhere that that command is “Pending” until some event occurs? Currently the only difference between a Device Command message and a regular MQTT message is that we store a history of commands that can be retrieved via our API. Once you send a Device Command, that’s where our message lifecycle ends. There is currently not a method in place for us to know if the device received that command, if the device did what it was supposed to do, or if it failed. But, there is a workaround, you can have the device that received the command publish to a topic on successful receipt of a command (or upon successful completion of a task due to the receipt of a command).

All this being said, your requests today have sparked some internal conversations regarding our Device Commands and Device Command lifecycle. There are some features here that would make sending, receiving, and acting on Device Commands much easier.

Again, once I have more information on my side, I’ll be sure to keep you updated! And, once I have more information on the above, I’ll get those features in for you as well :slight_smile:

I hope this information was helpful.

Thank you,
Heath

Hey @Heath,

I think the spirit of the requirement is that Commands, like Devices, have a lifecycle. Each time a command is issued, it’s unique. If this is purely an MQTT message with a persistent log, it’ll be a lift to get mutable state and such (and your workaround is understood).

UUID in this case would be for the command instance…but since it’s an MQTT message/log entry it’s not really an object, so a UUID doesn’t make sense under the current architecture. I’d just do as you said and add it to my payload.

Target Device ID…yep, understood. I can enrich this data myself.

Regarding the state…at a high-level you got it. The issue I’m trying to overcome is message handling…strict per-device FIFO queuing and “exactly once” semantics. If I send a reboot to a device, I want to know the lifecycle of that command in the logs…because I want to make sure I don’t fire off more commands until I’ve confirmed that command is complete. If I were writing firmware on the device I could simply say “Don’t get any more commands until I’m done doing this one”…but my interaction with most of my endpoints is via CLI or worse, so I have to poll these devices if I want to know if they’re ready for something else…and they don’t always offer a good way of asking. Better for us to say a command is “Pending” and don’t send anything until either the TTL has expired or explicit confirmation is received.
With a reboot…I might get away with not knowing when it’s been completed…but if I’m doing a firmware update, I need to be certain that I don’t send anything else until the device is ready. If I want to issue commands that access internal device APIs and perform deeper actions, I need a way to track the progress of those events in the digital twin on the Losant server-side.

At this point, I’m not sure I’d even want a FR to be submitted on these points since perhaps broader overhaul is needed. I’m working up an architecture of Edge Workflows as microservices that will perform this handling…when it’s closer to being done I can share with you and the product team to take you through it if you’d like.

@Frederick_Loucks,

I’m totally with you, and I really appreciate the extra information and insight into your use case.

Your questions and requests have sparked a lot of internal discussion. We are still discussing on a best path forward. Once it is decided which path we will take, and which features will be implemented, I will be sure to follow up with you and keep you in the loop on all our updates.

Looking forward to speaking with you more.

Thank you,
Heath

1 Like