MQTT local machine with and without an IP

General
1

A while ago I asked about how to get MQTT running on a machine locally.

Normally the machine is connected to a network and has an IP address.

All worked (don't get ahead of me) but then one day it wasn't and it didn't work.

I then realised the IP number I assigned was the 192. one when I should have set it as 127.0.0.x

Here's a new problem as it has presented itself to me.

I want to keep the local 127.0.0.x MQTT so local stuff stays local.

BUT!
Also have it so when it is on the network, it also has its 192.x address which is bridged (right word?) to the 127.x network.

Is that clear?

(Try 2)

The normal MQTT for my network is working.

Now, this other machine has a local MQTT running because it does stuff via MQTT locally and I don't want/need this to be on the bigger network.
I want this other machine to also be a broker which is visible to the bigger network also, but maintain it's local structure as well.

Or would it be easier to just make the broker on that machine use the bigger network's IP address?

2

What do you mean by this ?

127.0.0.1 is a special/private IP that every host has; the local loopback address - (originally to test the TCP/IP stack of your computer) - and only acts locally. It cannot talk to the LAN, which is why you need to have a valid private IP 192.168.x.x/172.16.x.x/10.x.x.x to participate on the network.

3

Yeah. Got that.

So what I was wanting to do was - probably making things too complicated but I'm asking to learn.

The 127 one is - yes - local. I don't want it's stuff going outside. Not needed.
So I run the broker for that IP.

Could I run another broker on the bigger network address only because I am wanting to send this machine messages directly when on the network to get around if the main broker is down.

So I'm guessing I will need to start another MQTT broker with the 192.x.x.x range and then I would have an MQTT - in node from the 192.x.x.x to a MQTT - out in/on the 127.x.x.x range.

Or is that just messy? (sloppy?)

And would/could that be done all from within NR, or do I have to create another MQTT broker for the 192.x.x.x. range on the RasPi?
127.x.x.x is already done/working.

Something like this:

[{"id":"ce510e66.69af4","type":"mqtt out","z":"a1911aa3.c45be8","name":"","topic":"","qos":"","retain":"","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"1ecd3a9e.dc5bfd","x":730,"y":4110,"wires":[]},{"id":"1e48b587.7ad26a","type":"mqtt in","z":"a1911aa3.c45be8","name":"","topic":"POWER","qos":"2","datatype":"auto","broker":"2c461445.1708c4","nl":false,"rap":true,"rh":0,"x":580,"y":4110,"wires":[["ce510e66.69af4"]]},{"id":"1ecd3a9e.dc5bfd","type":"mqtt-broker","name":"TelePI MQTT","broker":"127.0.0.1","port":"1883","clientid":"","usetls":false,"compatmode":false,"protocolVersion":4,"keepalive":"60","cleansession":true,"birthTopic":"SOM","birthQos":"0","birthPayload":"TelePi comms UP","closeTopic":"EOM","closePayload":"TelePi shutting DOWN","willTopic":"EOM","willQos":"0","willPayload":"TelePi Comms FAILURE"},{"id":"2c461445.1708c4","type":"mqtt-broker","name":"192.168.0.93","broker":"192.168.0.93","port":"1883","clientid":"","usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willPayload":"","willMsg":{},"sessionExpiry":""}]
4

No, you don't need another broker.
127.0.0.1 isn't a real ip address, it is just a way of saying "the ip of this machine whatever it is". So if the ip of the machine were 192.168.1.7 then, on that machine, you can reference the broker as 127.0.0.1 or 192.168.1.7. There isn't any difference (will not much anyway). You don't need to run another broker to make it accessible externally. If you are using the latest mosquitto however, and you want to allow access from outside (or via the 192 address) then you will have to tell it to allow that, so (on linux) create a file /etc/mosquitto/conf.d/mossy.conf containing

listener 1883
allow_anonymous true
1 Like
5

I'll look at this soon.

Alas a couple of things have just hit the fan which is annoying and sort of raised this problem.

I'm not sure which I should give higher priority.

6

Not really true Colin. It is certainly a valid IP Address. It is just that it is routed higher-up in the network stack and doesn't need to hit the network card. Indeed, unplugging the network cable will still let you use the localhost address(es).

Quite a few differences really. Firstly, the localhost address doesn't need to be physically routed outside the local device as mentioned. Secondly, most services that use networking can be limited to specific network bindings. The localhost addresses are a different binding to the LAN address so you can limit network traffic to only local services (on the same device as the broker), only LAN services or both. If you have multiple network devices (e.g. 2 ethernet and/or Wi-Fi), binding can be restricted to any/none/all of these.

Generally services will let you bind to an IP Address range (or multiple) and the special address 0.0.0.0 is used to denote that all bindings are allowed.

7

Yes, I know all that. I was trying to simplify it for Andrew. In the situation Andrew finds himself in, there isn't much difference in practice, other than the mosquitto issue that I described, which is due to exactly what you say about the routing.

8

Ok thanks both.

I do appreciate the time you invest in replying.

I am kind of across the 127.0.0.x bit. Got caught on that big time a while back. Learnt and moved on.

So that example (two nodes) I posted.... Would that do what I want or - again - is that just making it more complicated than it needs to be?

9

That depends on what you want to do. Is the IP address address of the In node the IP of the machine that node-red is running in? If so then then that will just cause an infinite loop as the In and Out are referring to the same broker via the external and local ip addresses.

1 Like
10

Yes the IP address is the real IP address of that machine and Node-red is running on said machine.

Ok, thanks.

Granted I haven't set the topic but there would be a very specific topic. I didn't include it (and yes, ok, that could be problematic in the workings of this scenario) only for keeping it simple.

Then the OUT node would send on a very specific topic also.

11

I still don't know what you are trying to do. Please explain.

12

Ok, this will be a bit long then.

Sorry, but I guess if it saves time in the greater picture.....

BIG PICTURE:

MQTT broker 192.168.0.99. (RasPi)

This machine: 192.168.0.93 (RasPiZW)
It listens to the main broker for MOST things.
This machine also have a broker running for 127.0.0.1 as there is a python script running using MQTT for messaging and it is strictly local stuff. This doesn't need to be in/on the bigger picture.
I'm using MQTT only because this is how I was shown how to do this. Be that good/bad/what ever.
This drives an LED strip. Not Neopixel, but a similar type. These are used to indicate conditions.
So if the WiFi fails I need to the LED strips so the LED that indicates the WiFi status needs to be activated.
If the WiFi is down, then the MQTT won't be working and the LED won't be activated.

THE PROBLEM:

The RasPi(Z)W is - obviously - connected via WiFi.
Recently there have been problems with things and I am trying to find out what the cause is.
If the main MQTT broker (or machine) is throwing a hissy fit things may not work.

If I set up that/this second machine (the RP(Z)W) to have a broker that can be seen on the bigger network too, I can then send these messages directly to that machine and then transcode the message to the 127.0.0.1 broker so the LEDs can be controlled, it would help me work out what is going on.
There would be only ONE topic which will be transcoded (ok, what ever you want to call it).

13

If I understand correctly you have a broker running on the PiZW. You currently access it via 127.0.0.1. You say you want to have another broker accessible on 192.168.0.93. But 127.0.0.1 and 192.168.0.93 are the same PiZW. They are just different routes into the same machine, so you can address your existing broker as 192.168.0.93 if you want. As I said earlier there is no need for another broker. Also as I said earlier the only thing you might need to do in order to address it via the external ip address is configure it to allow that, and that is only if it is version 2 of mosquitto.

Think of the broker as being your house. You might have two gates into your garden, one labelled 192.168.0.93 and the other 127.0.0.1. To get into your house you can go in either gate, it doesn't matter which one. If you are using v2 of mosquitto then the 192 gate will be locked by default, so to use it you have to make the config change described earlier.

14

This way you mean?

Ok, I shall have another look at it and try that.

It isn't I was wanting to be difficult. I was only mentioning how I was going to do it.

I'll try what you said an post back.

I don't think I have the latest Mosquitto. Probably because the O/S is also a bit old.
in the directory you mentioned there is only a README file.

O/S Stretch. :frowning: Yes, updating to Buster - or the later one - is on the cards.
But... as I am sure you understand: time gets in the way of getting things done.

Oh!

Ok, so I add those lines to mossy.conf and save the file.

Trying now.

Looking good.
Thanks.

15

Just for reference, it doesn't have to be called mossy.conf, it can be anything.conf in that folder.

1 Like
16

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.