Trigger on no location update constantly triggering

Configuration
1

I have the following trigger:

trigger:
  - platform: state
    entity_id: device_tracker.phone
    for:
      minutes: 2

Based on a few sources here[1], my intent was for this to trigger when the location of the tracker does not change (including attributes, as that’s where the coords are stored) for 2 mins.

However, I see this triggering every three seconds or so. I expect (any) trigger to only trigger the first time the trigger qualifies, so in the above the first time the tracker has not changed for 2 mins but not after that.

Any insight on why my understanding is incorrect? Is there an obvious fix?

(I did look at using a template trigger on last_updated but that doesn’t reflect attribute changes)

[1] Automation trigger when value is not changing for some time and Trigger an automation when a value does NOT change?

2

Actually now that I think about it, it triggers on any attribute change. Which is obviously not what I want.

Short of creating a sensor to extract the coords and checking that state, is there any way to do what I want with the tracker directly?

3

No.

Unless you specify to track the state only, for will be based off last_updated which is non-specific… it updates whenever the state or any attribute changes.

Edit: Upon further testing, it seems the function of for with attributes may have been updated to be specific to the selected attribute.

4

Huh. During my (apparently inadequate) testing, last_updated did not update with attribute changes, but I just tried it and it worked. In that case the template trigger on this should do the trick?

trigger:
  - platform: template
    value_template: >
      {{ now() - states.device_tracker.phone.last_updated >= timedelta(minutes=2) }}

That being said (for my understanding) why would the original trigger ignore the 2 min criteria?

5

Another option is to add to: null or for: null clause. That will exclude attribute changes:

The 2 min criteria was not ignored, it just triggered 2 mins after the gps coordinates changed.

6

Thanks @Edwin_D , but I don’t think I want to ignore attribute changes? Given that the location coords are stored there?

I want this trigger to fire when no updates have been received from the device tracker for 2 mins.

7

That would be rather random, as gps coordinates slightly vary all the time. I assumed you meant 2 mins in the same zone. What is your definition of ‘not changed’?

No updates is something different. If the state does not change, it does not mean there were no updates. You can have updates without moving too.

What you were seeing is a trigger 2 mins after each small location change. If those small changes are three minutes apart, you’ll see each move, but 2 mins after it happened.

8

How about using the composite integration and use the speed option to detect (lack of) movement?

9

I’m specifically looking for the times when the app/device stops sending updates for a technical reason, so would expect there to be precisely zero changes to the state/attributes[1]. I suspect the speed integration will fall foul of the same issue as proximity (but even if it isn’t, I think I can solve the issue with my existing approach)

The trigger is firing much faster than that, every few seconds. Even if incorrect, I would expect it to only fire once every two minutes:

2024-09-11_21-14 - triggers

[1] Determine proximity direction over time rather than with subsequent location updates

10

Have you tried using the last_reported property?

trigger:
  - platform: template
    value_template: >
      {{ now() - states.device_tracker.phone.last_reported >= timedelta(minutes= 2) }}
11

Just tested that and it also works. Thanks!

Solutions aside, this still doesn’t explain the frequency of firing of the previous trigger.

12

We’ll have to wait for someone more familiar with how duration criteria are attached to the trigger listeners, but my guess would be that there isn’t a mechanism set up to do it with an open State trigger that is monitoring the state and multiple attributes.

When you specify that the trigger should only listen for changes to the state, the duration can be based on the last_changed property.

In the past there have been several threads where people complained about the use of for being unreliable when used with a specific attribute. My understanding is that this was due to the fact that it was being based on the last_updated property, which is non-specific. The recommendation given to those users was to create a template sensor to hold the value of the attribute in a state, so that it could support using for in automations.

Based on limited testing, it seems like that old behavior has been changed so that a specific timestamp is being created in the background when you set the trigger to be based on a specific attribute. But, when no attribute is specified, the for is just disregarded…?

1 Like
13

Hmm I do understand the theory, but I would have thought there was a mechanism to know whether a trigger has fired for a particular for clause (although I do see that as being difficult to do statelessly). Otherwise I would expect a for clause of 1 minute on a state to keep triggering after 1 minute of no changes too.

Happy to draw a line under this though. The template trigger works a treat.