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.

mqtt-bridge

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.

MQTT-Bridging-Schematic

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
mosquitto-bridge-schematic

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.

mosquitto-bridge-config-simple

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:

mosquitto-bridge-config-remapping

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

MQTT-Bridging-topic-Remapping-Example

 

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

bridge-test-config

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:

bridge-broker-console

When I run the script this is what I see.

python-client-output

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.

python-client-bridge-example

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.

mosquitto-mqtt-topic-remappimg

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:

round-robin-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.

mosquitto-bridge-username-password

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.

broker-loop-detection

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 ' '
#################################

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.

Related Articles and Resources:

Mosquitto Configuration Tutorials

Please rate? And use Comments to let me know more
[Total: 13   Average: 3.6/5]

105 comments

  1. Hi Steve!

    Great article! it helped me to set up a “cluster” with 3 front and one back broker who is synchronizing data between the other three; they all are behind a HAproxy pool and it works like a charm! 😉 thanks!!

    Now I have a few doubts
    – if I shutdown the back broker (a reboot, for example), the synchronization stops; when the service gets up again the synchronization starts as well but the messages are not resend from the front cluster. So those messages are not synchronized. Is there any way to get them?
    – As far as you know, is there any way to set a mosquitto cluster with high availability? I have seen other MQTT Brokers like EMQX, Verne or Hive that can do that (I have to say that I hadn’t tried any of them, just saw that feature on their webs), but the further I got with Mosquitto is this this design.

    Looking forward to get your answer
    Happy new Year!

    Esther

    1. Hi
      You are ahead of me there as I’ve never set up a cluster. However the messages will only be held for sending if the qos of the bridge is 1 or 2 and the messages arriving on the front end brokers is 1 or 2.
      You can set the front end brokers to store x messages the default is 100 I believe but you can check the manual
      Hope that helps.

  2. Hello,
    I want to make a bridge on broker1 to broker2 so when I publish something with client on b2, every client thats subscribed to this topic on b1 gets the message.
    My configuration on b1 is:
    #connection
    connection u0_bridge
    address it.pharaon.iotool.io

    topic # out 0
    topic # in 0

    When I run mosquitto on b1 or b2 with “mosquitto -v”, I can connect to either of them with any client and publish and subscribe to topics normally, but the bridge won’t connect. If i run b2 with same command and run b1 with “mosquitto -c /etc/mosquitto/mosquitto.conf” so that configuration is loaded, the bridge connects to b2 and I can still normally connect with clients on b2, but I can’t connect clients to b1. If I try, I get error message:
    “Client connection from 178.58.166.83 failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknwon protocol.”
    “New connection from 178.58.166.83 on port 1883.”
    “OpenSSL Error[0]: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO: unknown protocol.”
    “Socket error on client , disconnecting.”
    And I can’t connect to it. What am I doing wrong?

    Regards

    1. It looks like you need to run a listener on port 1883. Not sure of the SSL are you also trying to use encryption. If so disable it and get the bridge to work without it and add it later.

      1. You were right, there were some certificate files that blocked me from connecting to the broker, I disabled them. Now I can connect to both brokers, but I can’t publish to b1 (the one with a bridge). There are no topics opened on this broker (not even $SYS, which was otherwise already opened on all the other clients) and if I try to publish a topic, I get an error message “Denied PUBLISH from *my userID*”.

      2. I solved the problem with publishing, it was the ACL file that didn’t allow me to publish. Now the bridge works, if I send the message on one broker I get it to the client on the other broker.
        Now I have another problem. If I start b2 with “mousquitto -v”, that works as described above, but if I want to load conifugration with “mosquitto -c …”, I can’t connect to b2 either with b1 or clients. I get error “Socket error on client , disconnecting.”

  3. Can you please share any working example of shared topics in bridge configuration.
    So that would be to have two brokers bridged to one single bridge on shared topic so the bridge could load balance.
    We are trying to bridge our cluster of two mosquitto brokers (broker1 and broker2) with one bridge (broker3), and we want them to be subscribed to shared topic so the messages could be load balanced.

    Is there a solution for this through mosquitto ?

    Regards,
    John

    1. Not done that I will give it some thought. I assume broker 1 and 2 are subscribing to a shred topic on broker 3? is that correct?

      1. Hello,

        Correct.
        We have tried several options and only one that works is when we set
        $share/group/service/a in 0
        When we try any combination with local/remote prefix we are unable to get any message flow.

  4. Dear Steve,
    I have configured two brokers in two virtual machine instance in the Google cloud. I want to set up a bridge between these two brokers. But the setup is not working . Can you please help me on reasons for not working.

  5. Hi Steve,

    I have changed my cloud broker from hiveMq to mosquitto and by doing so my problem has been resolved but now my local broker (bridge) does not receive any messages from the cloud Broker and vice versa.
    Furthermore, when the client connected to the local broker publishes then on cmd i can see the message “publishing to cloud MQTT broker” but i did not receive that message on the client that is connected to cloud broker and has a subscription for that topic.

  6. Hi Steve,

    I have followed the configurations as you instructed in this tutorial but i could not receive messages from subscribed topics on a public broker?

    My Config file setting:

    connection bridge-to-HIVEMQ
    address broker.hivemq.com:1883
    topic automation/station both 0 “” “”
    topic sensors/octocopter01/altitude both 0 “” “”

    I also run the command that you mentioned and got the following error:
    “1603189003: Error: Only one usage of each socket address (protocol/network address/port) is normally permitted.”

  7. Hi,
    I have tried to connect two brokers with a bridge. so i gave ,in the config file of broker 1 ,
    connection bridge-02
    address 192.168.23.24:1883
    topic # out 0
    topic # in 0

    So is the name bridge-02 given after the “connection” is ip address or host / domain name of broker 2? Do i need to specify that name anywhere in the config file of broker 2? What is that name actually? I am new to mqtt so please answer this question.

  8. sir steve, if i want to use arduino to act as client to subscribe and publish messages
    should i install mosquitto broker in it or other broker, or what i could do please

    1. You could use a cloud broker. The advantage of using your own local broker is that it is easier to troubleshoot as you can see the broker console.
      Rgds
      Steve

  9. hi sir i’m just stuck with mqtt and usage of mosquitto broker, do i need to establish the code for clients and broker in the server means in production level, or i could just write the code for clients and connect it to cloud broker, also what’s the need of mosquitto

  10. Hi Steve,

    First of all thank you for your informative homepage.

    I have a problem receiving messages when configured bridges cannot be created.
    To the setup.
    I have a local broker in the production network and bridged the one to several brokers in the plant network.
    The configuration on the local broker:
    # bridge to plant1
    connection bridge-172.16.35.11
    address 172.16.35.11:1883
    topic # in 2 “” “”
    topic 172.16.35.11/# out 2 “” “”

    bridge_protocol_version mqttv311
    notifications true
    cleansession true
    restart_timeout 5 30
    max_inflight_messages 0
    round_robin true

    # bridge to plant2
    connection bridge-172.16.35.13
    address 172.16.35.13:1883
    topic # in 2 “” “”
    topic 172.16.35.13/# out 2 “” “”

    bridge_protocol_version mqttv311
    notifications true
    cleansession true
    restart_timeout 5 30
    max_inflight_messages 0
    round_robin true

    # bridge to plant3
    connection bridge-172.16.35.14
    address 172.16.35.14:1883
    topic # in 2 “” “”
    topic 172.16.35.14/# out 2 “” “”

    notifications true
    bridge_protocol_version mqttv311
    cleansession true
    restart_timeout 5 30
    max_inflight_messages 0
    round_robin true

    No special configuration is made on the bridged brokers.

    The bridges can be created successfully if all brokers running and I can publish messages back and forth.
    Well my problem is, if e.g. Plant 1 and Plant 2 are offline, the local broker can’t create a bridge. This is clear. Plant 3 is online, the bridge is successfully created. If I now publish messages from Plant 3, e.g. via MQTT-Explorer, the messages arrive on the local broker with a delay. I have noticed that the delay is caused by the broker while trying to create the bridge connection on Plant1 and Plant2. If the creation of the bridge fails, the messages are received from plant 3 (MQTT-Explorer connected to local broker).

    I’m running MQTT Broker version 1.6.9 as a service on Windows 10 (local and remote)

    Can you help me?

    Best regards,
    chris

    1. Hi
      Just to clarify the fail condition.
      When you publish from plant 3 with 1and2 offline the message doesn’t appear on the local broker until the connection timeout to plants1 and 2 has expired? Is this correct?
      What is the delay time?
      How about messages going to plant3?
      Rgds
      Steve

      1. Hi,

        The message from Plant 3 doesn’t appear on the local broker while local broker trying to connect to a offline bridge. (plant1)
        2020-05-04T08:46:47: Connecting bridge bridge-172.16.35.11 (172.16.35.11:1883)
        2020-05-04T08:47:08: Error creating bridge: Unknown error.
        After the message “error creating bridge”, the message from plant3 appears on local broker.
        Trying to connecting bridge takes about 21 seconds.
        There is no other delay time configured. Only restart_timeout 5 30.
        Same Problem with messages going to plant3.

        many thanks!
        Chris

        1. Chris
          It looks like the broker is waiting to connection timeout before processing traffic. I need to set it up and test it can you use the ask steve page and send me a quick sketch of the setup and you config files.
          Rgds
          Steve

  11. I need to configure a mosquitto broker as mqtt bridge where the remote broker has many clients that subscribe to same topic
    but the messages are mapped to the respective clients with the help of username and password authentication of the end-point(or subscriber client).
    Is there any way to route the mqtt-packets to respective clients of remote broker using several passwords and usernames along each mqtt-packets?

    There is a manual way to do this using MQTT API, but ‘mqtt-bridge’ seems easier and automatic to forward messages between two brokers.
    The following are the MQTT API for publishing and subscribing the request and responses!

    for client1:
    mosquitto_pub -h “HOST_URL” -t “REQUEST_TOPIC” -f “REQUEST_MESSAGE” -u USER_NAME1 –
    P PASSWORD1
    mosquitto_sub -h “HOST_URL” -t “RESPONSE_TOPIC” -u USER_NAME1 –P PASSWORD1

    for client2:
    mosquitto_pub -h “HOST_URL” -t “REQUEST_TOPIC” -f “REQUEST_MESSAGE” -u USER_NAME2 –
    P PASSWORD2
    mosquitto_sub -h “HOST_URL” -t “RESPONSE_TOPIC” -u USER_NAME2 –P PASSWORD2

    for client3:
    ………
    and so on.

    or is there a way to publish same mqtt message on two different brokers (hosts) with same topic?

    or any other solutions/suggestions for this problem would be greatly appreaciated.

    Looking forward to your kind response.

    Regards,
    Thangz

    1. Not really sure what you are trying to do.
      Messages are routed to clients based on the topic they subscribe to and not the username/password.
      When you configure the bridge it is configured to send messages to the remote broker based on topic not username/password.
      If you use a python client you can easily send the same message to two brokers.
      rgds
      Steve

  12. Hi ,
    I am not sure I go to the wrong topic or not. I just want to find a solution that can as a client then receive topic data and then restructure it and publish to another MQTT server. Is it the feature of the bridge? Or other solution can fit this feature?

  13. Hi steve!

    Suppose that I need to manage 50 small sensor networks. And each network has their own broker on Raspberry Pi.
    I have two questions.
    1. Could I connect 30 local brokers to cloud such as Amazon cloudMQTT or Google Cloud IoT Core to make one large logical sensor network?
    2. What kind of benefits would I get from those cloud? Device management, Data flow, Machine learning?

    1. Yes you could send them to cloud broker by bridging the broker.
      However you may want to process data locally and only send processed data to the cloud service. This is especially true of the sensors send lots of redundant information.
      Having access to all 50 networks by sending and receiving messages to 1 or 2 brokers is much easier to implement.
      As for machine learning I don’t see it makes any difference as long as you get the data.
      rgds
      steve

  14. Hey, Steve. Appreciate your site a lot! I’ve been going nuts with a problem, and wondering if you have any insights.

    I’m trying to bridge a local (Ubuntu-hosted) Mosquitto MQTT instance with Beebotte, so that I can use Beebotte for connecting with IFTTT etc. and use my local instance for running Node-RED, Home Assistant, local control exchanges, etc. I’ve been running my local instance and connections to Beebotte for some time, and both work fine on their own (e.g., I can mosquitto_sub and mosquitto_pub to both just fine; I have apps running Paho that connect fine to both, etc.). So I’m pretty sure that there are no network connectivity, fundamental authentication, etc. issues in play.

    However, when I try to bridge from Mosquitto to Beebotte, I never get a successful connection, and just cycle between (in the logs):
    – Connecting Bridge (mqtt.beebotte.com:1833)
    – Bridge sending CONNECT
    – Socket error on client , disconnecting.

    When I sniff the network traffic (tcpdump), I see the connection go through to Beebotte, with the authentication token in the header, and I can see the connection established (netstat) for 30 seconds, after which the connection is dropped.

    When I compare the network traffic (tcpdump) to a successful mosquitto_sub or mosquitto_pub to Beebotte from the same machine, the only real difference I see (just eyeballing the packets) is:
    – mosquitto_sub/pub appear to send a blank password (two additional bytes past the authenticating user ID); I can’t configure a blank password in the Mosquitto bridge configuration, or it throws an error)
    – mosquitto_sub/pub follow up the connection with a request, whereas the bridge doesn’t.

    I’ve combed the ‘Net, and while people talk about bridging to Beebotte, I haven’t been able to find any live examples, or any discussion of problems bridging.

    Below is my configuration (I’ve tried every other variant I could think of, as well). Any ideas? Thanks in advance!
    —-
    connection beeb-from-local
    address mqtt.beebotte.com:1883
    remote_user
    topic topicparta/topicpartb both 0 “” “”
    notifications false
    cleansession true
    —-

  15. Hi Steve,
    Just been using hours on finding any one whom had made a mosquitto bridge to ThingsBoard IOT service. Your guide is the closest I could find. Thank you for it.

    Have you done this (bridge to ThingsBoard) successfully and what would the .conf file look like ?

    Thanks in Advance, Sami

      1. Thanks Steve for quick reply. As relative new to MQTT and Mosquitto …. what do you refere as client?

        Just back ground what i’m trying to achive. So I have several Nodemcu + DHT11/CO2 sensors around house and logging indoor /outdoor temps and humidity and CO2 levels in house. All connected via LUA scirpt directly to Thingsboard.com. Works perfectly. Then as started to look for the CO2 levels I started work on project that the CO2 levels would be going also to my HVAC unit (connetec to NodemCU and TRIAC unit) and hence the levels would actually control the unit also. Here I managed to create a system in LUA that it send data to both two broker Thingsboard and Mosquitto. I was just looking would it be easier just to send the data to mosquitto and the re-distribute it to Thingsboard and I would not need to send it into two destinations from the NodeMCU’s.
        Thanks !

  16. Hi, Steve, I’m beginner here. I try to make the bridge between my local broker and CloudMqtt. Without bridg’s section in mosquitto.conf it start ok:
    sudo systemctl status mosquitto
    ● mosquitto.service – LSB: mosquitto MQTT v3.1 message broker
    Loaded: loaded (/etc/init.d/mosquitto)
    Active: active (running) since Wed 2019-02-20 21:17:03 +05; 1 day 12h ago
    Process: 511 ExecStart=/etc/init.d/mosquitto start (code=exited, status=0/SUCCESS)
    CGroup: /system.slice/mosquitto.service
    └─531 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf

    Feb 20 21:17:03 rsb mosquitto[511]: Starting network daemon:: mosquitto.
    Feb 20 21:17:03 rsb systemd[1]: Started LSB: mosquitto MQTT v3.1 message broker.
    Feb 20 21:17:03 rsb mosquitto[531]: mosquitto version 1.3.4 (build date 2018-09-28 22:21:32+0000) starting
    Feb 20 21:17:03 rsb mosquitto[531]: Config loaded from /etc/mosquitto/mosquitto.conf.
    Feb 20 21:17:03 rsb mosquitto[531]: Opening ipv4 listen socket on port 1883.
    Feb 20 21:17:03 rsb mosquitto[531]: Opening ipv6 listen socket on port 1883.
    Feb 22 08:04:29 rsb mosquitto[531]: Saving in-memory database to /var/lib/mosquitto/mosquitto.db.
    And when I add next strinngs in mosquitto.conf:
    connection cloudmqtt
    # address m99.cloudmqtt.com:55555
    # try_private false
    # notifications false
    # start_type automatic
    # remote_username uuu
    # remote_password ppp
    # topic # both
    then I get mosquitto stopping:
    pi@rsb:~ $ sudo systemctl status mosquitto
    ● mosquitto.service – LSB: mosquitto MQTT v3.1 message broker
    Loaded: loaded (/etc/init.d/mosquitto)
    Active: active (exited) since Fri 2019-02-22 09:31:32 +05; 6s ago
    Process: 933 ExecStop=/etc/init.d/mosquitto stop (code=exited, status=0/SUCCESS)
    Process: 940 ExecStart=/etc/init.d/mosquitto start (code=exited, status=0/SUCCESS)
    Feb 22 09:31:32 rsb mosquitto[940]: Starting network daemon:: mosquitto.
    Feb 22 09:31:32 rsb systemd[1]: Started LSB: mosquitto MQTT v3.1 message broker.
    Uncommenting strings above gives same result.
    Help me please. Thanks!

    The ping to CloudMqll presents and First the mosquitto starts The contain

      1. Thanks for the answer.
        Now my mosquitto.conf contains lines:
        connection mybridge
        address m99.cloudmqtt.com:55555
        try_private false
        notifications false
        start_type automatic
        allow_anonymous false
        remote_username nazmosq
        remote_password *************
        topic # both 0 “” “”
        and mosquitto stopped:
        pi@rsb:~ $ sudo systemctl status mosquitto
        ● mosquitto.service – LSB: mosquitto MQTT v3.1 message broker
        Loaded: loaded (/etc/init.d/mosquitto)
        Active: active (exited) since Thu 2019-02-28 23:29:02 +05; 4s ago
        Process: 969 ExecStop=/etc/init.d/mosquitto stop (code=exited, status=0/SUCCESS)
        Process: 976 ExecStart=/etc/init.d/mosquitto start (code=exited, status=0/SUCCESS)

        Feb 28 23:29:02 rsb mosquitto[976]: Starting network daemon:: mosquitto.
        Feb 28 23:29:02 rsb systemd[1]: Started LSB: mosquitto MQTT v3.1 message broker.
        Using mqtt-spy for connection with cloud-mqtt with such remote user is ok
        What I must do?
        /var/log/mosquitto/mosquitto.log is empty
        I spent so much time for bridge..:(

      2. Today I passed to remote broker iot.eclipse.org without authentification. Mosquitto.conf contains lines

        connection mybridge
        address iot.eclipse.org
        notifications false
        start_type automatic
        topic test001/# both 0 “” “”

        But messages from the remote broker are not filtered according to a topic test001:
        1551551860: Bridge rsb.mybridge doing local SUBSCRIBE on topic “”test001/#
        1551551860: Connecting bridge mybridge (iot.eclipse.org:1883)
        1551551860: Bridge rsb.mybridge sending CONNECT
        1551551862: Received CONNACK on connection rsb.mybridge.
        1551551862: Bridge rsb.mybridge sending SUBSCRIBE (Mid: 39, Topic: “”test001/#, QoS: 0)
        1551551863: Received PUBLISH from rsb.mybridge (d1, q1, r0, m69, ‘test001/hum’, … (4 bytes))
        1551551863: Sending PUBACK to rsb.mybridge (Mid: 69)
        1551551863: Received PUBLISH from rsb.mybridge (d1, q1, r0, m70, ‘test001/heap’, … (5 bytes))
        1551551863: Sending PUBACK to rsb.mybridge (Mid: 70)
        1551551863: Received PUBLISH from rsb.mybridge (d1, q1, r0, m71, ‘test001/tdht’, … (4 bytes))
        1551551863: Sending PUBACK to rsb.mybridge (Mid: 71)
        1551551863: Received PUBLISH from rsb.mybridge (d1, q1, r0, m72, ‘test001/heap’, … (5 bytes))
        1551551863: Sending PUBACK to rsb.mybridge (Mid: 72)
        1551551863: Received PUBLISH from rsb.mybridge (d1, q1, r0, m73, ‘test001/tdht’, … (4 bytes))
        1551551863: Sending PUBACK to rsb.mybridge (Mid: 73)
        1551551863: Received PUBLISH from rsb.mybridge (d1, q1, r0, m74, ‘test001/hum’, … (4 bytes))
        1551551863: Sending PUBACK to rsb.mybridge (Mid: 74)
        1551551863: Received PUBLISH from rsb.mybridge (d1, q1, r0, m75, ‘test001/heap’, … (5 bytes))
        1551551863: Sending PUBACK to rsb.mybridge (Mid: 75)
        1551551863: Received PUBLISH from rsb.mybridge (d0, q0, r1, m0, ‘/034L2Xe68z/000/time’, … (73 bytes))
        1551551863: Received PUBLISH from rsb.mybridge (d0, q0, r0, m0, ‘GSM_FLOW’, … (73 bytes))
        1551551863: Received PUBLISH from rsb.mybridge (d0, q0, r1, m0, ‘/30c216b0ed/0/motion/perc’, … (11 bytes))
        1551551863: Received PUBLISH from rsb.mybridge (d0, q0, r0, m0, ‘fedor’, … (100 bytes))
        So I get
        Socket error on client rsb.mybridge, disconnecting.
        Steve, what I must write in line “topic..” ? Thanks!

        1. Hi
          Can you just give me a brief overview of the bridge you are trying to create.Use the ask steve page and I can respond via email
          rgds
          steve

          1. This my problem is solved. I confused subscribed messages and the messages which are written down in mosquitto.log. For some reason messages come to the mosquitto.log without filtration according to topic. Thanks for your attention!

  17. Hello.

    Great tutorial, very helpful.

    I want to bridge all topics in to my bridge but only some out. Still then, I couldn’t find a way of using wildcards to avoid havin to specify every topic individually as out…

    My config for in topics is (this works beautifully):
    topic # in 0

    My doubt is with the out topics, which I wanted to filter (for instance, all that contain word Sonoff or sonoff. Something like:
    topic *onoff* out 0
    or
    topic #onoff# out 0

    But it doesn’t seem to work properly.

    Any ideas on if I can do what I want and what am i doing wrong?

    Thanks in advance,
    Nuno

    1. hi
      you cannot use wild card characters as part of a name e.g string
      sonof# doesn’t work but
      sonoff/#
      should work
      * is invalid

  18. I tried to make a bridge with test.mosquitto.org with mosquitto version 1.4.14 on Windows and the results worked. but when I tried it with version 1.5.4 the result failed, the error statement was “unknown error”, this happened when the local broker tried to connect to the remote broker (test.mosquitto.org)
    This works when I make a bridge with a remote broker on the same PC

    1. Hi
      I have had others complain of bridge problems with mosquitto 1.5.4. I haven’t had chance to test it but it is probably nothing you are doing wromg.

  19. How to establish a TCP Bridge connection.
    Trying to TCP Bridge Mosquitto with EMQ.
    Included the bridge connection in my mosquitto.conf
    connection emq
    address 172.22.25.53:2883
    topic AB/# both 2

    The IP address mentioned above is an IP of a different system. And also setup the port at 2883.
    But the very rarely does the connection happen. It fails 95% of the times.
    Where am i making a mistake?

    1. Difficult to say. The mosquitto conf file that you included looks ok but missing a line like
      connection bridge-emq
      If that doesn’t work make sure that you can connect to emq using a normal client as it might have other restriction e.g authentication configured.
      Let me know how you get on.
      rgds
      steve

  20. Hi steve, can we increase client connection limit from default 1024 to 10,000 in mosquitto?
    I don’t find a proper solution from internet…so, it would be great for me if you can help in this problem..
    Thank you!
    ☺️

    1. From what I understand you can use -1 and have unlimited connections but the docs say that you might hit problems when you go over 1024.
      # The maximum number of client connections to allow. This is
      # a per listener setting.
      # Default is -1, which means unlimited connections.
      # Note that other process limits mean that unlimited connections
      # are not really possible. Typically the default maximum number of
      # connections possible is around 1024.
      #max_connections -1

  21. I am using Mosquitto MQTT Bridge between local gateway & remote MQTT broker server. It is working fine but when internet connection down then all topic published locally will not publish to broker when reconnect to internet even though QOS level is set to 2 and clean session flag is false so how can I ensure high quality of level between local MQTT bridge & remote MQTT broker without making retain topics. Is there any configuration from which local MQTT bridge ensure all topic sends to remote MQTT broker as or when internet connection resume?

    1. It is not just the QOS on the bridge. Yoy need to be publishing to the bridge with a qos of 1 or 2 and subscribing on the remote broker with a qos of 1 or 2 and it should work.
      You should also note that mosquitto has a limit of 100 messages (default) setting that it will hold in a queue.

  22. HI Steve
    I added following entry in broker2 mosquitto.conf file

    connection Bridge1
    address 127.11.0.1:1883
    topic # both 0 “” b0/

    That’s broker-2 as bridge, Broker1 as normal broker

    Started normal broker first(broker1) and then bridge broker (broker2) later.

    Used mosquitto_pub and mosquitto_sub to verify.

    Case 1: Publishing from Broker2
    # broker2:~# mosquitto_pub -t chassis/PSU0 -m “PSU0 is ON”
    # broker1:~# mosquitto_sub -t b0/chassis/PSU0
    PSU0 is ON

    Case 2: Publishing from Broker1
    #broker1:~# mosquitto_pub -t chassis/PSU0 -m “PSU0 is ON”
    #broker2:~# mosquitto_sub -t chassis/PSU0
    PSU0 is ON

    Broker2 publishes them to broker1 with a prefix of b0/
    Broker2 subscribes to all messages from broker1 with no prefix, is that correct ? I thought there would be /b0 this case as well.

    Please clarify

    1. No broker2 should subscribe to broker 1 using the prefix.
      When you publish a message to broker1 then any message not beginning with the prefix b0/ isn’t sent to broker2.

      When you send a message to broker2 it should send it to broker1 with the prefix.
      In this case the prefix is both ways in and out.

  23. Hi
    Thank you first
    I have question about bridge
    Assume my broker can accept 10k users
    If i use bridge,my brokers can 20k users?
    Regards

  24. Hi Steve,

    Great article. Quick question. Is there a practical limit to the number of brokers that can be bridged? In my project, I will have 100s of remote mqtt brokers. I’d like to pass status information from the remote brokers to my main cloud broker. The above configurations work great, but I’m unsure if there is a limit to the number of bridge connections (assuming the could version has the power to handle all of the incoming messages) a single instance can support.

    Thanks,
    James

    1. Shouln’t be a problem as the cloud broker sees client connections it is the edge broker that is configured to be a bridge. The edge broker only needs to support 1 bridge to the cloud broker or 2 if you want a standby cloud broker.
      Does that make sense?

  25. Hi Steve,
    When I bridge two mosquitto brokers in same laptop, it works. But not able to bridge two brokers in same network but both are running in different laptops. What could be the issue? Below is my configuration,
    connection bridge-01
    address 172.16.1.46:1883
    topic # out 0
    topic # in 0

    please suggest

    Regards
    Pradeep

      1. Thanks Steve for prompt response.solved.

        I am trying to setup mosquitto cluster. Is it possible to achieve High availability(HA) and Load balancing(LB)?
        As per my understanding, If I want to have cluster setup at cloud for HA and LB where mqtt gateways can publish data. It is not possible with mosquitto to achieve . Better I should choose another mqtt broker which gives HA/LB support and suitable for cloud.
        Is my understanding correct? please suggest

        Regards,
        Pradeep

        1. I haven’t looked at clustering mosquitto but I’ve seen several comments around the web saying you can’t do it.
          You might want to look at HiveMQ
          rgds
          steve

  26. i was getting “socket error on client (client id), disconnecting”
    could you please help me why this error occurred and how to resolve this

    1. Where are you getting the error? Does it occur on the broker that the bridge is trying to connect to? Do you have any security configured on the broker?
      rgds
      steve

  27. Is bridging suitable for HA architecture where I want to have say three brokers that all share clients’ data?My concern is that it seems that even with Round Robin there is only one bridge so if that bridge broker goes down then HA breaks – am I missing something?
    Bill

    1. HA?
      You’re correct the bridge is the weak link. The only alternative is to get the clients to publish to two brokers but that isn’t really practical.
      Bridging doesn’t give you any kind f resilience it is only meant to connect brokers together so that they can share topics.

  28. I am currently running a mosquito broker. I need to bridge this with mqtt broker running on m11.cloudmqtt.com. So as per your idea I need to do configuration on my mosquito.config file.Is it wright. I need to pass all messages publish all topics to remote broker and vice versa. Please provide comment on this

    1. Yes
      Edit the config file and start by bridging all topics. Once it is working ok then you can change it to only bridge selected topics.

  29. In the simple configuration you have

    topic # out 0 “” b1/
    topic # in 0 “” b1/

    But later you say

    When the bridge on broker b1 subscribes to a topic on b2 it uses the form
    remote_prefix + topic name e.g. b2/house/sensor1

    Where does the b2 come from? I see no mentioning of b2 in the simple config.
    Do you mean
    topic # in 0 “” b2/

    1. b2 is the remote prefix.The prefix is only used if you want topic remapping.You can use any prefix you want b2 is just an example.
      I’ll reread the tutorial over the next few days and check to make sure the examples are OK as I remember when I was doing it it got confusing.

  30. Hi Steve,
    I am newbie in MQTT. I am using a Mosquitto broker in my laptop for home automation applications. It has worked well for local network but not for remote one. Could you guide me to configure the Mosquitto broker in order to access from outside network?
    Many thanks in advance.
    Vince Tran

  31. Hello Steve,

    Very nice explanation on how to get this done. Could you please explain how to do this if say broker 2 has a username and password set up or TLS? Is it possible to configure in Broker 1, which is being used as the bridge a user name and password so it can access broker 2’s topic and publish to it?

    Thanks and expecting your reply soon.

      1. Hello Steve,

        Thanks for the quick response. I will be checking for the update, as I am in the middle of trying to develop my system now.

        Kind regards

      2. Hello Steve,

        I am just putting together this configuration, but I don’t seem to understand where this configuration is to be. Is it a different script, or this is to be inputted into the mosquitto.conf file found in /etc/mosquitto/.

        Regards

        1. When Linux start mosquitto it will use the mosquitto.conf file in the /etc/nosquitto folder. So if you want to start mosquitto automatically then you need to place your changes in the mosquitto.comf file. If you start mosquitto manually from the command prompt which is normal when testing the you can use any conf file as you tell mosquitto which file to use using the -c switch. I use a file called m1.conf as it is short and easy to type. So I start mosquitto
          mosquitto -c m1.conf

          1. Hello Steve,

            Many thanks for your quick responses, as I am beginning to get a hang of it now. The “connection “, what name exactly am I supposed to use, as can I just give it any name of my choice? below is my config, but the bridge seems not to be able to do anything as its finding it difficult to connect to my other broker:

            #connection bridge-01
            connection bridge-01
            address 192.168.0.30:1883

            topic home/sensor both 0 “” “”

            remote_username
            remote_password

            Please is there something I am missing?

            Regards

          2. Hello Steve,

            Many thanks for your quick responses, as I am beginning to get a hang of it now. The “connection bridge-01 “, what name exactly am I supposed to use, as can I just give it any name of my choice? below is my config, but the bridge seems not to be able to do anything as its finding it difficult to connect to my other broker:

            #connection bridge-01
            connection bridge-01
            address 192.168.0.30:1883

            topic home/sensor both 0 “” “”

            remote_username myusername
            remote_password mypassword

            Please is there something I am missing?

            Sorry had to send it again, as some text went missing in the last one I sent, and seems I can’t edit.

            Regards

  32. Hi,

    can you help on below issue , as my another bridge server denied publishing the data.

    Sending SUBACK to CHATSRV-BRIDGE-USER
    1492491690: | — mosquitto_auth_acl_check(…, local.KIBANA-BRIDGE-USER, AnonymouS, smart/, MOSQ_ACL_WRITE)
    1492491690: | — mysql: topic_matches(smart, smart) == 0
    1492491690: | — aclcheck(AnonymouS, smart/, 2) AUTHORIZED=0 by (null)
    1492491690: | — Cached [86CCE31BFEB0B45E07246624715795ACE9151C96] for (local.KIBANA-BRIDGE-USER,AnonymouS,2)
    1492491690: Denied PUBLISH from local.KIBANA-BRIDGE-USER (d0, q0, r0, m0, ‘smart/’, … (17 bytes))

    1. Hi
      I would look at the topic name as I’m not sure about the comma. Then I would see i the bridge as an access control list configured as that is when I’ve seen the publish denied message.
      What broker are you using for the bridge?

Leave a Reply to Abishek G Cancel reply

Your email address will not be published. Required fields are marked *