I think i was not clear enough.
I want one single point of maintenance : i.e. i modify one piece of code not 7.
Nor redeploy and reconfigure (statically) 7 times.
Scripts as stated get near to that.
They miss the dunamic config without multiplying helpers aspect.
If i have a script with 4 params and 7 instances of the script actuation i need to handle 7x4 input helpers where it would make much more sense to handle 4 plus 1 extra parameter specifying the instance.
Hope i am more clear now 
Hi @123 can you provide an example? I have done it using variables and a dictionarry but that is far from simple
Almost. Please check my reply below
I know blueprints.
They replicate the automation n times.
What happens when the blueprint changes?
Is it possoble to use single dynamic values (not replicated) for the inputs with blueprints
Here’s an example I put together for another user:
An example of consolidating multiple automations?
That’s what blueprints are for though. It’s a single point of maintenance, you just need to reload the automations that feed from the blueprints if I recall correctly.
you reload the automations
You’ll have to clarify on what you mean here.
No! You will need n entires on the automation list, but each entry will be just a call to the Blueprint file, and it’s parameters (inputs).
All your automation based on that Blueprint will use the new code as soon you reload automation on Developer tools (just 1 click and it refreshes the code for all the entries using that Blueprint).
Each automation entry is totally independent from each other, so inputs used in one automation are not used by other automation with the same blueprint, and if you have local variables in your blueprints those are isolated between the different automation entries using that Blueprint.
It’s exactly the same than copying a normal automation n times, but with the advantage of having just one single point for editing the code.
I did not know that a modification of the blueprint would be replicated automatically on the blueprint instances!
Is it possoble to use single dynamic values (not replicated) for the inputs with blueprints:
What I mean is the following:
Suppose I have a blueprint playing a notification if a window is open for more then n seconds on an echo.
And that I want the n and the echo to be specific, different and dynamically modifiable for each window,
I would like those parameters to be changeable via UI or programmatically.
To do this I would need 1 input_number for the n seconds and 1 input_select for the echo .And I would need One for each window.
I would like to be able instead of creating number of windows X 2 helpers just, 2 helpers + 1 extra parameter specifying to which window the helpers are referred.
You can do whatever you dream of if you utilize templates in the blueprint
Each automation entry is totally independent from each other, so inputs used in one automation are not used by other automation with the same blueprint, and if you have local variables in your blueprints those are isolated between the different automation entries using that Blueprint.
It’s exactly the same than copying a normal automation n times, but with the advantage of having just one single point for editing the code.
Almost there with blueprints…
Just a last bit:
Suppose I have a blueprint that emits a notification after a window is open for n seconds.
Where the “n” value is taken is a parameter of the blueprint specifying an input_helper.
In order to have a different “n” value source for each of the windows (i.e. to have a per window dynamically modifiable input) I would need to specify n different input_helpers.
Correct?
Sorry Petro, for sure I was not clear again, but this is not an answer (and may be my question, again, was not clear)
Thanks this is a great piece of code to avoid redundancy of automations
Much appreciated
This code is simply brilliant
Yes, you can do it, but it’ll require templates
There are multiple ways of implementing this “is open for n seconds”. If you choose to use Helpers, then you are right, you will nead one helper per instance of the Blueprint used in your automations. There is other WTH asking for a way to create the input dynamically, but this is not available yet.
But you have multiple ways and in your trigger for a state you can have this “for n seconds” without using inputs.
Got it . I think you mean deriving the input_helper name using templates
Thanks for the link I appreciate his style will look it
So finally, with the week end,I have time to write a more accurate description.
Blueprints are just a partial solution.
Please look at the updated top post