Child ids should contain the device id MQTT client

[toewsar]

Cumulocity recommends to use the device id of the MQTT client as part of each child device.

All children require a unique ID defined when creating the device. We recommend you to use a combination of the unique ID of the root device and a unique ID within the hierarchy.

See: device-hierarchies.

It is a valid case that there are multiple IoT Edges out in the field, which have exactly the same childs. To differ them in the cloud, they should have different externalIds.

My proposal is to prefix the child-ids with the device-id (e.g. $deviceId_$childId).

E.g.: When writing {"temp":30} to tedge/measurements/child1 on device MyUniqueDeviceId the mapper should forward it to c8y/measurement/measurements/create with payload: {"type":"ThinEdgeMeasurement","externalSource":{"externalId":"MyUniqueDeviceId_child1","type":"c8y_Serial"},"temp":{"temp":{"value":30.0}},"time":"2022-08-22T14:26:02.792698943Z"}

When creating the child device: 101,MyUniqueDeviceId_child1,child1,thin-edge.io-child

[didier-wenzek]

This is indeed a fix to consider.

• I see requesting unicity of chid device ids across device as a Cumulocity issue. Hence, such workaround is required.
• Having the c8y mapper adding/removing this prefix on the fly sounds a good proposal.
• However, we have to evaluate the impacts notably when a child device has been added from the cloud without following this naming convention.

[toewsar]

Any progress on this topic?

[reubenmiller]

@toewsar not yet, though we'd be happy to prioritise this issue if it is important to your use-case.

Alternatively, a simple registration process could be built on top of thin-edge.io to provide a child device registration mechanism, where the registration endpoint returns the fully qualified domain name that the child device should use. An example showing a custom registration services (via a HTTP request) is presented in this repository: device-registration-server

(update: apologies I just noticed that the referenced repository was marked a private, it is now public)

[albinsuresh]

@toewsar This has been implemented by https://github.com/thin-edge/thin-edge.io/pull/2266 as part of the migration of the thin-edge MQTT topics to the new scheme . This work is already merged and will be available from the next release. If a child device is using the new default topic scheme like te/device/<child-id>//, then the corresponding child in C8y will be created with an external ID: <main-device-id>:device:<child-id>.

[toewsar]

@albinsuresh Is there a reason for device in <main-device-id>:device:<child-id>? This makes the identifier even longer than it already is.

[albinsuresh]

@albinsuresh Is there a reason for device in <main-device-id>:device:<child-id>? This makes the identifier even longer than it already is.

That's a side effect of the new topic scheme that we've introduced. As per the new scheme, the default topic for a device is te/device/<device-id>// and the default topic for a service on a device is te/device/<device-id>/service/<service-id>. The corresponding C8y mapping of their external IDs would be <main-device-id>:device:<device-id> and <main-device-id>:device:<device-id>:service:<service-id> respectively, which as you can see, is derived from their topic identifiers. Those device and service keywords would be there only if you use the default topic scheme which doesn't require any explicit device/service registration, by default.

But, we also provide an explicit registration mechanism where you can completely override these auto-generated external IDs, and provide the exact @id that you'd want in the registration payload as described here. The value provided in @id will be used as-is, as the external ID.