New device is named "MQTT Device"

[rina23q]

Describe the bug The new device created named MQTT Device <device name> and the type is c8y_MQTTDevice.

The root cause is, 114 is published by tedge-mapper-c8y earlier than 100 by tedge connect.

pi@raspberrypi:~ $ mosquitto_sub -t "#" -v
c8y/s/us 114,c8y_SoftwareUpdate,c8y_LogfileRequest,c8y_Restart

c8y/s/us 100,release_0.5_rina,thin-edge.io
c8y/s/e 41,100,Device already existing

Also, our connect order:

Successfully created bridge connection!

Checking if tedge-mapper is installed.

Starting tedge-mapper-c8y service.

Persisting tedge-mapper-c8y on reboot.

tedge-mapper-c8y service successfully started and enabled!

Sending packets to check connection. This may take up to 10 seconds.

Try 1 / 2: Sending a message to Cumulocity. 
Received expected response message, connection check is successful.

I think we just need to change the order, move tedge-mapper-c8y start after sending packets to c8y.

To Reproduce Run tedge connect c8y on a newly registering device.

Expected behavior Name: Type: thin-edge.io

Screenshots

Environment (please complete the following information):

• OS [Raspberry Pi OS 10]
• Hardware [armv7]
• System-Architecture []
• thin-edge.io version [0.4.3 release testing for 0.5]

Additional context It's regression after supported operation feature merged.

[didier-wenzek]

The correct way to fix this issue would be to establish a direct connection from the tedge connect command to Cumulocity to create the device there and to create the bridge only once properly done.

This would also make useless the double restart of mosquitto - a workaround that has been added because Cumulocity creates some of the topics only once the device is registered.

That said the quicker fix is to delayed the start of the mappers after the connection check. I would do that first, to have the time to implement a proper fix.