A simple way to implement multiple input nodes:
this need to make a little change to the core.
I don't think multiple inputs are part of the underlying design philosophy. But if you really need them, you can use a function node to accept the multiple inputs on a single input and route them to the appropriate output and pretend the outputs are the messages from the multiple inputs.
The node configuration properties have inputs and inputLabels already, which only need to be implemented in the core.
Why do you need multiple input nodes ? You can differentiate between the input messages (just like the join node).
The topic of multiple inputs has been discussed many times in the forum. Our position is well documented that we have no plans to support multiple inputs currently.
It is not due to a lack of ideas on how it would work, but a conscious design choice we have made.
Already with input and input labels, you only need to modify the core slightly to display multiple input ports, doing a similar job as the join node. This would be a big improvement, but not a violation of the original mechanism
make the flow more readable
Nick has made the position clear.
Multiple inputs would imply some kind of synchronisity that simply does not exist. Every node that supported >1 input would have to make sure they processed the inputs in a consistent way. But there are many ways to handle separate incoming msgs so there really isn’t a “standard” way.
I'd like to add my perspective on this: reusability.
First the practical reasoning: I'd like to define a sub flow, which represents my modbus relays device with 16 channels. So I'd like to have a universal (reusable) sub flow for this device class with 16 inputs. I'd preferrably not want to place "change topic" nodes around each instance of this sub flow to assign the topics, e.g. channel0...channel15, as this would add another 16 nodes to the flow on every use.
Now the theoretical stuff: As a software developer I see and understand the underlying complexity and I also agree, that the concept should not be changed. However, I would say this is a "similar" feature, which I would describe as follows:
Add "topic inputs". A node can have multiple inputs, where each input has a topic name assigned. When a message arrives on such an input, msg.topic is assigned the topic name of that input and the message triggers the one and only input event (as if it arrived on the one and only input).
This should be rather simple, as it does not change the core, it does not involve caching previous messages, nothing. Just assign a topic (aka mark, through which input gate the message came in) to the message before it enters processing the very same way as before.
I would be really happy, if this definition of multiple inputs could be reconsidered 
Do subflow properties solve that problem?
Not really, as they are static.
I mean imagine you have a physical device, which you want to be represented by a node. This device has 16 relays on it. The prettiest solution would be "send true to input 1 to turn on relays 1", etc.
Now imagine you have another type of physical device which is a room light switch, which contains only 4 physical switches. Then you have a node with 4 outputs, each of them emitting true when the switch gets turned on and false when it gets turned off.
Now you want to combine 4 instances of the 4 channel switches with 1 instance of the 16 Channel relays device. Pretty would be to just connect all the outputs with all the inputs and you are finished. With my suggestion this would be easy.
Instead you have to place a change node in each line and assign the right channel number manually to the msg topic. I mean I do this right now, it's not very yoyful 
But that's the main difference between what the node red developers seem to understand when they hear "multiple inputs" and what many users probably need (I've found all those threads with the discussions). I think "multiple inputs" can mean different things.
BTW: this would also work for functions, as the multiple inputs are just altering the topic to denote through which input the event came, before calling the function, nothing else!
Most switch nodes already let you set the topic (or some property) so you can wire them all into the one input already without needing change nodes... - ok so visually they aren't 16 separate wires but logically they are.
The problem with that is you can no longer be dynamic & have to have 16 permanent wires feeding in. In the current guise, a simple function or change+jsonata can be used to "compute" the desired topic and avoid all the extra wiring.
So that means there are 16 wires to connect.
Let me play devils advocate & turn this around for a seconds...
Imagine you have a physical device, which you want to be represented by a node. This device has 16 relays on it.
Imagine you have another physical device which is a room light switch, which contains 4 physical switches. Then you have a node with 1 output, emitting {topic: 'switch/1/x', payload: true} when the switch gets turned on and {topic: 'switch/1/x', payload: false} when it gets turned off. (where 1 is the switch bank / ID and x is a number from 1~4)
Now you want to combine 4 instances of the 4 channel switches with 1 instance of the 16 Channel relays device. All you would do is pass the payload through a change (or function) that converts bank number and switch number into a relay ID and connect that to the single input of the relay block - a lot less static wires AND a fully dynamic solution (can scale up or down with just a "relay count" config modification).
By setting the topic you would lose the incoming topic - which a user may (rightfully) want.
To summarise, there are just as many arguments for and against multiple inputs.
I understand from a visual / low-code POV it seems to make sence to have multiple inputs BUT as soon as that feature is delivered and everyone starts building nodes with multiple inputs, you then get a whole bunch of people asking "how do I route a msg dynamically to the 6th input - I am sick of setting up switch nodes to route the msg and having to wire every pin. There are more scenarios I can think of too. Things get just as messy.
Maybe I've misunderstood but that feels like it would simple move the problem to a different place rather than actually help?
If you want to route using topics (sensible), assign the topic at source not at target. That is far more robust anyway isn't it?
This also feels like a misuse of low-code programming? The principle I would always follow is start with nodes for speed of development but then simplify flows with function nodes where you find logic that seems node heavy.
Not really, I would have 1 output with meta-data showing the source of the data. For a complex example, here is the input processing for all of my 433MHz devices including plugs, controls, lights, doorbell, etc.
This flow is only that complex because I chose to separately record unknown devices and record both raw input (just used for occasional debugging) and enhanced input (which is what I actually use).
Note that each input signal type is a single output despite servicing many devices and indeed, the final output which is used in the other flows is a single feed. No need for lots of inputs because each msg carries the appropriate identifiers and meta-data that allows any other flow to make use of it.
Thanks for all the input. All of the suggestions were clear for me, I am an experienced software developer, so I fairly understand what I can do with code. Yet I am new to node red as a platform, so I still have to explore. Obviously I had wrong expectations on what node RED is. My intention was, to avoid hiding the logic of my connections behind function nodes. Just like schematics in electronics world would show "the whole truth". Sure I can achieve the functionality with all of the suggested ways, but I will not be able to visually see everything. In my example I won't just see, which channel of which switch controls which relay. Instead I have to look into node configurations or function nodes code to find it out.
@Steve-Mcl I don't see the issue of losing the incoming topic on a message, that ends inside the node (like for the relay example) but it could be just any property, not just topic, that gets modified. And every node can change the topic anyway, so it's totally out of control for the outside user anyway. Plus: No-one disallows to have a "normal input" as well. And if that feature is missing on an open source node you want to use, simply improve it.
@TotallyInformation not quite. Just imagine you re-use the 16 channel relay module multiple times. Assign topic at source: imagine you have 1 switch, switching relays numbers 2 and 14 simultaneously. With multiple inputs of the relay module you simply draw two lines. This is also why dceejay's suggestion does not convince me.
Actually I see sub flows more as a way of doing modularization, so having multiple input (to achieve multiple functionalities) should be quite natural. Imagine you could only have one single function in every ECMAscript module and the ECMAscript developers say "just add a parameter to the function that switches it's functionality", would you want to accept that as a developer?
On my opinion a generic system should not be closed to improvements that don't cause harm - everyone could decide to use it or not.
Anyway: I don't want to steal any more time from you guys though. All the topics around clearly show that the developers of node red, which really did quite a good job by the way, are closed for that. I'll live with that I have to do things hidden (in configuration parameters or code), that I'd prefer to see from the schematics. Still I think it's a pitty.
Well - it can also depend on how the relay node is created - If it is only a 16 relay board node - then yes - but then you would also need a node for 8 relays, 4 relays etc - If the node was for one relay and the config assigned it to slot one on board 2 (for example) then you have a 1-1 correspondence.
Indeed - and as a fully open source project anyone is free to fork Node-RED and modify it as they wish.
At the end of the day, as @knolleary said originally - it is/was a conscious design choice we made, and revisiting that is just not on the priority list of things to do.
I genuinely think that this is about experience with the platform. In my view, one of the difficulties with visual programming is that you can end up with so many nodes and wires that the logic is really hard to follow. As with any programming, careful use of wording, comments, labelling is needed to ensure that the logic is clear and unambiguous. The more complex your logic becomes, the more critical this is. Do have a look at some of the examples in this forum from long-standing members and you will often see that we come to similar ways of doing things - keeping nodes tidy, using groups and labels and comment boxes, etc. We all aim for our logic to be clear even if it is just for the sake of our future selves.
My intention was, to avoid hiding the logic of my connections behind function nodes. Just like schematics in electronics world would show "the whole truth".
I think this comes down to what node-red is and what it isn't.
If I try to describe it: An advanced message router and transcoder.
I would not consider it to be a visual logical connection builder - it is not an HMI, as is not about connections per se, those are merely multiplexed "trunks" and at each edge you need to handle the data. Each node is specialized for it specific type of input/output data.
In the end: specific input should produce reproducible output and how it's done you build in a flow, once (properly) tested, you "should" not have to look at it anymore. I have certain flows running for years, have not touched or looked at them since I made them.
Good, you sayed what I want to say.
And did you read & fully understand the responses below that as for why it is not necessarily a good idea?
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
