Is your feature improvement request related to a problem? Please describe.

When the basic auth credentials are used in the tedge-mapper-c8y, the tedge connect c8y --test is always successful since the s/uat method to check the connection is not available when using basic auth.

This means that even if the bridge is down (as visible in the service/status), the command will not detect the error.

Describe the solution you'd like

Work out a reliable way to verify the Cumulocity connection when using basic auth. If no server check is possible, then the bridge's service status should be used instead (to at least normalize the way users can check if the connection is up or not).

For newer Cumulocity versions, there is a SmartRest 2.0. template, 123, which can be used to request the device managed object's id, which provides a request/response pattern which might be suitable for a test.

Request

tedge mqtt pub c8y/s/us '123'

Response

$ tedge mqtt sub 'c8y/s/ds'
[c8y/s/ds] 124,3749509160

Describe alternatives you've considered

Alternatively, the SmartRest 2.0. template, 600, which can be used to request the Cumulocity server version, could be used, but it was only added around March 2025, so it is less likely to be supported, whereas the 123 template was added around March 2023 (two years earlier).

Additional context

• https://cumulocity.com/docs/smartrest/mqtt-static-templates/#600