support device profile operation

[reubenmiller]

Is your feature request related to a problem? Please describe.

Add support for the Cumulocity IoT device profiles feature which enable deploying firmware, software and configuration in one single operation, though each of the items are optional.

Describe the solution you'd like

The following are the requirements for the device profile feature:

• thin-edge.io is to implemented an abstraction over the Cumulocity device profile interface

  The device_profile capability should be published on the following topic:

  topic

  te/{identity}/cmd/device_profile
  

  payload

  {}

  The tedge-mapper-c8y, should translate the thin-edge.io device_profile capability to c8y_DeviceProfile when publishing the Cumulocity "Supported Operations" 114 message.

• the tedge-mapper-c8y should map the Cumulocity SmartREST template, 527 to the following local thin-edge.io command topic:

  te/{identity}/cmd/device_profile/{cmd_id}

• thin-edge.io workflows should be used to handle the processing of the device profile and reusing the existing firmware_update, software_update and config_update workflows to process each part of the device profile

• it should be possible to influence the processing order of the device profile by customizing the device_profile workflow

• the current device profile should be stored so it can be checked after after the device_profile command has been acknowledged (similar way to how the current firmware name/version is tracked)

Describe alternatives you've considered

Additional context

Device Profile Flow

The Cumulocity IoT device profile flow is as follows, though be sure to read the official documentation.

1. Receive the c8y_DeviceProfile operation via the c8y/devicecontrol/notifications topic

2. Convert the payload to an abstracted payload (TBD) and publish to the local te topic:

   te/{identity}/cmd/device_profile/{cmd_id}

3. Set the operation to executing

4. Publish a 121 SmartREST message to Cumulocity indicating that the device profile has been received and is in the process of being executed (in addition to the normal operation status transition!)

   topic

   c8y/s/us
   

   payload

   121,false,[profile_id]
   

   Note The [profile_id] is optional, though it would be better to be explicit if the profile_id is available (it is part of the Cumulocity operation payload)

5. Processing the different parts of the device profile

6. Publish a 121 SmartREST message that the device profile has been executed

   121,true,[profile_id]

7. Set the operation to SUCCESSFUL or FAILED

   If one part of the device profile fails, then the whole operation should be set to FAILED.

Cumulocity Device Profile Payload

An example Cumulocity IoT c8y_DeviceProfile payload is shown below:

{
   "profileName": "my profile",
   "profileId": "158751",
   "c8y_DeviceProfile": {
       "software": [
           {
               "name": "curl",
               "action": "install",
               "version": "2.3.4",
               "url": "http://my.url.com"
           },
           {
               "name": "cumulocity_agent",
               "action": "install",
               "version": "1.2.3",
               "url": "https://cumulocity.com/agent"
           }
       ],
       "configuration": [
           {
               "name": "ssh_conf",
               "type": "ssh_conf",
               "url": "http://cumulocity.com/conf"
           },
           {
               "name": "agent_conf",
               "type": "agent_conf",
               "url": "https://demos.cumulocity.com/inventory/binaries/156719"
           }
       ],
       "firmware": {
           "name": "device_fw",
           "version": "1.0.1",
           "url": "https://cumulocity.com/fw"
       }
   },
}

Out of scope

• Atomic device-profile rollback. Individual components are responsible for handling any rollbacks if applicable (e.g. firmware does it's own rollback handling)

[didier-wenzek]

**Note** The `[profile_id]` is optional, though it would be better to be explicit if the profile_id is available (it is part of the Cumulocity operation payload)

Looking C8Y documentation, I don't see where this profile ID is defined and passed to the device.

• the current device profile should be stored so it can be checked after after the device_profile command has been acknowledged (similar way to how the current firmware name/version is tracked)

Is this enough to store the latest profile ID (if any)? Or its content (the payload published on te/{identity}/cmd/device_profile/{cmd_id})? Or what has been successfully applied (a subset of the command payload)?

[reubenmiller]

**Note** The `[profile_id]` is optional, though it would be better to be explicit if the profile_id is available (it is part of the Cumulocity operation payload)

Looking C8Y documentation, I don't see where this profile ID is defined and passed to the device.

• the current device profile should be stored so it can be checked after after the device_profile command has been acknowledged (similar way to how the current firmware name/version is tracked)

The .profileId can be read from the message received on the c8y/devicecontrol/notifications topic.

Is this enough to store the latest profile ID (if any)? Or its content (the payload published on te/{identity}/cmd/device_profile/{cmd_id})? Or what has been successfully applied (a subset of the command payload)?

At this stage just keeping the profileId and profileName should be enough. The Cumulocity IoT device management UI will show a diff to the user to show the difference in the profile and contents. Though we can build upon this feature in the future.

[gligorisaev]

QA Checked all described features and confirms successfull operation

Ongoing testing and possible automation using RAUC