QOS flag for MQTT

[flygrmn51]

It would be nice if we can have a QOS flag at the device level. This is very important for MQTT functionality and will work much better than the retain flag where the subscriber is connected intermittently. The same is true for QOS at the subscriber level. This will ensure all messages are picked up regardless if there was an interruption in the connection.

I have standardized on using ESPEasy on all my units. Love the functionality and flexibility. I use Openhab MQTT controller with Node Red exclusively.

Thanks.

[TD-er]

Is this still needed when this PR is merged? https://github.com/letscontrolit/ESPEasy/pull/1669#issuecomment-419236639 The link points to my post with the latest test build.

In short, the controllers will then have a queue to make them less blocking and use some delay between messages to prevent flooding the receiving end (and keeping ESP side busy) Also the queue may hold messages until the network connection has been restored.

[flygrmn51]

I believe it will be. As far as I understand, if the qos level is at 0 any messages delivered will only reach active subscriptions that are connected while received by the MQTT broker. Interrupted connections would not receive the messages if they reconnect afterwards. We can prevent flooding at the ESP level by setting the qos for received messages to 0, but sent messages should be able to be at a higher level to ensure subscribers receive them, I think. Perhaps the messages on the ESP could be managed by only holding the last message in the queue for each task if qos is higher than 0.

[TD-er]

Well, I can apply some filtering in the queue algorithm ofcourse, which takes into account a QOS level. But I have to think about how this should be implemented. I guess we can start with some "default" definition for which sensors have a lower QoS level and switches or other input related plugins will have a higher QoS.

No idea by the way, if PubSubClient does support QoS levels. We also have to look into that.

[TD-er]

See PubSubClient documentation. It does support QoS for the will (at connect) and for the topics.

So I guess this is only useful if the topic can also be set at plugin level.

[flygrmn51]

Perhaps it is possible to look at AsyncMqttClient as an alternative. It seems to be a bit more flexible and has Qos built in. Although I have limited experience here. Thanks for looking at this.

[TD-er]

I like Async communications, but I am not likely to change a well established library for another. Also PubSubClient does support QoS.

[flygrmn51]

I understand. Thanks.

[erokoder]

@flygrmn51 @TD-er Any progress about QoS?

[TD-er]

@erokoder Not yet. The last weeks I've been very busy on trying to find the watchdog reboots. The rest of the feature requests have been a bit neglected while finding these stability issues.

[TungstenE2]

Any news on QoS?