Dear All,
Hi, I have an old Raspberry Pi 3 running Raspbian Debian 11 Bullseye.
I have installed Node-Red with the Mosquitto MQTT broker to receive signals from temperature/humidity sensors and current probes for home automation.
The Node-Red Flow has about 10 "MQTT IN NODE" nodes, one for each sensor. Each sensor with Tasmota Firmware, every 5 minute send MQTT data to Raspi Mosquitto..
I wonder if this is the correct solution or if, to save resources and processing power/Robustness and reliability of the Flow, I should use a single "MQTT IN NODE" to read all MQTT inlet message and, from its output, use a "function" node to split and send the received signal to one of the 10 outputs of the function node I think I need, to send the data to the following process nodes, depending on which sensor was read.
What do you think about this?
Thanks in advance!
I don't use MQTT (much)
But I would subscribe to a base topic (with a wildcard) in 1 MQTT In Node.
then use a switch node (not a function node) - to split out from there based on the top level topic
Better folk around here then I for MQTT, but that is my approach
These are fairly low numbers.
So, overall I don't think that 10 MQTT nodes and a flow or 1 MQTT followed by a switch (no need to use a function) and then the flow makes a significant difference performance wise.
What is the most readable option for you ?
If you come back in one year as you add/remove one sensor which option you will find easier to amend ?
So, avoid the function, as there is probably no effective need.
Then, 1 MQTT Nodes and a switch with 10 options, or 10 MQTT Nodes is, I think, a matter of taste.
Personally, I'd go for 10 MQTT Nodes and I would give them a "good" name. Eg. the sensor of that subscription.
The choice will not make any measurable difference to any of those factors. Use the KISS principle (keep it simple, stupid). Do whichever you think is the simpler (but use a Switch not a function node if you go that way). Personally, I use individual mqtt nodes.
Exactly as @colin says above, the difference is minimal.
However, consider this.
if your broker is producing 10000 messages per second & you subscribe to a wildcard to filter ALL except 10 messages, your code is processing 9990 useless messages every second.
As it’s nodejs they run on an event loop so can never occur at exactly the same time. So yes do whichever you find makes most sense to you to understand when you come back to it in 6 months time.
Hi,
For me it was also decisive how “easy to maintain” my Node-Red implementation is. Since the MQTT Broker is explicitly only responsible for messages to and from Node-Red, it wouldn't matter if there were one or more MQTT in-nodes. However, since each node has its own config (different client IDs otherwise it won't work properly), I decided on an in-node with a subsequent switch node. It works great and I control more than 120 devices with it.
Ok, if you use the automatic generation of the client ID. But if you want to know who is listening on the MQTT broker and therefore use your own client IDs, you have to assign a separate config to each MQTT in node.
ok, I read the old post again: MQTT node disconnecting - #9 by TotallyInformation
it's a bit more complicated: only if there are multiple config nodes THEN each must have a different client ID.
This no longer has anything to do with this original post - just a note
If you now only use one MQTT-In node with the topic “#” as a wildcard, you could at least save yourself the thousands of system messages from the broker and would not have to filter them out using a switch node.
To do this, enter the following in
/etc/mosquitto/mosquitto.conf
# no updates of the system messages
sys_interval 0
Not quite true. You may well have other MQTT clients connected - outside of Node-RED or in different Node-RED instances. Leave the id field blank in Node-RED unless you really need to take control over the ID.
You may wish to monitor the MQTT Broker so switching off the system messages not always, or even often, a good idea.
Much better to think through your topic structures to simplify but retain flexibility over subscriptions. Notably, a small number of top-level topics broken logically into sub-topics.
Also worth noting that because MQTT is very efficient, especially with a high-performance broker like Mosquitto, you don't need to be afraid about having multiple topic structures for the same data. I regularly use simple "raw" topic hierarchies along side symantic hierarchies. e.g. RFX_RAW/# contains raw entries from my 433MHz tranciever whereas environment/# will have much of the same data but structured by room and sensor type (temperature, humidity, etc). And, of course, environment will also contain data from other types of platform as well such as the heating system, Shellies and ESPHome devices.
A better solution is to use a base topic e.g. home/# or something else. No need to switch off system messages. They wont be sent to your Node-RED if you subscribe to a topic as suggested. One day, you may actually WANT to subscribe to system messages for health checking!
I faced this exact issue/question when I started using Node-RED a couple years ago. I remember back then my home automation flows were an absolute mess, partly because I used one single MQTT IN node and everything branched out from that one single entry point, making my flows very ugly and messy and hard to follow, manage, etc.
So I switched to dedicated MQTT IN nodes for different topics and automations, and it is sooo much tidier and easier to maintain now, so I really recommend doing it.
And it has no "real" performance impact, since it uses 1 MQTT connection (per config node) under the hood anyways - as confirmed by the MQTT server logs.
I'm a bit surprised you feel your flows are less messy, and easier to maintain, with a seperate config node and mqtt-in for each discrete topic.
What happens when you change your MQTT password?
Still, I can see the appeal of a discrete input point for each flow / section of a flow.
This thread illustrates a problem with a particular cloud based broker service and one mqtt-in per topic.
