Any plans for MQTT QOS 1



Any plans for QOS 1.

We would like to use the mosquitto bridge on our gateway devices to manage disconnection/connection to loasant and and it can then manage local retention of messages and playback when reconnected to Losant.

This is something we would be willing to pay for.

in the meantime I would build a local queue (e.g probably based on redis) and manage that myself. But I am really trying to write as little as possible :wink:




I think QoS 1 would be pretty straightforward for us to support, especially for your use case. Things get challenging on our end when we start getting into persistent and retained messages, but those aren’t required for your example. I don’t have a timeline right now, but I’ll submit it as a ticket. Thanks!


Partial QoS 1 for publishes is now live. We implemented PUBACK support, which should provide what you need.



Hopefully I can get time to try it today.

One question, how does Losant deal with out of order (by time - explicit timestamp) data.
For instance if old day is sent do we need to put specific guards in Workflows to not process this.

I would assume so

Thanks again for your rapid responses.




Losant does not guaranteed timestamp ordering when running workflows, so if ordering is important to your application, you will have to put guards in place.

I would recommend using the Store Value and Get Value nodes. You can store the date of the last processed payload using the value type “Payload Path” with the value of “time” (the “time” property holds the timestamp on the payload).

On each workflow run you can then get the value and use a conditional block to compare the incoming date to the last processed date.


HI Brandon

No problems, I thought that was the case.

If we send old data we will probably set a flag rather than having to check the dates.