I have a specialized singleton node which needs to do a stuff, at the node registration , and then put the result in the flow. This result is expected by some other nodes, also at the node registration.
So, the question is, can I force the registration node order ?
When the runtime starts your flows, it first looks for all configuration nodes and starts them. It tries to identify any dependencies between the config nodes and will start them in the right order to satisfy those dependencies. It then starts the regular flow nodes, one tab at a time, in the order they were added to the tab.
If you have a node that other nodes depend on, I would assume its a config node - as regular flow nodes don't, in general, have dependencies on each other like that.
If your node is a config node, and other nodes declare a dependency on it, then it will get started first.
The node, I need to start first, is a node responsible for the translation of prompt. This node has a config part where all the prompts are declared.
At the node creation, it requests the translation to the distant HUB (synchronous call) and then puts the information in the flow context.
And I would like some other nodes to use these prompts info in their init.
@knolleary - Nick, If I add TAB1 then TAB2 then TAB3 (all regular flows) from what you say, it will start them in that order.
But what if I move TAB3 before TAB1 so you have TAB3, TAB1, TAB2 - is TAB3 or TAB1 started first? i.e. is it the order they occur in the tabs or the order they were added?
I would also suggest that you should make your flows resilient to data not being available as expected, either waiting for data to become available or falling back to some default or other appropriate action. Then when the data does become available normal operation should be resumed.
For the moment, we process the data on the first received msg, and only once.
Is there a mean to suspend the creation of a node waiting for the data ready ?
I used [node-red-contrib-config] and set the variable to 0 in the beginning, the startup routine will change this value and in the rest of flow I check this variable again before sending anything. So only when hardware is initialized I can use it.