You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature improvement request related to a problem? Please describe.
If the local MQTT broker (e.g. mosquitto) is not configured with persistence, all retain messages are lost when the service is restarted. As a result all devices registration message, supported commands will not be sent to the platform
Start the tedge-agent service (before connection to the cloud)
Configure thin-edge.io to connect to Cumulocity IoT (this will al)
The tedge connect c8y will also restart the mosquitto broker which will remove all of the previously published retained message by tedge-agent before the tedge-mapper-c8y has seen the messages. This results in the device in the cloud having only partial information about the device.
Describe the solution you'd like
Since registration and device capabilities are fairly critical for other components to understand what the device is and what it can do (e.g. does it accept get/set configuration, software_update, firmware_update command etc.), it might make sense to publish these message every time the component connects to the MQTT broker (and not assume these message are persisted when the MQTT broker is restarted).
Describe alternatives you've considered
Additional context
Below shows an example of the reduced number MQTT message after the MQTT broker is restarted (when it is not configured with persistence).
Before the MQTT broker is restarted, the tedge-agent has previously registered itself and its capabilities:
Is your feature improvement request related to a problem? Please describe.
If the local MQTT broker (e.g. mosquitto) is not configured with persistence, all retain messages are lost when the service is restarted. As a result all devices registration message, supported commands will not be sent to the platform
Start the tedge-agent service (before connection to the cloud)
Configure thin-edge.io to connect to Cumulocity IoT (this will al)
tedge cert create --device-id example001 tedge config set c8y.url example.c8y.com tedge connect c8y
The
tedge connect c8y
will also restart the mosquitto broker which will remove all of the previously published retained message by tedge-agent before the tedge-mapper-c8y has seen the messages. This results in the device in the cloud having only partial information about the device.Describe the solution you'd like
Since registration and device capabilities are fairly critical for other components to understand what the device is and what it can do (e.g. does it accept get/set configuration, software_update, firmware_update command etc.), it might make sense to publish these message every time the component connects to the MQTT broker (and not assume these message are persisted when the MQTT broker is restarted).
Describe alternatives you've considered
Additional context
Below shows an example of the reduced number MQTT message after the MQTT broker is restarted (when it is not configured with persistence).
Before the MQTT broker is restarted, the tedge-agent has previously registered itself and its capabilities:
After restarting the MQTT broker using
systemctl restart mosquitto
, the majority of the message are no longer present.The text was updated successfully, but these errors were encountered: