Hmm, I just have logger: in my config file with no further details and I see these in my log file.
Regarding consider_home, my reading of the code is that only applies in a limited number of cases. For example, if the device provides GPS position, then I think consider_home is ignored.
Oh, and I gave up on other presence methods, too, early on and use Life360 exclusively.
digesting everything here…
and adding this:
if id try to calculate a time difference to be ignored there’s the triggering device’s attribute last_changed.
{{ trigger.to_state.attributes.last_changed}}
how would i calculate a minimum timeframe of lets say 5 minute to be the ignoring period between 2 triggers?
I try this since for the consider_home to be useful int shouldn’t be any higher than 30 seconds or so, and the for: in the trigger condition doesn’t take into account a time delta between 2 triggers.
i’d like to try something like
{{ (time - trigger.to_state.attributes.last_changed) > min:5}} …
So the for part is supposed to not trigger until a new state stays the same for that much time. I haven’t looked at the code, so I’m not sure what “state” it considers for this. Is it just the state (as in to_state.state), or is it the entire “state”, including attributes (as in to_state)???
But to answer your question:
{{ (now() - trigger.to_state.last_changed).total_seconds() > some_number_of_seconds }}
But do you want to compare now to to_state’s last_changed, or from_state’s last_changed??? If the current trigger was caused by an attribute changing, they should be the same. But if the current event is an actual state change (as in from_state.state != to_state.state), then to_state.last_changed will effectively be now, whereas from_state.last_changed will be the last time the state changed (before the current event.)
OOPS! Let me think about that statement a bit more…
EDIT: I forgot last_changed is a datetime. I’ve updated the statement above.
lol, doing the same here… tbh, I am not sure. But wont accept yet, it couldn’t be done, just have to find the correct logic the system uses to notify us…
checking my logs both comparing the last 2 to_states and comparing to_state and from_state could two the trick.
comparing the last 2 to_states should be combined with {{trigger.to_state.state}} being equal i guess (not sure how to template that yet…)
comparing to_state and from_state should need an extra condition i guess, but testing should make that clear.
The issue with that method is it will delay your arrival at home notifications by 5 minutes. Increasing consider_home will only delay your departure from home notifications. I’m not sure about your use case, but in my use case, I want arrival at home to be detected quickly, and I prefer reliability and confidence over responsiveness when leaving home.
Another option is the History Statistics Sensor where you can calculate the amount of time in the last 5 minutes that the device_tracker has been not_home, then trigger when it reaches 5 minutes. This greatly increases the complexity and doesn’t support other zones.
but would it do so also, if I added the extra condition as described in my post, last 2 {trigger.to_state.state}} being equal?
you’ re absolutely spot-on wanting the arrival to be as precise as possible. but it shouldn’t hit more than 15 times in a minutes 
That won’t really affect it either way.
Increasing consider_home until the false positives go away is the simplest option. I’m curious why you’re hesitant to change it?
well, tbh, I am confused now… I am not hesitant to try at all, in fact have already changed it. But I thought you told me that even upping it to 600 didn’t give the correct results in your setup?
with the added value_template I was in fact trying to mimic a situation like this, where a motion sensor is triggering motion as it happens, but a binary_sensor based on that motion sensor is watched for being Off a certain period. After which the desired action fires. Something like that is what I am looking for in the device_trackers of the phones.
trigger:
platform: state
entity_id: binary_sensor.dining_table
to: 'off'
for:
minutes: 5
without loosing the device_tracker lock on entering the Home, when it truly happens. That should be immediate, or at most the setting of consider_home…
I gave up on nmap as my primary source of presence because I found that gps methods like life360 are significantly more reliable. To get nmap to be reliable, you may end up needing to increase it to an hour or more. The issue with reliability will also affect your use of for and templates based on last_changed.
Any WiFi based presence detection like that suffers because modern smart phones turn off WiFi when they’re in deep sleep mode. My answer is to augment it with Bluetooth. By using both in a group I’ve had zero false positive away events.
that’s a configuration I had before. Upon several tips I disabled the BT tracker, since it was supposedly the cause for many timing issues.
Also, in my setup, the Pi is not near enough to cover the house and make bt tracking reliable.
btw, ive had no erroneous notification after having added this condition:
- condition: template
value_template: >
{{ (now() - trigger.to_state.last_changed).total_seconds() > 120 }}
tbh, ive had no notification at all have to check to see if this is correct…
If I test the template in the service dev-tools, it says
Error rendering data template: UndefinedError: 'trigger' is undefined
if I use the same template but substitute with states.device_tracker.phone.last_changed, it works fine.
does this error mean the trigger wasn’t created, or the template is syntactically wrong…?
another uncertainty I have had for a longer time: when to use trigger.to_state, and when to use trigger.identity_id ? Both seem to work and point to the same trigger?
{{as_timestamp(now()) | timestamp_custom('%X') }}
{{ trigger.to_state.attributes.friendly_name}} {{ 'arrived at' if is_state(trigger.entity_id, 'home') else 'left' }} home,
{{ trigger.entity_id.split('.')[1]|replace('_', '')}} is
{{ trigger.to_state.state }}
I believe {{ (now() - trigger.to_state.last_changed).total_seconds() }} will always be 0 because trigger.to_state.last_changed is essentially now(). You may have better luck with {{ (now() - trigger.from_state.last_changed).total_seconds() > 120 }} instead because that should have the time of the previous state change instead of the current one.
That’s expected because trigger is only available in the context of an automation.
trigger.entity_id is the entity_id that triggered the automation. trigger.to_state is the current state of the object that triggered the automation and trigger.from_state is the previous state of the object that triggered the automation. As far as entity_id is concerned, they’ll all be the same, so I just use trigger.entity_id since it’s less typing.
This looks like you only care about the home zone, so why don’t you use the trigger that you posted previously so you don’t have to mess with the conditions?
trigger:
- platform: state
entity_id:
- device_tracker.daughter1
- device_tracker.daughter2
- device_tracker.daughter3
- device_tracker.daughter4
from: 'not_home'
to: 'home'
for:
minutes: 5
- platform: state
entity_id:
- device_tracker.daughter1
- device_tracker.daughter2
- device_tracker.daughter3
- device_tracker.daughter4
from: 'home'
to: 'not_home'
for:
minutes: 5
thank you, I’ve been turning my head around this too. The thing is, if i test it with states.device_tracker.daughter.last_changed, it works as desired. so maybe instead of to_state, or from_state, should be testing the trigger.entity_id. especially if I add the to: and from: to the trigger, to narrow down.
will do both and see what happens
this was a snippet from another automation, in which I tested both the entity_id and to_state. triggers, so I most certainly will be more precise in the final automations, thanks for pointing me to that .
using your templates in a dedicated iOS cloud presence tracker, I still get rather a lot of zone notifications (though much less then before)… seems to be random though no real logic behind it, and since these are not wifi related, must have another reason for triggering. Will test if I can do anything with the timing here too.
The tsunami of home and not_home notifications of the other non-zoning devices seems to have stopped, which is wonderful indeed
thanks for all of your help so far!
Try putting the IOS and nmap trackers in a group (1 group per person), then use those groups for your notifications. You should see a significant improvement in reliability after that. It that’s not sufficient, you can also increase the size of your home zone to help reduce some of the false positives from your IOS tracker.
that works fine indeed, had that for 2 of iCloud tracked devices, working properly.
for the non-zoning devices, device_trackers only using home and not_home, if I use this template:
value_template: >
{{ trigger.to_state.state is not none and
trigger.from_state.state is not none and
trigger.to_state.state != trigger.from_state.state }}
wouldn’t the last line mean it never will reach true? the only 2 states, home and not_home will by definition prevent this from triggering?
That prevents events like attribute changes from triggering the automation. For example state is home and only battery_level attribute changes.
please let me get back to this one more time.
besides the timing and trigger frequency aspects, how does this ever get to the {% else%} phase.
data_template:
title: 'Presence Tracking:'
message: >
{% set name = trigger.to_state.attributes.friendly_name %}
{% set to_state = trigger.to_state.state %}
{% set from_state = trigger.from_state.state %}
{% if to_state == 'not_home' %}
{{ name }} left {{from_state}}
{% elif from_state == 'not_home' %}
{{ name }} arrived at {{to_state}}
{% else %}
{{ name }} left {{from_state}} and arrived at {{to_state}}
{% endif %}
In my setting all devices when leaving a zone go into ‘not_home’, and hence switch between ‘left’ and ‘arrived at’…?? Devices cant go from one zone to another without being ‘not_home’ in between can’t they?
It’s possible to transition from home to another zone and vice versa. It just depends how close the other zones are to home and how often your device tracker updates.
ok, for my settings that wont be the case i fear, since the zones are wide apart, and a state not_home will always be in between.
That being said, im still looking for a way to stop especially this automation from triggering after each reconnect. {{trigger.to_state.state != trigger.from_state.state}} doesnt prevent that obviously, and i think it is because of the same reason. The device goes into not_home state and then the template passes…
I think i might use the gps coordinates here. Since they wont change, even in not_home, when on the same location …
{{trigger.to_state.attributes.longitude != trigger.from_state.attributes.longitude and {{trigger.to_state.attributes.latitude != trigger.from_state.attributes.latitude }}
or could I do that in a better way?
this would then be the full conditional section:
condition:
- condition: template
value_template: >
{{ trigger.to_state.state is not none and
trigger.from_state.state is not none and
trigger.to_state.state != trigger.from_state.state }}
- condition: template
value_template: >
{{trigger.to_state.attributes.longitude !=
trigger.from_state.attributes.longitude and
trigger.to_state.attributes.latitude !=
trigger.from_state.attributes.latitude }}
- condition: template
value_template: >
{% set zones = states.zone | map(attribute='entity_id')|list %}
{{trigger.to_state.state in ['home','not_home'] or
trigger.from_state.state in ['home','not_home'] or
trigger.to_state.state in zones or
trigger.from_state.state in zones}}What device trackers are you using now? If you’re having a lot of false positives, you should look at adding another tracker in a group or move to one that’s more reliable.