Cannot subscribe with MQTT QoS 1

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

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.

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.

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

@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, :red_circle:

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:

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, :red_circle:

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.

1 Like

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

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:

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! :red_circle:

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?

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.

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 :horse_racing:! :red_circle:

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:

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, :red_circle:

@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, :red_circle:

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.


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.

Thanks for this piece of info, that basically ‘seals the deal’ on how we are going to proceed next :slight_smile: One last question, would you know or can guide me to where I can find out what is Losan’t current MQTT keep alive time set at? Thanks, :red_circle: