Closed toewsar closed 12 months ago
This is indeed a fix to consider.
Any progress on this topic?
@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)
@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>
.
@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 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.
Cumulocity recommends to use the device id of the MQTT client as part of each child device.
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
externalId
s.My proposal is to prefix the child-ids with the device-id (e.g.
$deviceId_$childId
).E.g.: When writing
{"temp":30}
totedge/measurements/child1
on deviceMyUniqueDeviceId
the mapper should forward it toc8y/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