MQTT advance feature: wildcard topic and Qos

Product Suggestions
1

On MQTT integration, it will be good to be able to use wildcard # on the subscription topic.
Also, be able to implement Quality of service level for better integration

2

Hey @Nicolas -

We are looking to move to support MQTT beyond the constraints of machine montioring for event ingestion in the near future, and a big piece of this functionality will be adding support for wildcards.

Can you explain your needs around QOS right now when MQTT is only used for ingestion? My understanding is that QOS effectly something only relevant to a publishing client <> broker connection. Because our client does not do publishing, exposing this setting would be irrelevant. Looking at the NodeJS MQTT client docs, it doesn’t appear that this is a setting that can be configured on the .connect function.

We are in the process of adding write capabilities for MQTT, and this will support user definition of QOS at a function level.

image
image3840×1386 325 KB

Pete

3

Hi Pete,
We need to specifiy Qos for subscription message:
mqtt.Client#subscribe(topic/topic array/topic object, [options], [callback])
Subscribe to a topic or topics

  • topic is a String topic to subscribe to or an Array of topics to subscribe to. It can also be an object, it has as object keys the topic name and as value the QoS, like {‘test1’: {qos: 0}, ‘test2’: {qos: 1}}. MQTT topic wildcard characters are supported (+ - for single level and # - for multi level)
  • options is the options to subscribe with, including:
    qos QoS subscription level, default 0

This QoS information is important for the broker to queue or not the message.
Example for Solace: Managing MQTT Sessions (solace.com)

4

Hey @Nicolas -

Another update here. You are totally right, missed this from the MQTT docs. Checked with the team and we have implemented QOS 2 for all connections by default. QOS will always be limited by the publisher, so setting QOS2 will ensure that the client preference is respected.

It sounds like your broker is also driving unique behavior based on this QOS, and it looks like they perfer QOS 1 to enable proper caching. Is this right? if so, we can just make this setting configurable on the UI at creation time.

Pete

1 Like
5

Thanks, Qos 2 must be ok. I will test with our Messaging Team and keep you inform.

1 Like
6

Hi
In order to manage persistent queue on our messaging broker Solace, over reconnection, a key option for client connection must be “Clean” is set to false.

On NodeJS library, mqtt.Client(streamBuilder, options) it is written:

  • clean: true, set to false to receive QoS 1 and 2 messages while offline

Could you check with your team what by default it is implemented in Machine Data Source setup.

Thanks

7

Hey @Nicolas -

I just made a ticket for this. It will mandate some changes to how we manage the reconnection of subscriptions (which isn’t a tiny change), but this is also not a massive lift.

Pete