Yes, I am not keeping up with the latest developments, but I am messing around with someone else's flow that uses a sub-flow and am seeing something I have not seem before.
I don't know I have ever clicked on a sub-flow's node in the edit screen.
So I can't say.
But now (NR 1.0.3) I get a nice little list of things like this:
I sort of like it.
But (dumb question) are those variables going into or coming from the sub-flow?
I'm guessing into.
So in the sub-flow they will be: env.get("TimerNumber") (etc)
Ok.
Dumb-er question:
Why are the fields (shown)
limited to:
$env is a bit recursive - I feel.
Anyway, why can't msg.xxxxx be used?
To me that would be page 1 of what you want to send to a sub-flow.
You really have to look at subflows like they are nodes by now. You are correct in this is where you set the environment variables for this instance of a subflow. Those environment variables are static once deployed so you cant set them from within the subflow but only get the values put into the config screen. When you create a subflow you can actually choose which property if at all to put next to the input field:
Those environment variables are very useful for many things. For example imagine you build a subflow to communicate with a rest api over http requests. You could build a subflow that has an input field for the device that you want to request information for or the town you want to get the weather from. Than you could use that input to build the url in a function node in the subflow pass it to the http request and parse the json response and from the outside it looks like an actual node that for the weather example gives you the weather for the configured town.
So id recommend looking at subflows as quite a mighty tool that in many cases can actually substitute the need to build custom nodes. Have a look for example at this time range switch i build a while back. It has all the features of a node: an ui, status on the node, multiple outputs.
So definitely look more into them as they are an awesome feature of node-red.
I forgot that you can send msg...... to the sub-flow anyway.
This person wrote a sub-flow (actually he didn't. It was one node which did context tricks) that allowed multiple instances of the outer flow.
But he/they got caught by the trap that the code in a lot of the nodes was fixed to the first instance. So subsequent copies would not work.
The parameters were sent to the sub-flow via the afore mentioned method - which kind of makes sense - but caught them out with comms back to the higher level nodes.
Thanks @JGKK. I'm learning.
(That's the name of the game - yeah?)
