Why does the for statement of a trigger not respected for changing attributes?!

Dear community
I’m struggling detecting no attribute changes fo a time period. I configured this trigger for detecting no state or attribute changes for 15 minutes:

  - trigger: state
    entity_id:
      - device_tracker.eric
    for:
      hours: 0
      minutes: 15
      seconds: 0

I observed this doesn’t work for only attribute changes!! After saving the automation:

  • I was traveling, so all GPS updates didn’t change the state, only the GPS coordinate attributes changed roughly every 5 minutes,
  • SO the 15 minutes in the for statement should not expire!

Problem: 15 minutes after the first GPS attribute change the automation triggered for the first time, and so for every consecutive GPS update. So the automation triggered for every GPS changes, with a 15 minutes delay, in stead of ignoring them!

That feels like a bug, or do I miss something here?!

That’s not how that trigger example works.

Here is an except from the documentation explaining how it works.

In this example, the trigger fires if the state value of the entity remains the same for for the time specified, regardless of the current state value.

automation:
 triggers:
   - trigger: state
     entity_id: media_player.kitchen
     # The media player remained in its current state  for 1 hour
     for: "01:00:00"

Thanks @123
OK, but the documentation also states: will be triggered for any state or attribute changes, in case there is no to: or from: specified (like I did).
SO why does the ‘for:’ only respect no state changes, instead of no state or attribute changes (what I assumed reading the docs)
Also the automatic action name in the automation is suggesting that: " When eric changes state or any attributes for 15:00"

It seems I have to make a template trigger then:

 {{ now() -  states.device_tracker.eric.last_updated >= timedelta(minutes=15)  }}

Best Eric

When there isn’t a defined attribute and to or from are defined, for makes the trigger monitor last_changed, which is specific to the state changing.

But. when used with a defined attribute, the trigger monitors last_updated, which is non-specific… it updates for all attribute changes as well as state changed. This is one of the reasons behind the push in recent years to have integrations move dynamic attributes into their own entities.

All that to say, there isn’t really a good way to do what you are trying to do with a State trigger. Your template trigger is the better option.

1 Like

@Didgeridrew
Thanks for explaining. This helps me as well :partying_face:
I will retry defining the attributes, just to learn. Then move to the template :innocent: