I would like for a node to be able to find out what incoming wires the node has (e.g. what other nodes had outgoing wires to this node). I have found a solution that seems to work, but I do not think it is based on any official (e.g may not work in future releases) Node Red interface. The solution is using RED.nodes.eachNode() and from its results it filters out the wires leading to the node in question.
Is it likely for this function to be changed/removed in future releases? Is there some other (official interface) that provides the requested functionality?
Hi. Welcome to the forum.
Your question has been asked and answered many times. Please search the forum for your answer.
However, In short, no. A node should simply do what it does based on its own setup and the incoming message.
If it's a function node you could make it do different things depending on the value of msg.topic
if (msg.topic === "RESET") {
do something
}
else {
do something else
}
Thank you for replying. My problem is a bit different than just adding a topic value.
Thank you for the welcoming and for the answer.
I understand that you like to keep everything as ”simple” as possible and keep the public interface limited.
I noticed in a module (node-red-contrib-….) I am using that it called RED.nodes.getNode so I started to explore RED.nodes and found eachNode. Since I have not come across any documentation of RED.nodes I assumed that you should probably not use it.
To do what I want to do (boolean logic gates) requires my nodes to have information about the number of expected input sources to each node. There are several ways to achieve this and in my view the superior one would be if the node could retrieve this information based on what the system knows about the wires leading to the node. Another way would be to require manual node configuration but that should be avoided (error prone).
I tried to automatically send a message (node.send({payload: true})) in the node startup code, but in some flows that message never showed up an in other flows that message always showed up. Is there some way to reliably ”send” a message from a node that will get sent prior to any messages being sent from the nodes input handler? I can manage this in the input handler, but it would be ”cleaner” to have it sent from node startup code if that would work.
Related to Getting a unique ID for each node (that doesnt change)
Although it is possible to fetch the number of threads, this does not guarantee the goal because your node may have a link node as input and in this case you would have to do further research. Which implies quite substantial logic.
In short, the cleanest method would be to use topics
1 Like
In my view a link node does not impose a serious problem, unless all your inputs are link nodes. You could always have a no-op node in your flow between the gate and the link node. That is far less tedious than having to have to configure all source nodes and gate nodes with their respective topics.
All this information that you have to enter manually is ”available” by just looking at all your wires …
And what do you do with the switch or function node with multiple outputs? It's not as simple as you think...
In the case of nodes with multiple outputs that are wired to the same gate node, you can introduce no-op node(s) (a function node with no added code is a no-op node). This will be pretty easy to manage in the documentation.
Well you seem to be stubborn
If I take the example below, I can apply the same logic with the switch node as the function node. I mean with one node I can create several "gates" and that you cannot know with the wires.
The gate node does not need to be configured with topic values, all it needs to know is how many unique topics to expect. Look at node-red-contrib-boolean-logic-ultimate (node) - Node-RED for example.
1 Like
I might be stubborn or you may not understand what I am trying to achieve.
In general, you could come up with a multitude of examples where a particular node might not operate as intended. You always need to rely on the documentation to provide you with the required information about how the node could be deployed.
Are you trying to argue that the system should
- not provide information to nodes about the current wires of the system
- or that it is ”hard” to provide that information
I have accepted that the information is not provided, but I still think it would be good if it was available. Maybe that makes me stubborn …
If it becomes ”hard” to provide the information due to complexities beyond my capabilities becomes of no interest, since the information will not be provided.
You develop a node that has one input.
This node receives Boolean messages and you want to apply a logic gate but for this the node needs to know the number of gates.
As I say in my previous message, I can have one node (with one input) that has several gates (which sends several Boolean messages), the threads method does not reliably calculate the number of gates.
The only way to differentiate gates is to use a unique topic per gate, like the join or logic-ultimate node.
I hope you understand me now
I think it is more that we do not think you will arrive at a workable solution that is easier for the user than using topics, where is it just necessary for each input to have a unique topic and for the node to know how many topics to expect (in fact in some cases it is not even necessary to know this, it can work with however many input topics it receives. An OR gate, for example, does not need to know how many topics to expect).
However, once you have a working system we may have to reconsider as perhaps you can imagine a solution that is not obvious to us.
1 Like
My solution to the ”building boolean logic” problem is different than how logic-ultimate does it.
My idea for solving boolean logic in node-red is probably different from the existing ones (at least the ones I was able yo find).
The graphical flow representation provided by node-red is excellent and could be matched very closely with the needs of a design for a system of boolean logic gates.
The main difference is that boolean gates have multiple inputs and typically a single output. Node-red nodes on the other hand is is the opposite, a single input and possibility of multiple outputs. So this difference needs to be managed so that the single node input can map to several gate inputs. Your method is by using topics on the messages to represent the different gate inputs. My method is to use the id of the source node of the message to indicate the gate input. This way the wiring will be determining the input and not some additional manual configuration (setting up the topic information). Just by looking at the graphical flow representation you will see something that would be close to identical to the corresponding ”electronic drawing” of the boolean logic.
There are several ways to fix the problem of not getting the wiring structure of the flow(s) from the node-red system.
In my view, I really would like to avoid the extra effort of having to provide the topics related configuration, and I think I am able to achieve that.
In my view using MANUALLY configured topics is not the only way to differentiate between multiple logical gate inputs.
Just to interject some thought here.
Have you considered the pattern of "Gate" & "Provider" nodes?
Here me out...
Your Gate Nodes will take the input of its "Provider" nodes (only)
You can control this with a defined structure say - so if the Gate Nodes receives a message that is not from a provider node - its is ignored.
Each provider node will obviously have its ID - and given you have control of both nodes, you can create a relationship between them on start up.
-
On Start up
- Each Provider Node, sends to the Gate Node "Listen out for me later"
- Allowing the Gate to prepare its internals
-
When A message is sent to a Provider Node, it passes out the other end (but tagging the message, with the same ID that was sent in the "Listen out for me later" message.
I realise what this means, but it.
- Gives you complete control
- Doesn't involve hacking into unpublished APIs
- Your Provider Nodes can do some advanced processing if you project desires
- Wouldn't require the need to provide topics
- Stays within the Node RED design "expectations"
Many nodes in the repository requires a message from one of its family nodes - My ZWave Node is no exception.
I have A filter node - that only works with my controller node
So this can also be an area of thought
3 Likes
I don't know how to say it: with this method you will get the id of the function node -> deduce that there is only one gate -> that's wrong I can code several.
Marcus' method is a valid hack (usually the node adds a topic to the message)
Basically I am using this pattern 
