Just to clarify it’s not yet an official integration. Not until the next release (v95). You can use it as an integration now using the v95 dev version. But don’t expect it to work as an integration until you are on some style of version 95.
Hi,
just to let you know using the great Life360 CC, I’ve been able to persuade @ludeeus to help me add ‘country’ to the attributes of the device_tracker, and a lot more.
He made an AppDeamon app that uses the device_tracker.life360_name as input, and has it query an external python library, to add all available geo attributes to the existing device_tracker.
I can now show a country flag, simply based on a devices location 
see How to iterate over a timezone list in (python) to find country(code) for all details, and enjoy.
It was my first iteration in AppDeamon, and I really like it…
1 Like
Not exactly sure what your point is. It is available in version 0.95.0b1 and greater. You can install a beta version without having to clone and checkout from github. Instead of the usual upgrade command:
pip install --upgrade homeassistant
you can specify a beta version:
pip install homeassistant==0.95.0b3
And if you’re using some install method where you can’t use pip and you’re hands are tied, well, then I guess I can’t speak to that.
Hi Phil,
As Ive only found out just now, the life360 device_tracker can show an incorrect attribute for time_zone now and then. One of my family members was displayed to be in Europe/Berlin, while the lat/lon gives the correct address in my own country. (before you ask, this is on a HA instance without my AppDeamon app for the extra attributes…)
On the instance that has the App installed, the same incorrect time_zone is displayed, but all the extra attributes are 100% perfect, based on the lat/lon
Is the attribute time_zone taken from the Life360 source, or is it calculated in your component? If the former: probably can do nothing about that, if the latter, maybe have another look?
ok, well, I am not familiar with that of course, but simply noticed today that I was in Brussels today (which I was not), and my daughter is still in Berlin (which she most definitely is not …)
maybe the geopy package (which my AppDeamon app uses to find the extra attributes) finds a better time_zone?
Brussels and Berlin are in the same time zone, GMT+2. It’s reporting a zime zone, not a city.
ah, with time_zone, I meant the attribute time_zone, as Europe/Amsterdam, not the GMT setting. As displayed on your device_trackers:
more-info
and
dev_state
figured these are the timezones: https://www.php.net/manual/en/timezones.php and not the GMT settings, which can indeed lead to an incorrect time_zone
Yes, it’s a time zone, not a city. ‘Europe/Berlin’ is the same as ‘Europe/Brussels’, they’re both GMT+2. I’m just taking what timezonefinderL returns.
well, that’s not correct then… there are many cities/countries in the same GMT zone, which leads to false conclusions possibly. As we see now.
Not sure what geopy returns for time_zone (I don’t use that for my AD app) but it does get all other attributes 100% perfect. Maybe worth a quick look?
Why do you say it’s not correct? It’s not trying to report a city. It’s only trying to report a name for the time zone, which as you say yourself, contains many cities. If ‘Europe/Berlin’ and ‘Europe/Brussels’ are equivalent, then from the perspective of indicating the zime zone, either is just as good as the other.
What is not correct is drawing the conclusion that a time zone indicator is also a city locator. It’s not.
you must understand that… and of course I understand it’s not reporting a city, but the continent and capital of the country the lat/lon belong to.
if
It’s only trying to report a name for the time zone, which as you say yourself, contains many cities. If ‘Europe/Berlin’ and ‘Europe/Brussels’ are equivalent, then from the perspective of indicating the zime zone, either is just as good as the other.
than you could probably agree that isn’t the optimal perspective… What would be correct is displaying format UTC +2 for my timezone. translating that to any of the possible (many tens of) time_zone names is a bit risky as it now turns out to be. What use is an incorrect attribute .
All the more, if another package could do this better (and of course I don’t know that, merely reporting what it does do perfectly), why not give it a look?
I mean, if the component bases all info on the given gps’s lat/lon, shouldn’t it be getting the correct time_zone’s name?
No, it’s not reporting that either.
First and foremost, the datetimes reported have the correct time zone “suffix”, e.g., ‘+02:00’. Reporting a name for the time zone was as easy addition. And when there are multiple choices, then any is as good as another for reporting a name for the time zone.
I’m sorry you’re trying to derive a city location from the time zone name. That’s not a valid thing to do. The attribute’s name is time_zone, not city, or even location.
If you want to report a city name for the GPS coordinates, that’s a feature request. And since I’m not working on the custom component anymore… 
EDIT: I just checked the code again. In fact, it’s getting a time zone name directly from timezonefinderL, then it uses a HA utility to convert that to a tzinfo. So if you have an issue with the choice that timezonefinderL is making, Issues · jannikmi/timezonefinderL · GitHub
EDIT 2: Looks like there is a new version of timezonefinderL. I used 2.0.1, but now there is a 4.0.2. (Don’t get too excited, 4.0.2 is the next release after 2.0.1. lol!) Anyway, you can try changing the version in manifest.json and restart HA and see if it gives you any better results.
geopy can get city, country, etc from the lat/long values…not sure why you’re not getting the extra location details you want directly from the precise location rather than using timezone…
My point was that if they tried to configure the life360 integration in any version less than some flavor of V95 it won’t work.
I was saying that for the integration to work they would have to install some version of 95.
Ok, I was confused because I’ve said multiple times it’s available in 0.95.0 beta releases which are available now and have been since 6/19.
Guess it doesn’t hurt to make sure. 
1 Like
Whats the battery drain on Life360 like compared to Owntracks? Is Life360 better overall in terms of accuracy?
100% yes yes yes yes
I’ve used both and OwnTracks was a battery hog. I switched to Life360 before it worked with HASS and started using this app as soon as I saw it on the forums about a year ago. At the time it was more important to have an accurate location on my children than it was to have that location included in HASS. Integration into HASS was just the icing on the cake and this CC has always proven to be fantastic. Glad to see it going “official”.
I’ve only used OwnTracks for a very short time, and that was mostly for testing a fix I made to the integration. I don’t really have any experience with it’s battery usage to share.
Life360’s claim to fame is its ability to provide fairly responsive and accurate location information while minimizing battery drain. They are a for profit company with paid staff as opposed to an open source project. Although I have no scientific data to back it up, my money (literally) is on Life360 (i.e., I have a paid subscription. )
You might want to search the forum. I’m sure there are plenty of topics in which people share their experiences with OwnTracks.
EDIT: FWIW we’ve been using Life360 from August 2013, first just the app, then with SmartThings, and now with HA. It’s been installed on multiple cell phone models over the years, including both Android & iOS, and we’ve never noticed a battery issue. E.g., I just looked at the battery usage on my Android phone and it says Life360 has used 1%, same as Google Maps, and very much less than most of the other apps & system processes listed. I think that’s pretty typical.
We have been using Life360 for about 5 years and its been great with minimal battery impact!