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

[dvbit]

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

[Black_Fox]

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.

[ilovezigbee (Teun)]

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.

[123 (Taras)]

@dvbit

Why in hell do I have to replicate the same automation for each and every instance of multiple object?

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.

[dvbit]

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

[dvbit]

Hi @123 can you provide an example? I have done it using variables and a dictionarry but that is far from simple

[dvbit]

Almost. Please check my reply below

[dvbit]

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

[Didgeridrew]

Here’s an example I put together for another user:

https://gist.github.com/Didgeridrew/60ef67a12fa48c170334d33b9ab234f0

[123 (Taras)]

An example of consolidating multiple automations?

Evolution of an automation. Turn a light on/off at sunset/sunrise

A brief tutorial demonstrating how to create a single automation to control a light that is able to handle missed events (i.e. Home Assistant is off when the primary trigger(s) occur). Implemented as two automations:

Turn on a light just before sunset

- alias: 'Scheduled Exterior On' trigger: - platform: numeric_state entity_id: sun.sun attribute: elevation below: 1.8 action: - service: light.turn_on target: entity_id: light.exterior

Turn off a light just b…

Help with Automations - Consolidation

Try this instead: - alias: Disable Sonos Alarm trigger: - platform: state entity_id: input_boolean.alarm_clock_six to: 'off' id: six_am - platform: state entity_id: input_boolean.alarm_clock_eight to: 'off' id: eight_am action: - service: sonos.update_alarm data: entity_id: media_player.bedroom_sonos alarm_id: > {% if trigger.id == "six_am" %} 1129 {% else %} 1233 {% endif %} enabled: false

Best approach for creating automations?

There’s no need for it to ‘wait until’. alias: example trigger: - id: 'off' platform: sun event: sunrise - id: 'on' platform: sun event: sunset condition: [] action: - service: 'switch.turn_{{ trigger.id }}' target: entity_id: switch.whatever

Tea timer with flashing lights

If you’re interested, here’s one way to consolidate the two automations. - alias: "Timerstop_tea" id: "Timerstop_tea" trigger: - id: 'lawngreen' platform: event event_type: timer.finished event_data: entity_id: timer.green_tea - id: 'blue' platform: event event_type: timer.finished event_data: entity_id: timer.earl_grey_tea action: - service: light.turn_on target: entity_id: light.hue_iris data: br…

Time based climate automation (weekdays/weekend)

As promised, here’s the revised version. It’s more compact than the previous version I posted and can handle a scheduled hour that’s common to both the weekday and weekend schedules. alias: example description: '' trigger: - id: 'schedule' platform: time at: - '06:00' - '08:00' - '15:00' - '20:00' - '21:00' - '22:00' - id: 'override' platform: state entity_id: binary_sensor.tuer_balkon_onoff to: 'off' for: '00:01:00' - id: 'disab…

[petro]

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.

@dvbit

What happens when the blueprint changes?

you reload the automations

@dvbit

Is it possoble to use single dynamic values (not replicated) for the inputs with blueprints

You’ll have to clarify on what you mean here.

[EdwardTFN (Edward Firmo)]

@dvbit

They replicate the automation n times.

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).

@dvbit

What happens when the blueprint changes?

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).

@dvbit

Is it possoble to use single dynamic values (not replicated) for the inputs with blueprints

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.

[dvbit]

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.

[petro]

You can do whatever you dream of if you utilize templates in the blueprint

[dvbit]

@dvbit

Is it possoble to use single dynamic values (not replicated) for the inputs with blueprints

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?

[dvbit]

Sorry Petro, for sure I was not clear again, but this is not an answer (and may be my question, again, was not clear)

[dvbit]

Thanks this is a great piece of code to avoid redundancy of automations
Much appreciated

[dvbit]

This code is simply brilliant

[petro]

Yes, you can do it, but it’ll require templates

[EdwardTFN (Edward Firmo)]

@dvbit

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?

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.