Re: [mqtt] MQTT Can multiple Subscriber clients have the same Last will topic?

30 views
Skip to first unread message
Message has been deleted

Dustin Sallings

unread,
Feb 27, 2020, 1:18:59 AM2/27/20
to mq...@googlegroups.com
Last will is orthogonal to subscriptions.

But this question seems weird.  When you tried, did you see any reason why it would be a problem?


On Wed, Feb 26, 2020, 20:54 Naveen PS <naveen...@gmail.com> wrote:
Let say i have an array of sensors, and using Last Will & Testament I want to know the offline status of any sensor node along with sensor id when ungraceful disconnect happens.

the common last will topic is sensor/offline and the LWT message will the sensor ids

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/42eb0ec9-a259-4477-a418-c65240d0993b%40googlegroups.com.

Naveen PS

unread,
Feb 27, 2020, 2:57:41 AM2/27/20
to MQTT
I am Really Sorry. What i Meant was Can multiple Publisher clients have the same last will topic. Lets say the there are 4 sensor nodes which set the same last will topic  sensor/offline. and the last will message is the sensor id. How will the LWT behave in this scenario 


On Thursday, February 27, 2020 at 11:48:59 AM UTC+5:30, Dustin Sallings wrote:
Last will is orthogonal to subscriptions.

But this question seems weird.  When you tried, did you see any reason why it would be a problem?


On Wed, Feb 26, 2020, 20:54 Naveen PS <naveen...@gmail.com> wrote:
Let say i have an array of sensors, and using Last Will & Testament I want to know the offline status of any sensor node along with sensor id when ungraceful disconnect happens.

the common last will topic is sensor/offline and the LWT message will the sensor ids

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mq...@googlegroups.com.

Nick O'Leary

unread,
Feb 27, 2020, 3:07:31 AM2/27/20
to mq...@googlegroups.com
There is nothing special about the Will Topic. It's just a topic on the broker like any other. By default, any client can publish to any topic - regardless of whether that's done as a result of the Will being triggered or a regular publish.

So yes, every client can use the same Will topic.

The only caveat in that is some brokers provide access control rules to restrict who can publish to what topic. But that is above and beyond the protocol itself.

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/fdd90060-0241-48bc-b424-b9dd42ed91e2%40googlegroups.com.

Naveen PS

unread,
Mar 2, 2020, 12:25:28 AM3/2/20
to MQTT
Hi Nick,

Correct me if I am wrong. The Publisher clients on the first connect itself set the LWT Topic & Message in the broker with its CONNECT Packet. So, it means that the broker itself will have stored this LWT message and topic. So, lets say my sensor node 1 and sensor node 2 connects to the Broker with LWT topic sensor/offline and their respective sensor id's, wouldn't the topic message gets overwritten by the sensor node that disconnects later. When multiple sensor nodes disconnects ungracefully at the same time, wouldn't it be a problem? 

Thanks

Dustin Sallings

unread,
Mar 2, 2020, 12:45:28 AM3/2/20
to mq...@googlegroups.com

On Sun, Mar 1, 2020, 21:25 Naveen PS <naveen...@gmail.com> wrote:
Hi Nick,

Correct me if I am wrong. The Publisher clients on the first connect itself set the LWT Topic & Message in the broker with its CONNECT Packet. So, it means that the broker itself will have stored this LWT message and topic. So, lets say my sensor node 1 and sensor node 2 connects to the Broker with LWT topic sensor/offline and their respective sensor id's, wouldn't the topic message gets overwritten by the sensor node that disconnects later. When multiple sensor nodes disconnects ungracefully at the same time, wouldn't it be a problem? 

What problem are you observing and with what broker?

I've not implemented a fully compliant broker, but it didn't occur to me to index clients by lwt topic, so I wouldn't have been able to create bugs like the ones you're describing. I'm curious where you're seeing them.

Andy Stanford-Clark

unread,
Mar 2, 2020, 1:39:39 AM3/2/20
to 'Simon Walters' via MQTT
The LWT message (topic and payload) is stored *for each client* in the broker. 
Think of LWT as “the message you would like to publish if you knew you were about to go offline”.

BTW, I usually use different topics for the different nodes (e.g. status/node1, status/node2), and use a *retained* LWT message. When you connect, publish a “birth certificate” to the same topic (also retained) saying “online” (or in your case, a list of the sensors that are now online), and then at any time a new subscriber can come in and check the status of any node and sensors. 

Andy


To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/67e8a666-992a-4554-b5cf-a57fa5b61f74%40googlegroups.com.

Naveen PS

unread,
Mar 2, 2020, 11:45:17 PM3/2/20
to MQTT
Hi Dustin,

Thank You for your time. It is not an industrial level application or anything. I am just exploring MQTT Features with a couple of ESP32s (Publisher Clients-Nicks PubSub library - Hive MQ broker - Raspberry Pi 4 Subscriber(Paho python).

lets say there are 100s of sensor nodes publisher clients in an industry setting and other than lets say a dashboard subscriber client, we also have an emergency SMS Notification client. The SMS Notification client is subscribed to the common LWT topic of all the sensor nodes. So i was thinking like, when any of the sensors ungracefully disconnect, it will send its sensor id lets say s24 to the common LWT topic and the SMS Client will forward the sensor id as SMS to technician so that he can fix the exact module faster. I was thinking like rather than the SMS Client Subscribing to each and every individual separate LWT topic of each sensor, it can just subscribe to one common LWT topic. The reason why i was thinking like this is because, it will be easy for scaling as you don't need to modify the code of the SMS client.

Naveen PS

unread,
Mar 3, 2020, 12:01:54 AM3/3/20
to MQTT
Hi Andy,

Thank You for your time. That method is great. Using Retained and LWT together to know the status. Thank you
Andy


Karl Palsson

unread,
Mar 3, 2020, 4:45:09 AM3/3/20
to mq...@googlegroups.com
You seem to be making this more complicated in your head :)

Your "SMS Client" just subscribes to the wildcard topic
my/notifications/# Your devices just each use an LWT of
my/notifications/<deviceid>

No need to subscribe individually, ot list them all, or modify
code.

Use the topic heirarchy for your needs, it's what it's for!

Sincerely,
Karl Palsson


Naveen PS <naveen...@gmail.com> wrote:
> Hi Dustin,
>
> Thank You for your time. It is not an industrial level
> application or anything. I am just exploring MQTT Features with
> a couple of ESP32s (Publisher Clients-Nicks PubSub library -
> Hive MQ broker - Raspberry Pi 4 Subscriber(Paho python).
>
> lets say there are 100s of sensor nodes publisher clients in an
> industry setting and other than lets say a dashboard subscriber
> client, we also have an emergency SMS Notification client. The
> SMS Notification client is subscribed to the common LWT topic
> of all the sensor nodes. So i was thinking like, when any of
> the sensors ungracefully disconnect, it will send its sensor id
> lets say s24 to the common LWT topic and the SMS Client will
> forward the sensor id as SMS to technician so that he can fix
> the exact module faster. I was thinking like rather than the
> SMS Client Subscribing to each and every individual separate
> LWT topic of each sensor, it can just subscribe to one common
> LWT topic. The reason why i was thinking like this is because,
> it will be easy for scaling as you don't need to modify the
> code of the SMS client.
>
>
> On Monday, March 2, 2020 at 11:15:28 AM UTC+5:30, Dustin
> Sallings wrote:
> >
> >
> > On Sun, Mar 1, 2020, 21:25 Naveen PS <naveen...@gmail.com <javascript:>>
OpenPGP-digital-signature.html

Naveen PS

unread,
Mar 3, 2020, 6:08:06 AM3/3/20
to MQTT
My bad. I totally forgot about wildcards!. Thanks a lot!! 
Reply all
Reply to author
Forward
0 new messages