EMQ X nodes can be bridged by other types of MQTT message middleware to achieve cross-platform message subscription and delivery. In this article, we present a configuration example to illustrate how to configure the bridge from Mosquitto to EMQ X.

Mosquitto is a small, lightweight, open source MQTT Broker written in C/C++ language. Mosquitto uses a single core and single thread architecture to support embedded devices deployed in limited resources, access a small number of MQTT device terminals, and implement MQTT version 5.0 and 3.1.1 protocols.

Both EMQ X and Mosquitto fully support MQTT protocol features, but EMQX supports more communication protocols and private protocol access. In the application layer, Mosquitto lacks business-related functions such as authentication, rule engine, data persistence and high-performance message bridging (EMQ X Enterprise Edition); in the aspect of monitoring operation, maintenance and visualization management, EMQX has complete existing functions and expansion scheme support; and in the basic function, Mosquit has complete support. To cluster has weak functions, and it is difficult for both official and third-party cluster schemes to support the performance requirements of large-scale and massive Internet of Things connections.

Therefore, Mosquitto is not suitable for MQTT Broker for large-scale services, but because of its lightweight and compact enough, it can run on any low-power single-chip computer including embedded sensors, mobile devices and embedded microprocessors. It is a better technology selection for edge message access in the Internet of Things, and can be realized with its bridging function. Local processing and cloud transmission of messages.

Scene description

Suppose we have an EMQ X server cluster, emqx1, and a Mosquitto server. We need to create a bridge on Mosquitto to forward all sensor topic messages to the emqx1 cluster and subscribe to all control topics from EMQX.

EMQ X

Mosquitto

Configuration of Mosquitto Server

Configuring Mosquitto bridging requires modifying the mosquitto.conf file after installation. For each bridge, the basic elements that need to be configured are:

• The address and port of the remote EMQ X server;
• MQTT protocol parameters, such as protocol version, keep alive, clean_session, etc. (default values are used if not configured);
• The client login information required by EMQ X;
• Subjects of messages that need bridging;
• Configure bridging topic mapping (default no mapping).

A simple configuration example

New Bridge

Open the mosquitto.conf file and add a connection to create a new bridge. The string after the connection keyword is also the client id used on the remote node:

connection emqx1

Configure the address and port to bridge the remote node

address 192.168.1.100:1883

Configuration Protocol Version
The MQTT protocol version used by Mosquitto bridge defaults to 3.1, and the 3.1.1 protocol needs to be specified in the configuration.

bridge_protocol_version mqttv311

Configure the remote node username

remote_username user

Configure the remote node password

remote_password passwd

Specify topics that need bridging The configuration format of bridge topic is Topic Topic Topic Topic Mode Direction QoS Local Prefix Remote Prefix, which defines the rules of bridge forwarding and receiving. Among them:

• Theme pattern specifies the theme that needs to be bridged and supports wildcards.
• Directions can be in, out or both
• Quality of service is the bridge level of quality of service. If not specified, the original quality of service of the forwarded message is used.
• Local and remote prefixes are used for topic mapping, and corresponding prefixes are added to the forwarded and received message topics so that the application can identify the source of the message.

The following configuration example adds two bridging rules:

topic sensor/# out 1
topic control/# in 1

After the configuration is complete, Mosquitto needs to be restarted to make the bridge configuration effective.

Configuring EMQ X Server

After installing the EMQ X server, in order to make the Mosquitto bridge accessible, it is necessary to decide whether to configure the corresponding user authentication and authentication information according to the situation. Or, in order to simplify the test in the experimental phase, you can use anonymous login and acl_nomatch to skip authentication and authentication.

Test Configuration

We used mosquitto_sub and mosquitto_pub tools to test whether the bridge configuration was successful.

Test out direction of bridge

Subscribe to the'sensor/#'topic on'emqx1', which receives data reported by Mosquitto:

$ mosquitto_sub -t "sensor/#" -p 1883 -d -q 1 -h 192.168.1.100

Client mosqsub|19324-Zeus- sending CONNECT
Client mosqsub|19324-Zeus- received CONNACK
Client mosqsub|19324-Zeus- sending SUBSCRIBE (Mid: 1, Topic: sensor/#, QoS: 1)
Client mosqsub|19324-Zeus- received SUBACK
Subscribed (mid: 1): 1

Publish a message on Mosquitto:

mosquitto_pub -t "sensor/1/temperature" -m "37.5" -d -h 192.168.1.101 -q 1
Client mosqpub|19325-Zeus- sending CONNECT
Client mosqpub|19325-Zeus- received CONNACK
Client mosqpub|19325-Zeus- sending PUBLISH (d0, q1, r0, m1, 'sensor/1/temperature', ... (4 bytes))
Client mosqpub|19325-Zeus- received PUBACK (Mid: 1)
Client mosqpub|19325-Zeus- sending DISCONNECT

The message should be received on'emqx1':

Client mosqsub|19324-Zeus- received PUBLISH (d0, q1, r0, m1, 'sensor/1/temperature', ... (4 bytes))
Client mosqsub|19324-Zeus- sending PUBACK (Mid: 1)
37.5

Test the in direction of the bridge

Subscribe to the'control/#'theme on Mosquitto, which receives messages posted on EMQ X:

$ mosquitto_sub -t "control/#" -p 1883 -d -q 1 -h 192.168.1.101
Client mosqsub|19338-Zeus- sending CONNECT
Client mosqsub|19338-Zeus- received CONNACK
Client mosqsub|19338-Zeus- sending SUBSCRIBE (Mid: 1, Topic: control/#, QoS: 1)
Client mosqsub|19338-Zeus- received SUBACK
Subscribed (mid: 1): 1

Publish a message on'emqx1', which will be delivered in the'emqx1'cluster and bridged to Mosquitto locally:

$ mosquitto_pub -t "control/1" -m "list_all" -d -h 192.168.1.100 -q 1
Client mosqpub|19343-Zeus- sending CONNECT
Client mosqpub|19343-Zeus- received CONNACK
Client mosqpub|19343-Zeus- sending PUBLISH (d0, q1, r0, m1, 'control/1', ... (8 bytes))
Client mosqpub|19343-Zeus- received PUBACK (Mid: 1)
Client mosqpub|19343-Zeus- sending DISCONNECT

The message should be received on Mosquitto:

Client mosqsub|19338-Zeus- received PUBLISH (d0, q1, r0, m2, 'control/1', ... (8 bytes))
Client mosqsub|19338-Zeus- sending PUBACK (Mid: 2)
list_all

For more information, please visit our official website emqx.io Or focus on our open source projects github.com/emqx/emqx For detailed documentation, please visit Official Documents.