Workflow MQTT publish QoS?

Help
,
1

Hi,

The MQTT Message Node seems to only be able to publish with QoS=0.
Is there any way I can use QoS=1 so that my device can then subscribe with QoS also 1, at any time and successfully get the message from the topic it’s subscribed to?

From my understanding that is the only way to send a message (configuration command) to my device via Losant and MQTT.

Any ideas?

thanks

3

Hey Eduardo,

The QoS setting between publishing and subscribing are separate and do not impact one another.

QoS=1, when publishing, only ensures a broker received the message. Client subscriptions are not taken into account. When the broker then forwards that message to client subscriptions, the QoS of the subscription is then applied. This means you can still use QoS=1 for your subscriptions regardless of what the QoS setting of the original publish happened to be.

For Edge Workflows, the MQTT Output Node does use QoS=1 since the network conditions between the Edge Agent and the cloud are unknown. When using a cloud workflow, all communication is over Losant’s private network, so the likelyhood of a missed message is extremely low and not worth the performance overhead of QoS=1.

Here’s a nice article that goes into details on QoS when publishing and subscribing:

https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/

4

To follow up on this, although subscriptions can be made with QoS=1, Losant’s broker does not currently support cleansession=0, which means unacknowledged publishes to client subscriptions will not be retried. You can find more about message retries in the MQTT spec:

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718037

6

Thanks Brandon for the detailed responses.

Can i instead publish a retained MQTT message from the Losant workflow?
That would be really useful in over the air device configuration.

thanks

8

The Losant broker does not support retained messages. The reason is similar to why it doesn’t support cleansession=0: it’s a data buffering challenge when retaining even a small amount of data a very large number of devices. Certainly a technical challenge we’d like to solve, but not one we’ve solved yet - at least in a way that meets our scalability and performance requirements.

That said, we do store commands sent to devices, which are available via the API. The commands will be available in the history based on your organizations data retention limit.

An implementation I’ve seen successfully deployed is that a device will request its command history each time it reboots or reconnects. A device can authenticate against the API using its own access key and secret. This allows a device to request its own command history from the API.

Another option is to send the most recent command to a device from a cloud workflow each time the device connects.

  1. On Connect Trigger
  2. Losant API Node to request most recent command
  3. Publish command to custom MQTT topic
1 Like