MQTT every ten seconds question - multiple clients

#1

I have a flow in Node Red that publishes data over MQTT every ten seconds. It works fine in my testing with one client, a NodeMCU that subscribes to the topics and displays the message data. But, what happens if I have multiple clients subscribing to the same topics? Do I understand correctly that the MQTT broker keeps track of which clients haven't gotten their data, even with a QOS of zero? It's OK if the clients sometimes miss getting the data, but I am wondering the best practice here- separate topics for each client? Higher QOS?

0 Likes

#2

This 10? part guide linked below is worth reading to answer most questions on how MQTT works...

https://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt/

0 Likes

#3

Whether you have one or 100 clients subscribing to a topic should make no difference to the way each client is handled.
When you ask whether it keeps track of which clients have not got the data, what sorts of reason that might prevent them getting the data are you thinking of?

0 Likes

#4

The QoS is exactly that - a Quality fo Service... So for QoS 0 (fire and forget) the broker will send the message to each subscribed client - but doesn't check for an acknowledgment back. Qos 1 (at least once) - it retries until it gets an ack back (so may send more than once), QoS2 (once and once only) - it checks that it only gets received once. So depending on the QoS it does more or less "tracking". Clients can subscribe with whatever QoS they want.

0 Likes

#5

Thanks. With the two clients side-by-side, sometimes only one would update. Maybe one out of 20 messages. But, as I said, it is no problem if missed data is that infrequent. I just wondered if QOS "fire and forget" was the right level.

0 Likes

#6

This is the part of QOS that confuses me- if I publish with a QOS of 0, what difference does it make what QOS level that is set by the subscriber?

0 Likes

#7

AFAIK the two QOSes are basically separate (but do have affects on overall system behaviours)
Publish at QOS0 just mean the broker MIGHT get the message

Publish at QOS1 means the broker will def get the message but might get it several times

Publish as QOS2 means the broker will only get the message once

Once the broker has the message - it forwards it based on subscribing clients QOS topic setting

So if published at QOS0 - its possible that no QOS2 client will get the message as its not guaranteed to have reached the broker in the 1st place

Any QOS1 or 2 published message is guaranteed to get to a QOS1 or QOS2 subscribing client

Simon

0 Likes

#8

OK, I think I grok. I need to think of the publisher to client in two discrete steps and not a single path.

0 Likes

#9

Is your mqtt server local or is it on the internet? With everything on the local internet then that should not happen, even with QOS 0.

0 Likes

#10

Yes, there is no publisher to client path. It is publisher to broker and broker to client(s).

0 Likes

#11

It's local. And I haven't seen the anomaly again, so it could easily have been something else in my code.
Thanks for the info.

0 Likes

#12

Not quite. The Broker should never upgrade the qos of a message - it will only ever downgrade it to match the subscription qos.

  • A message that was published at qos 0 will be sent as qos 0 to all subscribers regardless of their qos (as qos 0 will not get upgraded to 1 or 2).
  • A message that was published at qos 2 will be sent at the qos of the subscription (as qos 2 can be downgraded to 0 or 1)
1 Like

#13

no coconut yet again :frowning:
But I was close :slight_smile:

0 Likes

#14

Thanks for the clarification. I had been under the wrong assumption that once set, the QOS doesn't change downstream.

0 Likes