MQTT Bridging

Bridged MQTT Setup

Prerequisites -> [Mosquitto Broker] .

Submitted by Guru of Nothing

If you are using MQTT for your automation backbone, you may need to have more than one MQTT broker. In my case, I have a main broker that the majority of my devices connect to in the local network (Skynet, a VM on an enterprise server locally) and I have a secondary broker (PiBridge, an rPi) that is located in the node cabinet at my gate. There are a number of devices at the gate that are critical and if the power goes out to the property, these are powered by 12v battery. Skynet will go down and the gate devices MUST have a broker. So a bridged setup is vital. I installed a Lite version of Raspi OS (previously called Raspbian) on a rPi 3b+ and enabled SSH. I then installed Mosquitto. The rPi is powered from the battery that all the other devices there use for backup power.

The basic bridge is pretty simple. There are lots of options for this and it gets pretty complicated rather quickly. Take a trip over toSteve's place if you want more info and additional options and use cases. I am sticking with a simple relay between the two. At the most basic, you need to set up ONE (and only one) of your brokers to be the bridge. For this 'relay' connection DO NOT do the following to both or you will create a messaging loop that will bork both of your brokers and make your devices want to commit suicide. Let's set up the bridge. These are Linux instructions, though the Windblows instructions are the same.

Setup

Find the location of your mosquitto.conf file in the primary broker. In my case its in the /etc/mosquitto folder. Use whatever editor applies to your tastes, but I like vim. You must have admin access to modify this file

sudo vim /etc/mosquitto/mosquitto.conf

In the file you will need to add the lines that create a bridge. Add in the following:

#External MQTT Broker
allow_anonymous true
connection <your_second_broker_name>
address other_broker_IP:1883
topic # out 0
topic # in 0

Save the file and restart your broker (More than likely by restarting the computer)

Important Notes #

• 'allow anonymous true' is required if you DON'T use name and password for your broker communications. Additional lines are required if you DO use authentication.
• Replace <your_second_broker_name> with whatever you want your other broker named internally. You must have this line but you can call it anything you'd like. I use DNS in my network so I named the same as the devices hostname.
• Replace other_broker_IP with the IP (or name if you have DNS set up in your network) of your second broker. If you use non-default or secured port numbers, change 1883 to the correct number of your broker
• The topic in and out lines tell the broker to subscribe to every message broadcast from the second broker and to broadcast out every message received directly on the first TO the second. This is why you don't want to do this to BOTH brokers. They will sub and publish to each other until their little brains fall out. Besides, it angers the IT folks in the matrix... just saying.
• BONUS NOTE: If you want to restrict what is sent between them, i.e. to not send STAT messages back and forth, you can change the '#' to specific topic and only that one will be rebroadcast... Refer to Steve's tutorial for more of that mind numbing configuration.

Testing

To make sure that you have it set up correctly, use your visual client of choice (I use MQTT Box) and open two instances. One needs to be connected to each of the brokers. Pick a topic and sub to it in each window... let's use 'broker/testing' for giggles. Then open a publish screen in both windows. Publish the payload "Hello World" to 'broker/testing' topic on one and make sure that in your sub screen "Hello World" shows up on BOTH brokers sub screens. If it does, good. If not, you did something wrong (like probably not restarting the broker you made the .conf file mods to). This tests that you have communication in one direction, broker to broker. Now, publish the same message to the same topic in your other window and make sure the message shows up in the subscribe screens of both brokers. This tests communications going the other way. Worked? Great! No? You need to troubleshoot...