Bridges

A bridge is a built-in MQTT client in the broker which can connect to another broker and forward messages between the brokers.

Configuration

Bridges are configured from the Bridges page in the console. If you are on Cute cat plan you're missing Bridges feature.

Username, password, hostname and port are mandatory values needed to connect to the remote broker.

Topic will be used in subscription in the local broker and/or the remote broker, depending on the direction configuration.

• Out will publish messages from local broker to remote broker
• In will receive messages from remote broker to local broker
• Both will publish and receive messages

Local and remote prefix is used to remap subtrees of topics. The topic entered in the topic field will be prepended with the remote/local prefix before the subscriptions is done. E.g. for a out bridge where topic=A and local prefix=sub/tree the broker will subscribe to the local topic sub/tree/A but publish the messages to A in the remote broker. If you then set remote prefix=some/path it will be prepended to the topic on publish which means that the message will be published to some/path/A in the remote broker. Topic can be set to # to forward all local topics under sub/tree to remote topics under some/path.

Advanced configuration

Advanced configuration let you set options like TLS/SSL and Quality of Service.

Remote clientid is the clientid the bridge will use for the remote connection. If left empty the bridge will use a combination of the bridge configuration identifier (generated by CloudMQTT) and the hostname.

TLS/SSL enables TLS for the connection. When set you'll be able to select which TLS version the bridge should use.

QoS sets the Quality of Service the bridge will use for publish and subscribe.

Keepalive interval is the maximumber number of seconds the client can idle before it's being treated as disconnected due to timeout. The bridge uses PING to stay alive.

Clean sessions controls whether the boker and client should clear stored states when the client reconnects after a disconnect.

Try private set will make the bridge indicate to the remote broker that it is a bridge, which will help detect message loops. Some brokers doesn't support this, so disable this if your bridge can't connect.

Examples

Some times it's not always straight up how to configure a bridges with another MQTT service.

Azure IoT Hub

Hostname, username and password should be pretty straight forward, just make sure to include SharedAccessSignature in your password. Then you need to set remote clientid to your device name, enable TLS/SSL and select TLSv1.2, and set port to 8883.

Azure IoT hub only allows messages to be published to devices/[device-id]/messages/events/. This means that you must configure topic and/or topic prefixes wisely if you're gonna use your cloudmqtt instance to other things than a brige to Azure IoT hub. If you set the bridge topic to # all messages published to the broker will be forwarded to Azure, meaning that you can only publish messages to devices/[device-id]/messages/events/ or the bridge will be disconnected by Azure.

You can set the bridge topic to devices/# to only forward topics prefixed with devices/. Another approach is to use the local prefix option to redirect topics with a custom prefix. E.g. you could set local prefix to azure/ and topic to # to forward messages published to any topic prefixed with azure/. The bridge will remove the prefix before the message is published to Azure, which means that if you publish a message to azure/devices/[device-id]/messages/events/ it will be forwarded to devices/[device-id]/messages/events/ in azure.

Also make sure to read Microsoft's docs on Azure IoT hub and mqtt.