How is the trigger 'for:' <time> implemented?

Configuration
,
1

For no other reason than just being curious (no specific task at hand) how is for: implemented? How does the code know that a state (or attribute) has been continuously in the specific state (or attribute value) to trigger after the for: time?

I tried to look at some of the code and an older post, but got a bit lost.

Take a simple automation:

alias: "Test: for"
description: ""
triggers:
  - trigger: state
    entity_id:
      - light.living_room
    to: "on"
    for:
      hours: 0
      minutes: 0
      seconds: 30
conditions: []
actions: []
mode: parallel
max: 10

My simple assumption is when the light-turned-on-event happens the code then sets another listener to fire at the for: time (in 30 seconds in this example).

When that timeout/event happens at 30 seconds what test is done to determine that the light has been on continuously for that entire 30 seconds?

Initially, I imagined that when the 30 second event fires that the code then checks if the state is still on AND that the last_changed time <= now() - 30 seconds.

But that approach doesn’t work for attributes because last_updated will change with any attribute update.

For example:

triggers:
  - trigger: numeric_state
    entity_id:
      - light.living_room
    attribute: brightness
    above: 200
    for:
      hours: 0
      minutes: 0
      seconds: 30

Works as expected even if I update the friendly_name, which updates the last_updated timestamp in the middle of the 30 second delay.

Or does the code work by canceling the waiting for: if the state (or attribute value) changes away from the expected state?

Again, everything works as expected. I’m just curious how it works.

Thanks.

2

You expect people to read a very long post, and then answer a question that is complicated to answer.

Why?

You will probably do a lot better asking the question(s) directly that you actually care about.

https://en.m.wikipedia.org/wiki/XY_problem

3

Not a developer so views are my own imagination interpretation.

Home Assistant has a state machine that keeps track of the states and subscriptions to notify/trigger things. The information I can find which may help with your curiousity:

4

It doesn’t work the way you described.

It triggers only when the light’s state has been on continuously for at least 30 seconds.

A state-change (i.e. turned off) occuring during the 30 second countdown serves to reset the trigger.

5

If “it triggers” is the automation, yes, that’s how the automation trigger happens. I was asking about the implementation (in code) which would have to use the state change as the initial event, and then set a timer. But you essentially answered how it is implemented:

That makes sense, as my initial thought of using last_updated/last_changed timestamps couldn’t work.