Am I missing something? I can't see anything not working. Are you getting an error or just no msgs going through?
On the machine which is to be the bridge, I edited the config file as shown.
This is what I see if I check what MQTT is doing:
pi@PIFACE:~ $ sudo systemctl status mosquitto.service
● mosquitto.service - LSB: mosquitto MQTT v3.1 message broker
Loaded: loaded (/etc/init.d/mosquitto)
Active: active (running) since Tue 2020-12-01 08:22:31 AEDT; 4min 42s ago
Process: 5170 ExecStop=/etc/init.d/mosquitto stop (code=exited, status=0/SUCCESS)
Process: 5176 ExecStart=/etc/init.d/mosquitto start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/mosquitto.service
└─5181 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
Dec 01 08:22:31 PIFACE mosquitto[5176]: Starting network daemon:: mosquitto.
Dec 01 08:22:31 PIFACE systemd[1]: Started LSB: mosquitto MQTT v3.1 message broker.
pi@PIFACE:~ $ mosquitto -v
1606771641: mosquitto version 1.6.10 starting
1606771641: Using default config.
1606771641: Opening ipv4 listen socket on port 1883.
1606771641: Error: Address already in use
Looking at the link supplied above I get to this part:
Configuring the Broker
You will need to configure
- The Address and port of the remote broker or brokers. – Address keyword
- A client name. – Connection keyword
The address and port.
As this is written under the BRIDGE heading, I am guessing that means the broker which is going to be the bridge.
Fair enough. That is what I did.
The last character in the topic line is a ZERO - QOS qualifier.
Ok.
So the "port already in use" is now a stumbling block for me.
So I get back to:
- The Address and port of the remote broker or brokers. – Address keyword
The config file:
connection bridge-01
address 192.168.0.99
Yes, ok, I don't have a port. Is it needed if it is the default one?
Anyway, stepping back for a second:
That machine's nodes are set for 127.0.0.1 (local host) and all is good.
The Cat-5 cable is plugged in and things are ticking away happily.
I unplug the cable. Everything stops.
Plug the cable back in: Working.
To me that indicates that the MQTT nodes in NODE RED are not using the local broker.
(Or it isn't running because the port is already in use)
So I guess I could resolve that as: No messages getting through.
For clarity - maybe - this is how the nodes on the remote machine (the one which needs MQTT working if/when it is not on the bigger network) is set up.
I also should probably get rid of the legacy support. I'll do that now.
To further confuse me, I tested it from a CLI - though of course the CAT-5 cable was plugged in.
This is what I see:
So to me that means it is talking locally.
I guess I will have to dig up another monitor and see what is happening really as it is difficult to do all this with only ONE monitor.
As an example this is what I have at the end of one of my system's mosquitto config file
connection bridge_x201-vps-weather
address server-vps.local:1883
remote_username xxxx
remote_password xxxx
topic tydwr/weather/# out
topic tydwr/greenhouse/th10_temperature out
topic tydwr/greenhouse/s003/tele/PID out
You won't need the user/pwd if you have not got authorisation enabled.
That almost certainly means you have another mqtt broker on that machine. Have you installed one of the node-red nodes that provides a broker?
Honestly I can't say.
I have the default MQTT nodes, but they aren't a broker are they?
I'll have to keep digging to find out what is going on with that machine.
I did a dpkg -l on it and there is only one MQTT broker I can see listed.
(Yes I know this is getting outside NR's field, but I am just saying.)
Try one of these suggestions to see what has port 1883 open:
Ok, this is what I see:
pi@PIFACE:~ $ sudo lsof -i -P -n | grep LISTEN
node-red 417 pi 19u IPv4 16162 0t0 TCP *:1880 (LISTEN)
cupsd 511 root 10u IPv6 10210 0t0 TCP [::1]:631 (LISTEN)
cupsd 511 root 11u IPv4 10211 0t0 TCP 127.0.0.1:631 (LISTEN)
vncserver 624 root 12u IPv6 13541 0t0 TCP *:5900 (LISTEN)
vncserver 624 root 13u IPv4 13542 0t0 TCP *:5900 (LISTEN)
rpcbind 639 root 8u IPv4 11466 0t0 TCP *:111 (LISTEN)
rpcbind 639 root 11u IPv6 11469 0t0 TCP *:111 (LISTEN)
sshd 656 root 3u IPv4 9847 0t0 TCP *:22 (LISTEN)
sshd 656 root 4u IPv6 9849 0t0 TCP *:22 (LISTEN)
rpc.mount 844 root 9u IPv4 13442 0t0 TCP *:36945 (LISTEN)
rpc.mount 844 root 11u IPv6 11550 0t0 TCP *:40241 (LISTEN)
rpc.mount 844 root 13u IPv4 11554 0t0 TCP *:55799 (LISTEN)
rpc.mount 844 root 15u IPv6 12593 0t0 TCP *:43163 (LISTEN)
rpc.mount 844 root 17u IPv4 12599 0t0 TCP *:52645 (LISTEN)
rpc.mount 844 root 19u IPv6 12605 0t0 TCP *:36693 (LISTEN)
smbd 1161 root 35u IPv6 14130 0t0 TCP *:445 (LISTEN)
smbd 1161 root 36u IPv6 14131 0t0 TCP *:139 (LISTEN)
smbd 1161 root 37u IPv4 14132 0t0 TCP *:445 (LISTEN)
smbd 1161 root 38u IPv4 14133 0t0 TCP *:139 (LISTEN)
Xvnc-core 1197 pi 0u IPv6 14619 0t0 TCP *:6001 (LISTEN)
Xvnc-core 1197 pi 1u IPv4 14620 0t0 TCP *:6001 (LISTEN)
Xvnc-core 1197 pi 11u IPv6 13033 0t0 TCP *:5901 (LISTEN)
Xvnc-core 1197 pi 12u IPv4 13034 0t0 TCP *:5901 (LISTEN)
mosquitto 2684 mosquitto 5u IPv4 19114 0t0 TCP *:1883 (LISTEN)
mosquitto 2684 mosquitto 6u IPv6 19115 0t0 TCP *:1883 (LISTEN)
pi@PIFACE:~ $
And if I do a sudo systemctl stop mosquitto.service the mosquitto mention is gone.
So...... to me that is good.
To keep things in context.
If this is true, then the broker is running locally.
(Bridged)
So why does MQTT stop working when I unplug the Cat-5 cable?
This is other stuff to (I hope) help:
the config file:
pi@PIFACE:/etc/mosquitto $ cat mosquitto.conf
# 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:1883
topic # out
topic # in
pi@PIFACE:/etc/mosquitto $
The node/s.
Do the nodes show disconnected when you unplug the cable? If not then how do you know MQTT has stopped working?
If they do show disconnected then likely they are not configured to use localhost. In the node-red editor look in Configuration nodes and check that there is only one mqtt broker config node and that it is configured for localhost.
Good question.
I have a python script running which is listening to MQTT and it is getting the time.
So every second the time is displayed on the LCD display plugged into/onto the Pi.
Unplugging the cable, the clock stops showing a dynamic time. It just sits there with the last time being displayed.
Plugging in the cable, a second later the time is correctly displayed.
If I unplug the cable the nodes say they are still connected. Sorry, I forgot to mention this.
So I guess they are seeing the local broker.
So either the broker isn't getting the messages or it isn't re-sending them locally.
How do I find out which is happening?
Are you sure the python script is connecting to the local server?
What is publishing the time to MQTT?
What happens if you stop mosquitto at the central machine?
Also, to investigate the situation in node-red, restart node red then disconnect the cable for long enough to see the problem and connect it again. Then run node-red-log and you should see the startup message and the initial mqtt connect messages to localhost. See what it shows when the cable was disconnected. If the log shown by node-red-log doesn't go back far enough you can run
node-red-log -n 100
which will show 100 lines instead of the usual 25. You can put in whatever number is necessary.
1 Like
You are so right.
I just (now) realised this.
The script has the IP address of the broker - of course - and I forgot to modify it.
Doing that now.
(I have a feeling it is going to be one of those days.)
Thanks.
Small update:
This machine is very unstable. I am lucky to get 10 minutes of working Firefox.
It keeps crashing/exiting for no reason.
That is not helping me find out what is going on.
The other problem is the RasPi.
It is Jessie, and I am luckiy to get a browser to load the edit page. Let alone the GUI page.
All browsers on it crash/exit when the GUI page is loaded.
So it is not helping me find out what is going on here.
Alas from what I now know:
The script is talking to the local MQTT broker.
BASIC commands are getting through.
But stuff for the clock isn't. 
I am going to have to do further testing when the machines feel like allowing me to.
But thanks for pointing out/reminding me/(what ever) that the script needed changing to the local IP address.
Ooops.
Run top and see if you are running out of memory when you launch the browser.
Ok, the MQTT problem. Here's what has since happened:
Hooked up a monitor to it.
Remember that all MQTT nodes on this machine are set to 127.0.0.1. (Local host)
Some of the flow/s send messages locally to be used by a python script.
There is no way to see what that is as there is no MQTT IN node. It is all done at the program level in python.
So, what I do is get a MQTT IN node at set it to the same topic as that which the program is listening.
Hook up a debug node and watch. In the mean time I know there is stuff working as the clock on the LCD is ticking over every second.
NOTHING coming out of the debug.
Hmmmm....
edit the topic so it is one level higher and has a wild card.
So (eg): rather than being /piface/lcd/text I made the topic /piface/lcd/#
again: nothing showing up.
opened a CLI and did: mosquitto_pub -h 127.0.0.1 -t /piface/lcd/test -m hello
BING! I see that.
So I am not understanding what is going on. I can send messages on test but text isn't being shown. Yet, I know it is working as I can see the clock happily working.
I'll leave it here for now.
But that's the story to now.
It is not recommended to use a leading / on topic names. In fact perhaps you are getting confused over whether there is a / or not. Set the mqtt In to topic # and see what it shows.
Ok, thanks.
Interesting about the leading /.
I'll have to check that again.
When I have more info I'll post it. I should have taken screen shots, but didn't think to as it isn't the main machine and I was a bit confused with other things.
I'll get back to you with more info ASAP.
Yes, the leading / was something that people did way back at the start of MQTT. But people quickly realised that it added no value at all and just confused things.
Also note that if you have a leading / then to subscribe to everything I assume you would have to use /# but then that wouldn't pick up topics without a leading /.
Yeah, ok. My bad.
Here is what it looks like with the cable plugged in.
You can see the messages being sent and being received.
(Poorly I know, but it shows them going out/in)
Here you can see the message happily going along.
Until I unplug the Cat-5 cable.
Then they stop.
This screen shot was taken on the machine directly as I have it plugged into another screen/monitor.
So, to recap:
MQTT broker on this machine (.86) are set to 127.0.0.1 and the config is set to bridge mode.
(.config file posted above)
There are no topic translations/editing.
So long as the cat-5 cable is plugged in, all things are happy.
I unplug it, and MQTT stops.
You can see the nodes are not complaining, as they are still seeing their broker.
Oh, it is also strange the MQTT OUT node isn't getting anything sent to it.
Next thing:
So, the cat-5 cable is unplugged.
I click on the DEBUG node's tab to enable/disable them showing things.
Why am I getting this message?
Are you sure that you are using localhost to access Node-RED? You should only get that if you are using the external address because it then has to go into the network stack.
One thing to try would be to make sure that Node-RED is sending/receiving on any network - possibly it is locked to using the eth0 or whatever your ethernet uses.
