Automation help, turn off switch after a period of time

caleb · July 3, 2019, 12:48pm

This is really two questions. First one, I have the following automations:

- id: 'butt_truffles_kitchen'
  alias: Butt Truffles Kitchen
  trigger:
    platform: state
    entity_id:
      - switch.kitchen_bathroom_fan
    from: 'off'
    to: 'on'
    for:
      hours: 0
      minutes: 20
      seconds: 10
  action:
    service: switch.turn_off
    data:
      entity_id:
        - switch.kitchen_bathroom_fan
- id: 'butt_truffles_master'
  alias: Butt Truffles Master
  trigger:
    platform: state
    entity_id:
      - switch.master_bathroom_fan
    from: 'off'
    to: 'on'
    for:
      hours: 0
      minutes: 20
      seconds: 10
  action:
    service: switch.turn_off
    data:
      entity_id:
        - switch.master_bathroom_fan

Those will turn off bathroom fans after 20 minutes of being on. Since those are exactly the same, just different switches, how can I combine those in to a single automation? I could list all the entities under each section, but I’m assuming that if one fan hit 20 mins and triggered the turn_off, it would turn all the fans off and not just the one that hit 20 mins.

Second question: How can I make that one more reliable? It seems that while I’m actively testing it, it works exactly as designed. However, the next day it seems it no longer works and the fans stay on indefinitely unless I go play with something in HA. If I reload automations, it starts to work again. I think really what I would like is instead of triggering on the state change from off to on, I would like to just turn off after it’s detected it’s been on for 20 minutes. Is this possible? Or what would be a more reliable way to do this same thing?

petro · July 3, 2019, 1:00pm

so I don’t use automations, so I’m not 100% sure if you can combine the entity_id section of the trigger. I would assume it would treat the entity_id list as ‘or’ but it could treat it as ‘and’. You might have to experiment.

- id: 'butt_truffles_kitchen'
  alias: Butt Truffles Kitchen
  trigger:
    platform: state
    entity_id:
      - switch.kitchen_bathroom_fan
      - switch.master_bathroom_fan
    from: 'off'
    to: 'on'
    for:
      hours: 0
      minutes: 20
      seconds: 10
  action:
    service: switch.turn_off
    data_template:
      entity_id: "{{ trigger.entity_id }}"

Worse case scenario is that you have to have 2 triggers.

123 · July 3, 2019, 2:39pm

I have to ask, what is ‘Butt Truffles’?

caleb · July 3, 2019, 2:53pm

Lol, this automation is so when someone goes in to use the restroom, they turn on the fan, use the restroom and can close the door and leave the fan on so the stink doesn’t get out. The fan does two things, pulls in fresh air more quickly than just letting it naturally come in, and it serves as a warning to others that if the fan is on, enter at your own risk. My naming is just to entertain myself

caleb · July 3, 2019, 2:54pm

Thanks, I’ll give this a try. I think

data_template:
      entity_id: "{{ trigger.entity_id }}"

Is what I was missing on my original attempts.

caleb · July 3, 2019, 3:14pm

It seems that doing it this way it sort of works. If only one switch is turned on, it works fine. If one switch is turned on, then a few seconds later (before the first one turns off) another turns on, it will only act on the first switch and not the second.

petro · July 3, 2019, 4:24pm

You may want to keep the automations separated if it’s not behaving the way you want it to. It’s not bad to have multiple similar automations. It’s just more overhead. You could move to appdaemon to handle your automations and you could combine these two. But appdaemon runs off python, so you need to know python.

caleb · July 3, 2019, 5:03pm

Thanks, I’ll look at AppDaemon. Python is not an issue, I live in python (be that good or bad) all day for work. I hate duplicating code, so that’s why I was trying to reuse the same automation but if it just can’t do it then I’ll just have to duplicate. Thanks for your help.

petro · July 3, 2019, 5:04pm

if you know python, you’ll end up switching to all appdaemon. I did it a few years back, and it’s worth it. Especially if you have 10 of the same automation. Or if you want to perform any for loop.

caleb · July 3, 2019, 5:07pm

Thanks. I’ve installed AppDaemon but hadn’t yet looked at it. I’ve also had many times that I’ve wanted to loop through something, sounds like I should just figure out AppDaemon.

pnbruckner · July 3, 2019, 5:18pm

The first solution @petro provided above should work, but doesn’t (sometimes) because of a bug that has been in the state & numeric_state triggers for a long time. I just fixed them both. (See PR 24904 & PR 24910.) Should be in 0.96.

To explain… If you have multiple entities listed when using to & for, an independent “timer” will be started for each entity when it satisfies the trigger criteria (i.e., to, and possibly from.) It shouldn’t matter what the other entities do during that time, as long as its own state doesn’t change during that period. If it does change, the “timer” will be canceled. If it stays the same, then when the “timer” expires the automation will “trigger.”

But due to the bug, however, if another entity changed in the scenario described above, and the other entity’s new state value differed from the to state, then that would incorrectly cancel the first entity’s “timer.” This is what you were experiencing.

duren · August 12, 2019, 2:21am

This “timer”… how exactly does it work?

Is the clock state within the running instance of HA? What happens if you want something to trigger at 5pm and running for 1h and HA was restarted at say 5:30pm - when it restarts, does it look for the last state change, ie that it was at 5pm and that there are 30 minutes left and it will set the clock for 30 minutes instead of an hour?
Let’s say for the above example we are talking about a simple on/off state. What happens if within the hour the state was “unavailable” / “offline”, whatever the sensor reports when it can’t get the value. Would this change reset the “timer” or would it consider this bad state a blip and continue with however many minutes are left on the 1h clock?

pnbruckner · August 12, 2019, 2:12pm

The timer used to implement the for: option will not span a HA restart. All automation triggers reset when HA starts.

Once the trigger: criteria is met, the for: timer starts. If the state of the entity changes such that the trigger: criteria is no longer met, before the for: timer expires, then the trigger, and hence the for: timer, will be reset. Changing to unavailable would probably cause the trigger to reset (unless, of course, the trigger was “to: unavailable”.)