Schedule simple action after time period in the UI

Often times I’d like home assistant to execute some simple action like turning off a switch or activating a scene after some time period from now. For example, turn off light in 30 minutes. Turn on that fan in 4 hours. Activate scene “turn off everything” in 1.5 hours - something like sleep timer.

I know it is possible to do via automation, and I’ve done that for couple of my switches so far by creating an input slider to choose time period. But that is too complicated (requires 3 automation rules for every slider/switch) and must be tailored for every single switch.

It would be great, if HA can support this functionality for any switch or scene. That’s how I envision that in the UI. When switch/scene clicked, default action should remain turn on/off or activate. But when right-clicked or long-clicked (or somehow else) a popup window appears allowing me to choose action and a time period. After I set this and close popup, the switch should visually indicate that action is scheduled. Can right/long click again and see that action.

Anything like this possible? Or if not a nice UI, maybe there is simpler way to do this in general case without creating 3 automation rules for every single switch/scene?

If I read correctly, your request is quite similar to mine:

Sadly I have no competence to work on it by myself…

With version 0.57 there is the new timer component. In this release it won’t have the UI you ask for, but it may be capable of simplifying your automations already. Improving the UI (selectable duration, starting, stoping etc.) is on the agenda for a future relase.

Would this be possible with automation and a input boolean, input number and input select on the front end? (intent with Alexa should work also)

input boolean to set whether to turn on or off
input number to set the minutes till
input select will have every entity what you want to control

1 Like

I haven’t tried it yet, but it may be possible to directly use the input_datetime component with the has_date option turned to false. The timer componenent takes either seconds or durations like 0:10:00. If you want seconds, then the input_number would be the better choice. It depends on what you want to do since handeling longer durations with a slider might be less usable.
Anyways, you could have an automation that fires when the state of the timer is idle AND the value of your input has changed. The action would then be to call the timer.start service with the duration from the input as the duration in the service data. The state of the timer would then change to active, which you can base the automation on that actually controls the light or whatever.
If the duration can be static it would be enough to just have a script that triggers the timer.start service without the duration parameter. Scripts can be toggled in the UI by default, so that could be an alternative without using the automations / templates when using the input entities.

Edit:
I have tried to use it with input_datetime and it basically works:

timer:
  timer:
    duration: '0:01:00'

input_datetime:
  timerduration:
    has_date: false
    has_time: true

automation:
  - alias: starttimer
    trigger:
      platform: state
      entity_id: input_datetime.timerduration
    action:
      service: timer.start
      entity_id: timer.timer
      data_template:
        duration: >
          {{ trigger.to_state.state }}

With that you can enter the time in the input_datetime and the timer will start with the given duration. The problem however is, that the input_datetime seems kind of flaky to me. It behaves awkward when entering data. The value I enter gets sent to HASS almost directly after every keystroke, so in the logs some errors appear because of invalid data. As soon as the data is correct it works though. In my opinion the input_datetime component (UI) could use some improvements.
So I guess this for now is already much more intuitive than what needed to be done previously with complex automations, scripts and delays.

Great, timer component definitely looks like a step in the right direction! However, there is another aspect of simplification I’m looking for. Let me illustrate how I implemented a fan with a timer so far.

Initially I just had a plain switch without any timer functionality. It was as simple as this:

switch:
  - platform: tplink
    host: 192.168.0.15
    name: fan switch

Then I decided to add timer functionality, based on input_number. Spent few hours figuring things out and finally came up with this.

input_number:
  fan_timer:
    name: fan timer
    initial: 0
    min: 0
    max: 120
    step: 10

- alias: fan start
  trigger:
    platform: numeric_state
    entity_id: input_number.fan_timer
    above: '1'
  action:
    service: switch.turn_on
    entity_id: switch.fan_switch

- alias: fan end
  trigger:
    platform: numeric_state
    entity_id: input_number.fan_timer
    below: '1'
  action:
    service: switch.turn_off
    entity_id: switch.fan_switch

- alias: fan countdown
  trigger:
    platform: time
    minutes: '/10'
    seconds: 0
  condition:
    condition: numeric_state
    entity_id: input_number.fan_timer
    above: '1'
  action:
    service: input_number.set_value
    entity_id: input_number.fan_timer
    data_template:
      value: '{{ states("input_number.fan_timer") | int -10 }}'

It looks like this. Simplicity is key here, I can turn it on and set time with just one drag/drop gesture. I had to sacrifice time range and precision for the sake of simplicity, but I like that I don’t need to open any drop-down box or use up/down buttons to select time.

fan2

Anyway, the point I’m trying to make is that it took additional 40 lines of yaml to implement this simple timer for just 1 switch. All that yaml is hard coded to 1 switch. Now I have 12 switches at home, and ideally all of them should support timer functionality. Writing 40 lines for each of them is what I mean by complicated. (Looks like timer component can make my “fan countdown” automation simpler, but the other two are still required.)

So, is there a way to write all these automations once and make them work with any switch? Some sort of a template, maybe?

1 Like

Coincidentally 0.57 also includes increment and decrement for input_number entities, which I did for (selfmade) timers that work exactly like yours, but without the need to use templates! :smiley:

That being said, I’m pretty sure you can change your automations to work with more than just one entity. I’m honestly not the best one when it comes to automations, but templates would be the way to go. You already use them, but when you set multiple entity ids as a trigger, you can use that trigger in the service template. That allows you to use a single automation to handle state changes of multiple entity ids and execute the correct service depending on the trigger.

I did something similar but used the light component for the switch and the brightness of the light as the timer. This way I can have the timer and switch on one line in the front end with custom-ui.