How can I check that the connection to the MQTT service is actually established?

• Neither tedge connect c8y nor tedge connect c8y --test tells a word about the MQTT service and status.
• I tried on purpose to break the config, no errors are returned by tedge connect.

Good. The bridge status published on te/device/main/service/mosquitto-c8y-mqtt-bridge/status/health is working and reports broken as well as correct settings.

=> I would add a test assertion that a status message of 1 is received on this topic.

Addressed in 7a827c8 by checking the health status of the bridge service in C8Y.

There's something really weird with multiple subscriptions on MQTT service. MQTT service is rejecting subscription requests with multiple topics from the built-in bridge, which is why this test case was failing. Here is the same reproduced with mosquitto_sub client:

$ mosquitto_sub -v -h albin.latest.stage.c8y.io -p 9883 -i albin-123 --key device.key --cert device.crt --cafile c8y-root.crt -u t37070943 -t sub/topic -t demo/topic
All subscription requests were denied.

Once you limit the subscription to a single topic, it works. This test also works when there is only one subscription topic.

But to my surprise, the mosquitto bridge with multiple subscriptions works just fine (as done in the first test case).

This was discussed offline, but the outcome was that it seems to be a current limitation of the MQTT Service, however we provided the appropriate RnD team that supporting multiple subscriptions would mean that the MQTT service would be more compatible with different MQTT tooling (and what users expect when interacting with such as service)

It is already working with mosquitto bridge as it sends separate subscription requests for each bridge rule. The same behaviour was replicated in built-in bridge as well with 584b438

Is this not better derived from c8y.mqtt, which will likely already have the correct domain for MQTT connections (I'm assuming this is the same issue as for standard MQTT connections)?

Resolved by 015ee3d

Given mosquitto seemingly does this by default, I wonder whether we actually don't want a flag and just want to change the behaviour to always use subscribe per topic.

Resolved by c06940e

Since August 7 release of MQTT service, device isolation is enabled by default preventing another MQTT client from receiving the message published by this device. Since there isn't any another easy option to test the message passing between the device and the cloud, you may turn device isolation off as follows (using your tenant admin credentials):

curl --location --request PUT "https://<TENANT_DOMAIN>/features/mqtt-service.tenant.isolation/by-tenant" \
--header "Authorization: Basic <AUTHORIZATION>" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data-raw '{ "active":true }'

before connecting the test client to subscribe/publish to the device topics.

Or using go-c8y-cli

c8y features tenants enable --key mqtt-service.tenant.isolation