Trigger & block in subflow

[zimcube]

Can I put a trigger & block node inside a subflow? My guess is each time a new message comes in, a new instance of the subflow will be created.

• What mental model should I have of a "node". Is it analogous to an instance of a class or more analogous to a singleton?
• Can I solve this inside a subflow by having a global lock on the specific door (entity_id)?
  • does this exist already as a contrib?

Context

I am running Home Assistant and have multiple (2) garage doors. When the door starts closing it emits a closing state event. The Close Door with retries subflow will retry closing the door 3 times and then give up and send me a notification to my phone.

Inside the Close Door with retries subflow, after it detects the closing has failed (door state is open) the subflow will tell Home Assistant to close the door, which then triggers the state_changed node again. That's why I have the trigger & block node before the subflow.

I am new to Node-RED and Javascript.

[zimcube]

Okay, my guess was wrong on this. I built

[{"id":"1c84d314d704e11d","type":"subflow","name":"Subflow 1","info":"","in":[{"x":180,"y":180,"wires":[{"id":"8efde020a7b4e6d5"}]}],"out":[]},{"id":"4b1dc2cbb648a042","type":"delay","z":"1c84d314d704e11d","name":"","pauseType":"delay","timeout":"1","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":600,"y":180,"wires":[["26aeeaa0eef3f90e"]]},{"id":"e9ba2383658a2116","type":"debug","z":"1c84d314d704e11d","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":610,"y":120,"wires":[]},{"id":"26aeeaa0eef3f90e","type":"change","z":"1c84d314d704e11d","name":"","rules":[{"t":"set","p":"reset","pt":"msg","to":"true","tot":"bool"}],"action":"","property":"","from":"","to":"","reg":false,"x":820,"y":180,"wires":[["8efde020a7b4e6d5"]]},{"id":"8efde020a7b4e6d5","type":"trigger","z":"1c84d314d704e11d","name":"","op1":"","op2":"0","op1type":"pay","op2type":"str","duration":"0","extend":false,"overrideDelay":false,"units":"ms","reset":"","bytopic":"topic","topic":"payload","outputs":1,"x":380,"y":180,"wires":[["4b1dc2cbb648a042","e9ba2383658a2116"]]}]

The trigger & block node handles each msg.payload and performs the way I want. This means that each node you drop is a singleton object. In hind sight this makes sense: in order for trigger & block to work it must be long lived, which means the subflow is also long lived.