MQTT question in light of what has recently happened

General
1

Ok, I was trying to update my RasPi to Buster and it failed.

While doing it, the machine was off-line for any Node-Red stuff and that machine is also my MQTT broker.

So, as I understand: The broker is the guy who sits there and receives messages and re-broadcasts them to the other devices.

Without the broker MQTT won't work.

This was obvious with my WAP temperature sensor. It was complaining no end when the RasPi was shut down.

WEIRD THING HAPPENED

On another RasPi, I have things happening on MQTT. It sends commands..... (doesn't really matter - yeah?)

The commands are sent to an IR Transmitter.

Though it didn't work I did see the command go through and it was attempted.
Alas now and these commands fail for reasons unknown.

But it raises the question for me:

If the broker was nonexistant: how did that work?

Someone?

2

What do you mean by this? You need to give more detail, like "machine "A" has a flow that uses an mqtt-out node. The mqtt msgs go to machine "B" which is the MQTT broker. On machine "C" I have an a flow that listens for certian MQTT msgs and then sends then using an IR Transmitter."

You should be able to duplicate this very easily by powering down machine "B"
You need to monitor the MQTT msgs being received by machine "C" to see what they are.

3

All things being good - be it there is such a thing - 99.99% of the time they work.
The commands are sent and they are obeyed.

Probably / could be problems with the nodes at the end. (Who knows)

But the commands are sent over MQTT from one machine to another.

Yes (as per your example): machine a has a MQTT OUT node and machine b has a MQTT IN node.
Machine c (or *another machine) is the broker.

So with a, b and c all online things ..... work.

Machine c was turned off - gone.... not existing. Being re-flashed / built / what ever.
What it is/was at that time: no longer existing.

During that time machine a sent a MQTT message and machine b received it, or part there of.

Is the broker essential for MQTT to work?

4

In which case Machine A and B are connected to an MQTT broker that is not on Machine C.

1 Like
5

Well, a and b have their MQTT nodes configured to use c as the broker.
(192.168.0.99)

That machine did not exist during the time of the message from a to b.

Well, unless raspbian comes with MQTT pre-installed by default.

I flashed the SD card with the BUSTER image and was updating/upgrading it.

It is an OLD machine. 2 x USB ports and a yellow composite video output.

So how did the message get from a to b if there is no broker?
The IP address they know as the broker didn't have MQTT installed. Unless - as I said - Buster comes with MQTT pre-installed.

As the new O/S didn't work (well, it did, but CPU @ 100% all the time: it isn't usable.) I took out the new SD card and put back the old(er) one with Stretch.

Back to what was (and working)

6

Are you certain? Perhaps you have a duplicate IP? Try turning it off while pinging that IP?

7

It isn't I want to be annoying in what I am saying.

(The long story)

The machine:

Raspberry Pi Model B Rev 2

PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Raspberry Pi reference 2018-03-13
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 00013d7972122d1304aacda8fff5098f073ceb43, stage5

IP address 192.168.0.99

That is my MQTT Broker
All machines on the network have their MQTT nodes set to talk to it.

It is Stretch and as much as it is great, the people at RasPi updated the kernel a while back and it killed the ability for the device to be a WAP, which I wanted.

Buster (supposedly) supports WAP and it has become really annoying not having the WAP, so I decided to update.

192.168.0.99 powered down. SD card out. New SD card in with Buster.
Set it up as the same IP address as the old SD card, as basically it is going to be the same machine anyway.

So, with the IP set, I plug in the Cat-5 cable and sudo apt update and then sudo apt -y upgrade.

This took about 30 minutes.

During this time machine a sent a message out via MQTT and machine b received most of the command.

Note: Now and then even with the old card that would happen. So as I said: it could be a problem with the node at the end. Not my problem.

I am stating that the MQTT message got through when I did not have a broker machine.

How is this possible?

Or as I keep asking: Does BUSTER come with MQTT pre-installed?
Though that can't be true as my thermometer which also uses MQTT was screaming that it couldn't find the BROKER.

8

What do you mean by "most"?

Pis do not come with a broker preinstalled and running.

9

(Sorry, not angry at you.)

I have a samsung TV. I have the nodes to control it.

Machine a has a schedule to send commands to the TV.
Machine b is an IR HUB that transmits

.
.
.

Oh (&&^(&(&*(&

It is sent by HDMI not IR.

I am sorry.

I am just stressed out by trying to update from Stretch to Buster - and it not working.
While I was trying to get it working an event happened and I got .... distracted by it working because I thought it was via MQTT and it was really by HDMI.

I'm stupid. We (you) already know that.

I'll shut up now.

Again: Sincerest apologies.

10

Side note, I finally decided that upgrade in place between Stretch to Buster is just not worth the headaches. I changed how I deploy applications above the OS, so I can create a new base image for a given OS distribution, and then install applications as needed. If you dig into the documentation of Debian based OSes, and lurk in the various forums, a full distribution upgrade in place is actually discouraged. It is typically not recommended, I have heard many times from various sources. I worked for a Fortune 50 firm for decades doing OS deployment strategies... and we never did a distribution upgrade in place, we automated OS deployment and application deployment, both as part of our DR strategy, and as validation for new application deployments, between DEV, UAT and PROD.

11

Maybe we should kindly ask management to assign a new category for you :upside_down_face:
Never wrong to ask...but sometimes...not so bad to check twice & test first

12

I wasn't upgrading it in place.

I got a new SD card and put Buster on it from blank.

Stretch was on another SD card altogether.

I am updating to Buster because Stretch used to (note: past tense) support WAP.
One day I did an update and the new kernel blacklisted the WiFi dongle which - until then - had been working fine.

RasPi won't talk to me unless I am using Buster.

As I kind of want the WAP part I decided to update to Buster.
If I knew how to downgrade Stretch to the previous working version: I would.

13

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