I am beginning to expand an application to 2 instances of Node-RED. This is to separate defined core functions which we do not want to expose to technicians, and the individual installation particulars of integration to sensors and devices.
The initial instance is installed globally. There will be programming for the sensors which needs to pass messages to the core functions. Then the result of the core functions will output information to output devices like printers. Devices need to be maintained, replaced and customized per the install.
Question: What is the recommended best practice to efficiently message between Node-RED "Device Instance 1" hosting input devices to the "Core Instance 2" and then back to the Outputs on "Device instance1"?
Hello,
Personally I use mqtt for communication both between nodered instances and nodered and other devices.
I find mqtt to be very robust with very little overhead. It’s a mature protocol and easy to implement across a wide range of services. It can be used not just to communicate from nodered but is also easily integrated into python applications or microprocessor clients.
One of the pluses for me is also that it handles lost connections and reconnecting very well and scales good.
It has features like last will messages and wild card subscriptions which make it very versatile.
It’s flexibility is probably one of the factors that led to such a wide spread adoption in the iot field.
Should you go down the mqtt road I really recommend reading the ten part series about mqtt by hivemq:
Also worth noting that you can do quite fine-grained configuration of MQTT if you need to. You might want this in order to ensure that messages are only able to flow from your core instance.
@JGKK,
Thank you for your assistance. Here is what I did.
Found MQTT broker in the "flows" Node-RED Library under "MQTT-" search... which got me. " node-red-contrib-mqtt-broker". That one is obsoleted and references to a node which is still in service. " node-red-contrib-mqtt-aedes". I installed it and set up configuration taking all defaults,
I suggest using mosquitto broker rather than a node red node acting as a broker. That way you more options for the configuration and it does not run in the same thread as node red.
To be honest about it. I was looking for a quick proof of concept and a test for my own satisfaction to successfully separate 2 Node-RED instances and communicate between them. I looked at MQTT earlier and since my background is not communications, it seemed a bit sticky. So I stayed away from it not having the time to delve into it. I found this test provided me with the assurance that I can get something working in little time and confusion.
Now that it does not seem so far-off, A dedicated broker like Mosquito MQTT broker is probably the way to go as you suggest. I'll look it up and see if I can install it in Windows.
I too was 'scared' of MQTT but made the decision to try it out.
In reading all 'the stuff', it seemed so difficult, but then, don't read too much into the protocol just to get it running, the rest comes later.
I installed, the Mosquitto broker, enabled MQTT on the sensor, messed around with CLI to publish and subscribe and got myself into a tizzy. I then discovered MQTTFX and use this to check things out before (easily) copying the 'message names' to put into Node-RED.
Having a separate tool to view what is happening is essential in my view and we often forget to tell people that. Without a separate tool, it is really hard to know what is going on. With a tool it is much easier.
I dislike Java apps generally (slow and cumbersome, resource hogs). I used to always use MQTT Spy (another Java app) but then mqtt-explorer matured and I nearly always use that.
Downloaded "mosquitto-2.0.5-install-windows-x64.exe". Symantec is cataching it on "information on this file is inconclusive" "We reccommend not using this file".
Comments? What download options do you recommend? or, Do I just ignore the issue and install it?
