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.
1 Like
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?
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.
1 Like
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.
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
so if I open a link in node I see something like
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.
1 Like
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
@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.
I had a spare hour and could not resist:
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.
3 Likes
funny coincidence that filtering was the topic of the live stream today 
pure co-incidence (for once...) - but possibly fortuitous
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.
2 Likes
Now on npm 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.
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
1 Like
ok, actually, I have to do another check for that case. Will fix that
@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
1 Like
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:
- 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?
- 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?
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.
1 Like
