Multiple Inputs on a Node?

10549 views
Skip to first unread message

PaulStoffregen

unread,
Aug 16, 2014, 12:29:55 PM8/16/14
to node...@googlegroups.com
Is there a way to create a node with 2 or more inputs?

Nicholas O'Leary

unread,
Aug 16, 2014, 12:31:16 PM8/16/14
to node...@googlegroups.com

Hi Paul

No, nodes can only have a single input.

You can use properties of the incoming messages to distinguish different sources.

Nick

On 16 Aug 2014 17:29, "PaulStoffregen" <paul...@gmail.com> wrote:
Is there a way to create a node with 2 or more inputs?

--
http://nodered.org
---
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.
For more options, visit https://groups.google.com/d/optout.

PaulStoffregen

unread,
Aug 16, 2014, 3:35:07 PM8/16/14
to node...@googlegroups.com
I guess I was hoping to use the UI to connect which sources control which things.  Sounds like that's not possible from the UI and I have to edit the javascript code for my node?

I'm still really new and wrapping my head around how much of Node-Red works.  Please forgive my ignorance.  It looks like a really awesome system and I absolutely love the UI for connecting stuff.

The Thing Box

unread,
Aug 17, 2014, 7:02:12 AM8/17/14
to node...@googlegroups.com
Well this could be integrated in NodeRED: we can imagine that each input goes to an input array and the node gets control for each value.

Nicolas
TheThingBox.io

Nicholas O'Leary

unread,
Aug 17, 2014, 10:40:24 AM8/17/14
to node...@googlegroups.com

Could you describe a bit more about what you're trying to do?

It isn't just the ui that only allows a single input; the nodes only have a single 'input' event in the runtime.

This was a purposeful design choice from the start. But I'm always keen to hear of use cases for it. All of the ones we have thought of have perfectly viable alternatives using the single input scheme we already have.

Nick

On 16 Aug 2014 20:35, "PaulStoffregen" <paul...@gmail.com> wrote:
I guess I was hoping to use the UI to connect which sources control which things.  Sounds like that's not possible from the UI and I have to edit the javascript code for my node?

I'm still really new and wrapping my head around how much of Node-Red works.  Please forgive my ignorance.  It looks like a really awesome system and I absolutely love the UI for connecting stuff.

Dave C-J

unread,
Aug 17, 2014, 2:11:20 PM8/17/14
to node...@googlegroups.com

And don't forget node.js is asynchronous in nature so each input would very in their own time. So you have to maintain state of all the other inputs. And then send an output based on the change of which input ? First ? Last? All ? Should initial output not occur until a valid input has been received on all inputs or should they default to some value ? Lots of potential behaviours that may need to be handled or exposed.

PaulStoffregen

unread,
Aug 17, 2014, 4:34:48 PM8/17/14
to node...@googlegroups.com
I must confess, at this point I'm merely fiddling with Node-Red and exploring ideas to use it for very different applications.  The absolute last thing I want to do is distract you guys from productive development with a lengthy off-topic thread.

Some of my crazy ideas, which could more honestly be called "pipe dreams", involve nodes that synthesize & process streaming audio and publishing to very small Arduino-scale embedded hardware, which is far too small to run node.js, but might be able to handle streaming media in limited ways....

Yesterday I played with the user interface.  Here's a small patch that adds multi-input drawing, only in the UI.

https://github.com/PaulStoffregen/node-red/commit/668b3db8dd541cf9252a5a83d3b047c922e2e798

I realize multi-input nodes might not ever fit into Node-Red's architecture.  I have no expectation this patch will get merged.  But if anyone else wants to fiddle with multiple inputs, or if it is desired someday, hopefully this patch will save more time than I've consumed with my crazy questions.

Thanks for putting so much great work into Node-Red and publishing it all as open source.  I really do appreciate it.

PaulStoffregen

unread,
Aug 17, 2014, 4:35:28 PM8/17/14
to node...@googlegroups.com


Eric Cattoir

unread,
Aug 18, 2014, 11:05:56 AM8/18/14
to node...@googlegroups.com
I have a similar "problem". I am running Nodered on a Raspberry. To the USB of the Raspberry I have connected a microcontroller which can read out a number of sensors.
I built my own node which reads 4 sensors and has them as 4 outputs. What I want to do next is make a function which creates a Json output containing the readings of the 4 sensors and in addition a device id. This message would then be sent to the IOT service in Bluemix. 

So I would want to write a function taking the 4 sensor readings and producing the JSON.

Is there a way to do so, the other solution I see is that I rework my node so that it outputs directly a JSON with the required format.

PaulStoffregen

unread,
Aug 18, 2014, 1:58:40 PM8/18/14
to node...@googlegroups.com
Multiple outputs are already supported, so you can pretty easily build a node which takes a data stream encoding 4 channels and break it into 4 outputs.

Nicholas O'Leary

unread,
Aug 18, 2014, 2:57:05 PM8/18/14
to node...@googlegroups.com
Eric,

does your node always emit the 4 messages at the same time, or does it send one of the 4 messages depending which sensor provides a reading?

If it always emits the four messages at the same time, it could just as easily emit a single message with the four readings in the payload. It depends what else you want to do with the node.

If it emits the individual messages at random times, then you face the challenge of deciding when you have a 'complete set' of readings to send on - that will be true if you build it into your own node, or if node-red supported multiple inputs into a single node. For example, if sensorA emits every 1 second, sensorB emits every 2 seconds and sensorC emits every 3 seconds, when do you emit a message combining all three readings? There are a number of strategies that could be used - but no single answer that would fit everyone's requirements.

The SensorTag node is an example node that can read multiple sensor values, but only has a single output. It sends an individual message for each of the sensors it is configured to report. The 'topic' property of each message is used to identify which sensor the value in the payload is for. That might be an approach you could consider - it is certainly a more scalable way to handle multiple sensors.

Nick


Eric Cattoir

unread,
Aug 19, 2014, 10:43:05 AM8/19/14
to node...@googlegroups.com
Indeed. It is always 4 messages at the same time. I have already reworked my node to emit only one message with the 4 sensor readings in a JSON format.
The impact of this is that when I want to do something with only 1 of the values I always have to parse the message. I have also a node which can display something on certain coordinates on an LCD Display.  Now displaying the separate values requires parsing. On the other hand it has become easy to send a message with my four sensor values to the Bluemix internet of things service.
The topic approach could definitely also work, but for now my solution works.

Dave C-J

unread,
Aug 19, 2014, 1:29:45 PM8/19/14
to node...@googlegroups.com

You can always have 5 outputs.... 1 for each separate and one for the JSON... Best of both...

Nathanaël Lécaudé

unread,
Nov 19, 2014, 6:11:45 PM11/19/14
to node...@googlegroups.com
If anyone is curious here's what Paul did :

It generates DSP code that can then be pushed to a microcontroller.

chris mobberley

unread,
Nov 21, 2014, 4:16:37 AM11/21/14
to node...@googlegroups.com
That is so awesome great work!

Dave C-J

unread,
Nov 21, 2014, 7:41:04 AM11/21/14
to node...@googlegroups.com
Indeed - awesome. +1

Bluefox Fox

unread,
Nov 28, 2014, 6:24:42 AM11/28/14
to node...@googlegroups.com
That could be the good basis for "delay"-node with reset.
If this pull request will be merged, I could extend delay node to something like as in attachment.

пятница, 21 ноября 2014 г., 13:41:04 UTC+1 пользователь Dave C-J написал:
Indeed - awesome. +1
Delay.png

Bluefox Fox

unread,
Nov 28, 2014, 6:34:22 AM11/28/14
to node...@googlegroups.com
And it could be possible something like this.
AND.png

Nicholas O'Leary

unread,
Nov 28, 2014, 6:35:39 AM11/28/14
to node...@googlegroups.com
We have no plans to support multiple inputs on nodes.

Nick
--

Bluefox Fox

unread,
Nov 28, 2014, 6:37:31 AM11/28/14
to node...@googlegroups.com
Why?
GermanBluefox

daji wang

unread,
Jan 30, 2015, 1:34:06 PM1/30/15
to node...@googlegroups.com
i think its possible, check out AT&T node red flow sample, they have more than 3 ports on one single node. I have seen one input port, two output ports node in their flow.

在 2014年8月16日星期六 UTC-7上午9:29:55,PaulStoffregen写道:

Ray Kampmeier

unread,
Jan 30, 2015, 4:50:17 PM1/30/15
to node...@googlegroups.com
I'm really glad to see @PaulStoffregen in here! That guy has been an EE god, making some really solid platforms for embedded development. If you're interested in DIY electronics, you should check out his products: http://pjrc.com/store/teensy31.html

First off, I don't want to steps on anyones toes here, especially Nick's. Nick has done a kick ass job with Node-Red and I'm enthusiastic to start contributing to such a breakthrough project.  
I'm new to node-red and may not have fully grasped the trajectory and goals for the project, so please bear with me.  From what I've seen so, and in the way that I have been using it, it seems like multiple inputs would make node-red more efficient and approachable by novice users.

Context and background:
Many successful visual "flow" style programming environments before node-red that allowed multiple inputs. A couple of examples are Max/MSP and Pure Data:

Existing method for multiple "inputs" (input sources):
Using something like the "topic" property to specify the source of an input gets the job done, and can be edited from the visual interface. However, this approach seems less intuitive, and hides information. The user needs to first skim through documentation to find what a data source's topic should be, and then enter the data source's configuration and edit the topic text.

Proposed method for multiple inputs:
Alternatively, by wiring up to multiple inputs, the user has a visual indication that those inputs and their corresponding data sources are of a different type. The user would still need to skim through documentation for information on inputs, but to reconfigure they merely need to drag and drop a flow wire/connector/patch. By adding multiple visual inputs to a node, it seems we can more easily standardize and conceptualize different input types. Node help documentation can list inputs and their associated help in a standard format. 

From a developer usability perspective, it seems we could implement multiple 'input' events, or have a single input event include both the message, and input number. 

In writing "function" nodes within the GUI, the msg parameter could have a property that indicates what input it is coming in on. 

The main benefit of using multiple visual nodes seems to be for aesthetics and usability, not for ease of writing nodes in js. 

Examples: 
I have a simple "throttle" node. In theory it has two types on input:
1. Message in
2. Threshold timer (existing method uses the topic: "timer")

The function is as follows: A message from the "Message in" channel is only passed through to the output if the "Threshold timer" input has previously received an input event, and only if this "Message in" message was the first message since the previous "Threshold timer" event. 

Here's the existing code using "topic" to differentiate between inputs:

if(msg.topic === "timer"){
context.wait = false;
return; 
}

if (!context.wait) {                          
    context.wait = true;            
    return msg;
}else{
return null;
}



An architecture with multiple visual inputs wouldn't change the functional code too much, but it could make using a node like this more intuitive. A tooltip could be added for a quick reference of input names. 



This is a simple example that perhaps only shows a small benefit of using multiple visual inputs. A more complex example like a multiplexer for dynamically routing messages could show more advantages in using multiple visual inputs for intuitively displaying its function. 

For anyone who isn't familiar, a multiplexer has multiple input channels, a "select" input, and a single output. The select input is an integer index that determines which of many input channel s are connected and pass through events to a single output. 


Nick - Are there philosophical or architectural reason(s) against support multiple inputs? Or is it just not something with immediate plans to work on?

Looking forward to hearing your thoughts/opinions. 

-Ray

Dave C-J

unread,
Jan 30, 2015, 5:21:43 PM1/30/15
to node...@googlegroups.com
Hi Ray,

thanks for the well argued post. As you note from the copied in post we currently have no plans to support multiple inputs.
Part of that is that actually we disagree with your initial statement "multiple inputs would make node-red more efficient and approachable by novice users." - in that for real novices having only one input makes it totally obvious where to wire things to.

We do realise that for many elec engineers multiple input gates are a way of life (I was one - and still claim to be now and again :-), so never say never, but for now we are daring to be different.

Ray Kampmeier

unread,
Jan 30, 2015, 6:06:29 PM1/30/15
to node...@googlegroups.com
Are you guys completely dismissing this discussion?

If not, I'm happy to post some more compelling examples. I already have a few in mind that are less EE and way more CS :)

-Ray

Nicholas O'Leary

unread,
Jan 30, 2015, 6:27:42 PM1/30/15
to node...@googlegroups.com

I'm happy to have the discussion.

A single input was an early design decision based on the simple fact that everything we were doing only needed a single input. We've tried to stick with that approach and we haven't hit a scenario that can't be solved with a single input.

I would be interested to see what specific scenarios you think are better served by multiple inputs. I think it is subjective which approach is more intuitive to users; we have a broad user base. But if we can identify such use cases it gives us something concrete to revolve the discussion around.

Nick

Edward Vielmetti

unread,
Jan 30, 2015, 6:33:51 PM1/30/15
to node...@googlegroups.com
I'm convinced that somewhere I saw a set of patches that created a node with multiple inputs, but for the life of me I can't find it. 

--
http://nodered.org
---
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.
For more options, visit https://groups.google.com/d/optout.

Ray Kampmeier

unread,
Jan 30, 2015, 6:42:09 PM1/30/15
to node...@googlegroups.com
OK, great! I'll whip up a better example.

My main angle is that the input's source shouldn't hold information about how it's data should be handled by the receiving node. An example of where that breaks down is when a single source is connected to multiple receiving nodes. Each receiving node may have different and conflicting requirements for the "topic" property of the incoming message. 

Seems like the source should hold information about what type of data it contains, while the input channel should specify how that data is treated/processed.

I'll post an example shortly. :)

Nick, Dave, thanks for being open to this discussion!

-Ray

Ray Kampmeier

unread,
Jan 30, 2015, 10:32:23 PM1/30/15
to node...@googlegroups.com

Hi everyone, here's a more practical example. I've performed my desired function using the existing single-input scheme. The result is the necessity of two additional nodes that could preferably not be included:
1. "Add Topic "push""
2. "Add Topic "shift""

What I'm doing here is making a multiple input scheme on top of the existing scheme. It's clunky looking and I'm adding additional nodes to format the input of my Queue node. 



If anyone is interested in the code: 


[{"id":"45c1c820.ba3e38","type":"function","name":"Queue","func":"if(!context.queue){\n\tcontext.queue = new Array();\n}\n\nif(msg.topic === \"shift\"){\n\tif (context.queue.length === 0){\n\t\treturn;\n\t}else{\n\t\treturn context.queue.shift();\n\t}\n}\n\nelse if(msg.topic === \"push\"){\n\tcontext.queue.push(msg);\n}","outputs":1,"x":557,"y":246,"z":"ad4402ca.52bc","wires":[["84344ea8.7bcbb"]]},{"id":"ee9916b2.1166e8","type":"comment","name":"Topic is \"push\"","info":"","x":477,"y":181,"z":"ad4402ca.52bc","wires":[]},{"id":"6eeedfe6.91112","type":"comment","name":"Topic is \"shift\"","info":"","x":484,"y":338,"z":"ad4402ca.52bc","wires":[]},{"id":"84344ea8.7bcbb","type":"debug","name":"","active":true,"console":"false","complete":"false","x":725,"y":243,"z":"ad4402ca.52bc","wires":[]},{"id":"4cbfe837.b34018","type":"twitter in","twitter":"","tags":"","user":"dm","name":"","topic":"tweets","x":168,"y":204,"z":"ad4402ca.52bc","wires":[["fbab1e33.0454e"]]},{"id":"58715aed.a78ea4","type":"comment","name":"This node doesn't let you edit topic","info":"","x":198,"y":157,"z":"ad4402ca.52bc","wires":[]},{"id":"fbab1e33.0454e","type":"function","name":"Add Topic \"push\"","func":"msg.topic = \"push\"\nreturn msg;","outputs":1,"x":382,"y":227,"z":"ad4402ca.52bc","wires":[["45c1c820.ba3e38"]]},{"id":"fdce4636.0231b8","type":"http in","name":"http post","url":"","method":"post","x":161,"y":359,"z":"ad4402ca.52bc","wires":[["a7c03d2f.583fc"]]},{"id":"a7c03d2f.583fc","type":"function","name":"Add Topic \"shift\"","func":"msg.topic = \"shift\"\nreturn msg;","outputs":1,"x":382,"y":293,"z":"ad4402ca.52bc","wires":[["45c1c820.ba3e38"]]},{"id":"da53afe2.25ac5","type":"comment","name":"The idea of this flow: Queue up Twitter DM's and unload them one at a time as we receive an http post","info":"","x":454,"y":106,"z":"ad4402ca.52bc","wires":[]},{"id":"afd06635.502f98","type":"comment","name":"This node doesn't let you edit topic","info":"","x":171.5,"y":410,"z":"ad4402ca.52bc","wires":[]}]

Dave C-J

unread,
Jan 31, 2015, 4:33:44 AM1/31/15
to node...@googlegroups.com
Hi Ray

there is nothing sacred about msg.topic - apart from the fact that we use it as a go to place to put things that sort of describe what's in the payload if appropriate...  so a lot of the time we don't use it at all...

In this case - all tweet messages have a msg.tweet property - so why not use that instead to differentiate....
Makes your flow much simpler...




[{"id":"452d938f.bad26c","type":"function","name":"Queue","func":"\ncontext.queue = context.queue || [];\n\nif (msg.hasOwnProperty(\"tweet\") {\n\tcontext.queue.push(msg);\n}\n\nelse {\n\tif (context.queue.length === 0){\n\t\treturn;\n\t}else{\n\t\treturn context.queue.shift();\n\t}\n}","outputs":1,"x":592,"y":429,"z":"70e701e3.8f19","wires":[["32f4805e.cd0b8"]]},{"id":"bc195342.43e6b","type":"comment","name":"all Tweet msg have a msg.tweet","info":"","x":551,"y":375,"z":"70e701e3.8f19","wires":[]},{"id":"32f4805e.cd0b8","type":"debug","name":"","active":true,"console":"false","complete":"false","x":810,"y":420,"z":"70e701e3.8f19","wires":[]},{"id":"e76dd09.f18923","type":"twitter in","twitter":"","tags":"IBM","user":"dm","name":"","topic":"tweets","x":253,"y":381,"z":"70e701e3.8f19","wires":[["452d938f.bad26c"]]},{"id":"6adbd589.95242c","type":"http in","name":"","url":"","method":"post","x":244,"y":461,"z":"70e701e3.8f19","wires":[["452d938f.bad26c"]]},{"id":"5bc2dd30.a43d24","type":"comment","name":"http inputs have msg.res and msg.req","info":"","x":523.5,"y":480,"z":"70e701e3.8f19","wires":[]}]

It does beg the question as to whether we should maybe have a property that is in a known place to obviously identify the previous node - to make it easy to write that function. Maybe by type ?      say     msg._type   ?   = twitter  = http in   etc ?
(Yes I know that that wouldn't cater for two of the same type feeding in - but if you get there then you can revert to topic/tweet/res etc)

thoughts ? 

Nicholas O'Leary

unread,
Jan 31, 2015, 4:39:48 AM1/31/15
to node...@googlegroups.com

Not sure how well that sits with the principle that nodes should not have to know what nodes they are wired to. And, as you say, if you have two function nodes (or Change nodes, which are a much more efficient way to set a property on the message) then it wouldn't help at all.

Nick


--

Dave C-J

unread,
Jan 31, 2015, 4:48:11 AM1/31/15
to node...@googlegroups.com
I don't think it changes the principle at all. It's just making info available in a common place so users know where to look rather than having to find out that msg.tweet exists on this node and msg.req is unique to that node etc. In the above case then no extra nodes would be needed - surely the most efficient ? If you need to unique tag something then you only need to pass one leg through a change node - (and not even have to change anything as the _type would then get set to change :-)

Anyway - just a thought.

Ray Kampmeier

unread,
Jan 31, 2015, 11:53:35 AM1/31/15
to node...@googlegroups.com
Hi Dave, it's understood about the topic property. I only chose it because in the most convenient case this property is editable directly from a node's config menu.

In response to your (Dave's) example: 
Dave, it's a good suggestion for cleaning up this particular example. It's definitely made this particular flow more approachable by a newcomer. I'm worried about what it's done to the reuseability of the queue node.

This solution looks visually cleaner, but is less "modular" and could present another set of issues as the flow expands. 
A problem that I see with your example is that the "queue" function is no longer general purpose. It's functionality has now been modified to accomodate a particular set of data sources. Multiple queue functions in the same flow would each need to be modified to accomodate their corresponding sources.
As Nick mentioned, these nodes now need to know what other nodes they are wired to. 

If I would package the queue node from your example as third party bode, the user would no longer have the ability to edit it's code (as easily edit). It would be far less helpful if it worked only with Twitter and http requests. 
You could design it so in the queue node's visual settings you could choose the topics of It's input sources, but this still seems to break a modular concept where nodes shouldn't have to know what they are wired to.

Hey, sorry if this was a long winded response I'm very curious to hear your feedback on this one.

-Ray
--
http://nodered.org
---
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/Q0YLQYCUJ_E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+u...@googlegroups.com.

Dave C-J

unread,
Jan 31, 2015, 12:28:55 PM1/31/15
to node...@googlegroups.com
Ok , think I'm on the same page now. So continuing with your example... say we had a node with two inputs... and some tweets have come in and built up a queue.... then an http request comes in.... what comes out ?
Just the msg object from the queue ? - which (in this case) would be no good to return to the web page as it doesn't have the necessary properties from the http request msg... or some weird mixture of messages... (in which case you may well need to know the input types also).

Is the 2nd input only ever a trigger ? or could it be configurable - if it has configurable properties (such as msg.payload > 10) or msg.tweet.lang = en ) then the sending end would need to know what to send. 

I think it is going to be very hard to generalise such a node such that it needs no configuration, unless the second input is purely just a trigger on anything arriving - which is another sort of limitation rather than generalisation.

The other sort of node one could envisage in this mould is one where the second input is one value the other message passes through and if not then it doesn't (basically like an and gate) - but again there the sensing end would need to know what to send, as in this case a simple trigger would not be sufficient - unless we had 3 inputs... one for the message, one for turn on and one for turn off.

and so it grows.... just one more input...

Bluefox Fox

unread,
Jan 31, 2015, 12:55:56 PM1/31/15
to node...@googlegroups.com
Hello,
I am for multiple inputs too. Example:
-Reset of delay node
-Logical operations: and, or, function with more than one argument
-Triggers

Logical nodes can be configured as: calculate on any input event and take other inputs as 0 or last value, or calculate only if all inputs have last value.

It is all required for Home automation. E.g if after 19:00 and brightness is less than 30, then close the shutter. And so on.

Of course it can be implemented as a function, but it is not so elegant.

Greetings,
Bluefox

Ray Kampmeier

unread,
Jan 31, 2015, 4:43:39 PM1/31/15