Continuously Monitoring Connection Status to c8y

Forum
1

What is the suggested way of monitoring on the device itself if the connection to Cumulocity is up?

I’m running into the situation that if the internet connection fails at some point, then thin-edge doesn’t notice it and just continues blindly trying to send data to Cumulocity. The status of the service locally is healthy.

Basically, I want to be able to locally monitor the connection from thin-edge to Cumulocity and be able to do something locally if the connection is down for any reason. This could be anything from a local log message to a device restart, to a fall back on another communication method, etc.

2

thin-edge.io offers multiple ways to monitor the connection locally and do some follow up action.

Option 1: Monitoring on the local MQTT broker

Checking the bridge status will depend on a thin-edge.io setting, mqtt.bridge.built_in, which controls whether the mosquitto bridge is being used, or the Rust based built-in bridge which is included inside each cloud mapper.

You can check which bridge type you’re using by checking the following tedge config value.

$ tedge config get mqtt.bridge.built_in
true

Once you have the value, then you can subscribe to the following MQTT topics. Below shows how to subscribe to the MQTT topic using the tedge command, but you can use any tool to subscribe to the MQTT topic (e.g. mosquitto_sub or any specific library).

Note: In the future, we will be change the default to use the built-in bridge as it gives us more control over the connection, and we can support other features like proxies, HSMs etc.

When using mosquitto bridge (mqtt.bridge.built_in=false)

$ tedge mqtt sub --count 1 'te/device/main/service/mosquitto-c8y-bridge/status/health'
[te/device/main/service/mosquitto-c8y-bridge/status/health] 1

When using built-in bridge (mqtt.bridge.built_in=true)

$ tedge mqtt sub --count 1 'te/device/main/service/tedge-mapper-bridge-c8y/status/health'
[te/device/main/service/tedge-mapper-bridge-c8y/status/health] {"status":"up"}

Option 2: Using tedge connect c8y --test

Another option is to use the tedge connect c8y --test command to verify the connection. This connection will do a full connection check by actively sending a message to the server to verify that it is actually working successful, so it will result in more data being sent, but depending on how often you plan on invoking it, then the increase might be negligible.

This method is convenient to use in scripts as the exit code of the tedge connect c8y --test command will be determined based on the outcome of the test, so this means you can use it in an if statement nicely:

#!/bin/sh

if ! tedge connect c8y --test; then
    echo "Device is not currently connected to Cumulocity"
else
    echo "Device is currently connected"
fi
2 Likes
3

With regards to option 1:
What causes the health of the bridge to switch to 0/down?

4

It could be for multiple reasons, as the health changes to 0 anytime when the bridge is disconnected from the cloud MQTT, so such events would be:

  • mosquitto is restarted (as the mqtt client would be disconnected)
  • device loses connectivity to the cloud
  • cloud MQTT broker can disconnect the bridge (i.e. the MQTT client) if invalid messages are published to it (as per the MQTT Broker spec)…though I don’t think this happens often.
5

I apparently did bad testing. Retesting this again, the bridge status correctly went to 0 when pulling the plug to the internet.

Maybe I was just too impatient.

Thanks again!