Node-Red start up cycle

Good morning all, I need advice with the Node-Red start up cycle. I have several relay outputs controlled by a Modbus node. These outputs are controlled by several variable comparisons and calculations coming from a field MQTT device. Before node red has started up and has all the necessary information for controlling the outputs, the relays switch on and off in an erratic manner, this can obviously result in damaging equipment being switched by these relays.
Any suggestions?

Is that due to bugs in the flows causing that? Add debug nodes showing what is being done by node red and select Output to console in the debug nodes. Then the output will be written to the node red log on startup so you can check. Give the debug nodes names to make it easier to follow.

Hi Colin, I don't believe is is a bug. But what I would like to do is block the output's (lets say 10 seconds) from any information flow until all the information is procesed. The switchin is based on current measurements comming from different devices. So in a total start up cycle, node-red is making switching operations when not all information is available.

Do what I suggested and work out exactly what is happening. Then adjust your flow to cope properly with the startup conditions. If you use a hack like disabling output for an arbitrary period then at some point something will happen that delays the initial data setup and your system will fail unpredictably.

ok, thanks colin I will do what you suggested.

Before Node-RED has started the IO are only under the control of the Operating system - so you really need to provide your own isolation. You would need to work out how the IOs are set by default before Node-RED gets involved, and ensure your kit stays safe in that mode.

This sort of problem can often be caused by using global or flow context variables before they have been initialised. You can avoid that by using inject nodes set to trigger on startup to initialise them, or often better is to avoid the use of such variables completely.

Maybe not the best solution. I used a q-gate node to block all outputs until all parameters were read, and the outputs set to their normal state. I then release the gate, it works like I would expect. Thanks for advice.