Oh I ssseeeeeeee… ! Thanks for this. So if I make my HA config GPS radius bigger I might see this happen less. Thank you. 
I don’t really say this on the doc page (maybe I should ), but there still may be a difference between how HA decides a device_tracker is in a HA zone vs how Life360 determines if a device is in a Life360 Place, even if the HA zone and corresponding Life360 Place are identical in location and radius, and both systems have the same GPS coordinates for the device. I know HA’s algorithm, but I don’t really know Life360’s.
HA decides a device is in a zone when the circle representing the zone overlaps with the circle representing the device. (The device’s circle is centered on the device’s GPS coordinates, and the radius of the circle is its current gps_accuracy attribute. You can easily see what I’m talking about by looking on HA’s map when the device is not home.) So, even when the device is not strictly in the zone (just by the GPS coordinates), HA may say it is (if the device’s circle is large enough to touch the HA zone.)
Again, I don’t know how Life360 decides a device is in a Place. So, even if HA’s home zone is identical to Life360’s home Place, they still might disagree about whether or not the device is “home.”
Probably the best chance for making them agree is to include places in show_as_state, and make HA’s zone.home much smaller than Life360’s “Home” place (and make sure home_place is set correctly.) This way HA will always say the device is home when Life360 does, and the likelihood of HA saying the device is home when Life360 does not is minimized. (You could also set HA’s zone.home to be somewhere in Antarctica, and that way you can be pretty sure that HA won’t say you’re home when Life360 doesn’t! 
Of course, that might mess up other things, like sun.sun, …)
Personally, though, I use add_zones: all, which makes HA’s zone.home agree with Life360’s Home Place, and I don’t worry so much about the two systems having slight disagreements about exactly when a device enters a zone/Place.
1 Like
Released 2.7.0
Treat errors during setup (other than login errors) as warnings and continue. (Also bumped the version of the lower level life360 package, which is automatically installed from PyPI, to 2.2.0.)
I wasn’t sure whether to do this as a message or a reply to this thread - but Phil, do you personally do any kind of checks on whether a device is reporting to Life360? For some reason my wife’s phone just totally stopped reporting for about a 26 hour period. No idea why. I opened the app on her phone (it was already open as far as I can tell) and it restarted. But for presence detection it would be handy to be able to get notice of this problem before it goes so long next time! Thanks
You should probably check the support/FAQ page on www.life360.com.
But I can tell you from my own experience, using Life360 on two Android phones (one of which that is always in power saving mode), and one iOS phone, that there can be dropouts, and some for quite a while. The worst, in our experience, is with the iOS phone (but that could just be the Internet coverage in the area.) This is why (as I’ve explained before) I use both Life360 and Google Maps Location Sharing combined with my composite tracker. For some reason, which I can’t explain, running both on the same phone seems to let each “fill in the gaps” of the other.
Regarding being informed when this happens, you should check out the max_update_wait config variable, and this example in particular.
EDIT: While we’re on the topic…
When HA starts, if the “last seen” value from the server exceeds the max_update_wait setting the corresponding event will be fired at that time. However, I just recently noticed that this happens before automations are ready, so it will basically be missed. (It’s still in the log, but…) I will probably work on a new release that delays that first event long enough to make sure automations are ready to catch it.
1 Like
Thanks! Trying to get the example to work…
device_tracker:
- platform: life360
username: [email protected]
password: xxx
prefix: life360
show_as_state: driving, moving, places
driving_speed: 18
max_gps_accuracy: 200
max_update_wait:
minutes: 45
- alias: Life360 Overdue Update
trigger:
platform: event
event_type: life360_update_overdue
action:
- service: notify.iphone
data_template:
title: "Overdue Update"
message: "Update for {{state_attr(trigger.event.data.entity_id, 'friendly_name') or trigger.event.data.entity_id}} is overdue."
target: ""
I get
Error rendering data template: UndefinedError: 'trigger' is undefined
5:14 PM helpers/service.py (ERROR)
in my log.
Will do some more testing/experimenting anon.
Thank you.
A work in progress for me!
That’s supposed to go under automation, not device_tracker.
If you have this exactly as shown then you need to make the following change:
automation: ##<----ADD THIS##
- alias: Life360 Overdue Update
trigger:
platform: event
event_type: life360_update_overdue
action:
- service: notify.iphone
data_template:
title: "Overdue Update"
message: "Update for {{state_attr(trigger.event.data.entity_id, 'friendly_name') or trigger.event.data.entity_id}} is overdue."
target: ""
Edit: Or what pnbruckner said^^^^ 
1 Like
Sorry (and thanks!!) to @atomicpapa and @pnbruckner - it IS separate. I thought I’d added enough line breaks in my post above to show them as separate code snippets but obviously not as they are merged in the post. They were showing as distinct in the preview.
So yeah, the alias trigger is in my automations and the device_tracker info was just there to show how I’ve implemented max_update_wait.
Ok, so it’s still not working then?
I do now see the error was in the service call, not the config.
But that error doesn’t make any sense. The trigger variable should exist.
I’m getting the following warning in HA 0.88. Do we have to change anything, or will this be done in a future update of your excellent component?
Integrations need to be in their own folder. Change device_tracker/life360.py to life360/device_tracker.py. This will stop working soon
Well, I’m still on 0.84.6 and probably will be for a while, so I can’t really test it myself. Plus, whatever I do would still have to work on previous versions for those that haven’t updated either.
Could you do me a favor. Could you try moving the file accordingly? I.e., create a folder in <config>/custom_components named life360, and copy my life360.py file there and then rename it to device_tracker.py. Then restart and tell me how that goes?
Invalid config for [device_tracker.life360]: value is not allowed for dictionary value @ data[‘add_zones’]. Got ‘include_home_place’. (See ?, line ?). Please check the docs at https://home-assistant.io/components/device_tracker.life360
Was?
Can you share you current life360 configuration (with sensitive information redacted)?
device_tracker:
- platform: life360
username:
password:
interval_seconds: 10
filename: life360.conf
show_as_state: driving, moving
driving_speed: 20
add_zones: include_home_place
max_update_wait:
minutes: 30
Oh, yeah, that was a setting only in the beta. I changed the add_zones options to false, only_home, except_home or all. If you still want the same functionality, change it to all. See Configuration Variables for more details.
Yes, that works ok. No more warning and device_tracker seems to work fine
Ok, thanks. For now I guess I’ll just note this in the installation instructions. What a PITA. 
The downside is that it does not show up in the custom_updater anymore. I also wonder if this would also work on older versions.
I see that an issue already raised about this. https://github.com/custom-components/custom_updater/issues/90 .
I also see that a lot of changes have been made to the custom updater around how it is configured. Holding off updating for a bit longer