The not_home state is shown as Away in the UI, so that’s expected behavior.
The state wouldn’t change from home to not_home unless the GPS coordinates changed. I don’t think this condition will filter out anything useful.
You can make the radius for your home zone larger. Another option is to create something like https://philhawthorne.com/making-home-assistants-presence-detection-not-so-binary/.
of course… what was I thinking… with all these customizations, I forgot what it was without 
well, the iCloud trackers do. They continuously switch on/off to save power apparently. If they switch Off, their state changes to not_home. Hence triggering the automation, even without a gps coordinates change. Exactly that was the property I tried to catch… without a lot of succes, I must admit.
testing your mqtt_json presence setup now with @pnbruckner 's Life360 CC homeassistant-config/docs/life360.md at master · pnbruckner/homeassistant-config · GitHub
Which seems to work right out of the box. I hope this takes less battery than the iCloud, so my other half doesnt kill it all the time…
Using that in the proximity component, and Waze travel time.
Make iCloud tracking unnecessary, and stop Google from charging…
thx for the Phil Hawthornes page, had already checked that for reference and use bits here and there. Very imaginative indeed!
I don’t have any iCloud or Apple devices, but that definitely doesn’t match the behavior of any of the device trackers I’ve used. Maybe that’s a bug in that device tracker?
I think you’ll be pleased with Life360. It’s the best device tracker that I’ve tried so far.
just to let you know, I’ve tried and added the battery: to the json, so it updates that as well:
payload: >-
{
"latitude": "{{ trigger.to_state.attributes.latitude }}",
"longitude": "{{ trigger.to_state.attributes.longitude }}",
"battery": "{{ trigger.to_state.attributes.battery}}",
"gps_accuracy": {{ trigger.to_state.attributes.gps_accuracy | int }}
}
Hope this will work? Both my gps based devices have an attribute battery, and Ive added battery: 0 to the router based sensor:
payload: >-
{
"latitude": "{{ states.zone.home.attributes.latitude }}",
"longitude": "{{ states.zone.home.attributes.longitude }}",
"battery": 0,
"gps_accuracy": 0
}
but somehow it won’t work…
I wonder, your automations seem somehow counterintuitive. In my settings home/not_home is used for the router /bluetooth detection, and the zones for the gps locations. You use these exactly the other way round. Shouldn’t the zones be used for the gps locations? Or is it only focusing on zone.home, while the gps automation’s to_state looks at all the other zones
Would seriously appreciate it if you’d had a look for me @NotoriousBDG, to what I am doing wrong here.
----edit—
found it! needs to be "battery_level".
not sure about the |int though. since "battery_level" : 0 is used for the router/bluetooth automation, I take it I’d need:
payload: >-
{
"latitude": "{{ trigger.to_state.attributes.latitude }}",
"longitude": "{{ trigger.to_state.attributes.longitude }}",
"battery_level": "{{ trigger.to_state.attributes.battery | int}}" ,
"gps_accuracy": {{ trigger.to_state.attributes.gps_accuracy | int }}
}
btw. why dont you use the double quotes on the gps_accuracy?
Not sure that 0 will do what you want. Your battery level will drop to 0 whenever there is an update from router/bluetooth. Perhaps {{ states.device_tracker.person1.attributes.battery_level}} would be a better option as it’ll just send whatever the current battery level is.
Because it’s an integer.
indeed, was wondering already
will test the device_tracker.life360 here, which is always on for now…
not sure I fully understand that. When to use double quotes and when not…?
FWIW, gps_accuracy and battery are ints, and latitude and longitude are floats.
cool this is.
have it set as follows now:
for the gps:
payload: >-
{
"latitude": "{{ trigger.to_state.attributes.latitude }}",
"longitude": "{{ trigger.to_state.attributes.longitude }}",
"battery_level": {{ trigger.to_state.attributes.battery | int }} ,
"gps_accuracy": {{ trigger.to_state.attributes.gps_accuracy | int }}
}
for the router:
payload: >-
{
"latitude": "{{ states.zone.home.attributes.latitude }}",
"longitude": "{{ states.zone.home.attributes.longitude }}",
"battery_level": {{state_attr('device_tracker.life360_marijn','battery')|int}},
"gps_accuracy": 0
}
HA frontend
more info
This has been a really useful thread…
As usual on this forum I have learnt yet more new things not even directly related to the actual original question.
Specifically, I didn’t know you could put a condition inside an action in an automation 
action:
- condition: template
value_template: "{{ trigger.to_state.state is not none }}"
@NotoriousBDG Is there any particular reason you are doing that rather than this?
condition:
- condition: template
value_template: "{{ trigger.to_state.state is not none }}"
or is it just your style preference?
you can use a condition in the action part, if you want more actions to take place based on added (sub) conditions.
If you have only 1 condition which has to be met for all actions to take place, you use the
condition:
condition: template
which means you’d never start an action with a condition… that should have been under the condition part of the automation.
I typically place conditions that use trigger in the action section because those are evaluated even when the automation is manually triggered via the UI. Since the trigger variable will not be defined when that happens, it’s easier to stop the action and prevent errors.
that is really a rather neat reason indeed, need to rephrase my answer above.
Still:
This confuses me… the trigger wont be defined, which means the action won’t fire, won’t it? What do you mean in that case with ‘stop the action and prevent errors’?
The trigger variable typically contains info about the entity or event that triggered the automation. If you manually trigger, it there isn’t an entity or event. For example, the first 2 conditions in this action will not be true if you manually trigger the automation via the UI. So this essentially prevents the notify.slack_notify service call from running.
action:
- condition: template
value_template: "{{ trigger.to_state.state is not none }}"
- condition: template
value_template: "{{ trigger.from_state.state is not none }}"
- condition: template
value_template: "{{ trigger.to_state.state != trigger.from_state.state }}"
- service: notify.slack_notify
data_template:
message: >-
{%- if trigger.to_state.state == "not_home" -%}
{{ trigger.to_state.attributes.friendly_name }} left {{trigger.from_state.state}}
{%- elif trigger.from_state.state == "not_home" -%}
{{ trigger.to_state.attributes.friendly_name }} arrived at {{trigger.to_state.state}}
{%- else -%}
{{ trigger.to_state.attributes.friendly_name }} left {{trigger.from_state.state}} and arrived at {{trigger.to_state.state}}
{%- endif -%}
If you manually trigger this automation via the UI, the action will throw an error because the condition is not evaluated and the notify.slack_notify service is called even through trigger is not defined.
condition:
- condition: template
value_template: "{{ trigger.to_state.state is not none }}"
- condition: template
value_template: "{{ trigger.from_state.state is not none }}"
- condition: template
value_template: "{{ trigger.to_state.state != trigger.from_state.state }}"
action:
- service: notify.slack_notify
data_template:
message: >-
{%- if trigger.to_state.state == "not_home" -%}
{{ trigger.to_state.attributes.friendly_name }} left {{trigger.from_state.state}}
{%- elif trigger.from_state.state == "not_home" -%}
{{ trigger.to_state.attributes.friendly_name }} arrived at {{trigger.to_state.state}}
{%- else -%}
{{ trigger.to_state.attributes.friendly_name }} left {{trigger.from_state.state}} and arrived at {{trigger.to_state.state}}
{%- endif -%}
A yes, I see, of course!
Ok, It is crazy but I have been struggling with this simple concept for days.
It just now dawned on me that obviously (to me anyway, although I MUST be doing something wrong) the problem I have is that triggering on the state change of, say, device_tracker.life360_me will only fire once when it leaves or enters a zone.
For example, I am in zone Home, state is home. I leave the zone so the state changes to not_home, and will stay that way forever until I enter another zone thus never triggering the automation.
Please! What am I doing wrong? - I can’t now see the wood for the trees.
well, this sound completely correct? What would you expect it to show, if you’re not home, or in another zone…it should show away. Unless you/ve arrived in another zone, in which case it should show the new zone
Thanks, well at least I am not going completely mad in the sense that yes that is what I expect it to do!
The madness comes in by not noticing that all this talk has been (only) about home presence detection rather than more general location positioning. That will teach me not to blindly follow a method to do something it is not meant to be doing just because it looks cool!
But all is not lost, I have learnt a great deal and this is indeed a great way to do what it sets out to do and I will continue to use it for that!!!
@Mariusthvdb I’m sorry to keep coming back to this but…
doesn’t
{% set zones = (states.zone | map(attribute='entity_id')) | list %}
return: something like:
['zone.place', 'zone.another_place', 'zone.place3']
which would mean that
trigger.to_state.state in zones or
trigger.from_state.state in zones
will never be true because the trigger.to_state and the trigger.from_state are both only the zone name without the zone. prefix?
As I said I’m sorry to keep this going but I just can’t get it to work so I am now questioning everything 
no i don’t think so, and the automation proves its correct working. Always a bit mind bending indeed, but the trigger (trigger.to_state) is the device, and the trigger.to_state.state is the zone it is in. Zoning gps devices have their zone.name as state, and the (friendly_)name is the name without prefix ‘zone’. I hope…
btw, i use this template not only as a sort of replacement for the ‘to’ and ‘from’ in the trigger section, and, importantly, to prevent unknown states and attribute changes from triggering the automation. these devices have many attributes that change all the time (battery…) whithout changing location, and we dont want these changes to trigger the automation
Yes it is bending my mind 
Are you saying that trigger.to_state.state and the trigger.from_state.state will return something of the form
zone.my_zone (with the .zone prefix)
because
{% set zones = (states.zone | map(attribute='entity_id')) | list %}
definitely returns:
['zone.place', 'zone.another_place', 'zone.place3']
at least it does in my dev templating tool.
PS I have my device trackers working well now; this is for something different.