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

[Dustin Sallings]

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]

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]

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]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/fdd90060-0241-48bc-b424-b9dd42ed91e2%40googlegroups.com.

[Dustin Sallings]

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]

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]

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]

Hi Andy,

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

Andy

To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/67e8a666-992a-4554-b5cf-a57fa5b61f74%40googlegroups.com.

[Karl Palsson]

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:>>

[Naveen PS]

My bad. I totally forgot about wildcards!. Thanks a lot!!