[Feedback wanted] How should duration-based triggers behave when the state already qualifies at creation?

[nielsrowinbik]

We are looking at how duration-based triggers should behave when the watched entity already meets the trigger condition at the moment the trigger is created or reloaded. We want input from the community before settling on a behaviour.

Take a "light turned on" trigger with a duration of 30 minutes. The intent is for the trigger to fire once the light has been on for 30 minutes. Now imagine the light is already on when the trigger is created.

Case A, the light has already been on for 29 minutes:

• Fire 1 minute after creation, counting the time already elapsed?
• Start the timer at creation, so it fires 30 minutes later?
• Require the light to go off first, then start counting on the next "on"?

Case B, the light has already been on for 31 minutes:

• Fire immediately, since the duration is already satisfied?
• Start the timer at creation, so it fires 30 minutes later?
• Require the light to go off first, then start counting on the next "on"?

What would you expect here, and why? If your answer changes depending on the use case, please describe the use case.

[TheFes]

In case B I would expect the 3rd option. Why would the trigger act differently compared to the situation without a duration.
If no duration is set for the light turned on trigger, the trigger also won't fire if the automation is created when the light is already on

In case A it's a bit different, because the actual event on which you are setting the trigger (the light being turned on for 30 minutes) didn't happen yet before saving the automation. With my knowledge of how this works with state triggers, I wouldn't expect it to trigger, but that doesn't have to be a limitation to implement it differently.

[nielsrowinbik]

In case B I would expect the 3rd option. Why would the trigger act differently compared to the situation without a duration. If no duration is set for the light turned on trigger, the trigger also won't fire if the automation is created when the light is already on

Exactly, we touched on this in our internal discussion and we fully agree from a predictability standpoint, however we're not entirely sure if it's also the most natural/intuitive option. What do you think?

In case A it's a bit different, because the actual event on which you are setting the trigger (the light being turned on for 30 minutes) didn't happen yet before saving the automation. With my knowledge of how this works with state triggers, I wouldn't expect it to trigger, but that doesn't have to be a limitation to implement it differently.

Apart from how things currently work, how would you expect this to work?

[mib1185]

I would vote for option 2 in both cases (Start the timer at creation, so it fires 30 minutes later) as this is predictable for the user.
But I'm unsure when a trigger could be reloaded? I guess the event to create a trigger, is when the trigger gets added to an automation and this automation is saved. But when does a reload happen?

[nielsrowinbik]

A reload happens when HA restarts and when the automation in question is changed in any way.

[mib1185]

ok, then I definitely vote for option 2 in both cases, as this is the only predictable option. I mean, when restarting HA, we don't know since when the light has already been on, as the state is not preserved over the HA restarts.

[BBE-FR]

I strongly disagree there for the reload. this is in full opposition with the "no time confirmation" trigger.

At HA reload you do not refire all the triggers for all the "when a lamp turn on". Why refire the one that are "when a lamp turned on for 5 minutes".

The definition of the trigger is "when a lamp turned on" not "when a lamp is on".

[cvroque]

This one made me think longer than expected.

I checked some automations I already have based on duration and on the most mission critical ones I ended up using timers! Example for this situation: When the light turns on, start the timer for 30 minutes, wait for timer to finish and execute the action.

I believe this would make more sense when keeping in line with timers:

Case A ➡️Fire 1 minute after creation, counting the time already elapsed

Why? Let's say I turned the light on 25 minutes ago and then restarted HA for some update, when it comes back up and reaches the 30 minutes mark I would like it to fire the event.

Case B ➡️Require the light to go off first, then start counting on the next "on"?

Why? The event is already gone, I don't expect this event to happen while HA is restarting (same as timers finished).

[BBE-FR]

Two cases are slightly different:
Usecase 1: trigger creation (or modification) with HA running context
Usecase 2: trigger reload due to HA restart

For the Usecase1 (trigger creation / modif without HA restart), I would answer:
Case A : answer 1 (this is the actual time the trigger should fire)
Case B : answer 3 (the trigger should have fired a minute ago, it is past, thus to re-fire need to reload the logic)

For the Usecase2 (HA restart), I would answer: lets copy the behaviour of the "without time confirmation" trigger there :
no transition => no trigger thus solution 3 for both cases (with or without confirmation, if the transition occurred with HA off no trigger should occur)

Saying it differently, for usecase 2, the behaviour should be almost identical for no time confirmation and for a 1s confirmation. If there is a difference, there should be a strong rationale behind. (If I decided to set a confirmation time to "debounce" things, I do not expect triggers to fire when no confirmation time would not have.)

If you need to secure HA off transition, you have do your trigger differently (with timers for example) to secure the "HA off" transition.