NodeRed MQTT bridge?

General
1

Does anyone know of a flow to do this? I can't do it in Mosquitto (via the broker itself) unfortunately as there's some bug which means the bridge keeps disconnecting.

I wondered if it could be done easily in Node Red?

I found an example online for an Adafruit one but it's not what it appears to be.

many thanks!!

2

Is that a documented bug? If not then I suspect it is not a bug. I don't have any such problems.

What do you see in the mosquito log?

3

You will have to elaborate about what functionality you are looking for.

Node-RED can certainly subscribe to topics on one broker and publish them to another one.

But it would also be good to understand what bug you're hitting in mosquitto.

4

As anything that would likely cause the broker to be disconnected from it's paired broker would also likely disconnect the "outbound" connection from Node-RED as well.

But also MQTT bridges can make use of QOS 1 or 2 to ensure that no messages are missed if there is a disconnection event (just delayed until the connection is re-established)

5

I'm doing it with Mosquitto, I forward the $SYS messages from Mosquitto on my old Pi2 to my live home server (converting the source $SYS/# to the target services/pi2/mosquitto/# topic). It is working well and loads of data gets sent every 10s.

Currently showing me that the Pi's broker has been up for 15372066 seconds :slight_smile: Around 178 days if I worked it out correctly.

6

Socket error (Bridge)
Reconnect (Bridge)
Socket error (Bridge)

All the while, the normal clients stay connected

7

Thanks

Simply looking to republish topics and payloads from one MQTT broker to another (across a VPN)

I'm hitting a bug with Mosquitto v2 (I know it's old) that means when I use the following config for the bridge

connection bridge-01
address 192.168.1.2:1883
topic # out 0
topic # in 0

or

connection bridge-01
address 192.168.1.2:1883
topic # out 0
topic # in 0
try_private false
notifications false
bridge_attempt_unsubscribe true

I get the connection attempt then an immediate socket error

I'm using Mosquitto v2 because I neither want nor need all the various security that later versions more or less insist on. I've tried a few times to upgrade and turn off the security but each time my MQTT totally fell over and I was unable to configure it to work unauthenticated like with Mosquitto v2. I've posted about it here as well, but so far no response. Which is fine. Nobody's obligated to respond to me! :smiley:

8

In my setup, I pull from the Pi so the config is on my main server. I added a new file to /etc/mosquitto/conf.d/ with a name starting with z so that it sorts last and other conf's load first.

connection pi2-mosquitto
address pi2.xxxxxxxxxx
cleansession true
notifications true
topic "" in 0 ESP/D1M02 HARDWARE-IN/WIFI/D1M02
topic # in 0 services/pi2/mosquitto/ $SYS/broker/
topic "" in 0 telegraf/pi2/ telegraf/pi2/

As you can see, three topic tree's are pulled, each being translated into a new tree in the target. Output from an old ESP8266 device (no longer needed actually, just not got round to changing), The source $SYS tree and the source telegraf tree which is system stats produced by telegraf on the Pi.

I do not include a port number in the address.

My main server is running Mosquitto v2.0.12 but the Pi is running v1.6.12 as it doesn't get a lot of love these days, just keeps on rocking.

By the way, v2 IS the latest version.

9

That's great. But it doesn't seem to like that option at my end, hence wondering about a lovely NodeRed option! :slight_smile:

10

ah sorry - I'm running it as an add-on to Home Assistant, and there the latest version is 6 something

Thanks I'll try it from the opposite end then! :slight_smile:

11

V2 isn't old, that is the current version.

If you do it without bridging then add an MQTT In node subscribed to the remote topics and connect it an MQTT node publishing to the local one. Also add a pair the other way round. Make sure you don't have the same topic in both directions in that case though, or you will get a loop.

Does bridging cope with specifying the same topics in both directions? I have never tried it. I always want one broker to be the master for a particular topic so I make the it clear in the bridge definition which direction any particular one travels.

12

Home Assistant seem to insist on having their own version numbers for things they include that mask the real underlying version number. We see it with people using their Node-RED container as well. It makes it very hard to work out what the actual version people are running is.

13

I think this is my problem - I've tried just connecting an "in" node to an "out" node (obviously set to the different brokers) but it mangles the topics. That's the reason for this thread.

14

What do you mean it mangles the topics?

15

Sorry, As in doesn't "relay" them, they aren't mirrored. I'll try to post an example

16

hmmm, so I tried your config, and this is what I got

1639733750: mosquitto version 1.4.15 (build date 2018-03-04 15:36:00+0000) starting
1639733750: Config loaded from /etc/mosquitto.conf.
1639733750: Opening ipv4 listen socket on port 1883.
1639733750: Opening ipv6 listen socket on port 1883.
1639733750: Warning: Mosquitto should not be run as root/administrator.
1639733750: Connecting bridge homehass (vin.duckdns.org:1883)
11639733772: New connection from 172.3.3.1 on port 1883.
1639733772: New client connected from 172.3.3.1 as 5ALWSarEytsChZ4R (c1, k60, u'homeassistant').
1639733810: Socket error on client local.core-mosquitto.homehass, disconnecting.
1639733841: Connecting bridge homehass (vin.duckdns.org:1883)
1639733901: Socket error on client local.core-mosquitto.homehass, disconnecting.

I'm wondering if it's an SSL thing? Both of my Home Assistant servers use SSL

17

Obviously make sure you have the topic blank in the MQTT Out so that it will use the topic in the message.

18

Hmm....

Yes, see my config. You can have the exact same topic tree or you can change the root topic as I do.

I use it to bridge from an old setup that I've not quite gotten round to decommissioning yet to my current home automation server.

Are you using websockets on the broker? Not sure whether that message is simply unclear or whether that is part of the problem.

Why are you using this? That means that traffic is leaving your local network - is that what you want?

19

MQTT client disconnects due to errors always say "socket error" don't think it's related to websockets.

Yeah like I said it's a VPN connection - between two sites

20

Got the Node-Red bridge working - thanks.

[
    {
        "id": "fce60d48.6e19b",
        "type": "tab",
        "label": "Flow 2",
        "disabled": false,
        "info": ""
    },
    {
        "id": "f619cb6.40bac38",
        "type": "mqtt in",
        "z": "fce60d48.6e19b",
        "name": "h Hass",
        "topic": "iotlink/#",
        "qos": "0",
        "datatype": "auto",
        "broker": "70556b7.be24694",
        "x": 410,
        "y": 360,
        "wires": [
            [
                "97493c3c.40ef5"
            ]
        ]
    },
    {
        "id": "97493c3c.40ef5",
        "type": "mqtt out",
        "z": "fce60d48.6e19b",
        "name": "p Hass",
        "topic": "",
        "qos": "",
        "retain": "",
        "broker": "af7f0536.34c678",
        "x": 600,
        "y": 360,
        "wires": []
    },
    {
        "id": "70556b7.be24694",
        "type": "mqtt-broker",
        "z": "",
        "name": "homehass",
        "broker": "192.168.1.2",
        "port": "1883",
        "clientid": "nodered",
        "usetls": false,
        "compatmode": false,
        "keepalive": "60",
        "cleansession": true,
        "birthTopic": "",
        "birthQos": "0",
        "birthPayload": "",
        "closeTopic": "",
        "closeQos": "0",
        "closePayload": "",
        "willTopic": "",
        "willQos": "0",
        "willPayload": ""
    },
    {
        "id": "af7f0536.34c678",
        "type": "mqtt-broker",
        "z": "",
        "name": "whass",
        "broker": "192.168.1.3",
        "port": "1883",
        "clientid": "node-red",
        "usetls": false,
        "compatmode": false,
        "keepalive": "60",
        "cleansession": true,
        "birthTopic": "",
        "birthQos": "0",
        "birthPayload": "",
        "closeTopic": "",
        "closeQos": "0",
        "closePayload": "",
        "willTopic": "",
        "willQos": "0",
        "willPayload": ""
    }
]