Multiple Long-running commands

[romankiss]

The document described a simple example for Long-running commands. It will be nice to add couple examples for response with a complex type and also for component command.

I have tried many examples, but the command response history didn't show the finally respond via the reported property:

1. The following screen snippet shows sending a long-running command:

2. Get the command history using the REST API:

3. Finalizing a long-running command:

4. Raw Data:

As you can see the above, the device model accepted my long-running command reported property as a command response, but the command history is not changed:

5. Using the REST API to get the command history:

Document also doesn't describe what happen, when the IoT Central App will invoke multiple times this long-running command during its in-pending process. It looks like, there is no blocking to invoke the same long-running commands, something like we have it for standard commands, also there is no correlation id for each invoking call.

Another missing part in the doc for that long-running commands is related for commands with no response. Basically, I am expecting for long-running (in pending) commands their finishing always via the reported property included also for commands without the response.

One more thing, the standard and long running commands can received either a status code=200 or code=202. What about the code=400 (Bad Request)?

Thanks Roman

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 655f6e68-4cc4-af5f-8bbb-ce26b41cf082
• Version Independent ID: 34f57ba4-d744-774e-1d6f-0599dbf84a37
• Content: How to use device commands in an Azure IoT Central solution
• Content Source: articles/iot-central/core/howto-use-commands.md
• Service: iot-central
• GitHub Login: @dominicbetts
• Microsoft Alias: dobett

[AshokPeddakotla-MSFT]

@romankiss Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

[dominicbetts]

Hi @romankiss - I'm talking with the product team about this to figure out if it's a bug and about the expected behavior if a command is invoked multiple times. I'll let you know as soon as I hear anything back.

[romankiss]

Hi @dominicbetts, thanks Dominic, what about the issue related with updating a long-running (in-pending) command history by its reported property, which it will indicate, that the long-running command has been ended in the device direct method. Note, that this ending of the long-running command must work also for command with a no response required.

Thanks Roman

[dominicbetts]

I'm checking but it looks like a bug. What I'm seeing is:

• If the long running command is defined in a simple model (no components), then using the property to indicate completion works, and you see the value from the property in the command history.

• If the long running command is defined in a component, then using the property to indicate completion doesn't work, and you don't see the value from the property in the command history.

[romankiss]

I have created a new instance with a simple test mode:

The first part such as a status = 202 is working:

The following screen snipper shows a response payload for Get command hsitory:

Now, the command reported property is sent to the IoT Central: { "longRun2": { "Msg":"Done" } }

The Raw Data:

The respond from the Rest Get command hsitory:

The History on the command (portal):

So, based on the above, it looks like the simple model (in my instance) also doesn't work. The command history in the IoT Central App doesn't work properly based on the command reported property.

Thanks Roman

[romankiss]

Hi @dominicbetts, another issue in the command (standard and long-running) you can see, when anytime the device sent a command reported property, the IoT Central will delete the response property in the last command. In other words, when the standard command has been processed and then the device will send the command reported property, we can lost the last history of that command.

IMHO, the command reported property should be accepted only when the long-running command is in pending state (such as only the code=202).

Thanks Roman

[dominicbetts]

Hi @sandeeppujar - I'm assigning this to you so you can respond to @romankiss directly. Thanks!

[dominicbetts]

reassign:sandeeppujar

[romankiss]

Hi @sandeeppujar, did you have a chance to look at the issue with a Long running commands?

It looks like all behaviour for this feature doesn't work properly:

1. History of Request/Response messages (azure portal and REST API) are not displayed.
2. On the component level
3. the responseCode property is always 202
4. impact issue for responses when cleaning a reported property
5. doesn't handling a multiple long-running same command
6. any command response can be modified by reported property anytime without invoking a request message

Thanks Roman

[romankiss]

Hi @dominicbetts, please could you reassign this issue (IoT Central Bug) to another person?

Thanks Roman

[sandeeppujar]

@romankiss , sorry for the delay, the intent for long running command patterns is to send delayed updates. The pattern is the last run/update wins, we don't support multiple long-running same commands (I will confirm this).

[romankiss]

Hi @sandeeppujar, thanks for your reply.

It looks like, there is a bug implementation in the long running command pattern:

1. The long running command doesn't work for component level
2. There is no history of the Request/Response messages and also there is missing a responseCode in the portal version
3. There is no blocking mechanism for invoking a multiple long running commands
4. Any command response (standard or long running) can be changed without a command invoking
5. cleaning a reported property will make an impact for response of the commands

Thanks Roman

[sandeeppujar]

@romankiss, here a few follow ups

1. The component command response is not being mapped correctly, this should be { "sensors*enableSensors": { "value": "Done" } } where sensor is the component name and enableSensors is the command name. This should fix the experience issue
2. Long running commands are intended to provide a way to send delayed responses, they don't have the semantics of blocking. Multiple command executions are sent to the device and the command response is resolved to be the last known response.

[romankiss]

Hi @sandeeppujar, thanks for this input.

I have tried your format for command reported property name and the device model failed (_unmodeleddata), see my following screen snippet:

Note, that the command response has been updated, but the History still didn't show a pair of the Request/Response messages.

When I used the payload for component property (standard format), such as: { "sensors": { "__t":"c", "enableSensors": { "value":"Done" } } }

the property has been recognized by the device model:

It looks like, this is an implementation bug and the correct way should be the same like we have for component reported property. Note, that in this case, there is no update for command response.

Also, there is an issue when the History of command is asked by REST Get request. As you can see, the responseCode is always 202 and it should be also updated to the 200:

Thanks Roman

[romankiss]

Hi @sandeeppujar, @dominicbetts

Based on my testing related to the long-running command, I can see, there are two different implementations and it looks like, that each IoT central team made it differently.

The IoT Central v3 (the recently latest version) is a model driven application, so the command response via the reported property is accepted, see the following screen snippet of the Raw data:

Note, that this command response message is not forwarded to update a value of the command response, because its logic is based on the old version without the components, like it is shown in the following Raw data:

As the above picture shows, the message is recognized like property as an _unmodeleddata, but in this case the command response has been updated:

I hope, the IoT Central team will fix this bug and the document will be updated, too.

Thanks Roman

[sandeeppujar]

@romankiss - thank you for the detailed response, we will look into this

[romankiss]

Thanks @sandeeppujar, I have just published my article Azure IoT Central Tester, so I would like to update this issue.

Thanks again Roman

[dominicbetts]

Hi @sandeeppujar @romankiss - is this this issue resolved now? Thanks

[romankiss]

Hi @dominicbetts, it looks like this issue is not resolved.

Thanks Roman

[dominicbetts]

Hi @sandeeppujar - do you have any update on this? Thanks! Dominic