Pubsubclient: Allow persistent connections

[RalfJL]

Hi,

I currently stumbled across a problem.
I want to build a device that is running on battery. Obviously it will connect only sporadically to the mqtt server and publish the status of a sensor.

But it also should listen to some configuration changes that are transmitted via a set Queue.
Currently the client can only connect with "persistent = false" and that is not configurable.
I would like to see an option on "connect" that allows a persistent connection.
I hardcoded this to line 146: v = 0x00;
And it works. If you send a message it will be delivered when the device connects.
But i really would like to see this being configurable on "connect()".

Please consider.

Thanks

Ralf

[sjcliffe]

I too would like to see this feature.

[r666t]

Me too!!!!!

[Suxsem]

We could add persistent session support mainly to avoid re-subscriptions and to get messages sent when the board was offline.
If the board tries to send messages when it's offline they just get discarded (moreover, your library only supports qos=0 so no problem).
I think that adding persistent session support should be straightforward, just change the connect header. All other things could be left invariate.

Just a thought: when the board should subscribes? No more on connect obviously. When power up? May happens that the broker restarts and session information are lost. So I think that the connect method of the library should return something like 0 if connect fails, 1 if connect success and there is no persistent session, 2 if connect success and there is persistent session. So subscribes should be done only if connect returns 1.
The CONNACK packet sent from the broker includes session status so this should be easy to implement too.

I can do a pull request if you like

[knolleary]

Even with a persistent session the client must still resubscribe after
reconnect. I'll look at the necessary changes later this week.

On Wed, 10 Feb 2016, 13:27 Suxsem [email protected] wrote:

We could add persistent session support mainly to avoid re-subscriptions
and to get messages sent when the board was offline.
If the board tries to send messages when it's offline they just get
discarded (moreover, your library only supports qos=0 so no problem).
I think that adding persistent session support should be straightforward,
just change the connect header. All other things could be left invariate.

Just a thought: when the board should subscribes? No more on connect
obviously. When power up? May happens that the broker restarts and session
information are lost. So I think that the connect method of the library
should return something like 0 if connect fails, 1 if connect success and
there is no persistent session, 2 if connect success and there is
persistent session. So subscribes should be done only if connect returns 1.
The CONNACK packet sent from the broker includes session status so this
should be easy to implement too.

I can do a pull request if you like

—
Reply to this email directly or view it on GitHub
https://github.com/knolleary/pubsubclient/issues/86#issuecomment-182372282
.

[Suxsem]

emh, why a client should resubscribe?
http://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages

[knolleary]

@Suxsem ignore me... juggling too many things and replying whilst at my 2yr olds birthday party are not a recipe for success.

[Suxsem]

Ahah enjoy the party :D

[RalfJL]

Hi,

just to give you some motivation for implementing this.
In my case i want to build a sensor grid. As far as i know this is
exactely what mqtt is designed for.
So i do have battery powered sensors that will promote their values
via mqtt and go to sleep for some time. That would not require
persistent conection to mqtt.
But those sensors should also accept commands from mqtt, like change
your promotion interval to say 10 minutes. If the mqtt connection is
not "persistent" the command can only be received while the sensor is
active, which will be only a very short time (approx. 1 second every
10 minutes).
Persitent in this case means that the mqtt server will keep the
message until the client reconnects and collects the message. And this
is exactely what i need for that sensor.

So please consider a flag for persistent connections.

Thanks

Ralf

----------------ursprüngliche Nachricht-----------------
Von: knolleary [[email protected] ]
An: knolleary/pubsubclient [[email protected] ]
Kopie: RalfJL [[email protected] ]

Datum: Wed, 10 Feb 2016 13:25:01 -0800

[ https://github.com/Suxsem -> @Suxsem ] ignore me... juggling too
many things and replying whilst at my 2yr olds birthday party are
not a recipe for success.
—
Reply to this email directly or [
https://github.com/knolleary/pubsubclient/issues/86#issuecomment-18258812
4 -> view it on GitHub ].

[pat1]

any news?

[m3g4by73]

I'm with Ralf with exactly the same use-case. It's the only way to get data down to a device that spends most of its time asleep (very common on sensors).

[gardendirect]

Hi guys,

same here. I'm using ESP with rabbitmq+mqtt adapter running on RPi. The subscriber queue is deleted when esp goes for deep sleep. The same as Ralf described, I need to send command data to queue and deliver once esp is back online for like 15 seconds per hour. :)
I tried qos 1 subscription, the queue on rabbitmq is created as durable, but auto-delete flag is on. Clean session would fix that I assume.
thanks

[Raja-Raman]

My use case is exactly the same, and my chip is ESP12 which is very battery-hungry. In the absence of a persistent connection, I have implemented a work-around: One of the sensors is configured as a monitoring device, but works continuously on mains power.
When the data sensor comes out of sleep and publishes a message, the monitor also gets a copy of the message. It immediately delivers the stored instruction to the data sensor. The data sensor just waits for a couple of seconds before going back to sleep, so that it can receive the command payload, if any.
To me, this sounds like a poor architecture, but it just works !
BTW, when can we expect to get the real persistent sessions, please ?

[bastianleirpo]

Same Problem here. Esp for adjusting Thermostat on a Radiator every 10 Minutes.

Best wishes
Sebastian

[knolleary]

The 2.7 release was published yesterday and introduced the ability to connect with clean-session set to false.

Enjoy!

[toogooda]

I have this problem also but can someone tell me how to use this fix, i have downloaded the library update but where do I set the false flag?

[knolleary]

@toogooda https://pubsubclient.knolleary.net/api.html#connect5

[toogooda]

@knolleary you are a legend :) I had seen that one in the header but didn't realise I could use null for U/P which I currently don't use behind the firewall. I am hoping this fixes my issues of not recieving my subscribed messages after deep sleep.

[toogooda]

Hi @knolleary using the new false flag, but still miss everything sent while sleeping, I am using Mosquitto/node red at the other end, can you please confirm this is what is supposed to happen:

• If the client had been previously connected and subscribed, then been disconnected.
• A message is then published and the client connects again with cleansession = false.
• when the subscription is at QOS1/2 and the message is published at QOS1/2

Then

I should recieve the message on the next connect after the resubscription

client.connect("WaterTank1Client",NULL,NULL,"farm/water/tank1/status",1,0,"Off",0)

[toogooda]

looked through your pubsub code and found this:

boolean PubSubClient::subscribe(const char* topic, uint8_t qos) { if (qos > 1) { return false; }

So it looks like I can't subscribe using QOS2.
Changed it to 1 and it now works but will have to code around possible duplicates.

[OliverWieland]

Hi,
thanks for the clean_session flag. I want to use this on my ESP that is in deepsleep mode most of the time for configurations.
But I don't get any Subscriptions values after Reconnection, even when I set the clean_session to false.
I publish the messages using Node Red with retain= false and Qos=1.

Please could you provide a sample that uses the clean_session flag?

Thanks in advance
Oli

[knolleary]

What QoS are you subscribing at? It need to be a QoS 1 subscription (we don't support qos2 in this library). You must also ensure you use a fixed clientid and not randomly generate one.

[OliverWieland]

OMG!
I forgot to set qos 1 in the subscription... :-|
Sorry for this...

Oli

[KianYeo]

Hi knolleary,

I am having problems with getting a persistent session to to work. I am connected to the broker (on CloudMQTT) using this line:

client.connect("ESP32Client", mqttUser, mqttPassword,"lastwill",1,0,"Disconnect",0 )

And I am subscribing to a topic with QOS 1:

client.subscribe("mytopic",1);

I am using an ESP32 with Arduino IDE and my ESP32 goes to deep sleep every 30 seconds, wakes up and stays awake for 10 seconds. From the Websocket UI on CloudMQTT, I can publish to a topic. If I am publishing during the 10 seconds when the ESP32 is awake, I can receive data from the topic i subscribed to. However if I publish during the time when the ESP32 is in deep sleep, when it wakes up, it is not receiving any data.

Do you know what can be wrong?