Multiple Inputs on a Node?

[PaulStoffregen]

Is there a way to create a node with 2 or more inputs?

[Nicholas O'Leary]

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]

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]

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]

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]

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]

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]

[Eric Cattoir]

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]

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]

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]

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]

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

[Nathanaël Lécaudé]

If anyone is curious here's what Paul did :

http://www.pjrc.com/teensy/gui/

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

[chris mobberley]

That is so awesome great work!

[Dave C-J]

Indeed - awesome. +1

[Bluefox Fox]

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

[Bluefox Fox]

And it could be possible something like this.

[Nicholas O'Leary]

We have no plans to support multiple inputs on nodes.

Nick

--

[Bluefox Fox]

Why?

GermanBluefox

[daji wang]

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]

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:

- https://cycling74.com/products/max/

- http://puredata.info/

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]

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]

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]

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]

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.

--

Edward Vielmetti +1 734 330 2465

edward.v...@gmail.com

[Ray Kampmeier]

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]

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]

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]

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]

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]

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]

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]

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]

Hi Dave, this particular example was designed for simplicity so that we could focus on the input to the queue. It wasn't my intention that the queue functionality be focussed on. In this example, the queue node could easy be replaced with something like a "throttle" node, a "stack" node, a semaphore/gate node, or any other concept that performs a multitude of functions.

In the example of queue, throttle, and stack, these nodes each serve two types of functions. They are all similar in that one of their inputs/functions is merely a "trigger" and doesn't require data input. The process of a message being sent to that input is enough to invoke a desired action. 

This doesn't need to be the case for all nodes though! Some routing nodes like the Multiplexer or demultiplexor could benefit from multiple inputs which all pass different types of data.

The Mux has n inputs and a control input that is more than a trigger. The control input receives data that specifies the node's configuration for routing messages.

I'm not saying there should be just a second input allowed. I'm saying that the number of node inputs should be dynamic and configurable within the node's code. 

I agree completely with you guys that nodes with one input are simple and straightforward. I think that the node-red default nodes can mostly contain single input nodes and continue to cater to newcomers. However, I don't feel there should be a restriction on the input number. It's seems to be limiting the power of this platform, especially for logical/routing functions. 

Allowing for multiple input nodes isn't necessarily going to mean that the system will be flooded with more confusing multi-input nodes. New/novice users will always be greater with the stock set of nodes. More advanced users who are installing packs of third party nodes can leverage the benefits of multi-input.

-Ray

On Saturday, January 31, 2015, Dave C-J <dce...@gmail.com> wrote:

--

[Julian Knight]

Just a thought but isn't that what topic already does for us? Isn't that the principle that is used with MQTT where all this started?

Point taken from Nick about trying to keep each note stateless and not need to know what went before. But hey, sometimes it is quicker and easier to be told rather than to have to find out!

[Julian Knight]

Maybe I'm not getting this but couldn't the trigger feature be achieved simply through convention and not needing a second input?

If there were an agreed convention for nodes that says something like: "if msg.trigger is true ...." wouldn't that be enough?

[Dave C-J]

Ray,

yes, ok - I hear you. As I said way back, as an Elec Engineer I can see that multiple inputs are quite normal and could possibly have a place. We will add the requirement to the white-board for possible future investigation, though as we also said it's unlikely to be very close in as we have some other significant things we need to get in place (like more security, v0.10.0 etc :-)

It would need some quite considerable internal changes as rather than wiring node-node it would then have to wire pin-pin, as each node could/would now have multiple endpoints - so will need some serious thinking about to preserve backwards compatibility and prevent breakage.

[Ray Kampmeier]

Hi Dave, thanks for hearing me out. Please let me know how I can help with this feature. 

-Ray

[Wojciech Zieliński]

+1 at least multiple inputs on sublflows, logical operations are pretty important, also many other uses. For example priorities of triggers/switches with delays and rule checking, this can be achieved by using nodes, but if you check how it looks for 5 windows with 5 heater with 10 thermometers multiplied by 3 floors (every single rule is different) then it is crazy, additional inputs at least in subflows may simplify flow a lot.

[Peter Scargill]

Apparently not, Paul. I asked that a few days ago.

[Peter Scargill]

Mind you of course you can pipe several outputs into one input…

--

[Per Malmberg]

What came of this discussion?

I'm really missing multiple inputs on sub flows. It would make boolean algebra, i.e. (OR, AND, NOR gates) so much easier.

[Dave C-J]

It's a true reflection of the current state. It had been discussed, and while the semantics of multiple inputs are well known to elec engineers etc, the fact that you can assign extra properties to a message to distinguish between them means that there are other ways to solve this that don't

​ require major internal structural changes. As a result it's "on the whiteboard" for ongoing discussion and ideas - but nowhere near the top of the list of things to do.

[Per Malmberg]

What you state as a reason not to prioritize I see as a perfect reason to do just that.

Modifying the data before it enters a node, just to be able to tell messages apart inside that node is not at all user-friendly, it only adds to the burden of the user. Also, it breaks the two first points of the guide lines since you have to put logic both inside and outside the node in order for the node to be able to do what it is meant to do.

Look at this very simple use case, in pseudo code:

if( frontDoorIsOpen || backDoorIsOpen ) {

  soundAlarm()

}

This looks very simple, but in node-red it becomes this:

Code for the function node (simplified, needs additional checks on input data):

var inputA = context.get('A')||false;

var inputB = context.get('B')||false;

if( msg.topic === 'A') {

    inputA = msg.payload;

    context.set('A', inputA);

}

else if( msg.topic === 'B') {

    inputB = msg.payload;

    context.set('B', inputB)

}

return {payload:inputA||inputB};

All this just to achieve a simple boolean or-logic. 

If multiple inputs are allowed, the code becomes much simpler (again, simplified) and the change-nodes are not needed.

var inputA = inputs.get(0)||false;

var inputB = inputs.get(1)||false;

return {payload:inputA||inputB};

If you only have a few conditions to check, the current workaround isn't terrible, but when you have > 10, it becomes pretty cumbersome, error prone and manual - and we're all about automating things, right? :)

Also, what if you want a three- or four-input OR gate? It is easy to see how quickly it becomes a real burden to manage.

With multiple inputs you can easily build a three-input using two two-input nodes etc. With the current one-input-only solution you can't even see how many different "inputs" the node supports or what topic (or other property) it uses to differentiate between messages.

Br,

Per

[Nicholas O'Leary]

Per,

given messages would arrive at each input entirely independently of each other as asynchronous events, there are lots of open questions on how multiple inputs would work

 Does it get triggered whenever an input is received?

 How does it know which input triggered it?

 Does the node now have to remember the last message it received on each input in case they are needed later?

In an electrical circuit, an AND gate works because the wires coming into it maintain a state (off or on). That is not the model Node-RED uses - messages are events that flow along each link, they are not a 'state' of the wire.

To be slightly pedantic, in your first example, the messages would already have different msg.topic properties as they have come from different mqtt nodes, so nothing further would be needed between them an the Function node.

Nick

--
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.

[Per Malmberg]

Nick,

Yes, I am well aware of those questions, this is my opinion on them:

Q: Does it get triggered whenever an input is received?

A: Leave that up to the implementation of the node, no reason to specify that before hand - we can't know what nodes people invent and what behavior they should have.

Q: How does it know which input triggered it?

A: That's an implementation detail, but a very simple solution is to pass the number of the input (or the label).

Q: Does the node now have to remember the last message it received on each input in case they are needed later?

A: Same answer as in the first question.

>> To be slightly pedantic, in your first example...

True, but think of the bigger picture. Not all messages have a topic - or even worse, they have a topic that has been inherited from earlier in the chain which may be changing between calls. The function-node have no way to handle such a case without the additional change nodes in the example. Yes, you could write a different function for each condition to avoid the change-nodes, but that doesn't go well with the idea of reusing sub flows, does it?

Br,

Per

[Peter Scargill]

But.. you can do that with multiple sub objects.... msg.this and msg.that ????

--

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/Q0YLQYCUJ_E/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.

[Per Malmberg]

Peter,

Do you mean merging data like this?

msg = { this = {dataA}, that = { dataB } }

If you have a simple solution on how to write reusable Boolean logic nodes using this method I'd be more than happy to listen. Can you please elaborate further? 

Br,

Per

[Peter Scargill]

If (msg.payload && msg.otherpayload)

[Nicholas O'Leary]

Peter - the question here is how to combine properties from two separate messages that arrive at different times. Not combining properties on the same message.

Per - Your suggested simplified version of the Function node does imply quite specific answers to those questions and assumes far more than just having multiple inputs. For example, it assumes the node is also storing the last message received on every input so that it can do inputs.get(0/1/2/...). That really is not desirable to do by default from a resource usage point of view.

In reality, for the Function node, the code would be near identical to the original version, but instead of msg.topic, it would have some auto-generated property identifying the input it was received on.

In my experience, I've not found the single input to be a problem. The vast majority of cases where I've needed to combine data in a single function from multiple sources, each source already came with some identifying property for 'free' and no Change nodes were required.

Nick

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.

[Per Malmberg]

Nick,

Absolutely, it was just a suggestion/simplified example. A less resource-demanding solution would be to let simply store the - in this case - boolean representation of the incoming payload for each input.

Yes, I can see that there often is a usable topic available, but what in those cases there isn't? What did you do then? Would multiple inputs have helped/made it a cleaner flow?

I get it that a single input has worked so far and that there are ways to work around this shortcoming, but multiple inputs would really make node-red even more usable. I honestly don't understand the reasoning that multiple inputs makes things complex - how are they worse than multiple outputs? And isn't it worse to force the the user combine data - which is actually the exact opposite to what the user wants - than to just connect a wire between to points?

Br,

Per

[Gilbert]

Here's a problem I ran into yesterday, which might be related.

In responding to an HTTP request, I need to make two GET requests, put them together, and send the result to the client. Since both http request nodes return their respective data in msg.payload, I couldn't figure out how to do this without some sort of Promise.join. 

Am I taking the wrong approach? Should I perhaps implement a "higher-order node" that would be able to combine multiple http request nodes?

Thanks,

Gilbert

[Dave C-J]

Hi Gilbert,

as usual it all depends... it's not really related to Per's question as that is more about boolean level type data rather than messages... however it is in that it is about multiple inputs...

In you case you probably want to look at the join node we released as part of v0.14.x - this can wait for two objects and join them either into an array, or (potentially) another object... I say potentially as if they have the same properties then they may/will overwrite each other.

The other way is to use the change node to move one set of results from .payload to something else... - but you would need to use context to save the first result (so not unlike Per's question :-) - until the second arrives - and then rebuild the onwards message. 

[Stephen Wallace]

It does get cumbersome and less visual when trying to code conditional home-automation to have a zillion nodes feed into a single point of a function node that has to act as a traffic cop based on msg.topic. With all of the individual change nodes that have to precede entry into the function to keep track of the source of messages, the spaghetti increases. 

Isn't there some value, both aesthetic and practical, to allowing the user to define the number of inputs a function node should have, and then have the node automatically assign a routing number to "msg.input" as messages come in? It seems that keeping all of this in the function node would add a lot of organizational capability to those who want it, without the need for adding a more general multi-input capability to other nodes, which would probably require extensive redesign.

I think by keeping all the multi-input capability restricted to the already existing (and backward compatible) function node, you would see an explosion of interesting logic-gate implementations (among other things) that satisfy people's needs and wouldn't conflict with the existing architecture, without the need for an official solution for how to deal with all the other implementation questions that arise when you consider allowing the creation of multi-input nodes in the architecture more generally.

[Dean Cording]

On Sunday, 7 August 2016 02:20:20 UTC+10, Stephen Wallace wrote:

It does get cumbersome and less visual when trying to code conditional home-automation to have a zillion nodes feed into a single point of a function node that has to act as a traffic cop based on msg.topic. With all of the individual change nodes that have to precede entry into the function to keep track of the source of messages, the spaghetti increases. 

Link nodes will solve your spaghetti problems - they allow you to link from anywhere to somewhere else and the flow line is hidden until you click on the link node at either end.
 

Isn't there some value, both aesthetic and practical, to allowing the user to define the number of inputs a function node should have, and then have the node automatically assign a routing number to "msg.input" as messages come in?

There isn't really much to be gained from multiple inputs.  Firstly, Node Red is a visual tool and a lot of its benefit comes from being able to see what is happening.  If your multi-input node is handling each input differently, then there is no benefit in hiding that inside one node.  It is much clearer to have individual nodes for each function, and not much extra work considering a family of nodes can share a codebase.  If you are wanting to process messages differently according to input, you are better off just tagging the message and processing it according to the tag.  As you will have to do some type of flow switching to get messages to the right input, adding a tag is no extra work (msg.topic is ideal for the purpose and would require no extra effort).

Having said that, I do have a use case where multiple inputs would be nice.  Say I had two input flows, a primary flow and a backup flow, say an external GPS time source and an internal time source.  A two input switch type node could be useful to implement a failover mechanism to switch from the primary to the backup automatically.  It can be done now but a bit convolutely.

Dean
 

[logt...@gmail.com]

Hi ,

First , let me start with how awesome node-red is, I started using it recently and its very intuitive. However I agree with @Dean that in certain scenarios it will be nice to have a multi input node. It would be a good if developers of nodes have option to include multiple inputs. 

I have made some change to editor and run-time and unit test to get the function node to have configurable input nodes. I will be very happy to contribute to main project if you consider this feature. You can loot at the changes here - https://github.com/KunalSaini/node-red 

[Stefan Stiene]

Hi,
I am a robotics researcher for the past 15 years. Robotics and IoT have several overlapping areas. In robotics component based programming has prevailed.
See for example:
http://rock-robotics.org/stable/documentation/orogen/task_interface.html
or
http://wiki.ros.org/roscpp/Overview/Publishers%20and%20Subscribers

i just started analysing Node Red if its suitable to define such software component networks for robotics (reading for example the component specification from JSON). And having multiple input ports with different topics and data is crucial for this. Additionally not everything is publish subscribe like MQTT supports but also sychronous and asynchronous request response. And a single component can have multiple different data flow ports, configuration ports and service (REQ/RESP) ports.

So from a robotics perspective I can say that multiple inputs for a component are very useful!
Best
Stefan

[Leif Neland]

Tag every input signal with msg.foo=<source>, 

connect all to the input of the function

then in function store the value, based on msg.foo. 

if (msg.foo="voltage") {context.set('voltage',msg.payload; msg=null); //don't send out a message (not sure it works like that)

if (msg.foo="current") msg.payload*=context.get('voltage') //Send power. (voltage*current);

return msg::