# MQTT data persistence not possible due to automatic unsubscribe before disconnect

**URL:** <https://discourse.nodered.org/t/mqtt-data-persistence-not-possible-due-to-automatic-unsubscribe-before-disconnect/56865>\
**Category:** General\
**Tags:** mqtt\
**Created:** [18 January 2022 15:19 UTC](https://discourse.nodered.org/t/mqtt-data-persistence-not-possible-due-to-automatic-unsubscribe-before-disconnect/56865 "2022-01-18T15:19:20Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Keylies](https://avatars.discourse-cdn.com/v4/letter/k/eb8c5e/32.png) [@Keylies](https://discourse.nodered.org/u/Keylies)\
**Post date:** [18 January 2022 15:19 UTC](https://discourse.nodered.org/t/mqtt-data-persistence-not-possible-due-to-automatic-unsubscribe-before-disconnect/56865/1 "2022-01-18T15:19:20Z")

</div>

Hello everyone,

I have trouble testing the persistence of MQTT messages with Node-RED.

I have a Node-RED 2.1.6 server, in which a "mqtt in" node subscribes to a topic.

I would like that if my Node-RED server goes down, I can retrieve the messages from the topic I subscribed to when the server starts again.

For that, I subscribe with the "clean start" option disabled, and QoS2. All is good theoretically I already tested this process outside Node-RED.

However, when I stop the Node-RED server, there is an unsubscription to the topic before the disconnection, so the Mosquitto broker can't keep in memory that it has to keep the messages for the ID RED-DEV client.

Here are the logs from Mosquitto after a Node-RED service stop :

```auto
2022-01-18T15:04:29: Received UNSUBSCRIBE from RED-DEV
2022-01-18T15:04:29: Sending UNSUBACK to RED-DEV
2022-01-18T15:04:29: Received DISCONNECT from RED-DEV
2022-01-18T15:04:29: Client RED-DEV disconnected.

```

I have already read in this topic that it is normal that there is an automatic unsubscription when a node is destroyed: [Issues in persisting messages in MQTT Broker using NodeRed MQTT Nodes - #23 by Colin](https://discourse.nodered.org/t/issues-in-persisting-messages-in-mqtt-broker-using-nodered-mqtt-nodes/4666/23)

In what situation can we then recover the messages sent while Node-RED was not available? Is it possible to override the initial behavior to only disconnect the client and not unsubscribe?

Thank you, have a nice day.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [18 January 2022 15:57 UTC](https://discourse.nodered.org/t/mqtt-data-persistence-not-possible-due-to-automatic-unsubscribe-before-disconnect/56865/2 "2022-01-18T15:57:10Z")

</div>

When node-red stops, the runtime in which the client exists is destroyed. So what you are describing cannot be avoided.

Are the values published with `retain` set?

If not, you won't get the values when you restart (any) MQTT client and re-subscribe.

---

<div class="post-metadata">

**Author:** ![Keylies](https://avatars.discourse-cdn.com/v4/letter/k/eb8c5e/32.png) [@Keylies](https://discourse.nodered.org/u/Keylies)\
**Post date:** [18 January 2022 16:46 UTC](https://discourse.nodered.org/t/mqtt-data-persistence-not-possible-due-to-automatic-unsubscribe-before-disconnect/56865/3 "2022-01-18T16:46:11Z")

</div>

Thank you for your answer.

I don't use the "retain" feature because I read that it only retains the last message sent to a topic, and I need to retrieve all messages.

I have tested persistence with other techno (Flutter), when a problem occurs, the client (in same configuration with no clean start and QoS2 of course) is disconnected without unsubscribing first, so the broker knows it has to retain all the messages until it returns.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [18 January 2022 20:33 UTC](https://discourse.nodered.org/t/mqtt-data-persistence-not-possible-due-to-automatic-unsubscribe-before-disconnect/56865/4 "2022-01-18T20:33:39Z")

</div>

> [@Keylies](#):
>
> I don't use the "retain" feature because I read that it only retains the last message sent to a topic, and I need to retrieve all messages.

If you need the _history_, you don't want MQTT but a database. Many of us use InfluxDB which is a timeseries database well suited for recording ongoing sensor and other events.

MQTT is meant to be lightweight and only meant to retain the last value when using the retain flag. It acts as an event hub letting you have subscriptions to topics and get notified when something changes and the new value.

You can set up persistent storage in Node-RED as well, have a rummage through the docs. But this is also ill-suited to storing historic data. A database is what you need for that.

> [@Keylies](#):
>
> I have tested persistence with other techno (Flutter), when a problem occurs, the client (in same configuration with no clean start and QoS2 of course) is disconnected without unsubscribing first, so the broker knows it has to retain all the messages until it returns.

For MQTT, you can choose whether you have a "clean start" so that when a client reconnects it doesn't get all of the retained and subscribed topics. However, this is not often very useful and not really of any use if you have restarted Node-RED completely.

If you need something more, have a look at the MQTT v5 settings as these give you more options & they may help you get what you want.

However, you still only ever have the last value in MQTT, anything more requires a database.

---

<div class="post-metadata">

**Author:** ![Keylies](https://avatars.discourse-cdn.com/v4/letter/k/eb8c5e/32.png) [@Keylies](https://discourse.nodered.org/u/Keylies)\
**Post date:** [19 January 2022 07:47 UTC](https://discourse.nodered.org/t/mqtt-data-persistence-not-possible-due-to-automatic-unsubscribe-before-disconnect/56865/5 "2022-01-19T07:47:50Z")

</div>

From your answer, I understand that Mosquitto is the one that offers the 1+ message retention feature, and that it is not available with Node-RED by design.

I will look into database solutions, thank you for your answers!

---

<div class="post-metadata">

**Author:** ![deputynl](https://avatars.discourse-cdn.com/v4/letter/d/49beb7/32.png) [@deputynl](https://discourse.nodered.org/u/deputynl)\
**Post date:** [20 January 2022 09:24 UTC](https://discourse.nodered.org/t/mqtt-data-persistence-not-possible-due-to-automatic-unsubscribe-before-disconnect/56865/6 "2022-01-20T09:24:28Z")

</div>

Just an idea, but would RabbitMQ help you? It's a queue and is able to retain messages when the client is not available.  
[https://www.rabbitmq.com/tutorials/tutorial-two-python.html](https://www.rabbitmq.com/tutorials/tutorial-two-python.html)

---

<div class="post-metadata">

**Author:** ![shanmukha](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/shanmukha/32/61181_2.png) [@shanmukha](https://discourse.nodered.org/u/shanmukha)\
**Post date:** [10 March 2022 10:16 UTC](https://discourse.nodered.org/t/mqtt-data-persistence-not-possible-due-to-automatic-unsubscribe-before-disconnect/56865/7 "2022-03-10T10:16:14Z")

</div>

is this issue resloved?  
Im also getting the same issue ,  
when im disabling the flow in which my mqtt client subscribe (with persistance and Qos level 2 connection) to a topic.  
when the flow is enabled im receiving messages properly no issue here,but when im disabling the flow and then connecting after sometime im not getting the messages that were sent during the disabled time period ,but it should receive right.  
i have checked same test situation in MQTTX tool and in that im able to get the messages when i come online again ,but in node-red it is not .

as said @Keylies the node-red is unsubscribing the topic before it is getting disabled. so is there any way to prevent it from unsubscribing?

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [10 March 2022 10:31 UTC](https://discourse.nodered.org/t/mqtt-data-persistence-not-possible-due-to-automatic-unsubscribe-before-disconnect/56865/8 "2022-03-10T10:31:32Z")

</div>

> [@shanmukha](#):
>
> is this issue resloved?

No, it is not. It is just how node-red was designed to work.

However, there is a feature request in node-red repository waiting for someone to implement it: [Don't unsubscribe MQTT Level 1 or above topics on nodered restart / close or at least add option · Issue #3452 · node-red/node-red · GitHub](https://github.com/node-red/node-red/issues/3452)

It may or may not get done in time for node-red V3 (Planned for April) - it depends on achieving other assigned tasks (or if a community member picks it up)

---

<div class="post-metadata">

**Author:** ![shanmukha](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/shanmukha/32/61181_2.png) [@shanmukha](https://discourse.nodered.org/u/shanmukha)\
**Post date:** [10 March 2022 10:34 UTC](https://discourse.nodered.org/t/mqtt-data-persistence-not-possible-due-to-automatic-unsubscribe-before-disconnect/56865/9 "2022-03-10T10:34:21Z")

</div>

ok thanks for the information 👍

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [9 May 2022 10:34 UTC](https://discourse.nodered.org/t/mqtt-data-persistence-not-possible-due-to-automatic-unsubscribe-before-disconnect/56865/10 "2022-05-09T10:34:39Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.