Sending commands from nRF Cloud to LTE Device

[ragruslan]

Hi!

In our project, we need to send cloud-to-device commands. By "command" I mean a request to do some short action, not a request to change device's configuration/state. We see two ways of sending such requests:

1. C2D messages

2. Device shadow

What are the pros and cons of each way?

Here I see a recommendation to use Device shadow for commands sending. But if we talk about commands in the sense I described above, would this recommendation be still actual?

If yes, is there a recommended way (or some sample) of Device shadow usage for sending such commands? I mean, which fields Device shadow should contain and some algorithm of updating desired and reported section during sending command and its execution.

In case of C2D messages, the main problem seems to be command delivery when the device is offline. Right? Or is there some mechanism for this case in nRF Cloud?

Thank you!

[dejans]

Hi,

I will look into your questions and come back to you possibly in the first half of next week.

Best regards,
Dejan

[dejans]

Hi,

C2D topic is best used as a return path for data requested by the device on a D2C channel rather than asynchronous commands for the device. If device is online, it will not receive messages on C2D or any other MQTT topic. For issuing commands by any means you wish, shadow would be appropriate to use. 

We have an example using "config" section in multi-service sample. Using a section for commands would be the same process. You could create "cmd" section in your shadow. You can use built-in AWS shadow delta mechanism and/or newly added transform MQTT topic, with nrf_shadow_transform_request().

Best regards,
Dejan

[justin]

In the meantime, I am now trying to at least have the device handle the delta message it receives while it is connected. Upon receiving the delta message (as per above) the device now publishes to $aws/things/<devceid>/shadow/update the following:

Try the following:

{
  "state": {
    "reported": {
      "config": {
        "cmd": "command"
      }
    }
  }
}

[teba99]

Hi justin ,

Ah, thanks -- using "state" works as expected ... now the cmd is processed and appears in "reported: config: cmd" in the full shadow. I think that addresses my first problem. For my information, can you explain why "state" is necessary when sending a device update via MQTT but is not allowed when using the API (UpdateDevice)?

However, the problem I still have is: When the device is online, it receives the delta update in the "desired: config: cmd" section (and can now process it, as above). But when the device is offline and then comes online, how should it retrieve the pending delta update? 

Thanks,
-- Terrence

[justin]

teba99 said:

why "state" is necessary when sending a device update via MQTT but is not allowed when using the API (UpdateDevice)?

"state" is necessary when interacting with the shadow via MQTT because that is what AWS requires.
it is not needed in the REST API since that is a custom nrf cloud API.

the device should subscribe to the /update/delta topic and it should receive delta events until they are processed. 

[teba99]

Hi justin ,

"state" is necessary when interacting with the shadow via MQTT because that is what AWS requires.
it is not needed in the REST API since that is a custom nrf cloud API.

Got it, thanks.

the device should subscribe to the /update/delta topic and it should receive delta events until they are processed. 

Unfortunately, the device simulator doesn't get any delta events after connecting. 

Here's the delta event when the device simulator is connected:

************** MESSAGE RECEIVED ***********

TOPIC: <deviceid>/shadow/update/delta

MESSAGE: {

  "state": {

    "nrfcloud_mqtt_topic_prefix": "prod/.../",

    "pairing": {

      "state": "paired",

      "topics": {

        "d2c": "prod/...",

        "c2d": "prod/..."

      }

    },

    "config": {

      "cmd": "command"

    }

  }

}

*******************************************

Then I stop the device simulator and send a new "cmd: command1" update via the cloud API. Then I start the device simulator. It subscribes (again) to /update/delta and fetches the full shadow:

************** MESSAGE RECEIVED ***********

TOPIC: <deviceid>/shadow/get/accepted

MESSAGE: {

  "desired": {

    "pairing": {

      "state": "paired",

      "topics": {

        "d2c": "prod/...",

        "c2d": "prod/..."

      }

    },

    "nrfcloud_mqtt_topic_prefix": "prod/..."

  },

  "reported": {

    "control": {

      "alertsEn": true,

      "logLvl": 3

    }

  },

  "config": {

    "activeMode": true,

    "locationTimeout": 300,

    "activeWaitTime": 300,

    "movementResolution": 120,

    "movementTimeout": 3600,

    "accThreshAct": 4,

    "accThreshInact": 4,

    "accTimeoutInact": 60,

    "nod": []

  }

}

*******************************************

The "cmd: command1" is not present. And even if the device simulator continues to be connected it never receives a delta update of the "cmd: command1". 

Thanks,
-- Terrence

[Tuomas P]

Hello, Justin is not able to contribute to cloud support anymore. I'll take over. Apologies for the delay. 

It is clear that our documentation needs more info on this topic. Issue reported

The notify of shadow update while device was offline does not seem to work as Justin describe. I'll try to reproduce the issue with simulator v2