MQTT dynamic setting

Core Development Feature Requests
1

Hello,
Regarding the dynamic subscription of MQTT from version 2.1.0, I've noticed that if you feed a MQTT node with several topics for subscription (one after another as separate msg's), the node will "remember" the topics and act well.
But, there is no way to know to what topics the node is already subscribed (unless the user takes care of this elsewhere). What I mean is that the node does not have a report status which it can output all of its subscribed topics (and maybe some more info).

One way I thought to deal with this is to remove all subscribed topics by sending a msg with action 'unsubscribe' and with topic '#" but this doesn't work.

Would like to know if there is a way to clear all subscribed topics without knowing what they are...

Thanks, Rami

2

There is a currently undocumented feature that lets you send msg.action="getSubscriptions" and the node will send a message with:

{
   topic: "subscriptions",
   payload: [ .. array of subscription objects .. ]
}

You can then pass that back into the node having moved msg.payload to msg.topic and set msg.action="unsubscribe"

2 Likes
3

You should also be able to send action "unsubscribe" & topic true (not tested, not sure if that feature made the cut but it was there before release).

4

That would be easy to achieve & might make more sense than sending true what do you think @knolleary?

2 Likes
5

Is it possible to subscribe to # and also other topics (strange I know, but if I tried hard enough I could probably think of a use case). In that case unsubscribing from # should only remove that one.

6

hmmm, yeah, good point.

it is (should be) possible to subscribe to '#' (though some brokers dont allow you or just dont transmit anything to '#')

7

Are you sure? Mosquitto certainly allows it.

8

I use EMQX broker and by default it doesnt give you anything for '#' - I believe it can be changed in the settings.

9

Great, this is a good and elegant solution
Thanks

10

I dont know if you missed it but simply injecting true will remove all subscriptions...

image

11

I am sure it is just a lack of imagination on my part, but as a regular user of the MQTT nodes before this addition, do you have a sample case where it would make since to use the dynamic setting capability?

12

There are a number of scenarios that were hard to do without the dynamic mode.

The following are scenarios that I've come across from time to time

  • running on a device with intermittent connectivity and wanting to schedule the connect/disconnect, rather than being 'always' connected

  • connecting to a service that dynamically provisions the connection details. Such as having a standard set of flows that are deploy to multiple machines, and each machine has to "call home" to a provisioning service to get the broker details it should connect to.

  • an mqtt service that rotates credentials regularly so you cannot hard-code them in the flow

  • a service that has to 'discover' it's topic tree based on events so cannot be hardcoded

It is certainly a feature that most mqtt users won't need... Until you need it, then you really need it.

13

Thanks for the answer. I think the last two are ones I can really imagine clearly now that you mention them. I think you hit the nail on the head with your final part:

Great that the continued development is getting to these more obscure corner cases that won't be needed often, but will be very valuable when they are.

1 Like
14

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.