# Mqtt like link node based on topics

**URL:** <https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616>\
**Category:** General\
**Created:** [1 June 2020 11:52 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616 "2020-06-01T11:52:15Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![cinhcet](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cinhcet/32/438_2.png) [@cinhcet](https://discourse.nodered.org/u/cinhcet)\
**Post date:** [1 June 2020 11:52 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/1 "2020-06-01T11:52:15Z")

</div>

Hi,

In the beginning of my Node-RED time, I have used MQTT extensively.  
If I now look at old flows, I am using MQTT mainly to connect flows within the same Node-RED instance.  
I have the feeling that many other people do that as well.

It is somehow questionable if it is a sensible idea to use MQTT as a middleware to route messages within Node-RED.  
Therefore, I would like to know what people think about a "link" node which behaves like an MQTT node with topics etc.  
There would be a "link out" node, which would have a configurable topic property.  
Then there would be a "link in" node, which could subscribe to a topic of the "link out" nodes, with wildcards etc. as in MQTT.

Does this make sense?

I also think it should be a new node and not an addition to the link node.

The advantage compared to a link node would be mainly wildcards and maybe a bit better organization.

---

<div class="post-metadata">

**Author:** ![ristomatti](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ristomatti/32/5857_2.png) [@ristomatti](https://discourse.nodered.org/u/ristomatti)\
**Post date:** [1 June 2020 12:01 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/2 "2020-06-01T12:01:47Z")

</div>

At first sight it sounds like it could make things more confusing given that link and MQTT nodes are already present. Could you describe further how it would work and what kind of use case could benefit from it?

You could already set a topic to a message before link out, then use a switch node with "contains" evaluation as a crude "wildcard" on the link in end?

---

<div class="post-metadata">

**Author:** ![cinhcet](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cinhcet/32/438_2.png) [@cinhcet](https://discourse.nodered.org/u/cinhcet)\
**Post date:** [1 June 2020 12:03 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/3 "2020-06-01T12:03:59Z")

</div>

it should basically behave exactly as an MQTT node, with the difference that there is no broker involved, hence the communication happens directly within the runtime.  
It is just a performance consideration or a way to get rid of an MQTT broker altogether.

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [1 June 2020 12:11 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/4 "2020-06-01T12:11:29Z")

</div>

Well more like a link node with wildcards... as without a broker you wouldn't have QoS, Retained messages, LWT, etc so not very much MQTT left. Adding wildcards to links effectively removes the explicit wiring - which is not something we want to do, as one of the key tenets is to be able to trace where messages are going. Of course there is nothing to stop you naming your links a/b/c and then link to that at the other end as you could then read it like a topic... :-)...

But yes 👍 for @ristomatti suggestion - a link plus a switch.

---

<div class="post-metadata">

**Author:** ![cinhcet](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cinhcet/32/438_2.png) [@cinhcet](https://discourse.nodered.org/u/cinhcet)\
**Post date:** [1 June 2020 12:27 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/5 "2020-06-01T12:27:18Z")

</div>

QoS would not make much sense anyway, right?  
Retained could be implemented, if one wants to (with persistent storage), but I would not do it.

How does a link plus a switch provide the following?  
You have link out nodes at multiple places, named "control/lights/light1".  
Then you want to have a link in node, connecting to "control/lights/#"?  
You would have to connect that link in node to all other link out nodes and if you add a new out node, you have to connect that as well.

Yes, at the moment, I am either using MQTT or naming my link nodes as topics 🙂 But this does not solve the above issue.

But as you said, making it an addition to the link node does not make sense.

Edit: I think even with wildcards one could have a visual indication of the wiring. This would be good for efficiency anyway, if at the start of the flows all wildcards are parsed and then explicit connections are stored in a lookup table

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [1 June 2020 12:47 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/6 "2020-06-01T12:47:50Z")

</div>

so if I open a link in node I see something like

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/7/c/7cdeb2de10e646ac3149b986304192f928b1afef.png)  
If that view maybe had a "filter" so you could select all the ones with (for example) "moving" in - then that would accomplish the same wouldn't it ?

PS - top tip -if you already have one connected up to as much as you like then a quick cut/paste will create another connected in the same way... so easy to add more.

---

<div class="post-metadata">

**Author:** ![cinhcet](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cinhcet/32/438_2.png) [@cinhcet](https://discourse.nodered.org/u/cinhcet)\
**Post date:** [1 June 2020 13:07 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/7 "2020-06-01T13:07:45Z")

</div>

it would accomplish the same if you do not later add another "moving" node. Or did you thought about making that filter something that is re-evaluated on deploy?  
I quickly checked the link node code, where is the magic happening?

Although not quite what I had in mind, I think such a filter is a good idea anyway 🙂

Your top tip is the reason why I use link nodes more often than the MQTT solution

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [1 June 2020 17:28 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/8 "2020-06-01T17:28:07Z")

</div>

@cinhcet forgive me for not fully reading and comprehending your requirement but it looks like you want MQTT like functionality without a broker?

have you looked at the GUN nodes?

I haven't played with it for a week so so but I know @TotallyInformation has made some excellent progress (uncertain on wildcards though) - in its simplest form, its a _little_ bit like MQTT without the broker.

---

<div class="post-metadata">

**Author:** ![cinhcet](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cinhcet/32/438_2.png) [@cinhcet](https://discourse.nodered.org/u/cinhcet)\
**Post date:** [1 June 2020 17:58 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/9 "2020-06-01T17:58:19Z")

</div>

I had a spare hour and could not resist:

> **[cinhcet/node-red-contrib-topic-link](https://github.com/cinhcet/node-red-contrib-topic-link)**
>
> Contribute to cinhcet/node-red-contrib-topic-link development by creating an account on GitHub.

  
Does what I want 🙂 And is efficient at runtime, since the wildcards are resolved on startup.  
Now one could also in theory draw lines as with the link node, despite the fact it has wildcards.

There is one downside, the wiring between the nodes is performed each time a new node instance is created. This is because there is no guarantee that certain nodes are initialized before others.

Is there a way to execute a function after all nodes have been loaded?

@Steve-Mcl Yes, I have looked at the GUN nodes, looks really interesting and will use in the future, but not directly for what this topic is about.

---

<div class="post-metadata">

**Author:** ![cinhcet](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cinhcet/32/438_2.png) [@cinhcet](https://discourse.nodered.org/u/cinhcet)\
**Post date:** [1 June 2020 18:02 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/10 "2020-06-01T18:02:25Z")

</div>

![screenshot](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/d/4/d46da145679f9f20430e036a37011eba7e9e5b6b.png)

---

<div class="post-metadata">

**Author:** ![cinhcet](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cinhcet/32/438_2.png) [@cinhcet](https://discourse.nodered.org/u/cinhcet)\
**Post date:** [1 June 2020 20:15 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/11 "2020-06-01T20:15:49Z")

</div>

> [@dceejay](#):
>
> If that view maybe had a "filter" so you could select all the ones with (for example) "moving" in - then that would accomplish the same wouldn't it ?

funny coincidence that filtering was the topic of the live stream today 🙂

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [1 June 2020 21:11 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/12 "2020-06-01T21:11:13Z")

</div>

pure co-incidence (for once...) - but possibly fortuitous

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [1 June 2020 21:58 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/13 "2020-06-01T21:58:52Z")

</div>

> [@Steve-Mcl](#):
>
> uncertain on wildcards though

No concept of wildcards in Gun I'm afraid. But then you might not need them since you choose the top level of the hierarchy that you want to query and get back the next level of the hierarch which you can walk over - or you can get the whole hierarchy. Your choice.

Had to take a break to do something useful for Mrs TI at the weekend - Node-RED to the rescue, I will doubtless do a post about that at some point, it is quite interesting but I digress.

---

<div class="post-metadata">

**Author:** ![cinhcet](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cinhcet/32/438_2.png) [@cinhcet](https://discourse.nodered.org/u/cinhcet)\
**Post date:** [5 June 2020 22:23 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/14 "2020-06-05T22:23:46Z")

</div>

Now on npm [https://www.npmjs.com/package/node-red-contrib-topic-link](https://www.npmjs.com/package/node-red-contrib-topic-link)  
Also supports dynamic topic setting via the message (is then less efficient, of course) now.

---

<div class="post-metadata">

**Author:** ![ristomatti](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ristomatti/32/5857_2.png) [@ristomatti](https://discourse.nodered.org/u/ristomatti)\
**Post date:** [5 June 2020 23:54 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/15 "2020-06-05T23:54:19Z")

</div>

I quickly skimmed your repo out of curiosity. Perhaps it would be a good idea to use an existing matcher for MQTT topics if the idea is to mimic the pattern. For example this seemed to be very popular: [https://www.npmjs.com/package/mqtt-match](https://www.npmjs.com/package/mqtt-match)

---

<div class="post-metadata">

**Author:** ![cinhcet](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cinhcet/32/438_2.png) [@cinhcet](https://discourse.nodered.org/u/cinhcet)\
**Post date:** [6 June 2020 07:24 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/16 "2020-06-06T07:24:39Z")

</div>

- I like having no dependencies for such a simple thing
- I think their code is less efficient and also more complicated, since they loop over the wildcard topic and not the actual topic, which then requires to do a length check for `bla/#` vs `bla`, which my code does not require.

---

<div class="post-metadata">

**Author:** ![cinhcet](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cinhcet/32/438_2.png) [@cinhcet](https://discourse.nodered.org/u/cinhcet)\
**Post date:** [6 June 2020 07:36 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/17 "2020-06-06T07:36:54Z")

</div>

ok, actually, I have to do another check for that case. Will fix that

---

<div class="post-metadata">

**Author:** ![cinhcet](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cinhcet/32/438_2.png) [@cinhcet](https://discourse.nodered.org/u/cinhcet)\
**Post date:** [6 June 2020 07:59 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/18 "2020-06-06T07:59:29Z")

</div>

@ristomatti, indeed, I had a bug 🙂 It should now be fixed and pushed to npm. Thanks. As soon as somebody will ever find another bug in the topic matching, I will use the package you mentioned.  
Interestingly, they also had a bug around a similar topic combination

---

<div class="post-metadata">

**Author:** ![cinhcet](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cinhcet/32/438_2.png) [@cinhcet](https://discourse.nodered.org/u/cinhcet)\
**Post date:** [10 June 2020 11:44 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/19 "2020-06-10T11:44:45Z")

</div>

Hi,

Don't know if anyone is even interested in that node, but I am in the process of converting all my flows to use this node and already find it very useful.

Two questions I would like to hear opinions on:

1. MQTT does not support wildcards when publishing. I thought about allowing this in my node for `+` wildcards, meaning that when publishing on `room/+/control` for example `room/device1/control` and `room/device2/control` would get the message. Like? Not like?
2. At the moment, there is the option "Set parsed topic property", which defaults to true and means that a subscribing link node will output a message where the topic property is set to the topic the message came from. The downside is that this will overwrite the topic property, if there is one. How to deal with that in case publishing wildcards are allowed? One can invent funny cases, e.g. publish on `bla/+/cool/hello` and subscribe on `bla/topic/+/hello`, so inferring the topic to `bla/topic/cool/hello`?

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [10 June 2020 12:05 UTC](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616/20 "2020-06-10T12:05:01Z")

</div>

Both proposals look useful. Just be sure to document the behaviour in the built in help and users can use it or not. Ps point 1 looks quite useful like a fan out node.

[Next page](https://discourse.nodered.org/t/mqtt-like-link-node-based-on-topics/27616.md?page=2)