WTH can't we snooze automations

There are many ways to do this yourself using automations. A simple way is to create a timer helper and add a condition to your automation that the timer must not be running. Then you can start the timer for the tome you want to snooze. And you can still use the automation disable for normal disabling.

I do actually have that built for a few automations. But it is manual and requires front end work for each automation. I have 58 automations. I, for one, would vastly prefer if it were just part of the main system.

Wouldn’t that amount to just a single Input Boolean per automation?

The automation triggers at 06:00, confirms its associated Input Boolean is on then proceeds to execute its actions. If it’s off, it simply ends without executing actions.

A separate automation manages the Input Boolean(s), turning it/them back off after a predetermined period of time.

It’s so trivial to implement (and customize) that it makes it unlikely be created as a dedicated feature.

Well, mine require more than a single input boolean. You at least need another input for the time to snooze, unless you want them all to snooze for the same period, which seems suboptimal. Yes, it is simple, but but having to do it for 57 separate automations just seems unnecessarily repetitive Would be better for me if this were just a part of the UI. And seems like a really simple thing to add.

In over six years of participating in this forum, this is the first time I ever heard anyone need to snooze dozens of automations. It’s such an “outlier” requirement that the odds are low for implementation.

Are you familiar with software development for Home Assistant?

  • If yes, you can submit a PR to the Core repo. You may first need to submit the idea in the Architecture repo because it alters the way automations currently work.

  • If no, then what metric was used to judge the relative ease of implementation?

1 Like

I think you should be able to achieve this with a single script with two fields, one for selecting the automation, one for time (assuming you even want the time to be customizable). Though maybe in practice it would be better to have one script per automation, easier to use them.

I haven’t tried doing this exactly, but I’m using it for turning a device on and then off after a customizable delay. No need to create helpers.

This could probably be made to incorporate the use of the local calendar making it possible to easily get an overview of snoozed automations.

Using the Calendar triggers Automation Trigger - Home Assistant it should then be fairly easy to disable/enable the automation again.

I fully respect your view that it would be easy to work around. All I can say as that an end user, I would really appreciate the ability to snooze automations directly from the UI.

I think it’s still somewhat of a niche thing to interact with the an automation in this way, but if you just want to toggle it on and off you can simple do this.

I do wish some more high quality blueprints where included with home assistant from start where they would be easily searchable. Then things like this could be more easily be supported.

You can also use entities card for multiple automations. I do that for some and it works nicely.

But yeah, even though there are some workarounds, I agree it would be nice to have such option built in, so I added my vote.

What???
You have 57 automation just for your shades?
Well… there’s your problem!

You could probably do that in just a few.

That would be quite a few shades. No, I have 57 different automations, some part I’ve wanted to snooze for various reasons. But shades in multiple rooms is one set (ie, want to snooze the guest room but not the kids rooms or vice versa). I have a motion sensor in the back yard which turns on the lights but want to snooze when my son is using his telescope. Or alert automations when something goes offline but I want to snooze while the electrician is working. Etc, etc. There have been many many times when I have asked WTH there isn’t a snooze function….

I understand it’s not a problem for everyone. That’s ok. It’s a problem for me. There seem to be more than my upvote here. It’s not an unsolvable problem, but it’s an annoyance for me and seems at least a few others.

I think the easiest way would be to disable the automation.
Then set up an automation that triggers on any automation being disabled for 1 hour and enables it again.
I would probably add that if the name of the automation starts with “Disabled” then it should not enable the automation.

This means you need to rename the automation if you want it permanently off.

I have this script to turn on whatever entity in a specified time:

alias: Turn on within
icon: mdi:location-enter
mode: parallel
sequence:
  - delay: "{{timeField}}"
  - target:
      entity_id: "{{entityField}}"
    data: {}
    action: homeassistant.turn_on
  - target:
      entity_id: "{{entityField}}"
    data: {}
    action: switch.turn_on
  - target:
      entity_id: "{{entityField}}"
    data: {}
    action: light.turn_on
  - target:
      entity_id: "{{entityField}}"
    data: {}
    action: script.turn_on
  - target:
      entity_id: "{{entityField}}"
    data: {}
    action: scene.turn_on
  - target:
      entity_id: "{{entityField}}"
    data: {}
    action: input_boolean.turn_on
  - metadata: {}
    data: {}
    target:
      entity_id: "{{entityField}}"
    action: cover.open_cover
  - metadata: {}
    data: {}
    target:
      entity_id: "{{entityField}}"
    action: timer.start
fields:
  entityField:
    selector:
      entity:
        multiple: true
    name: Entity
    required: true
  timeField:
    selector:
      time: {}
    name: Turn on in
    required: true
    description: Set time to wait before turn on entities.

It looks like this in UI, you can select as many entities as you want:

I have a similar one to turn off entities.

You can build this your own. Have an automation triggered on the automation state off for a certain amount of time and have it toggled.

Here’s what I use:

alias: Time based state restore
description: …
mode: queued
triggers:
  - entity_id:
      - automation.example01
      - automation.example02
    to: "off"
    for:
      hours: 0
      minutes: 30
      seconds: 0
    variables:
      trigger_service_call: automation.toggle
    trigger: state
  - entity_id:
      - automation.example03
      - automation.example04
    to: "off"
    for:
      hours: 1
      minutes: 0
      seconds: 0
    variables:
      trigger_service_call: automation.toggle
    trigger: state
  - entity_id:
      - input_boolean.motion_detect
    to: "off"
    for:
      hours: 1
      minutes: 0
      seconds: 0
    variables:
      trigger_service_call: input_boolean.turn_on
    trigger: state
conditions: []
actions:
  - data: {}
    target:
      entity_id: "{{ trigger.entity_id }}"
    action: "{{ trigger_service_call }}"

Having that said, another solution is to use a helper that toggles at a certain moment and have that helper in the conditions of your shade automations.

Thanks! I see lots of ways to program this, all of which require upkeep, maintenance and programming.

I also had my pages arranged in sections before the section view was available. The section view just makes it so so much easier to maintain and change.

It’s the same for snoozing. Just because you can find work arounds doesn’t mean that adding it to the core isn’t a good thing. If it isn’t for you, I understand and salute you. It would be great for me, and seemingly a few others here.

Generally speaking, if a desired ability can be achieved using existing, built-in capabilities, it rarely ever becomes a built-in feature. Odds are better if the desired ability cannot be replicated via existing means.

If you peruse the Feature Request section, you’ll find that the ones that can already be achieved remain unfulfilled for a long time.

FWIW, if you want to minimize maintenance, I suggest you consider creating a Blueprint for your dozens of automations. Alternatively, consider consolidating them (the ones that are nearly identical).

1 Like

The trigger in the code that Recte posted can be a template that will include all automations

This one is very similar to:

Except in this case, it is about turning off the automation for X time, while the linked one above is for turning off stuff for X time.

I know it’s not built-in, and it is a bit of a pain to set up (and maintain, I know I know), but recently I’ve started building some automations that notify me and give me an action I can run to pause them.
You could do this to pre-empt running too by sending the notificaiton some time before the actual automation would run.

So I have a datetime helper for named “Ignore X Until” (were X is like, “Front door”, “washing machine”, etc).
Right now I mostly do 1 hour, but I have some that push longer - for example changing the filter in the furnace when I have an action that is “I changed it”, which pushes it ahead IDK 2 months or something, so that automation doesn’t run again until then.

In the automation I have a condition like this to check the datetime condtion:

condition: template
value_template: >
  {{ now() > states.input_datetime.ignore_front_door_until.attributes.timestamp |
  as_datetime }}
alias: Check if we should be ignoring right now

The notification with the action looks like this:

action: notify.mobile_app_jon_iphone
metadata: {}
data:
  message: >-
    Front Door is {{ states('sensor.front_door') }}
  data:
    actions:
      - action: IGNORE-FRONT-DOOR-1H
        title: Ignore 1 hour

And the final piece is the automation that handles the mobile action:

alias: " Mobile App Actionable Notification Handler"
description: ""
triggers:
  - event_type: mobile_app_notification_action
    event_data:
      action: IGNORE-FRONT-DOOR-1H
    id: IGNORE-FRONT-DOOR-1H
    trigger: event
conditions: []
actions:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - IGNORE-FRONT-DOOR-1H
        sequence:
          - metadata: {}
            data: {}
            target:
              entity_id: input_datetime.ignore_front_door_until
            data_template:
              datetime: >-
                {{ (now() + timedelta(minutes=60)).strftime('%Y-%m-%d %H:%M:%S')
                }}
            action: input_datetime.set_datetime
mode: single