Raspberry pi help setting up a second MQTT broker

General
1

(On another machine.)

All things being as they are, I have a broker on a machine. All works.

I have a couple of RasPies that have a python script on them and use MQTT to do things on that machine.

As is, they work. But some of them will be taken off my network and used alone.
(Or maybe on another network - but that is unlikely.)

As they will be alone, I need to install a broker on that machine too.

I have installed it, but now I have to set the IP. (I'm guessing it would be 127.0.0.1)
And change the port used.

I'm sure there are going to be traps waiting for me.

I remember someone here saying they had two brokers running on their system.

Could you help me please.

2

I believe you should not worry too much, if I have understood your concern. Give you an example:

In my "system" with many, well some 10, RPis (3B and 3B+ types) or so, I have a "main" broker installed in a retired Lenovo laptop running as a kind of "server". But almost all RPi's also have a local install of Mosquitto broker even if they are not used. I believe they just sits there since early testings. I know, fully unnecessary, but I have seen no negative impact what so ever, the additional load is neglectable

So I think you can safely install Mosquitto in all your RPi's without problem, then using 127.0.0.1 as you say and leave the default port as is

3

I usually use localhost but either should work. Why would you need to use a different port?

4

I'm asking because I am not sure.

My understanding of how "the bigger picture" is:

Main broker. (99)
All machines on my network use it.
All their nodes are set to it.

I am going to install another broker on a machine which is/can/may be on my network and needs MQTT for things to work.

I install the broker on it too.

To allow both to work, I would detect if the main (99) broker is available.
If it isn't then there would be secondary MQTT nodes which talk to the local broker.
They would be then used for any MQTT messages.

Slightly messy, but that is how I see it all fitting together with the knowledge I have now.
(Yes, a little knowledge can be dangerous)

I'm discussing it asking how you have two brokers on one network.
How do you change between them? If that makes sense. But it is worded with the knowledge I have now.

5

I get that. But that is (as you put it) just sitting there. Do you mean that literally, or are they actually active?

--
Back to the bigger question:

As the MQTT nodes have the IP address in them, I don't see how to have a "fall back" IP address if the primary isn't available.

So I would have two nodes - one to each broker - and send the message/s to both.

But then at the other end, two messages are received and that is madness! :wink:

That's what is catching me at this point.

6

Sure, they are active, or running, just waiting for eventual client connections and publishing/subscribing. The guns are loaded

Now, that is a different question! I guess for that (keeping one single ip address but two separate physical boxes with their own NIC's) you would need a redundant server solution

But sending to two brokers and then make a "smart & clever" filtering might be a way, at least cheaper since I think redundant server solutions are pretty expensive. Unless you can find free software that can bind two RPi's together as one redundant host, who knows what can be found on the net?

7

Silly me.

I hoped it would be understood that I wanted to use the second one also.

That way when that machine is not on my network, MQTT can still work.

So the way I was suggesting sounds about the better way?

Luckily what is required is a very small part and should be easy to apply the way I described.

I was just wanting to check how anyone else who has two brokers working on one network get around that problem.

8

Actually, I dont have two brokers in redundant configuration, instead I monitor the functionality of the single broker I have and make some automatic restarts if it should fail. So far, cross fingers, it has worked flawless for years

If I would have to setup a redundant host with brokers, I would eventually first try to search if there would be something relevant available on the net. Eventually I would do just like discussed, having two in parallel operation and sending to both all the time, using RBE nodes to filter, monitor that both brokers are alive, restart automatically the one that eventually would fail, send me info about it via Telegram or some other message service

9

The way to do this is to use MQTT Bridging. Mosquitto has built in support and it is very easy to configure. The basic concept is that you setup node-red always to use the local MQTT broker, and setup the local broker to synchronise topics that you choose (or all of them if you wish) to another broker (which will be your 'main' broker in this case). The result is that when both brokers are up and there is a connection between them then the local server makes sure the main broker is always up to date. If the connection fails then node-red will carry on using the local broker and when the connection recovers mosquitto will automatically update the main broker with the latest data. As I said, it is very easy to setup, here is a good explanation of how it works examples of how to set it up with mosquitto. Mosquitto MQTT Bridge-Usage and Configuration

1 Like
10

Yes @Colin but it then sounds to me that you will lose the awarness with the "real world" as long as the connection between the brokers are down? Or did I miss something? Having a redundant host or two mqtt brokers on separate computers with "clever" filtering would not have that disadvantage

11

Well if the link is down then yes you can't get any updates from the real world - but with LWT - you would at least know the link is down.

12

Agreed, but I understood a "hot standby" fall-back was required...therefore my thoughts. If not needed, well, just skip it

13

My idea is maybe too advanced for the use case:

14

If the connection is down then you would be be disconnected from the outside world anyway so I don't see what the difference is. What network layout are you thinking of that would not suffer from this problem?

15

True - a live passthru is not quite the same as a remote hot standby - though the bridge client it uses to connect local to remote can be configured with a list of brokers to attempt to connect to (unlike the default simple client) so that can indeed then auto swap to a new remote broker. See " Configuring Bridges" section of https://mosquitto.org/man/mosquitto-conf-5.html

16

Yes, maybe drifting a bit OT, but having a small setup like that, would be an interesting project. Maybe more than originally asked for, I don't know, but would provide high reliability.

17

Agreed, and for a complex system that may be useful, but for the typical home automation setup, if the local node red and broker are running on a pi or similar, maybe connected by wifi, and the central broker is running on a server machine of some sort, hopefully wired into the router, then by far the most likely cause of failure is the wifi on the pi dropping out occasionally, and basic MQTT bridging does what is required in this situation, I believe.

18

Or you could just talk to the local broker and set up a bridge from the local broker to the main network broker and sync data over that bridge. MQTT has bridging capabilities built in.

As others are saying, the overheads of the Mosquitto broker are really tiny.

If you can't do it the bridge way ...

Assuming that you reboot the Pi if it goes off the network, write a startup script that checks the network. Rewrite the HOSTS file and then in Node-RED use a name instead of an IP address.

If you don't reboot, run the script periodically.

19

... or have two mqtt out nodes - one to each broker - and one of those switch nodes in front to direct the traffic to whichever is preferred/available.

1 Like
20

Ok, so what's happened in the world of Oz?

I have installed and started the mqtt broker

sudo systemctl start mosquitto.service

pi@PIFACE:/etc/mosquitto $ sudo systemctl start mosquitto.service
pi@PIFACE:/etc/mosquitto $ sudo systemctl status mosquitto.service
â—Ź mosquitto.service - LSB: mosquitto MQTT v3.1 message broker
   Loaded: loaded (/etc/init.d/mosquitto)
   Active: active (running) since Mon 2020-11-30 16:29:00 AEDT; 15h ago
  Process: 414 ExecStart=/etc/init.d/mosquitto start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/mosquitto.service
           └─429 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf

Nov 30 16:28:59 PIFACE systemd[1]: Starting LSB: mosquitto MQTT v3.1 message broker...
Nov 30 16:28:59 PIFACE mosquitto[414]: Starting network daemon:: mosquitto.
Nov 30 16:29:00 PIFACE systemd[1]: Started LSB: mosquitto MQTT v3.1 message broker.
Dec 01 07:38:08 PIFACE systemd[1]: Started LSB: mosquitto MQTT v3.1 message broker.
pi@PIFACE:/etc/mosquitto $

I then edited the MQTT broker node in NR and pointed it to 127.0.0.1 and deployed.

Not working.

This is my mqtt.config file for that machine:

# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example

pid_file /var/run/mosquitto.pid

persistence true
persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log
#log_dest topic /var/log/mosquitto/mosquitto.log

log_dest topic

log_type error
log_type warning
log_type notice
log_type information

#connection_message true
#log_timestamp true


include_dir /etc/mosquitto/conf.d

#password_file /etc/mosquitto/passwd

#  2020 12 1  Bridge mode for MQTT
connection bridge-01
address 192.168.0.99

topic # out 0
topic # in 0

Of course the 0 and o are rather difficult to tell the difference on the link.
(Just saying.)

So is that 0 or o at the end of the topic line/s?