Device Name set to MQTT_DeviceId

Forum
,
1

Hello,

I’m connecting a device using thin-edge and have noticed some inconsistent behavior: the device name is sometimes set to “DeviceId” and other times to “MQTT_DeviceId”. I’d like to understand how to make this deterministic.

For context, here’s the flow:

  1. A custom microservice registers the device with Cumulocity (c8y)
  2. thin-edge downloads the certificate onto the device from c8y
  3. thin-edge connects the device to c8y

Any hints on what might be causing this or how to control it would be greatly appreciated.

Thanks!

2

The race condition comes from when tedge connect c8y doesn’t successfully run for some reason, for instance if the device goes offline between downloading the certificate and running tedge connect c8y for the first time. The tedge connect c8y send the Cumulocity SmartREST 2.0 registration message which will create the device with the desired name (which we use the certificate’s Common Name by default). The misnamed device occurs when registration message isn’t successfully sent to Cumulocity. What happens instead is that Cumulocity will auto create the device (when some other SmartREST 2.0 message is received) and set a default name following the convention MQTT Device {CertCommonName}.

Common Scenarios that can lead to this behaviour:

  • The tedge-mapper-c8y service is stated before you’ve run tedge connect c8y
  • tedge connect c8y fails due to some intermittent connectivity issue (afterwards it still leave the tedge-mapper-c8y service running)

Now for the good news. The name doesn’t have any impact on the overall thin-edge.io functionality, so it is purely a cosmetic annoyance. But to fix the issue I would recommend the following:

  • ensure that the tedge connect c8y is run before you start the services
  • manually update the name of the device by publishing the following message on the device (though only if you can’t guarantee the previous step):
    tedge mqtt pub -r te/device/main///twin/name "\"$(tedge config get device.id)\""

For testing, if you interesting in reliably reproducing the error scenario, you can run the following steps assuming you’re using systemd (which skips the tedge connect step on purpose):

sudo tedge config set c8y.url thin-edge-io.eu-latest.cumulocity.com
sudo tedge cert download c8y --device 'example0001' --retry-every 5s
sudo systemctl start tedge-agent
sudo systemctl start tedge-mapper-c8y
3

Thanks Reuben for the detailed explanation.

I am running few config commands, then I download the certificate and finally run the connect command. I am not sure how can I control the start of the service given I don’t do it explicitly.

I am running download and connect commands from the golang code.
For example:

image
image1034×555 32.1 KB

4

The tedge connect c8y will start the tedge-mapper-c8y service, but you might want to check that the service isn’t already configured to run for some reason (e.g. tedge-mapper-c8y is configured by default to start, or a container runs the tedge-mapper-c8y process directly etc.)

5

Cumulocity Mapper | Thin-edge

You can also look into disabling auto registration of entities. I think this solved the problem with MQTT … devices being created for us in most cases.