Find out incoming wires to a node …

Developing Nodes
21

Once I publish my solution you are welcome to explore it

22

That method does reliably send a message. The problem is that any receiving nodes may not yet have been initialised so will not be ready to receive messages. It is the receiving that is unreliable, as it depends on the order of node initialisation.

3 Likes
23

Just to be clear, in a custom node, the this.send function is only available after RED.nodes.createNode(this, config) has been called in the function that is called from RED.nodes.registerType. That is because the createNode function attaches all of a node's standard methods to this.

But, as Colin states, that function is called quite early on in Node-RED's startup and depending on the order of nodes and flows having been added, other nodes might not yet be ready for action.

Try wrapping the send in a setTimeout function with a couple of hundred ms delay if you are getting that kind of a problem.

1 Like
24

Was going to suggest sending on a timeout, but got called to do grocery shopping :smirk:...
and this kind of delay will aid in the Provider/Gate setup I suggested

module.exports = function(RED) {
    function Init(config) {
        RED.nodes.createNode(this, config);
        const node = this;

        ....

        setTimeout(() => {
            node.send({
                payload: 'ready'
            })

        }, 250)
    }
}
25

:grinning: Know that call all too well. Thankfully, it is very stormy here today so no going out for us!

1 Like
26

You know it's Sunday, right? :see_no_evil:

1 Like
27

All the more reason I was sooo happy to go out :unamused:

28

Thanks for the clarification

29

Thanks,very valuable information.

30

This is what I did prior to experimenting using the RED.nodes.eachNode to find the wires.
Now I have turned back to sending messages to find out incoming wires, and the timer based initial send is back.

31

Some info about my current state:

  • I am now using the topic property to indicate logical inputs.
  • While working on the solution where I looked up wires with the eachNode method I also used a messaging hook that added a ’logicsource’ property on each outgoing message. I did that in order not to overwrite existing topic values. Since the hook is gone, I can now use the topic property to indicate logical inputs.
  • What is new (I do not recall having seen this in any boolean/ logic plugin) is that I use a configuration message and an initial configuration period to find out the wiring. This removes the need for any other configuration within the network of gate nodes, than the flow wiring (no need to specify number of gate inputs). For me this is very imporant !!!
  • I have also added an entrance node that is basically a gate node but it is a single logical input, i.e. it ignores the incoming message topics and feeds each logical message into the gate cluster. You could also create your own entrance nodes using (e.g. a subflow) an inject node that sends an initial configuration with a specific topic and a function node that tags each outgoing message with the same topic.

For the use cases that led me to this design, there is actually always a cluster of a fair amount of gates that have somewhat complex interconnection structure. In this context, having the graphical wiring as could be viewed by the Node Red editor becomes significant for the construction and maintenance of the logical network.
Using one or a few gates in ”isolation” does not impose the same requirements.

32

Becoming close to publishing my solution, I realized that what I basically was asking for in my initial question is possible to achieve via the Message Hooks Api. Further some study of external requirements are needed in order to be able to fine-tune the solution. So now I will go back to the drawing board …

Thank you all for your valuable input.

33

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.