Apologies for what may be an obvious question - just need to double-check my understanding.
Q: Does automation mode single apply to the automation, or to the automation per trigger?
Context:
I’m refactoring some automations at the moment and have a rewritten automation triggered by a state change, and with the following key characteristics:
single trigger entity_id
mode: single
use of a wait_for_template (this is a key element)
I could in theory use the same automation to replicate the functionality for multiple trigger entities (with some minor variable templating). These entities could trigger at the same time / within the same time window, so if automation mode single applies at the automation level, rather than automation + trigger level, then I will have to replicate the code per trigger entity (although
(I suppose an alternative could be to convert the automation to a blueprint)
Single–> Run a single instance of the automation, no new runs are allowed while the previous is running,
Restart → Abort the previously running automation and restart it.
Queued → Wait with the next run until the previous run has finished.
Parallel → Run multiple instances of the automation simultaneously (parallel).
This applies to the automation itself, not to the triggers within.
Thanks for the link - I did actually check the docs before posting, however for a rather tired me they left a question over whether the single run might be restricted to automation + trigger. Hence the apology in my OP.
It would be great to have single mode + trigger as an option. That would reduce amount of automations that I duplicate where trigger is the only thing different. I also use wait in action part.
I mean single mode that will be based on automation and trigger. Now if I have 2 triggers and one of them fires the automation. Then under actions I have wait template that is preventing automation to complete because of some condition. Then if second trigger fires the automation, it will not be actually run because the first one is not finished.
So I would like to have single mode, that is perfectly fine, but if single mode can take into account which trigger is executed, and if the same trigger is executed again while the first one is running, block it. Now it is blocking entire automation regardless what trigger is fired.
Here is my automation:
alias: "Notify: Temperature in Attic and Basement too low"
description: Not supporting multiple trigger entities.
trigger:
- type: temperature
platform: device
device_id: 03278deac1cd9391c7659fda6c7c9789
entity_id: sensor.temperature_3
domain: sensor
below: 15.5
for:
hours: 0
minutes: 2
seconds: 0
- type: temperature
platform: device
device_id: 4d38dbf9c86ac992983b8ffdea97c9b9
entity_id: 3984875c3ae775bcbbec7237688e89ee
domain: sensor
below: 15.5
for:
hours: 0
minutes: 2
seconds: 0
condition: []
action:
- service: notify.mobile_app_alan_s22
data:
message: >
Temperature for {{ trigger.to_state.attributes.friendly_name }} is at {{
trigger.to_state.state }} {{
trigger.to_state.attributes.unit_of_measurement }}.
title: Temperature is too low
data:
tag: temperature_low_{{ trigger.entity_id }}
group: Temperature low
channel: Temperature sensor
notification_icon: mdi:snowflake-thermometer
color: "#179FE7"
ttl: 0
priority: high
- service: notify.persistent_notification
data:
title: Temperature is too low
message: >-
Temperature for {{ trigger.to_state.attributes.friendly_name }} is at {{
trigger.to_state.state }} {{
trigger.to_state.attributes.unit_of_measurement }}.
- alias: Wait until value back to normal for 15 minutes (900 seconds).
wait_template: >-
{{ (states(trigger.entity_id) | float > trigger.below) and
(as_timestamp(now()) -
as_timestamp(states[trigger.entity_id].last_changed) >= 15*60) }}
enabled: false
- repeat:
while:
- condition: template
value_template: "{{ states(trigger.entity_id) | float <= trigger.below }}"
sequence:
- alias: Wait until value back to normal
delay:
hours: 0
minutes: 10
seconds: 0
milliseconds: 0
mode: single
Because that’s the very definition of single mode.
The mode of operation you described isn’t any of the four available modes (single, restart, parallel, queued) but a hybrid of single and restart. In other words, operate like single if it’s the same trigger triggering and behave like restart if it’s a different trigger. Feel free to submit a Feature Request.
I resume this old post because I’m facing strange behaviour on a Single Mode automation. Complex automation fired by 3 triggers.
The automation is fired by trigger 1 that execute some action and than enter in a wait_template till a sensor stay with value “charging” for 30 second
Automation trigger 2 is also fired when the same sensor stay in “charging” for 30 second (for: )
My expectation was the automation triggered only once, because when trigger 2 become true, automation is already running, fired by trigger 1. This is not, even if the automation is running, trigger 2 fire a new instance (i see it in the traces). Instance fired by trigger 2 stop immediatelly because a condition I included check if the automation is already running.
What’s the behaviour without the condition? Is instance 2 stopped before starting to perform the actions or there is something wrong managing the single mode?
Edit: If I differentiate the number of seconds between wait_template (I set 15) and the “for” on trigger 2 (30 sec), the instance of the automation is not triggered by trigger 2 event after the 30 sec.
Looks definetivelly something wrong in the management of the Single mode
As you are not including any code, it is impossible to say if there is an issue in your automation logic or a possible bug in automation execution/triggering.
Here the code.
If 30 sec. are set on the trigger # 3 and on the wait_template (both marked wit <<<<<<<<) the Automation is fired twice. Setting 15 on the wait_template the Automation is fired only once
- id: energia_consumo_gestione_carichi_carichino_bilanciamento_potenza
alias: Energia Consumi - Gestione Carichi - Carichino Bilanciamento Automatico
description: Automazione per gestire la potenza del carichino in base ai consumi dell'abitazione
mode: single
triggers:
# Scheduled start
- trigger: time
at: input_datetime.energia_consumo_carichino_ora_ricarica
# Immediate start
- trigger: state
entity_id: input_boolean.energia_consumo_carichino_ricarica_immediata
to: "on"
# Start if the charge started manually
- trigger: state
entity_id: sensor.carichino_status
to: charging
for: "00:00:30" <<<<<<<<<<<<<<
conditions:
- condition: template
value_template: >-
{{ (is_state('sensor.carichino_status', 'charging') and not is_state('sensor.energia_consumo_carichino_automations_variables', 'Running'))
or is_state('sensor.carichino_status', 'charged')
or is_state('sensor.carichino_status', 'waiting') }}
actions:
- alias: "Wait for real charging. On for at least 30 sec."
repeat:
until: "{{ state_attr(variabili, 'charging_wait') == true }}"
sequence:
# Attende che il carichino sia in carica per almeno n sec per evitare falsi avvii
- wait_template: "{{is_state('sensor.carichino_status', 'charging')}}"
alias: "Wait for status 'charging'"
timeout:
minutes: 120
- if: "{{ not wait.completed }}"
alias: "If not 'charging after 120 min Abort"
then:
- action: variable.update_sensor
alias: "Abort script"
target:
entity_id: "{{ variabili }}"
data:
attributes:
charging_stop: true
charging_wait: true
else:
- wait_template: "{{not is_state('sensor.carichino_status', 'charging')}}"
alias: "Check it stay 'charging' for 30 sec"
timeout:
seconds: "30" <<<<<<<<<<<<<
- if: "{{ not wait.completed }}"
alias: "if charging for 30 sec, continue the automation, else stay in the wwaiting loop"
then:
- action: variable.update_sensor
alias: "Ferma loop di attesa charging"
target:
entity_id: "{{ variabili }}"
data:
attributes:
charging_wait: true
## SOME OTHER CODES ##