ESP8266 MQTT Client (Arduino IDE) with QoS 0. 1, and 2?

[Geoff Lethbridge]

Is there a well written and reliable, in your experience, client that has all three QoS's for the ESP8266?  

I have been using PubSub but it is old and would like to use a client with all three QoS's

Regards

Geoff

[Simon Walters]

Having had a bit of a google and looking thru some code - this library might do at least QoS=1

https://github.com/256dpi/arduino-mqtt

BTW what is your use case for needing QoS 1/2 from an ESP type client?

Simon

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/800d9bca-2e18-4a1c-9099-94cac7c03b56%40googlegroups.com.

[Geoff Lethbridge]

Hi Simon

Thank you for your post.

I hope that someone who has deployed code will post their experiences.

I'm looking to change to code that will cover all three use cases.

Regards

Geoff

On Monday, 9 March 2020 21:28:16 UTC+11, Simon Walters wrote:

Having had a bit of a google and looking thru some code - this library might do at least QoS=1

https://github.com/256dpi/arduino-mqtt

BTW what is your use case for needing QoS 1/2 from an ESP type client?

Simon

On Mon, 9 Mar 2020, 6:20 am Geoff Lethbridge, <geoff.l...@gmail.com> wrote:

Is there a well written and reliable, in your experience, client that has all three QoS's for the ESP8266?  

I have been using PubSub but it is old and would like to use a client with all three QoS's

Regards

Geoff

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mq...@googlegroups.com.

[Dustin Sallings]

QoS2 is very complicated and unlikely to be done correctly on an embedded device.  It requires durable persistence.

QoS1 is great for most use cases.

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/5484e031-bb3f-4e28-87c1-f72edcacff98%40googlegroups.com.

[Andy Stanford-Clark]

QoS 2 is actually like two QoS 1 message back to back… QoS 0 is the easy one - QoS 1 and 2 are similarly hard (as you point out, they need message and state storage and a retry queue). It doesn’t *have* to be durable, though: do the best you can with what you’ve got. 

As long as the battery doesn’t fail, in-memory is probably good enough ;)

Andy

To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/CAFnwT58ToVDYaNFuSUYfQLddpMdChT3FMGtsKE%3DUdCvMnxJ-vg%40mail.gmail.com.

[Dustin Sallings]

On Mon, Mar 9, 2020 at 8:46 AM Andy Stanford-Clark <an...@stanford-clark.com> wrote:

QoS 2 is actually like two QoS 1 message back to back… QoS 0 is the easy one - QoS 1 and 2 are similarly hard (as you point out, they need message and state storage and a retry queue). It doesn’t *have* to be durable, though: do the best you can with what you’ve got. 

As long as the battery doesn’t fail, in-memory is probably good enough ;)

You get into some really ugly edge cases since there's no timeout on states.  Theoretically, the client can send a PUBREL and never receive a PUBCOMP.  At this point, the message isn't delivered, but can't be retried.  Or you can get part of the way through and have the client restart and receive a PUBCOMP for a message ID you have no knowledge of, but have in an outbound queue that you'll probably end up retrying because you can't correlate the in-flight transaction with known state on a new connection.

It's effectively specified as a byzantine generals problem.  The lack of timeout makes it nearly impossible to get right without durable state on both ends.

tl;dr: most people probably want QoS 1.

[Andy Stanford-Clark]

I know ;)

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/CAFnwT58GCFcQo69dEQg0HSxhFmfvRi03T8%3DB%3DWjMXpVOURoMEA%40mail.gmail.com.

[Dustin Sallings]

On Mon, Mar 9, 2020 at 10:03 AM Andy Stanford-Clark <an...@stanford-clark.com> wrote:

I know ;)

heh, I suppose you would.  I learned it the hard way (by doing an implementation from scratch and finding all the edge cases).  I wouldn't think QoS 2 would be useful for most deployments, but if OP has an interesting use case, I'd be interested in understanding it better.

Regarding libraries, I found https://github.com/256dpi/arduino-mqtt to be pretty well written.  I sent in a PR a few months ago to add MQTT v5 support since some of the features were fairly important to my deployments.  I tend to use it with QoS 1 and one or two properties specific to my needs (mostly message expiry interval).

[Geoff Lethbridge]

Thank you Dustin and Andy. :)

Regarding libraries, I found https://github.com/256dpi/arduino-mqtt to be pretty well written.  I sent in a PR a few months ago to add MQTT v5 support...

I'll take a good look at "arduino-mqtt" and MQTT v5 support would be nice.