Choose MQTT Persistent Session and QOS Appropriate for Use Case

[ForrestErickson]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Lee asked an AI the following

for an MQTT broker connection what does true do in this command: client.connect(BROKER_URL, clientId, true); // BROKER_URL, name, Clean session

The AI reported:

In your MQTT connection command, is the Clean Session flag. [1]
Setting it to tells the broker to create a non-persistent session. Here is exactly what this means in practice:

• No Message Queuing: If your device disconnects (due to a network drop or power loss), the broker will discard all incoming messages and subscriptions meant for your device.
• Fresh Start: When your client reconnects, it will start with a completely clean slate. It will have to re-subscribe to all of its topics.
• When to use it: It is ideal for sensors or devices that only care about real-time data and do not need to retrieve messages that were sent while they were offline. [1, 2, 3, 4]

Contrast with :If you set it to , you establish a persistent session. The broker will remember your subscriptions and hold onto undelivered messages (Quality of Service 1 and 2) while your device is offline, delivering them immediately when you reconnect. [1, 2]
For a deeper dive into how this affects message delivery, check out the HiveMQ Clean Sessions Guide.

AI responses may include mistakes.

[1] https://docs.n3uron.com/docs/mqtt-client-configuration
[2] https://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages/
[3] http://www.steves-internet-guide.com/mqtt-clean-sessions-example/
[4] https://thingsboard.io/docs/mqtt-broker/user-guide/clean-persistent-sessions/

Describe the solution you'd like
A clear and concise description of what you want to happen.

For Krake we need to test and choose if the connection is persistent.
Worst Case we make a user interface choice for the use case of end users. The Developer manual will need to educate the developer on how to chose persistent connection or not.

[ForrestErickson]

Background,
I was experimenting with MQTT in Processing trying to learn how to report client connection success and failures and important consequences of a parameter in the connect method.

It is not clear to me for Krake if we always want true or false for the "Clean Session" flag. See the issue for some more details and how the behavior has differences for the different QOS.

The decision for setting "Clean Session" must be made not only for the Krake, but also be made for the PMD and probably ADaM when used.

[RobertLRead]

I think we want this to be FALSE.

It is the "dropping of subscriptions" that worries me. If the connection drops, we can't have the the topics subscribed to by a device to be lost.

I personally don't think we need re-delivery of messages---I am not worried about that part.

[ForrestErickson]

Regarding, "I think we want this to be FALSE."
It is more complex.
There is the QOS sent by the PMD.
And there is the QOS by the subscriber, which is the Krake, at lease with respect to the mac_ALM.
I think we need experiments that make the retained message management reproducible.

Status: I am way too brain fog to try at this time today.

[nk25719]

For demo, KrakePubInv broker: krakepubinv.cloud.shiftr.io