MQTT nodes. Old messages. QOS. Retain

General
1

Ok, I have noticed something with MQTT messages and turning machines on/off and have some questions.

I am making new flows that send/receive MQTT messages. Some messages need to be retained and some don't.

Some need QOS 0. Others 1 and some QOS 2.

But I'm guessing that it isn't that simple. Or: Is that simple and I am trying to get too much from it.

Or something like that.

So, I am making flows and while making them, I inject test message to see how things happen.
All good, I don't worry any more.

But it is becoming annoying that every time I turn this machine on and go to edit the flows, all those test injections are still there.

Can I have some channels not retained and others retained?
All with one server/broker.

2

Why not simply try it?

1 Like
3

I have. It doesn't work as expected.

So given my track record: I am not getting it. aka: I'm stupid.

I have turned this machine off/on a few times since writing the flow in question and others.

I have injected the test messages. Looking at the MQTT node, the retain is NOT ticked.
Yet, when I turn on THIS machine and load the browser, I am getting messages given to me I injected 3 hours ago.

I am unable to resolve this.

4

You can clean topic with:

$ mosquitto_pub -t '$topic' -n -r -d -u "$user" -p "$pwd"

and * retry your inject node *

and check there is nothing with a new fresh subscription:

$ mosquitto_sub -v -t "$topic" -u "$user" -p "$pwd" #abort with Ctrl+c

and continue again an again these 3 steps with all inject nodes

5

Some behaviour I observed on the broker, if the initial (first) message had a retain flag, it will keep it retained, until removed (I could be wrong but it is what I see on the broker).

Use mqtt explorer to view/delete topics etc.

1 Like
6

Thanks.

@flecoufle. Um, Yeozers! I'll have to think about that as I am not good at reading the template.
As far as I know there is no $user or $passowrd. (pwd)

@bakman2
Yeah. I have MQTT explorer.

Stupid me, I wiped the messages.
Loading MQTT-explorer shows none of the messages.
I know (have a good idea) of those messages. They weren't there/shown.

So I don't get how that works.

I have seen other messages and their retain flag is set. Easy to see.
So it is a real curve ball for me.
I don't want to have to reboot/restart to get it to happen for the sake of seeing it.
I will have to try and remember to check next time I boot.

Oh! The message/s are seen on three different machines. So it isn't that a particular machine is deciding to be difficult.

7

The retain flag is only set on messages that are delivered by the broker for clients that connect late., (after the message has been sent to the broker - eg reconnecting). IE so you know the message is not "live". If the client is already subscribed and receiving data then even if the message is sent with the flag set (and thus held by the broker) - it is then delivered to the client without the flag set (as at that point it is currently live data).

1 Like
8

Thanks. That helps.

It kind of goes with what is happening.

The system is up. I power up this machine (the NUC) and it connects late to the network.
That/those messages are re-sent.

But if the retain isn't set. . . . . . ?

Should it be re-sent?

I'll have to check what is going on with the nodes for retain.

9

if the messages are published without the retain flag the broker won't retain them, and a late joining client will never receive them.

10

Thanks.

Again, I don't know the status of all the nodes in this part of the equation.

Shall follow up and see what I see.

Quick dumb question:
What is the retain is BLANK?
Is there a default on/off?

(Being honest with what the node shows and to what it is set.)

11

default false - not set

12

Yeah, ok. I can see it is not set. But what does that mean?

When I send a message through this node, is the retain flag set or not?
(Yeah, kinda rhetorical)

But I am mentioning that it could catch a lot of people like me (or maybe not) who leave it blank.

Is this making sense?

ITMT I have set it of FALSE but shall have to wait to see what happens in the future.

13

I think the dialog is like this because the underlying library doesn't require QOS or Retain flags to be included in the MQTT message

I think there is a case for the dialogs to default to QOS 0 and retain flag false to avoid confusion at the Node-RED level of MQTT abstraction?

Or maybe just have those values showing as greyed out like topic and name when nothing is entered for them?

14

Yes, I can accept that.
So maybe what I am asking is beyond Node-Red's scope.

If I send a message without retain set to false or true. . . . . . Though MQTT will send the message, what will happen if I send a message to a topic (channel) and later on connect/power up a machine which is also subscribed to the topic?

Will the message be sent to it obeying the retain or not?

I don't mind either way. It is just after having that mentioned (again) and refreshing my memory, it raises the question of why is the machine I just powered up getting messages from hours ago when the retain isn't set to either on the node?

I am not saying it needs to be forced to one or the other.
But maybe the effects of having it blank explained.

Yeah, ok that's a MQTT thing rather than a NR thing.

I'm just blabbing / thinking aloud.
I know that isn't always a good thing, but.

15

the defaults are retain=false and QoS=0... it doesn't require any more thinking about than that. The default means it is taken care of if you don't set it.

16

Ok. I was just wanting to be sure.

I am sure you know that when I make assumptions, I usually make a mess of things.

17

One thing that may be confusing you is that if you once publish to a topic with Retain set then that will not be un-retained by publishing with Retain not set. So a client subscribing at any time later will be sent a value. To remove it you have to publish with null contents as described earlier.

2 Likes