WTH Single automation for multiple instances of same automation with different devices

Why in hell do I have to replicate the same automation for each and every instance of multiple object?
If I have 7 thermostats in 7 rooms with 7 windows I would like to define a single time an automation for all 7 and have differentiated parameters for each.

For example: light turn off with delay after no movement: I want to define one single automation for each room and be able to set delay from the gui with different value for each Troon and not having to define 7 identical automations with 7 replicated set of helpers

What I would like to have is just partially achieved through Blueprints. Thanks for pointing me at the features I was ignoring.

What Blueprints solve: unified point of maintenance for the automation/script code.
What Blueprints do not solve: per instance dynamic persistent configuration, via UI or programmatically, of automation parameters.

Take again the thermostat window example.

Automation to turn thermostat off when window is open for more than n seconds and temperature below m degrees and day is working.
If I want those parameters to be dynamically modifiable per instance , at run time and without regenerating the blueprint the only way to go afaik is to have 3 helpers for each of the instance of the automation.
Imagine this multiplied by parameters and instances and you start figuring out is not very practical.

So what I would like is to implement an additional feature in the Blueprints to carry “instance specific parameters”.
This could be an extra parameter in the input_helpers defining to which instance the values are related.

Imagine an

input_number 
   name: window_open_timeout
   instance: 
      - kitchen
      - leaving room
      - bedroom

All of it persistent

This would allow a granular and dynamic configuration of automations without proliferation of automation (tx to blueprints) and input_helpers (through this extra feature)

I would like finally those parameters to be modifiable by the user from the frontend (i.e. not going into settings/blueprint).

I think this would be a valuable feature for HA and taking it even nearer to commercial products that have per automation dynamic config
I hope it is now clearer what I meant

If you don’t know about them yet, Blueprints would decrease your manual maintenance burden. You’d still have to deal with 7 automations in your list, but they would all share the same parametrized Blueprint.

You can also create a script for what you want to do and pass variables to it. You would still replicate some things, but it would make life a lot easier.

See this example for my washing machine

alias: Washer services
description: Washing machine services
variables:
  washer_start_switch: switch.action_washer_start_simulated_switch
  washer_pause_switch: switch.action_washer_pause_simulated_switch
  washer_cancel_switch: switch.action_washer_cancel_simulated_switch
  washer_entity_id: switch.wasmachine
fields:
  command:
    name: command
    description: What command should be sent to the washing machine?
    example: start_cycle
    default: start_cycle
    required: true
    selector:
      select:
        options:
          - start_cycle
          - pause
          - cancel
sequence:
  - choose:
      - conditions:
          - condition: template
            value_template: '{{ command == "start_cycle" }}'
        sequence:
          - service: switch.toggle
            data: {}
            target:
              entity_id: '{{ washer_start_switch }}'
      - conditions:
          - condition: template
            value_template: '{{ command == "pause" }}'
        sequence:
          - service: switch.toggle
            data: {}
            target:
              entity_id: '{{ washer_pause_switch }}'
      - conditions:
          - condition: template
            value_template: '{{ command == "cancel" }}'
        sequence:
          - service: switch.toggle
            data: {}
            target:
              entity_id: '{{ washer_cancel_switch }}'
    default: []
  - service: logbook.log
    data:
      name: '{{ washer_entity_id }}'
      message: Sent {{ command }} to the SmartThings Washer
mode: single
icon: mdi:washing-machine

This looks like the following when you call it as service

I would actually prefer to keep multiple automations though as it makes setting specific conditions and monitoring the logbook much easier. Using scripts though you can limit the amount of things you need to replicate in each automation.

2 Likes

You don’t have to do that. It’s possible to create a single automation to handle multiple devices or, like others have suggested, use a blueprint to easily manage multiple automations.

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 :slight_smile: :grinning:

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:

2 Likes

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.

1 Like

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) :slight_smile:

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.

1 Like