Mosquitto MQTT Bridge -Usage and Configuration

A MQTT bridge lets you connect two MQTT brokers together. They are generally used for sharing messages between systems.

A common usage is connect edge MQTT brokers to a central or remote MQTT network. The Mosquitto broker (server) can be configured to work as an MQTT bridge.

Generally the local edge bridge will only bridge a subset of the local MQTT traffic.

In addition you only need to configure 1 of the brokers to act as the bridge, the other will act as a normal broker.

How an MQTT Bridge Works

When you configure the mosquitto broker to act as a bridge it becomes an MQTT client to the remote broker and subscribes and publishes to topics on the other broker just like a normal MQTT client.

Configuring the Broker as a Bridge

You will need to configure

• The Address and port of the remote broker or brokers. – Address keyword
• A client name. – Connection keyword
• What topics the broker will publish, and which topics it will subscribe to. -topic keyword
• Remapping if needed.

Note: You can configure multiple remote broker addresses and the broker will switch to another broker if the current broker connection fails.

Topic Bridging

What topics are being bridged, and if they are being remapped is controlled by the topic entry. Wildcards can be used in the topic entry.

The general format is

topic topic pattern direction QOS local prefix/remote prefix.

Direction can be out,in or both.

out = publish from the broker
in = receive from remote broker
both = publish and receive

Note: If you aren’t using topic prefixes then you don’t need to add them.

This is best seen in examples using the layout in the schematic below

Example 1

Configuration file topics

topic house/# out

Result:

client 1 publishes on house/sensor1 or house/anything and the message is sent to broker 2

client 1 publishes on house1/sensor1 and the message is not sent to broker 2

client 2 publishes to any topic and nothing is sent to broker B1.

Example 2

Configuration file topics

topic house/# in

Result:

client1 publishes to any topic and nothing is sent to broker B2.

client 2 publishes on house/sensor1 or house/anything and the message is sent to broker B1

client 2 publishes on house1/sensor1 and the message is not sent to broker B1

Example 3

topic house/sensor1 both 0 “” “”

or

topic house/sensor1 both 0

The entries:
topic house/sensor1 in 0 “” “”
topic house/sensor1 out 0 “” “”

Are equivalent to the single entry:

topic house/sensor1 both 0 “” “”

and also

topic house/sensor1 both 0

Result:

client 1 publishes on house/sensor1 or house/anything and the message is sent to broker B2

client 2 publishes on house/sensor1 or house/anything and the message is sent to broker B1

client 1 publishes on house1/sensor1 and the message is not sent to broker B2

client 2 publishes on house1/sensor1 and the message is not sent to broker B1

The screen shot below shows how to bridge all topics with no remapping.

MQTT Topic Bridging and Remapping

This is accomplished using the local and remote prefixes.

When the bridge on broker1 subscribes to a topic on broker2 it uses the form

remote_prefix + topic name e.g. b2/house/sensor1

When the bridge on broker1 subscribes to a topic on broker1 it uses the form:

local_prefix + topic name e.g. b1/house/sensor1

The topic prefixes follow the QOS entry.

The screen shot below shows a remapping configuration for broker 1:

With the above configuration then:

• When Client1 publishes on any topic that message will be sent to broker 2 with the topic prefix b2/. Example incoming client message to B1 on topic house/sensor1 is published to broker 2 on topic b2/house/sensor1.
• When a client publishes a message to broker2 then messages published on b2/# are sent from broker2 to broker 1 but without the b2/ prefix. A message published to broker 2 on house/sensor1 is not sent to broker 2 as it doesn’t have the b2/ prefix

Broker 2 Configuration

Broker2 is functioning as a normal broker (not a bridge) and doesn’t normally need any extra configuration.

Bridging and Topic Remapping Examples

 

The following examples refer to the schematic above with two brokers Broker1 and Broker2 . Broker1 is configured as the bridge.

Normal clients will also be connected to both brokers.

---

Entry uses remote prefix:

topic house/sensor1 both 0 “” b2/

Equivalent to

topic house/sensor1 out 0
topic house/sensor1 in 0 “” b2/

Result:

Incoming messages from a client connected to broker 1 on the topic house/sensor1 are being bridged and will be remapped and sent to broker2 on topic b2/house/sensor1.

Incoming messages from a client connected to broker2 on topic b2/house/sensor1. will be sent to broker1 on topic b2/house/sensor1.

Broker1 removes the b2 prefix and will send them to clients subscribed to house/sensor1 on broker 1.

---

Entry uses local and remote prefixes:

topic house/sensor1 both 0 b1/ b2/

this is the same as:

topic house/sensor1 out 0 b1/ “”
topic house/sensor1 in 0 “” b2/

Result:

Incoming messages from a client connected to broker1 on topic b1/house/sensor1 are being bridged and will be remapped and sent to broker2 on the topic b2/house/sensor1.

Incoming messages from a client connected to broker2 on the topic b2/house/sensor1. will be sent to broker1 on topic b2/house/sensor1.

Broker 1 removes the remote prefix (b2/) and then adds the local prefix (b1/) and will send them to clients subscribed to b1/house/sensor1 on broker 1

Working Bridge Example

Using the configuration shown above on Broker1 I am going to publish a message to Broker1.

Broker1 has the bridge configured to connect to Broker2 (IP address 192.168.1.157).

The topic bridging entry is:

topic # both 0 “” b2/

Broker1 accepts messages and publishes them to Broker2 with a prefix of b2/.

Broker1 subscribes to messages from Broker2 on topic b2/#

Using a simple python client we will :

• Publish a message to Broker1 on topic house/sensor1. Using a client name of P1
• Subscribe to Broker2 on topic b2/house/sensor1 -Using client name of P2

When you start the broker on broker 1.

• It connects to broker 2 and subscribes to the topics b2/#.
• Connects to itself and subscribes to topic #

This can be seen from the console log messages:

When I run the script this is what I see.

Broker 1 receives message on topic house/sensor1 and publishes them to broker2 on b2/house/sensor1.

Broker2 receives messages on b2/house/sensor1 from broker1.

Backwards Testing

I can also publish to broker 2 on topic b2/house/sensor1 and it should be sent to broker 1 and made available as house/sensor1.

So now I will alter my script to send to broker 2 on topic b2/house/sensor1 and subscribe to house/sensor1 on broker 1.

Here is a screen shot of the results.

Notice the message is received by the client subscribed to broker 1 n the topic house/sensor1

Topic Remapping and Topic Republishing

Topic remapping takes an incoming topic and renames it.

E.g A broker would receive messages to topic sensor1 and remap them to new_sensor1.

Currently this form of remapping is not available, but prefix remapping is as shown above.

Bridging to Multiple Brokers- Round Robin

It is possible to bridge to another broker in the event of a broker failure.

To do so you need to set multiple address:port entries in the address field i.e

address 192.168.1.168:1883, 192.168.1.185:1883

will use broker 192.168.1.185 if the connection to the first broker (192.168.1.168) fails.

The round robin setting controls what happens when the original connection is restored. Here is the description taken from the online manual:

Authentication and Encryption

If the remote broker requires a username and password then you need to enter this using the remote username and remote password options.

You can also encrypt the connection between the brokers.

This is likely to be a common configuration and Is covered in more detail in the Configure Mosquitto Bridge With SSL Encryption- Examples tutorial.

Looping

Publishing and subscribing to the same topic on the broker could result in a loop.

However if you try this you find that a broker detects that another broker sent the message, and doesn’t send the message back to it even though the broker has subscribed to that topic.

This confused me at first as looking through the specs I couldn’t find any reference for broker detection.

I did find this comment from Roger Light on a forum that explains it.

This seems to be triggered by the try private statement in the configuration file. This is what the config file states:

# If try_private is set to true, the bridge will attempt to indicate to the
# remote broker that it is a bridge not an ordinary client. If successful, this
# means that loop detection will be more effective and that retained messages
# will be propagated correctly. Not all brokers support this feature so it may
# be necessary to set try_private to false if your bridge does not connect
# properly.
#try_private true

Bridging to Thingspeak Note

I had a request for help regarding bridge configuration on mosquitto when creating a bridge to thingspeak.

If you need to do this you need the following two entries:

notifications false
cleansession true

See this forum comment

Problems Encountered

When configuring bridges you may encounter some issues. Here are some of the errors I’ve encountered.

Error message on broker –socket error on client <unknown>disconnecting

Cause – Configuration file error. In my case it was the PSK setting.

Problem – Remapping not working as it should.

Cause -I forgot the QOS entry

Video -How to configure a bridged connection on the mosquitto mqtt broker

Note: Bridging to Beebotte

If you need to create a bridge to beebotte then you need to use the try_private command as shown below:

This mosquitto.conf file works (Note that is not my real user token)

############
port 1888
log_type all
connection bridge-01
address mqtt.beebotte.com
try_private false
cleansession true
topic house/# out 0 
topic house/# in 0 
remote_clientid broker1
remote_username 5I6IJSjYNFtfcvNhEZXAAZXOpWWGZt6WfgAY
#remote_password ' '
#################################

Reducing TCP/IP connections

MQTT is a connection orientated protocol which means that each MQTT client has a connection to the broker.

Broker connections are TCP/IP connections which take up memory on the broker as each connection is allocated a memory buffer.

A very effective way of relieving the connection load on a central broker is to use edge brokers configured as bridges.

If you had 1000 clients that needed to connect to a cloud broker then the broker would need to support 1000 connections if they connected directly, but if you connected 200 clients to a gateway broker then the cloud broker would only need to support 5 client connections.

Summary

MQTT bridging on Mosquitto allows you to connect two or more MQTT networks together. MQTT bridging is likely to be used to connect edge networks to a central network. Generally only a subset of the local topics will be bridged.

Bridging Alternatives

You can also use a client to do the bridging rather than the broker.

This means that you don’t need to be a broker administrator to do it and your broker doesn’t need to support it.

See Bridging using the python client

Related Articles and Resources:

• Mosquitto.conf documentation
• Connecting the last 100 metres –
• Owntracks -bridging
• Implementing SSL on the mosquitto broker.

Mosquitto Configuration Tutorials

• Installing The Mosquitto broker on Windows and Linux
• Quick Guide to The Mosquitto.conf File With Examples
• MQTT TLS Security – Mosquitto Broker Configuration
• Configuring and Testing MQTT Topic Restrictions
• Mosquitto username and Password Authentication Configuration Guide
• Configuring Logging on The Mosquitto Broker