Passing msgs between remote node-red hosts

[damo....@gmail.com]

Hi All,

A quick question. 

Is there a simple well-established method of passing messages between node red installs of different hosts?

With so many ways it could be done using flows, what is the simplest way to achieve bi-drectional flow between hosts?

Many thanks.

Damo.

[Walter Kraembring]

Yes, MQTT

[Bart Butenaers]

Hi Damo,

Will try to give a rather quick answer, but not to quick ;-)

Others will be able to give you much more details about MQTT, because I used it last weekend for the first time.

But here is what I understand from it ...

MQTT in a nutshell

When a publisher sends a message (containing a.o. a topic X) to an MQTT broker system, that broker will send the message to all subscribers that have been subscribed (in advance) to that same topic X:

MQTT brokers

There are a series of MQTT brokers available:

• Mosca: written in Javascript as a npm module.  Tried this one first, but I got stuck on C++ build errors on my Raspberry
• Mosquitto: then I tried to install this one, and it worked immediately
• ....

Distributed Node-Red

When you want to connect two Node-Red flows (which are running on two separate devices), one of the flows could act as a publisher (via the mqtt out node), while the other flow acts as a subscriber (via the mqtt in node).  For simplicity, the same Node-Red flow below will act both as a publisher and subscriber (which means the flow is sending messages to itself, which is of course a bit ridicoulesness).

For example we will try to send the value of a temperature sensor from flow X to flow Y.

Hopefully my following picture can give you a high level overview of what is going on, before you digg into more details:

These are the steps that are executed in sequence:

1. The MQTT in node subscribes to the broker (to listen to messages with topic 'temperature') : in this example we have setup the brokers server on localhost (port 1883)
2. We press the button to generate a message containing the temperature value and the topic 'temperature'
3. The MQTT out node publishes the message on the MQTT broker
4. The MQTT brokers sends the messages to all subscribers that are listening to the msg.topic = 'temperature'
5. We display the received message, which is identical to the message that we have generated in step 1

When you want to connect flows running on separate devices, you will have to change the IP addresses in the 'server' field of both MQTT nodes.  The broker could run on a separate device, in the cloud, or on one of the devices where a Node-Red instance is running.

[{"id":"9501411c.d6df1","type":"mqtt in","z":"4900f0c0.a1ad6","name":"Receive msg from MQTT broker","topic":"temperature","qos":"2","broker":"45638dd0.81dd74","x":846.0078430175781,"y":488.6602382659912,"wires":[["86456b19.41b7a8"]]},{"id":"571b08b1.b63468","type":"mqtt out","z":"4900f0c0.a1ad6","name":"Send msg to MQTT broker","topic":"","qos":"2","retain":"false","broker":"45638dd0.81dd74","x":528.0039367675781,"y":490.5937786102295,"wires":[]},{"id":"f8abf6e6.19f508","type":"inject","z":"4900f0c0.a1ad6","name":"Read temperature sensor","topic":"temperature","payload":"23,7°C","payloadType":"str","repeat":"","crontab":"","once":false,"x":258.00390625,"y":490.66799783706665,"wires":[["571b08b1.b63468"]]},{"id":"86456b19.41b7a8","type":"debug","z":"4900f0c0.a1ad6","name":"Display temperature","active":true,"console":"false","complete":"true","x":1105.00390625,"y":489.1367483139038,"wires":[]},{"id":"45638dd0.81dd74","type":"mqtt-broker","z":"","broker":"localhost","port":"1883","clientid":"Pi2-NR","usetls":false,"compatmode":true,"keepalive":"15","cleansession":true,"willTopic":"","willQos":"0","willPayload":"","birthTopic":"","birthQos":"0","birthPayload":""}]

Third party dashboards

Until now I have only used the Node-Red internal dashboard.  However in this thread I got a remark about third party dashboards for IOT:

• Freeboard
• Thingsboard
• iViewer
• TheHomeRemote 
• ...

If I understand correctly, most of these dashboards support MQTT (native or by plugins).  For example the HomeRemote designer offers standard MQTT topic fields for both input and output:

Through those topics, the dashboard can connect to an MQTT broker (both as subscriber and publisher):

• When you switch the button on the dashboard, a message with the PublishTopic will be send to the broker.  A Node-Red flow could listen to that PublishTopic and respond to the button switch.
• The other way around: if the Node-Red flows decides to update the button value, it will send a message to the broker with a SubscribeTopic.  The dashboard (subscribed to that SubscribeTopic) will get the message and will change the button status on the screen.

@Everybody: if some of this information is wrong or incomplete, please let me know !!!

Good luck with it,

Bart

[damo....@gmail.com]

Hi Bart,

Thanks for your response.  I'm actually very familiar with MQTT and have been using it for a while.  But you have written a great overview of the technology. :)

Indeed, my question was fairly broad, and MQTT was one of the many approaches I alluded to. 

Other approaches I think would also work are:

TCP
Websocket
HTTP

Each of these nodes could be designed in a way to allow 2-way passing of messages between separate Node-red installs.  There are almost certainly others.  If anyone is aware of any, please share. :)

I was wondering which might be the simplest and most reliable.  For instance the MQTT approach requires an intermediary (the broker) which makes it less simple to implement.  There are different caveats for the others.

With the other 3 above, you need to configure the nodes correctly according to the semantics of the protocol, to ensure that the right nodes from each end-point are communicating.  TCP for instance uses a 'socket connection' which is a source IP, source port, destination IP, and destination port combination.  This combination ensures two applications on two hosts can communicate directly with one another.  Websockets and HTTP generally being higher-level protocols than TCP have less technical methods, namely urls.

But my initial question was intended to lead to a supplementary question, which is:

Is it worthwhile to have a specialised node for passing messages between Node-Red installs?  If we abstract away the semantics of each underlying protocol, to something more simple for those who don't know TCP/HTTP/Websocket implementation specifics, it would be much easier to configure.

There is a 'FRED' node for instance, that allows you to pass messages between your personal Node-red and FRED in the cloud.  Would it be useful to have a Node for passing messages between two personal Node-Red installs, where you simply plug in the IP Address and say a topic that matches at each end?  I dunno - I am open to suggestions for how to enable multi-point to multi-point connections between installs, but thought I'd raise the question.

Do people generally want to pass messages simply and reliably between Node-Red installs?

D.

[Zenofmud]

Unless I’m missing something, this doesn’t seem hard. 

You have two pi’s ‘A’ and ‘B’ and you install MQTT on both.

 Pi ‘A’ subscribes to the broker on Pi ‘B’. Pi ‘B’ subscribes to the broker on Pi ‘A’. 

Pi ‘A’ publishes messages to broker ‘B’ and Pi ‘B’ publishes messages to broker ‘A’.

Messages can get sent back and forth.

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/1f784ca8-2e52-4d0a-aa4a-f337c9e16000%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Zenofmud]

Actually it should be even easier - install one broker on pi ‘A’. Pi A subscribes to messages with the topic ‘pi-b/whatever' and pi-b subscribes to topic ‘pi-a/whatever’

Pi “B’ sends things to pi ‘A’ by using the topic ‘pi-a/whatever’ and pi ‘A’ sends thing to pi ‘B’ using the topic ‘pi-b/whatever’

Communication with one broker and two pi’s. You sould be able to add more pi’s with that topic scheme.

On Aug 29, 2017, at 8:03 PM, damo....@gmail.com wrote:

[damo....@gmail.com]

Hi Paul,

From my point of view, I see ease and simplicity as relative terms.  For someone comfortable installing this additional software and who is prepared to learn how to use it, then you are probably right in it not being that hard.  But I am wondering whether there are plenty of NR users who don't fit this description.  They simply want to pass messages between NR installs just like you can pass messages between flows within NR (which is really neat btw).

FRED have included a node along the lines of what I am suggesting: (https://flows.nodered.org/node/node-red-contrib-fred).

This module provides a set of nodes for making it easier to connect to a FRED instance from a device like a Raspberry Pi.

These nodes currently connect to FRED using web sockets. These nodes are based on the built in web sockets modules that come with Node-RED. As FRED evolves, the method of connecting to a FRED-hosted Node-RED may change. Using these nodes will make sure your device flows will continue to connect to FRED using the most well supported protocol.

This is basically the argument I am making for the creation of an analogous node between two local NR installs. 

It also seems somewhat unnecessary to have to install an MQTT broker simply to pass messages between node-red installs, when by its very nature, message passing is what it does and does well.

This is my view, but how do others see it?

Damo.

[Walter Kraembring]

It also seems somewhat unnecessary to have to install an MQTT broker simply to pass messages between node-red installs, when by its very nature, message passing is what it does and does well. 

Well, in theory it sounds simple. Inside the same flow, it might be reliable enough. But the next minute when you start talking about communication between apps running on the same or different machines you start to think: security with certificates - reliability QoS - lightweight protocol - reconnections - persistence - one to many - many to one - many to many and a lot of other things. So then one answer to this is MQTT. And for more professional high-end applications, ActiveMQ.

In earlier days I programmed socket communication. For sure very efficient but to be really useful and fulfilling the above requirements, the answer would already then have been what MQTT is providing today. 

Web sockets, yes I use it too but only to update my web pages with state changes. If I'm not completely wrong, the protocol has by far much more overhead then MQTT (thats another reason why MQTT is the de-facto for IoT).

If MQTT (mosquitto) would be part of next "Jessie" distribution, maybe it would cover what you are looking for, making it simpler for those not comfortable enough to install mosquitto.

Best regards, Walter

[Walter Kraembring]

And btw, this is covered in The ThingBox Project

http://thethingbox.io/

[Dave C-J]

Two more options for you all to chew on...

The zeromq nodes and the n2n node (both contributed by me :-)

The zeromq node is peer to peer and has both socket and pub sub type models - see the zeromq website for details of the underlying protocol.

The n2n node is more "experimental" in that it is sub pub, uses multicast, and only supports small messages (<1 UDP packet). Basically a receiving node just asks for data that matches a topic regex, (a combined heartbeat and subscribe). If anyone on the local subnet can match it, it sends the data, whenever it is available or at a rate requested (publish). So no broker needs to be configured, and by using multicast, if there are multiple subscribers to the same thing then it is sent only once, so saving battery power. If the requester stops asking (60s) then the sender stops sending, also saving power.

Anyway... Just more to think about 

[steve rickus]

Damo, I think I see where you are going here -- and although I love all the other related discussions around this topic, here is the simplest version of what I would love to see (fwiw)...

I have 6 instances of node-red running on different ports within the same PC. Within each of those instances, I use the Link In/Out nodes to segment the flows into more manageable tabs (usually by task). Whenever I drop a new Link In node into a new tab, I get a nice list of all the available Link Out nodes that have already been created (essentially, the "endpoints" of my other tasks):

It would really be ideal if this list included endpoints from my other node-red instances! Today, when I need to pass msgs between my instances, I set up Http endpoints (or use TCP, MQTT, etc) -- but as Damo stated below, "message passing is what [node-red] does and does well".Granted, the list could get large, and specifying which other instances are available would have to be known somehow, but those are just "implementation details" ;*)

Kidding aside (sorry, the "clueless manager voices" in my head sometimes just pop out)... The simplicity of the Link node behavior would hide whatever mechanism was used to pass msg objects from one n-r instance to another. Since node-red already supports many communication protocols, the implementation would be free to select the most efficient one, based on things like what security checks are in place and whether it's between processes on the same server.

--

Steve

[damo....@gmail.com]

Hi Steve/Dave,

On Thursday, August 31, 2017 at 12:22:11 AM UTC+10, steve rickus wrote:

Damo, I think I see where you are going here -- and although I love all the other related discussions around this topic, here is the simplest version of what I would love to see (fwiw)...

It would really be ideal if this list included endpoints from my other node-red instances! Today, when I need to pass msgs between my instances, I set up Http endpoints (or use TCP, MQTT, etc) -- but as Damo stated below, "message passing is what [node-red] does and does well".Granted, the list could get large, and specifying which other instances are available would have to be known somehow, but those are just "implementation details" ;*)

Kidding aside (sorry, the "clueless manager voices" in my head sometimes just pop out)... The simplicity of the Link node behavior would hide whatever mechanism was used to pass msg objects from one n-r instance to another. Since node-red already supports many communication protocols, the implementation would be free to select the most efficient one, based on things like what security checks are in place and whether it's between processes on the same server.

 

Steve, I think this is a great idea and was just the sort of thing I was alluding to.  Unless you are doing something particularly demanding, this type of abstraction takes away the need to consider which node/protocol to use to interconnect the NR installs and let's NR do what it does best.

I wondered how many others might have multiple node-red installs on the same LAN.  I have a hub/spoke type arrangement with a NR on an intel-based host, and a collection of RPI each performing more or less a specific task.  I also use flows to segment various tasks.

I was going to do the whole mqtt broker thing (I already have mosquitto installed), but wondered whether there might be others with a similar problem (interconnecting NR devices/installs), who may have a simpler/neater solution.  Or that there was already something built into NR.

Technically, I think what you propose Steve is very possible, but would require implementation into the NR UI/Runtime.  Based on the trello tasks Dave & Nick have already outlined, I'm not sure where it would fit in terms of priority, but there are already some pretty hefty goals. 

From a technical standpoint, a avahi/zeroconf/bonjour (or even zeromq ;) ) type service advertisement mechanism could be built into NR such that they can 'see' one another, and show the flows available on each host, along with the local flows, as you have illustrated.  There would be some security consideration to think about, but nevertheless, a great idea.

In the meantime...

On Wednesday, August 30, 2017 at 4:23:54 PM UTC+10, Dave C-J wrote:

Two more options for you all to chew on...

The zeromq nodes and the n2n node (both contributed by me :-)

The zeromq node is peer to peer and has both socket and pub sub type models - see the zeromq website for details of the underlying protocol.

These nodes are really neat Dave.  I checked out the zeromq site.  What a great distributed approach to message passing, especially with all the different operational modes it supports.  I haven't yet peeked at your code, but I am hoping you had a library implementation to work with as it appears to be quite an involved protocol. :)

The n2n node is more "experimental" in that it is sub pub, uses multicast, and only supports small messages (<1 UDP packet). Basically a receiving node just asks for data that matches a topic regex, (a combined heartbeat and

The n2n limitation of UDP (and for most - Ethernet frame size) won't fit for my specific purposes, but very handy for communicating with modestly speced micro-controllers such as Arduino where power and RAM are finite.

Thanks everyone for your contributions to the discussion.  Further contributions welcome, if there is still interest.

Cheers,

Damo.

[Julian Knight]

One other aspect to think about - security.

While many of these approaches are perfectly valid, they are not all as easy to secure. For some implementations (actually for any implementation that carries information of value or controls critical hardware), even LAN's should only use secured data transmissions.

That makes MQTT or some similar broker the easiest approach as it is relatively easy to secure.

The other security related aspect to bear in mind of course is resilience. Again a broker or other message bus wins out again here as the protocols and services are designed to allow resilient setups.

On Friday, 1 September 2017 00:03:54 UTC+1, damo....@gmail.com wrote:

Hi Steve/Dave,

[damo....@gmail.com]

Hey Julian,

Welcome and thanks for contributing to the discussion.

On Thursday, September 7, 2017 at 6:01:42 AM UTC+10, Julian Knight wrote:

One other aspect to think about - security.

While many of these approaches are perfectly valid, they are not all as easy to secure. For some implementations (actually for any implementation that carries information of value or controls critical hardware), even LAN's should only use secured data transmissions.

That makes MQTT or some similar broker the easiest approach as it is relatively easy to secure.

Indeed, security is a very important consideration and I agree with you that an MQTT broker implementation would provide much better security for inter-node-red communication.  Yet, for intra-nod-red communication, the need for this level of secure communication might vary. 

Taking a reductionist perspective - at the heart of information security policy is risk management.  Risks and impact for a corporate LAN would typically differ to a home LAN.  The underlying point is that secured communication may not always be necessary.  But where it is, I agree an MQTT broker would be a good choice.

 

The other security related aspect to bear in mind of course is resilience. Again a broker or other message bus wins out again here as the protocols and services are designed to allow resilient setups.

The other problem not discussed about MQTT and a broker is that communications are only reliable if the appropriate endpoints are actually running and subscribed to the topic. If for whatever reason a node-red endpoint were to crash (or is otherwise not connected to the broker), the sending side may be unaware and the messages would still be lost. Will messages and some clever NR logic could be used yes, but things can become complicated very quickly.  While direct communication node-red to node-red could detect communication failure more easily.

Nick and Dave are working on a new NR API for msg passing and there was a discussion (initiated by me) on message reliability if you are interested.

Cheers,

Damien.

[Julian Knight]

No problem Damien. You are abolsutely correct that not all implementations need the same level of security - however, security is often thought of last when playing with IoT. As a security person and a Node-RED fan, I don't want Node-RED to be accidentally labelled as insecure. Nor do I want newcomers to lack security awareness since there are enough problems around IoT security already, as IoT enthusiasts, we should be recommending and steering people towards better solutions.

Of course security decisions need to be risk-based - value, exposure, criticality are all factors in the decision making process. But all too often I see people get excited by IoT in general and Node-RED specifically. They start with simple stuff but rapidly get drawn into home security and heating controls and other more critical things - often on home networks where security controls are limited. Or worse, on small business networks that may not have continuous oversight.

Scope creep changes risks but those risks are rarely assessed.

Anyway, I'll get off my hobby-horse now, hopefully the points made between us are useful to others. Security is hard, it should be thought about up-front and ongoing. But it shouldn't get in the way and certainly shouldn't stop the excitement and fun!

Regarding engineering of reliability - yes, things get very complex very quickly. Certainly experiments and fun stuff don't really need that reliability but it is worth being aware of the issues. I can say from experience that our better halves don't take kindly to automated lighting failures :-{ so even simple home automation will get more complex after your first big failure. Good news is that there is loads of community help out here and the low cost of Pi's and similar platforms make it pretty easy now to set up a decent level of resilience if needed. 

My comments were not meant to be comprehensive only to indicate some areas of thought that might be needed.

[Damien Clark]

Thanks Julian,

I completely understand your motivations. :)

And there is no higher reliability standard than the WAF (Wife Approval Factor). :)

D.

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---

You received this message because you are subscribed to a topic in the Google Groups "Node-RED" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-red/LFi6D3uiHRc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+u...@googlegroups.com.

To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.

To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/73a97871-97d6-481f-8a69-c45b753c6ba0%40googlegroups.com.