Configuring Mosquitto Bridge
Are you familiar with MQTT, the IoT standard protocol, and its popular broker, Mosquitto? One of Mosquitto’s most notable features is Bridging.
What is the definition of Mosquitto Bridge, and why do we need it?
In a nutshell, Mosquitto Bridge allows users to connect two or more Mosquitto brokers to share information with each other.
MQTT Bridge has proven to be useful in industrial production environments with multiple information aggregation levels. These levels can be represented using the concept of the “Automation Pyramid,” which categorizes and names the different levels of automation in a manufacturing process (see the image below). The pyramid starts at the shopfloor level, where machine controllers, sensors, and actuators are located, and extends up to the enterprise resource planning level.
To enhance resource efficiency and production performance in a sustainable manner, we recommend employing data-driven optimization algorithms by integrating operation technology (OT) at lower levels and information technology (IT) at higher levels. In this case, bridging is essential to enable and implement this integration effectively.
Two contrary factors mainly drive the development of bridging technologies:
- The high amount of data sources from different and diverse locations need to be accessible in a uniform and centralized manner (e.g., data lake)
- At the same time, there needs to be stringent information security and protection requirements that do not compromise accessibility.
The following sections describe and show three different technical concepts for bridging.
- First is the well-known bridging of two or more Mosquitto MQTT brokers.
- The second is a technical function currently under development that bridges MQTT and HTTP endpoints like well-known webhooks.
- The final concept is an emerging approach that involves smart and dynamic bridging. This approach is based on the changing needs of data sinks or data analytics to consume the information needed.
Mosquitto MQTT Bridging Configuration
Figure 1 depicts a classical, straightforward concept of structuring and condensing information. Assume you have multiple brokers on the shopfloor level with several production lines (e.g., line 1, line 2, and line 3).
The challenge here is to define a data scheme to name and identify the topics and configure Mosquitto bridges. We recommend using the Pro Edition for Mosquitto to configure your MQTT bridges.
Example of a Mosquitto bridge
So let’s take an example configuration and refer to Figure 1. The following lines are part of the Mosquitto bridge configuration file which is usually found in /etc/mosquitto/mosquitto.conf on Linux. Here, you’ll be able to find the configuration file documentation: mosquitto.conf man page | Eclipse Mosquitto.
1 connection OT-to-IT
2 address broker-site-01.local:8883
3 bridge_insecure false
4 bridge_capath /etc/ssl/certs/
5 remote_password verysecret
6 remote_username bridge
7 remote_clientid level02-line01-broker
8 try_private true
9 topic # in 0 down/ to-level/02/line/
10 topic # out 0 up/ from-level/02/line/The snippet is part of the configuration belonging to broker Line 1, which connects to broker Site 1.
- The keyword ‘connection’ indicates that a bridge configuration will follow.
- The parameters:
address,bridge_insecure,bridge_capathensure the use of a TLS-secured communication between brokers Line 1 and Site 1. - The set of credentials:
remote_password,remote_username, andremote_clientidare used for authentication and authorization.
Broker Line 1 acts as a normal MQTT client from the remote broker’s point of view. The exception to this is the setting try_private true, which means that when the client (broker Line 1) connects, it tries to indicate that it is a broker and establishes a bridge. (By default, the setting try_private is true, so it is not required to set it explicitly to true). This parameter minimizes the risk of recursive topic publish/subscription loops. However, this is not the standardized option, so connecting to brokers other than Mosquitto may not work.
Core Mosquitto bridge settings
The last two lines of the above snippet highlight the core functionality and settings of the configuration. They define the topic pattern that will be used to share and filter messages between the two brokers, Line 1 and Site 1 – any topics matching the pattern (which may include wildcards) are shared. Check out our Essential Guide to MQTT Topics and Wildcards blog for more information.
The general syntax is as follows:
topic pattern [[[ out | in | both ] qos-level] local-prefix remote-prefix]To explain this configuration option, let’s set the first example as:
topic # both 0- This bridges all topics in both directions with a Quality of Service level 0. Since no topic mapping is applied, clients on both sides of the bridge can publish or subscribe to the topics without noticing that all messages are copied between the brokers.
Now if we look at the last line of the configuration snippet, the topic pattern configuration is set to:
topic # out 0 up/ from-level/02/line/The configuration results in a topic mapping with the following functionality:
- When a message “Hello from Level 2” is published on broker Line 1 on the topic
up/1/state/info, it will also automatically be published to broker Site 1 with the same content but on the topicfrom-level/02/line/1/state/info. - The # wildcard for any topic published to broker Line 1 with the prefix
up/ensures that the bridge connection will publish the same message to broker Site 1 with the prefixfrom-level/02/line/.
The same approach is realized in the opposite direction by configuring the bridge topic pattern:
topic # in 0 down/ to-level/02/line/- If a message “Start working” on broker Site 1 is published on the topic
to-level/02/line/1/device_name/order, it will automatically be published with the same content on the topicdown/1/device_name/orderon broker Line 1.
Imagine a scenario where a device with the id dev1 is now connected via MQTT to the Line 1 broker. The device can now subscribe on the topic down/1/dev1/order to receive messages also from clients which are connected to the broker Site 1 (refer to Figure 3).
So far, a bridge between broker Line 1 and Site 1 has been established on the given topic patterns (up/ → from-level/02/line/ and down/ → to-level/02/line/). But in a real production environment, connecting many devices or machine controllers equipped with their own MQTT brokers may be necessary. Doing so will allow selected information to be published and received (subscribed) at any level as shown in Figure 1.
To show how to extend the configuration for this scenario, let’s assume that MQTT brokers in the lower levels (shopfloor) can be connected immediately without encrypted connections or user credentials. In real-world configurations, security options or mechanisms like firewalls or virtual or physically separated networks must be set to ensure information security.
Bridging multiple brokers
We will now add two more brokers – Line 2 and Line 3 – located on Level 1 in Figure 1. Both brokers are configured to bridge messages to and from Level 2, and both configuration extensions are identical except for the bridge topic pattern and the connection name.
1 connection line02-line01
2 address 10.2.0.22:1883
3 topic down/2/# in 0
4 topic up/2/# out 01 connection line03-line01
2 address 10.2.0.22:1883
3 topic down/3/# in 0
4 topic up/3/# out 0To explain this function clearly, let’s consider two MQTT clients. Client A is connected to broker Line 1 and publishes a message on the topic down/2/dev2/order. Client B is connected to broker Line 2 and has a subscription on down/2/dev2/#. As a result, Client B will receive the messages sent by Client A.
Client C on broker Site 1 can publish the topic to-level/02/line/2/dev2/order which will also publish the message to the other two bridges (refer to Figure 1).
The process works in the same manner in the opposite direction. A client with id 4713 connected to broker Line 3 publishing on the topic up/3/4713/info will receive messages on broker Site 1 on the topic from-level/02/line/3/4713/info.
Configuring topic patterns for bridges can be challenging, especially if the approach is to ensure the inclusion of the conceptual data architecture in the topic tree. The effort spent on configuration will yield benefits later on. For example, take thousands of sensors in production that publish their data to the data lake (data repository). It will be easier to apply data analytics to this data lake later on if your topic names are meaningful, and you can use them to filter for specific information in the topic tree.
Concept of HTTP bridge, currently under development
The concept of an HTTP bridge is similar to the MQTT broker bridge. The only difference is that an HTTP endpoint can be set instead of the remote broker in the configuration.
But why is it needed, and why is it an innovative advanced feature of the Mosquitto MQTT broker, and why is it needed? Let’s look back at our example scenario in Figure 1. With the previous configuration examples, the brokers bridge information from the shopfloor to the top broker, Site 1. A common way is to use HTTP endpoints over the internet or intranet to easily visualize the data or feed it to an external or internal company data lake.
Read our MQTT Wireshark guide to learn how one can debug MQTT implementations by visualizing packets with the help of Wireshark.
The concept of an HTTP bridge focuses on the out direction and sends a request to a configured endpoint every time the topic pattern matches and a message is published. A hypothetical configuration could then look like this:
1 connection level03-to-intranet-world
2 http_address data-sink.microservices.cedalo.com:443
3 bridge_insecure false
4 bridge_capath /etc/ssl/certs/
5 bearer_token affeaffe
6 topic # out 0 out/ from-site/01/line/If the broker Site 1 receives a message on the topic out/, the MQTT broker Site 1 will make an HTTP request with the POST method and a JSON payload, including the topic name and the message. The HTTP backend serving the endpoint can now parse and consume the payload for visualization or storage.
With such a function, realizing internal-to-external or company internal site-to-site data forwarding becomes possible, enabling backup storage, big data analytics, or other data-driven approaches.
Smart Dynamic Bridging, a future development concept
Smart bridging would be the next level of data handling. As previously discussed, MQTT broker bridging and MQTT to HTTP bridging can structure and condense data, i.e., a production environment in multiple sites. Experts will configure the brokers by modifying settings within several configuration files, thereby fixing the conceptual data architecture.
Imagine you have a structured data storage filled with information from various devices in a manufacturing facility. While processing data, you encounter a lag in specific sensor values. You know the equipment exists in the device repository, so you set the requirement that the specific sensor information from the shopfloor level should also be fed into the data storage. The bridges are then configured automatically via REST APIs in the background to deliver the necessary information.
This approach makes the bridging concept dynamically adjustable to meet consumer needs. A monitoring algorithm that consumes the bridge usage can track the topic usage and switch off the bridges if no consumers are subscribed.
Now that you have everything you need to configure Mosquitto Bridges, you can readily apply it to your projects. Imagine the potential for time-saving! So set up your MQTT project using our recommended Pro Edition for Eclipse Mosquitto.
About the author
Dr. Andreas Schiffler is a research professor at the Technical University of Wuerzburg-Schweinfurt in the field of production and data technology in mechanical engineering. In addition to research topics related to 3D metal printing, Dr. Schiffler developed a Kubernetes cluster for the practice-oriented basics of IoT and Industry 4.0 as part of the student training. Before joining the university, he worked in different product development-related positions for Siemens AG and Schaeffler AG.
His hobbies and private activities are mixed to share practical knowledge on topics like home automation driven by MQTT protocol or using open-source CNC controllers for machine tools.
Subscribe for monthly updates
