Inject node trigger behavior

Hiho :slight_smile:
I ve a problem question with the inject node:
When my system reboots I use a bunch of these nodes to trigger a initial activities of the flows or load variables. Therefor I use "one time injection after xx seconds". I set the seconds to time the sequence like lower should start earlier and higher values start later. This is because some flows are based on values which are set by a flow that shout start earlier. Now I ran into trouble with this because:
The more the project grows the more time it needs to start on a weak system like a raspberry pi its very notable. Somehow then the injection node does not start at all or at least is not set to a valid sequence.
example:
How it should be:
Flow 1: Injection node starts 10 seconds after node red boot - > sets value for Flow 2
Flow 2: Injection node starts 11 seconds after node red boot - > sets value for Flow 3
Flow 3: Injection node starts 12 seconds after node red boot - > sets value for Flow 4
startup finished.

How it seems to be:
Flow 1: Injection node starts 10 seconds after node red boot - > Fails to sets value for Flow 2
(because project has grown and startup time increases / is skipped)
Flow 2: Injection node starts 11 seconds after node red boot - > failed because missing variable of flow 1 or using useless default value
Flow 3: Injection node starts 12 seconds after node red boot - > failed because missing variable of flow 2 or using useless default value

How I expected it be:
startup takes longer:
put all to a queue and trigger them in the sequence like I set the seconds value and start them with delay. Or maybe at least add an option for that to the injection node if this behavior is for reasons not wanted as default.

May I propose another option?

You could use just one (1) inject node ... and connect the other flows with a link out - link in sequence. This ensures that the initialization of the dependent flow runs when the predecessor has finished its doing...

1 Like

Additional remark: The timer starts ticking when Node-RED instantiates the inject node. There's no reference to the moment in time when Node-RED booted. 10 seconds sound like an enormous span - even on Pi systems. How big is you project?

The issue here could rather be that the sequence of initializing the flows might be to dense; thus it could help perhaps to increase the span between injecting into flow#1 & flow#2 to more than one second.

1 Like

danke für deine schnelle antwort :slight_smile:

my current project is not huge (I think) but that s much about the definition of huge. I would say it has about 1000 nodes (400 inactive debug maybe 400 function rest exec, some less gui stuff). I am running this on a Raspberry Pi 3A+ with only 512MB of ram. htop shows this:
image

I have a much bigger project running on the Raspberry Pi 4 with 4 GB and have to set the injection node time to about 60 seconds there.

btw node red should have a stats view to show amount of flows / nodes ...aso.

If flows must be triggered in sequence, you can use the complete node

[{"id":"c97088bddf5f31b8","type":"inject","z":"09deee63c1b960f7","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":300,"y":2520,"wires":[["4026c2c46cbf2480"]]},{"id":"4026c2c46cbf2480","type":"delay","z":"09deee63c1b960f7","name":"","pauseType":"delay","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":460,"y":2520,"wires":[["955cca5606224839"]]},{"id":"955cca5606224839","type":"change","z":"09deee63c1b960f7","name":"delaytrigger","rules":[{"t":"set","p":"triggerDelay","pt":"flow","to":"true","tot":"bool"}],"action":"","property":"","from":"","to":"","reg":false,"x":630,"y":2520,"wires":[["b13e8b0ab9436e8f"]]},{"id":"e802a8c131c36fed","type":"complete","z":"09deee63c1b960f7","name":"","scope":["a09166e79e3d80e2"],"uncaught":false,"x":290,"y":2580,"wires":[["164bf11e64b44ddf"]]},{"id":"164bf11e64b44ddf","type":"debug","z":"09deee63c1b960f7","name":"debug complete","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":480,"y":2580,"wires":[]},{"id":"b13e8b0ab9436e8f","type":"function","z":"09deee63c1b960f7","name":"function 1","func":"node.warn('function 1')\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":780,"y":2520,"wires":[["28b16a50c2c61783"]]},{"id":"28b16a50c2c61783","type":"delay","z":"09deee63c1b960f7","name":"short delay","pauseType":"delay","timeout":"2","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":930,"y":2520,"wires":[["a09166e79e3d80e2"]]},{"id":"a09166e79e3d80e2","type":"function","z":"09deee63c1b960f7","name":"function 2","func":"node.warn('function 2')\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1080,"y":2520,"wires":[[]]}]

NB! not all nodes fire the complete event so that should be checked out but most of them do.

1 Like

That sounds like a nasty torture for this tiny system. :wink:
Anyway: Whenever there's a dependency - as in the case you described - I follow the practice to model it as a (solid & reliable) dependency... especially in such scenarios with impacted predictability.

1 Like

Thx. I will test that out. :+1:

thx 4 your hints. I still have to spend a lot of work to fetch that goal I think...

Take a look at this flow. You have to change the name of the file to read in.
On my little test machine it returns this

[{"id":"bcd4bc8e5fa549df","type":"file in","z":"72e3ac42d134d33c","name":"","filename":"/home/pi/.node-red/flows.json","filenameType":"str","format":"utf8","chunk":false,"sendError":false,"encoding":"none","allProps":false,"x":300,"y":100,"wires":[["5989a3158b6f6489"]]},{"id":"5989a3158b6f6489","type":"json","z":"72e3ac42d134d33c","name":"","property":"payload","action":"","pretty":false,"x":490,"y":100,"wires":[["d3a7a822b092f32d"]]},{"id":"f492b248145e9d02","type":"inject","z":"72e3ac42d134d33c","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":100,"y":100,"wires":[["bcd4bc8e5fa549df"]]},{"id":"d3a7a822b092f32d","type":"function","z":"72e3ac42d134d33c","name":"Count element types","func":"// Count different node types from the flows file.\n// Change the definition of counts{} below to modify which element types are counted.\n// Could usefully be tweeked to count subflows, I don't use them.\nlet counts = {     // names ending with 's' are handled differently below. The rest are valid values of element.type \n    \"nodes\": 0,         \"tab\": 0,    \"inject\": 0,    \"exec\": 0,    \"function\": 0,  \"group\": 0,\n    \"links_in_out\": 0,  \"debug\": 0,  \"ui_nodes\": 0,  \"ui_tab\": 0,  \"ui_group\": 0,     \n}\n\nfor (let i in msg.payload) {\n    let e = msg.payload[i]\n    if (e.hasOwnProperty(\"x\") &&  e.type !== \"group\" && e.type != \"junction\") {  //* consider a node = an element visible on editor ('x') except group & junction \n        counts.nodes++\n    }\n    if (e.type.includes(\"ui_\") && e.type != \"ui_tab\" && e.type != \"ui_group\" && e.type != \"ui_base\") {  // ui nodes \n        counts.ui_nodes++\n    }\n    if (e.type == \"link in\" || e.type == \"link out\" || e.type == \"link call\") { // Links: in, out and call \n        counts.links_in_out ++\n    }\n    if (counts.hasOwnProperty(e.type)) {   // anything else has to be in the declaration of counts{} above.\n        counts[e.type] ++\n    }\n}\n\nmsg.payload = counts\nreturn msg","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":660,"y":100,"wires":[["f2eb9d7a2c8aa5dd"]]},{"id":"f2eb9d7a2c8aa5dd","type":"debug","z":"72e3ac42d134d33c","name":"debug 293","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":850,"y":100,"wires":[]}]

Edit: tweeked and commented the script.
If anyone who uses subflows or alternative dashboards is interested in this, you might want to consider what elements should be counted for those features and adjust it.
It won't work for anyone using Projects.

2 Likes

Humm,

I can see this leading to "my flows are bigger than yours" :slight_smile:

1 Like

Thx nice !!

Challenge accepted:
The project I am talking about (Raspi 3A+):
image

My home automation project (Raspi 4 4GB):
image

Obviously you need to write more efficient code in your function nodes :wink: :rofl: :rofl: :rofl:

All function nodes are highly optimized :rofl: :rofl: :rofl:

you can easy compare it to native assembly code

1 Like

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