Cannot subscribe with MQTT QoS 1

[Denis_French]

Losant documentation (https://docs.losant.com/mqtt/overview/#mqtt-version-and-limitations) indicates that QoS 2 is not supported, implying that QoS 1 is.

When I subscribe to a topic using node-red with QoS set to 1 the received messages indicate that they are sent as QoS 0. This is replicated when troubleshooting using MQTT.fx .

Am I mistaken that subscribing with QoS 1 is supported, or is there something else that I am missing?

Any advise appreciated,
Denis.

[Brandon_Cannaday]

Apologies for the confusion. QoS 1 is only available for publishing. We’ll update the documentation to clarify that.

[Denis_French]

Thanks for clarifying Brandon.

Is there any intent to implement QoS 1 for subscriptions? It seems quite central to ensuring reliable communication with a range of distributed devices with disparate connectivity.

The embedded MQTT service was one of the attractions of the Losant platform; it would be disappointing to have to integrate with an external MQTT server.

[Brandon_Cannaday]

I submitted a ticket to investigate supporting QoS 1 for client subscriptions. In the meantime, if you require the functionality, we do have an MQTT integration that will allow you to use a third party MQTT broker while using Losant for additional functionality.

[Denis_French]

Thanks Brandon; I look forward to hearing how it goes.

[Jose_Cruz]

@Brandon_Cannaday : almost 4 years later, but we’re in the same boat as the post in here ► our MQTTS broker prefers/suggests SSL/Certificate (which we already implemented successfully) and QoS 1 - currently all messages in Losant are showing in the broker as QoS 0. I apologize if this has already been addressed elsewhere, if not, is QoS 1 still ‘on the works’ ? Thanks,

[Brandon_Cannaday]

Hey @Jose_Cruz,

QoS 1 is supported for publishing to Losant’s broker. This results in every message being PUBACK’d by the broker to verify delivery.

QoS 1 is technically allowed for subscriptions, but Losant’s broker does not support cleansession=0, which means unacknowledged publishes to client subscription will not be retried.

You can find a few more details and the reason these are not currently supported in the following thread:

Workflow MQTT publish QoS?

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

[Jose_Cruz]

I am assuming by cleansession=0 you mean the [✓] Clean option in the Losant Integration page to be ‘unchecked’, which is not. Please correct me if wrong. If that’s the case, is showing on the broker (I consider Losant to be the client) as QoS=0:

Let me know if any of this makes sense,

[Brandon_Cannaday]

I see, you’re referring to Losant’s MQTT integration connecting to other brokers. This thread, and the other thread I linked are referring to clients connecting to Losant’s broker.

Supporting QoS 1 for integration subscriptions may be possible. I’ll create a ticket to investigate.

[Jose_Cruz]

Ok, thanks. Now here’s the very dumb question: Losant has its own broker? Where is that configurable?

[Brandon_Cannaday]

Yep, Losant provides an MQTT broker. It’s one of the most common ways for devices to send telemetry data to the platform. All the details can be found here:

MQTT Protocol

[Jose_Cruz]

Oh, yes, I remember now - Losant broker can’t change the topic and has to be fixed (no wildcards). Nevermind. I remember now why it didn’t work for us and we had to go to an independent broker. Yes, if you can find about QoS1 that’d be great!

[Brandon_Cannaday]

You can use any arbitrary topics with Losant’s broker and wildcards are supported in most places. Can you describe the limitation you experienced in more details?

[Jose_Cruz]

MQTT publishing

I’ve seen a couple of threads of this issue, I’ve read them extensively but I’m still having some questions. In my case, the MQTT client and Losant MQTT broker work as long as: MQTT Broker URL is correct (which it is) MQTT path matches (whether device or non-device, depending on access key; which it does) Access Key and Secret are correct (which they are) ClientID matches device clientID (which it does but for just that one device): [image] #4 is my predicament (and what I’m getting at in t…

[Brandon_Cannaday]

That makes sense. Connections to the broker require a device to authenticate, which makes it hard to use for system-to-system or “application level” access. We’ve been exploring ways to authenticate against the broker at an application level, specifically to help enable system-to-system integrations.

[Jose_Cruz]

Ok, so it does not accept ‘arbitrary topics*’ and/or 'wildcards’. Because of this we’ve been at it for 2 years and are {now} comfortable with independent brokers. Our current MQTTS connection is SSL and Certified (thanks for that solution!). We just need the QoS1 clarification and we’ll be !

[Brandon_Cannaday]

It does accept arbitrary topics and wildcards. Your issue is more of an authentication problem, where a connection requires a device ID. It’s not uncommon for customers to use a “dummy” device as a way to get a client ID that can connect to the broker. The device isn’t used for any other purpose.

For example, you could have all of your devices publish data to my/custom/topic/<device-id> and then other devices (or the dummy device) can subscribe to the wildcard my/custom/topic/# and receive data for every topic under that wildcard. You can also use the MQTT Trigger to fire a workflow on that same wildcard topic.

As a note, additional topics are restricted by default. You’ll have to grant your access key access to the my/custom/topic/# wildcard topic. Details here:

Access Keys

[Jose_Cruz]

Ok, this is definitely something in need of exploring further from our side. Wish it would’ve been a bit ‘simpler’ and ‘clearer’ and not such the confusion since 2 years ago. We will explore these newer suggested options along with our current external efforts and evaluate/decide on what works best for us,

[Jose_Cruz]

@Brandon_Cannaday , we’re looking at this a bit further… when you say “other devices (or the dummy device) can subscribe to the wildcard”, can you explain a bit further so I can understand it? How will the devices subscribe to it, via the integration? Thanks,

[Brandon_Cannaday]

The MQTT Integration is not used in this scenario. The Integration allows Losant to subscribe to third-party MQTT brokers.

In this scenario, devices are connecting, publishing, and subscribing directly to Losant’s MQTT broker.

mqtts://broker.losant.com

The device’s access key/secret, which is used as the username and password in the MQTT connection, controls which topics a device is allowed to publish and subscribe to.

By default, an access key only allows a device to publish and subscribe to the special device-specific topics (e.g. state and command). However, you can grant access to any arbitrary topics you choose, including wildcard topics.

In your case, I would expect something like the following:

Devices publishing data would be restricted to a topic containing their ID - e.g. myCustomTopic/{deviceId}.

For wildcard access, you’d create an access key that was granted access to the wildcard version of that topic - e.g. myCustomTopic/#. This access key would allow a device to subscribe to that wildcard topic and will receive data for all matching devices.

One caveat to keep in mind is that the MQTT rate limit (2/sec/topic) sill applies. So if that wildcard topic is receiving data for tons of devices, you could quickly exceed that limit.