I get that subflows are a kind of Macro of a group of nodes.
They are limited to one input and I am not exactly sure about outputs. (But I'll look into that.)
So, I have a group of nodes which is repeated in multiple places in the flow.
Ideally this is where a subflow is handy, because if there is a problem with the code/functionality, you only have to change one, and that propagates to the rest.
Easy Peasy
Where I am getting stuck is that although I have a lot of duplicated stuff which in ways would be terrific to do this with, there are a lot of variables which are not the same.
In my set up these variables are variables set for that specific part/machine/thing.
So I have 10 machines, the function is repeated ten times (one for each machine) and can't be "macro'd" because the machine name is different in each.
I am starting to see how to get around this, but just want to ask, to help clear the confusion.
The one input is a sticking point for me.
I'll stop here because, for reasons unknown, the fog is actually thickening just now.
Hi,
I would stop calling it macro, subflows should be seen as a group of node that do a defined set of functionality. If these function-set are common to many machine they are good candidate to be reused and go in sub-flows as you said.
Variables can have Context scopes, they can be context, flow or global visibility.
Using your example I would put in different flow each machine with custom flow-variable and put there the subflow that read the flow variables
what part are you confused about?
The suggestion to use flow variable to "customize" you subflow execution should solve your problem. Otherwise you can pass it as input.
I forgot to add that although the input node can only be one, it can be an array of different objects. You can use the join and split nodes for that.
Here is a very small part of how big my flows are:
You can see there is a lot f duplication. BUT Rationalising that to "sub flows" - at this point in time - is beyond me.
Thus my asking.
I shall have to look at the structures and how the variables set.
Most of this is/was built as needed. (On the fly, if you will.)
As I got more RPIs I had to add another iteration of the code for the new machine.
It is just getting difficult to do updates and if I find a bug (well, between finding them) it is painful beyond belief that I have to edit so many nodes.
And so that could give rise to more bugs.
The easiest current approach would be to add the variables to your input msg's before calling the sub-flow. You can put a change node immediately before calling the sub-flow to add a new property to the msg with the data the sub-flow needs.
Alternatively, if the variable is independent of calling (e.g. a day/night variable), then use a global variable instead.
The easiest way to find out how sublows can benefit you is to simply start. Start with a small repeatable block and create a subflow of that small piece of code. Then replace your original code with the subflow and take it from there. It's all a lot easier and more straightforward then it sounds.
