Option to set/update device metadata

[reey]

Is your feature request related to a problem? Please describe. The thin-edge for now supports sending data like e.g. measurements and is able to perform operations. But it should also be able to send meta information regarding the device itself.. We are currently not able to define/customize anything that is e.g. added to the c8y managed object. Information that is stored on the device managed object if used:

• device name (currently set using the CommonName value of the certificate)
• device type (currently hardcoded to thin-edge.io AFAIK)
• hardware model
• hardware revision
• hardware serial
• IMEI & ICCID and more mobile related information
• nearby cell tower information
• Required Availability & Maintenance Mode
• Device Location (latitude/longitude)
• Address information (Street/City/Country)
• Network information More can be found here: https://cumulocity.com/api/10.11.0/#section/Device-management-library

A solution for this should also be able to work with any kind of custom attributes, that might be usecase specific..

Describe the solution you'd like The thin-edge should have a way for the device to store this kind of information within the cloud. Since cumulocity stores this kind of information in cumulocity specific attributes, we need the mappers to translate from thin-edge attributes to the corresponding cloud specific attributes.

Describe alternatives you've considered We could do per cloud specific implementations within usecase specific plugins and use e.g. existing or newly created SmartREST templates for cumulocity to save this kind of information, but actually the approach with thin-edge should be to abstract the cloud specific implementations..

Additional context

[itsyitsy]

Hey @reey, thank you for raising that issue. Very nice with this good description! Actually we have some tickets that cover a subset of the fields already: https://github.com/thin-edge/thin-edge.io/issues/684 https://github.com/thin-edge/thin-edge.io/issues/686

For Agent Hardware and Firmware we initially thought about getting that automatically from the system, but its harder than expected to find common command for that, that works on the different distributions.

The latest plans are just to do it via configuration. So the user can configure it and thin-edge will care about giving it to the cloud. For the format of this config that's a tough question.

1. As some of these configurations are pretty cloud specific anyways, we could have a per cloud configuration. What fields are in this documentation is then open. It just gets reported anyhow.
2. With a generic config for all clouds together we have to define whats supported by which cloud. The outcome will be a predefined list of supported fields and therefore less flexibility for the user.

What do you think about this approaches, or do you have something completely different in mind?

[reey]

@itsyitsy As I'm not really aware of other cloud providers (e.g. Azure or AWS) and if they have actually fields where they would expect those values it is really hard for me to say which approach is the better one..

My thoughts were, that we could have topics like e.g. /device/metadata and /device/metadata/<deviceId> where we would send a JSON object like e.g.: { "hardware":{ "model":"Raspberry Pi", "revision":"3B+", "serial":"<mac address of device>" }, "mobile":{ "imei":"", "iccid":"" }, "position":{ "lat":51.0, "lng":7.0 }, "name":"custom-thin-edge", "type":"custom-thin-edge-type", "reeys-custom-attribute":{ "deviceColor":"red" } }

This JSON would then be processed by the mapper and generates a JSON structure that is cloud specific for those attributes known by the cloud and for attributes that are not known by the cloud, we would just pass their structure on to the cloud.. The output of the c8y mapper might look like this, then: { "c8y_Hardware":{ "model":"Raspberry Pi", "revision":"3B+", "serial":"<mac address of device>" }, "c8y_Mobile":{ "imei":"", "iccid":"" }, "c8y_Position":{ "lat":51.0, "lng":7.0 }, "name":"custom-thin-edge", "type":"custom-thin-edge-type", "reeys-custom-attribute":{ "deviceColor":"red" } } while e.g. for Azure the output might be just e.g. the input (in case they do not have any specifications which attributes need to be used for which information): { "hardware":{ "model":"Raspberry Pi", "revision":"3B+", "serial":"<mac address of device>" }, "mobile":{ "imei":"", "iccid":"" }, "position":{ "lat":51.0, "lng":7.0 }, "name":"custom-thin-edge", "type":"custom-thin-edge-type", "reeys-custom-attribute":{ "deviceColor":"red" } }

For c8y we could then perform the device update via the "inventory/managedObjects/update/<deviceId>" topic: https://cumulocity.com/guides/device-sdk/mqtt/#json

[makr11st]

Hi guys, #686 has implemented fragments, would you mind checking if this is all you have asked for and close the issue if that's the case?

[reey]

@makr11st I guess this is a good first step, but this does not cover adding attributes to child devices, or did I miss that?

[reubenmiller]

I would move the updating of child device fragments to a different ticket and close this one for now.