Method to prevent resending of retained messages after client resubscribtion

Mosquitto MQTT Broker
1

Hi everyone!
Quick disclaimer upfront: I’m pretty new to all of this, so please excuse inaccuracies and lacking knowledge.

Setup
I’m running an Mosquitto MQTT Broker on a raspberry pi zero which also has a MQTT client running node red. The other client is an esp32 (running PubSubClient ) which sooner or later will be run on a battery and needs to conserve power. Therefore, it spends a lot of time in deepsleep, waking up based on different parameters, connecting to wifi and MQTT broker, subscribing, sending and receiving MQTT payloads, terminating connections and going back to sleep. Due to deepsleep, all payloads in topics the esp32 is subscribing to are sent with the retain flag set. All of this works splenditly besides of one detail regarding the client subscribtions: As @discobot may say it: The retain flag :white_flag: works too well. :smiley:

My issue
The ESP32 gets the same (retained) payloads (one per topic ofc) from the broker over and over again, once after each wakeup. I guess this is due to the fact it resubscribes every time. I’ve tried different QOS (although PubSub doesn’t support QOS3 subsribtions, due to ram limitations i believe) settings but nothing has helped so far. I even disabled clean sessions (on the client side at connection), but it still happens, probably due to the resubsribtion still happening. I’d like to keep those, if possible, since in case of a server reset I might lose them and don’t see how I can check if the client is still subscribed.

My question
Is there a way to prevent Mosquitto MQTT Broker to resend those messages after each subsribtion? Since the client has the same clientID, I guess it could know that it already got it.

Thank you for your help in advance and have a great day!

2

Hi! To find out what I can do, say @discobot display help.

1 Like
3

Update:
I tried switching MQTT clients on the ESP32 to AsyncMqttClient which allows QOS 2 subscribtions, but this still did not resolve the issued.

Update 2:
If the ESP32 client ist switched to a persistent session and the code altered after the initial subscribtion to not subsribe anymore it basically works as intended. BUT: In case of a server reset the device wouldn’t subscribe anymore on it’s own, so this isn’t a solution, merely an indicator to me that the issue is indeed the resubscribtion. :confused:

4

Hi Tina,

You don’t actually need QoS 1 or 2 for this to work. If you connect as a persistent client (so clean session set to false), then all of your subscriptions will be kept by the broker until you reconnect, regardless of QoS.

You are correct that it is possible that the server could have your client session reset. You can work around this by using the “session present” flag in the CONNACK packet - this should be provided to you in the on_connect callback or similar. If session present is set, then you do not need to resubscribe. If it is not set, then you must resubscribe.

It’s also worth noting that if you have access to MQTT v5.0, then there is a subscription option which controls when retained messages are sent - either on the first subscription to a given topic only, always, or never. You’d have to check the documentation for your client.

Regards,

Roger

1 Like
5

Thank you roger.light, the following certainly resolves the issue in case of a persistent session!

if(sessionPresent==false){
      mqttClient.subscribe("topicname", 2);
    }

I would have prefered to maintain a clean session so I wouldn’t need to be careful to not publish duplicate messages from the other client while the esp32 is in deepsleep, since the broker would just have kept the newest one, while now it retains all of them. But I guess I can modify my publish behaviour to be more restrictive.

MQTT v5.0. would be neat, but I am not aware of a beginner-friedly client for esp32. I saw one which required some (at least to me) advanced preparations, but I am always open for suggestions!

Thanks again! :relaxed:

1 Like