WTH there is no RUN condition in automations ( run once or multiple times)

Archive Month of "What the heck?!" 2022
1

Many of my automations are required to run either once or multiple times per day when the trigger device is triggered. Examples of automations that run once can be:

  • Turn of the lights when the bed sensor is activated.
  • Send a notification when the temperature is above or below a certain level.

In the above examples, you don’t want to turn the lights off again if while sleeping the bed sensor opens and closes again. Also if the temperature is above a certain level, you will get a notification every time the sensor updates.

Currently you can create a boolean and set it’s state as condition but this creates additional entities and make the logs heavier.

My suggestion is to create a Run condition with multiple options:

  • Run once
  • Run every time the trigger is triggered
  • Ask before running

In the " Run once" option you can set various sub options such as: per day, per month, per year and specify the date and time.

In the “ask before running” you can set up a phone that an actionable notification will be sent and if confirmed the actions will run.

I am aware that all this is possible today but with either more than one automations or with the use of helpers.

My suggestion would make things easier during automation building and you wouldn’t need to exit the automation to create a helper that you need.

Thanks for considering this idea!

2

I like the run after approval option

3

I’d support an easier way to throttle automations, but I don’t see how setting an “Ask before running” mode, then setting up an actionable notification is going to be easier than just setting up an actionable notification…

2 Likes
4

Throttling options seem handy. That being said, you don’t actually need another entity for any of these. Just add a condition to the automation that looks at last_triggered

Only once per day:

condition: "{{ this.last_triggered.date() != now().date() }}"

Only once per month:

condition: "{{ this.last_triggered.month != now().month }}"

Only once per year:

condition: "{{ this.last_triggered.year != now().year }}"

On specific date and time is kind of an odd one as a throttle, seems more like a trigger? But sure why not, we’ll throttle it to only run on a specific date:

condition: "{{ now().date() != as_datetime('2022-10-12').date() }}"

Or in between two specific times without a schedule (since you want no helpers):

condition: >
  {{ as_datetime('2022-10-12 19:00:00') | as_local < now() 
    and now() < as_datetime('2022-10-12 21:00:00') | as_local }}

Fwiw if you did want a trigger, these two templates work for that too. First one will trigger once on that day. Second will trigger once in the date range specified.

I mean not everyone uses the companion app. Making core features that require it is probably something to avoid. So you’d want this to have flexibility in how it asks for confirmation and receives the response. Which will be hugely complex and probably isn’t different then just writing hte automation

I feel like this bit is in reference to the “ask before running”, seeming to imply that you need more then one automation to do that? You don’t, you can just have multiple triggers and a choose like so:

alias: My confirming automation
trigger:
  - id: real_trigger
    ....
  - id: confirmed
    platform: event
    event_type: mobile_app_notification_action
    event_data:
      action: confirmed
action:
  choose:
    alias: Request confirmed, allowed to run
    conditions: "{{ trigger.id == 'confirmed' }}"
    sequence:
        ... Steps to do now that request has been confirmed  ...
  default:
    service: notify.mobile_app_phone
    data:
      title: Confirm automation run
      message: "Is {{ this.attributes.friendly_name }} allowed to run?"
      data:
        actions:
          - action: confirmed
            title: 'Yes'

I used mobile app because you said that was what you wanted. But someone using telegram or something then just change the confirmed trigger based on how they respond to those messages. Maybe they send a link to a webhook? idk, whatever works for them.

EDIT: Also, last tip:

Not if you use a numeric state trigger. If you use a state trigger with a condition then sure, that’s what will happen. But a numeric state trigger only triggers once when the value trips its threshold (or is in range if you’re using both above and below). It then won’t trigger again until the value is outside its threshold/range and then trips it again.

7 Likes
5

Wow, thanks for the tips, I was not aware that it was possible as I am not into yaml so much and this year there is a trend to minimize it’s usage as much as possible.

The way I do it now is that a set a helper and one automation to control its state. For example, if we are speaking for the bed sensor, I have a helper called bed actions… All day it’s off and in the evening a timed automation is turning it on. Then I have the actual automation that turns the lights off when I go to bed and when this runs it also sets the helper state to off so it won’t repeat.

Long story short, in order to do what I want I used, one helper and 2 automations. That’s what I was trying to avoid.

Regarding the date, it’s used not so much in the once per day but in the once per month where you need to specify in which day of the month the automation will run.

Also, I have an automation to alert me for aquarium temperature increase. It triggers every minute as the temperature reaches its value and stays there for hours… Maybe my logic is wrong but I will look into it.

Your tips are great and thank you very much.

6

Well, again, as CentralCommand mentioned above it is possible to be done within one automation but before he shares his knowledge, i was doing the actual notifications using 2 automations.

The first Automation sends the notification and set’s the options:

service: notify.mobile_app_michael
data:
  data:
    actions:
      - action: cinema
        title: Activate
      - action: null
        title: Do Not Activate
  title: Cinema Mode activation
  message: Would you like to activate Cinema Mode?

The second automation’s trigger waits to receive the response of the above options:

platform: event
event_type: mobile_app_notification_action
context: {}
event_data:
  action: cinema

The idea here was, that all of this would happen in the background. So when you select “Ask Before Running” you would have to set the options like:

Do you want to activate the Cinema Mode?
Option 1: Yes, Option 2: No

Then home assistant would in the background assign an ID for each one of the options and wait when this specific ID is received before continuing with the actions. This is complex to build i understand. There are many things to consider such as a reload of the automations.yaml a restart of HA. These listening to events should survive all this.

7

Hello CentralCommand,

One question please to the above solution you propose: You mentioned that you don’t need multiple automations to trigger the actionable notifications and you typed this code:

alias: My confirming automation
trigger:
  - id: real_trigger
    ....
  - id: confirmed
    platform: event
    event_type: mobile_app_notification_action
    event_data:
      action: confirmed
action:
  choose:
    alias: Request confirmed, allowed to run
    conditions: "{{ trigger.id == 'confirmed' }}"
    sequence:
        ... Steps to do now that request has been confirmed  ...
  default:
    service: notify.mobile_app_phone
    data:
      title: Confirm automation run
      message: "Is {{ this.attributes.friendly_name }} allowed to run?"
      data:
        actions:
          - action: confirmed
            title: 'Yes'

Since there are 2 triggers, you cannot assign further conditions per trigger right?

For example, i have an automation that activates the Cinema mode in my home. I use Plex and the logic is:

If (trigger) Plex (on my androidTV box) starts playing (Condition) after 20:30, then (action) send a notification on my phone to ask if the cinema mode should be activated. I use the notification because not everyone likes to watch movies in the dark. :slight_smile:

Then i have another automation that as trigger have the response from the above (if i choose to activate the cinema mode) and if yes, it turns off all the lights and activates my hyperion instance.

How is this solution different from what i do so far? You still need an automation to send the notification and an automation that receives the confirmation (like the one you proposed). Did i not get it right?

The main idea i submitted with the “Ask Before Running” intends to have the notification sending and waiting for the event in one automation. Like:

Trigger: Plex is playing

Condition one: after 20:30
Condition 2: Ask before running:
a) Entity ID: set the mobile phone that has the companion app
b) Message: Do you want to activate the cinema mode?
c) Option 1: Yes (this is the title)
d) Option 2: No (this is again the title)

Pause and listen for either positive or negative event from the companion app:

If positive event is received continue with the actions
If negative (or no response) event is received, then stop the automation

Thanks

8

Your proposed example follows the format of the main actionable notification example in the companion app docs almost exactly…

9

Sure you can. Just need an or:

condition:
  or:
    - "{{ trigger.id == 'confirmed' }}
    - ... Conditions that apply only to real_trigger...

If you do something like this then the condition always passes immediately if the that automation was triggered by the confirmed trigger. But if it was triggered by some other trigger then further conditions are applied.

Or forget the condition and just do it in the choose steps:

alias: My confirming automation
trigger:
  - id: real_trigger
    ....
  - id: confirmed
    platform: event
    event_type: mobile_app_notification_action
    event_data:
      action: confirmed
action:
  choose:
    - alias: Request confirmed, allowed to run
      conditions: "{{ trigger.id == 'confirmed' }}"
      sequence:
          ... Steps to do now that request has been confirmed  ...
    - alias: send confirmation notification?
      conditions: 
        ... Stuff to check before sending confirmation ...
      sequence:
        service: notify.mobile_app_phone
        data:
          title: Confirm automation run
          message: "Is {{ this.attributes.friendly_name }} allowed to run?"
          data:
            actions:
              - action: confirmed
                title: 'Yes'

Same trick really. If it’s the confirmed trigger then it goes down the first choose path every time. If not then it checks more stuff before deciding whether to send the confirmation notification in the first place. If it doesn’t pass those checks then the automation just ends without doing anything.

You can basically always combine automations. Just need trigger IDs and or conditionals or chooses.

1 Like
10

One caveat, any condition based on last_triggered will not work on brand new automations i.e. automations that have not triggered previously. For those you need to provide a default that will allow the template to render true.

Only once per day with default:

condition: >
  {{ (this.last_triggered | default(now() - timedelta(days=1), 1)).date 
  != now().date() }}
1 Like
11

Good catch! I would probably do this though:

condition: >
  {{ (this.last_triggered | default(as_datetime(0))).date != now().date() }}

That way you don’t have to tweak the timedelta based on your throttling period. Unless you want an automation that runs once every century the epoch is going to be outside the throttle period :laughing:

4 Likes
12

You guys are great at templating :slight_smile: maybe for you this idea might not be so useful. For the rest, an option in the GUI is helpful. Maybe the implementation can be different than my proposal, but i think we all get the idea!

13

Having some more friendly option than a template condition available does seem entirely reasonable.
The template talk is basically an option for doing it right now since the requested feature does not exist.

Nobody is denying that this is an entirely reasonable feature that should not need templates.

5 Likes
14

And here I was adding a simple time delay to the end of automations to prevent them from running more frequently than desired… Thanks for the suggestions.

15

Did it work for you? I believe that if you add time delay, the automation doesn’t complete until the time will pass… In case of a restart the automation will run again upon trigger…

16

Yes that is correct. Restarting home assistant will negate the desired reduction of run frequency. The templated conditions solution is superior.

I only have a few implemented throughout my setup, mostly inconsequential and short in duration, if there was a reboot.

17

Then use the above templates until hopefully we will have an easier way in the UI to select when an automation runs regardless of how many times the trigger, triggers…

Because of this thread, I changed the way I do automations thanks to the guys that provided the templates. While I still believe that we need something easier and to be honest I was expecting more votes, it will work for now…

3 Likes