Enhance Automations with "For Duration or Longer" Option

Home Assistant automations with conditions and duration triggers have a limitation: if an entity has been in a state longer than the specified duration when a condition becomes true, the automation won’t trigger.

Example Use Case: I want lights to turn off after being on for 30 minutes, but only during nighttime hours (10PM-6AM). Currently, if a light is turned on at 9PM and left on, it won’t turn off at 10PM despite being on for >30 minutes because the duration trigger fired at 9:30PM when the time condition wasn’t met.

Proposed Solution: Add an optional “or longer” checkbox to the “for” duration field in automations that would:

  • Re-evaluate the trigger when conditions change from false to true
  • Check at Home Assistant startup if the conditions are met and the duration has elapsed
  • If needed, allow periodic checks for long-duration states meeting both trigger and condition requirements

Technical Implementation: Add an or_longer: true/false option to the state trigger’s “for” parameter in YAML, and a checkbox in the UI.

Benefits:

  • Makes automations more intuitive, especially for beginners
  • Eliminates the need for workarounds using multiple triggers, templates, etc.
  • Reduces the learning curve for new Home Assistant users
  • Supports more reliable presence-based and time-based automations

Backward Compatibility: This would be an optional parameter, so existing automations would continue to work without modification.

Documentation: The “or longer” field could be described and documented as follows:

Ordinarily, a trigger (When) with a “for ” specifier will only fire once when the trigger state has been true for the specified time. If “or longer” is checked, then the trigger will fire again if the trigger state has been true for the specified time or longer and any of the conditions (And if) change state. Likewise, the trigger will fire at Home Assistant startup if the trigger state has been true for the specified time or longer.

For example, if the trigger (When) is “When the Kitchen Light changes to On for 30:00 or longer” and the condition (And if) is “If the time is after 10:00 PM and before 6:00 AM”, then the trigger will fire when the light has been on for 30 minutes AND at 10:00 PM if the light has been on for 30 minutes or longer.

Background:

I want automations that automatically turn off lights or lock doors after a certain duration, but limited to a time window (say 10 pm to 6 am), or conditions like no recent motion. I’ve read the docs, checked the community forum, talked to an experienced HA user, asked two AIs, and researched HACS integrations (like Entity Controller) without finding a great solution.

An automation to turn off a light that has been on for 30 minutes will not run if the light was turned on more than 30 minutes before the time condition window.

I tried to fix this by adding another trigger for “time = 10:00 pm”. This solves the problem if the lights are left on from before 9:30 pm, but it will force the lights off at the trigger time, even if you just turned them on 10 seconds ago, failing the 30-minute duration requirement.

Next, I created a template sensor to report the on-duration of the kitchen light and an automation that triggers once a minute with the conditions: time between 10:00 pm and 6:00 am AND the light on-duration >= 30 minutes. This works! But it requires custom YAML, creating an extra sensor for each such entity, and although it may be negligible, I’m troubled by firing events once a minute (or even every five minutes) to perform this test. It means my automation trace will be filled with pseudo-events, and I suspect it also results in a lot more logging. This is tricky enough that many users won’t figure it out and won’t get the behavior they want.

I did more experiments using value templates, different trigger times, and different conditions. Some worked, some did not, they were all a bit tricky and unintuitive.

The normal way to do this is to add all triggers as conditions and all conditions as triggers.
That way it will run when everything is true.

2 Likes

Your proposal hinges on:

which would be massively breaking to everyone. It would cause nuisance retriggers simply because a condition changed state.

You were almost there. You just needed to add a triggerId in each of those triggers, and then use a choose based on that triggerId. Job done.

Thank you for responding. This looks good. I even added a trigger on HA start.

alias: Kitchen Light Off - Night 30m
description: ""
triggers:
  - trigger: state
    entity_id:
      - switch.kitchen_light_switch
    to: "on"
    for:
      hours: 0
      minutes: 30
      seconds: 0
  - trigger: time
    at: "22:00:00"
  - trigger: homeassistant
    event: start
conditions:
  - condition: time
    after: "22:00:00"
    before: "06:00:00"
  - condition: state
    entity_id: switch.kitchen_light_switch
    state: "on"
    for:
      hours: 0
      minutes: 30
      seconds: 0
actions:
  - action: switch.turn_off
    metadata: {}
    data: {}
    target:
      entity_id: switch.kitchen_light_switch
mode: single

It’s a bit embarrassing to admit, but I was doing this the hard way, with a template sensor for the light “on duration”, which was totally unnecessary, since the condition can include “For 30:00”. I had also tried value templates to evaluate the light on time.

This is easier than I thought it might be. I’m disappointed that I struggled so long without finding the best solution. I’m also disappointed that Claude, Gemini Pro 2.5, and a CS friend of mine who has been using HA for years didn’t suggest this. As an electrical engineer / computer scientist on a bit of a sabbatical, with lots of time, I found it challenging and surprisingly time consuming to figure out a workable solution to this simple problem.

I still feel my proposal might be easier and more intuitive for some people. But I also understand it might not fit well into the HA automation architecture.

I think you’re confusing triggers and conditions.

A trigger fires when it changes from “not true” to “true”. This is an event, not a state. If you want lights to turn off after being on for 30 minutes, this trigger…

triggers:
  - trigger: state
    entity_id:
      - light.yard_1
    to: "on"
    for:
      hours: 0
      minutes: 30
      seconds: 0

…will fire once when that moment arrives. To make it work any other way you would have to rebuild HA from the ground up. :grin:

And everyone would have to change their automations because it would fire when they don’t want it to.

If I understand correctly, this is like Hellis81’s recommendation, but instead of testing “all triggers as conditions”, I would use the choose block to test all conditions other than the trigger (I know I’m mixing triggers and conditions and they are not precisely the same). For example, if I can trigger on A, B, or C, then in the choose block, if the trigger was A, add conditions equivalent to B and C before performing the action. Is this correct?

If so, this appears to yield the same result as the suggestion from Hellis81, but it’s somewhat more complex to set up and maintain. Is there an advantage I’m missing?

Help me understand this better. You and Hellis81 suggest adding a “trigger for each condition.” My proposal was to have the Automation integration add an implicit trigger for the time condition. I don’t see a large difference. I proposed that nothing would change unless the user selected the “or longer” option, so it would not break any existing automations.

In reading the responses and doing more experiments, another idea occurred to me. Triggers are combined with an implied OR. Suppose there was an option to combine them with an explicit AND? I already did this with a template sensor for my front door lock by creating a sensor which is true only when the door has been unlocked for 10 minutes AND is closed (so that the bolt is not extended while the door is open). Again, I understand that I’m mixing events and conditions, but that does not seem insurmountable from a coding perspective. The UI already provides an identical experience when I say I want to trigger when a light has been on for 30 minutes and when I add a condition (And if) that the light has been on for 30 minutes, although the implementation must be different.

It feels to me like HA automations are great for a large set of situations, but become challenging when trying to combine two or more triggers and/or conditions. I don’t know the best way to make this easier and I’m new to HA, so my ideas may not make sense. But by being new, I also see areas of confusion that long-time users have already overcome. My hope is that this feature request will prompt new ideas, brainstorming, etc. The feedback from you and Hellis81 have already helped me improve my automations, better understand HA, and clarify my thoughts on ways to improve automations.

That’s a lot to reply to, but I’ll try to cover everything I feel competent in…

In this specific case, Hellis’ suggestion makes more sense. My suggestion would have been more valid if you wanted to perform different actions depending on the trigger (like if the light was on before 10, then turn it off at 10:30 instead). Think of it like having 2 automations in 1.

Your proposal suggested that the trigger is reevaluated every time a condition changes to true. That makes it massively breaking for everyone because automations should only be triggered when the specified trigger changes state. Conditions should have no part in causing the triggers to reevaluate, since that could lead to nuisance triggering for other people.

Proposing that nothing would change unless the user selected only this very specific option would make it even less justifiable to a developer to implement it.

I have second hand information from a reliable source that this is in the pipeline. You might have to be patient for a little while longer, but the wheels are already in motion in that direction :wink:

It IS different because “And if” is a condition. If that condition does not evaluate to true, then the trigger does not fire again when it finally evaluates to true. The template sensor you mentioned combines both into a single AND trigger, avoiding the scenario where a change in condition retriggers the…erm…trigger.
So yes, totally different implementation.

They’re only challenging because you’re just starting out. Like you said - you’re new. It’s not that your ideas don’t make sense - it’s that you may not be aware of the (currently) optimal way to handle such scenarios.
Don’t worry. We’ve all been where you are at a certain point. Read the docs, search the threads and if you draw a blank, remember we’re here to help. Just don’t go running to ChatGPT :stuck_out_tongue:

2 Likes

That is correct.
But adding them all as both triggers and conditions means you don’t have to think.

That won’t work.
Triggers can be events lasting just milliseconds.
What is the odds that they all trigger at the same time. Literally zero.

We did answer you how to do it?
So what is so challenging with that method?
I understand that people come to HA with their mindset of what is how they want HA to function.
And I respect that, but when you just want to duplicate an already existing function or (as in other cases) create breaking changes, then it does not make sense to people here.
That is what we are saying.
Most feature requests posted by new users here are either of things that already exist or that will create massive breaking changes.
And because of that there are people who explain how to use this function or how that won’t be good.

I’m not in being disrespectful or anything I’m just saying what is more or less posted on a weekly basis in the feature request.
I have also been guilty of the mindset that you can change something because I thought I had a better idea.
This is not at all something that is uncommon.

You really don’t have to. There’s nothing wrong with having two or more automations - and in fact it can make maintenance easier. Automations are just sets of rules: when this happens, do that. We’re not writing software here. :grin: