FWIW, for battery charging, I’ve found that some apps report if the device is plugged into a charger, whereas others report if the device is actually charging (i.e., plugged in but not yet 100%.) I believe Life360 reports the latter.
Can you elaborate on what you mean by “big commitment”?
I assume that you are referring to supporting that component? Meaning you would feel more obligated to maintain the project?
If that is the case, I agree. I have added several things to Home Assistant and I feel obligated to keep them “working” however I don’t think it is difficult to do so if you are actively using it yourself. Several of the things I have added, I don’t own/use in my HA setup so I have attempted to find other devs out there to take over the initial implementation and maintain it. So basically in my experience as long as I am using the integration myself it doesn’t feel like a big commitment because I am directly benefiting from maintaining the integration.
Just thought I would provide my 2 cents. Thanks for the great work! Best device tracker I have found for using with my wife’s iPhone.
Finding the Life360 custom component really useful and have been using it for a few days.
I’ve just amended my configuration to automatically add places in Life360 as zones in HA.
I’m currently using the free version of Life360 which allows the creation of two “places with alerts” and multiple “places without alerts”. The “places with alerts” have indeed been created as zones in HA but the “places without alerts” haven’t.
Does this mean I’ll need to subscribe to have all places added as zones?
Thanks for your help.
I use the free version, and I have four Places (without any alerts set), and they are all getting picked up and turned into HA Zones.
If you have DEBUG set (which is the default), then you should see messages in home-assistant.log similar to these:
pi@raspberrypi:/home/homeassistant/.homeassistant $ grep Places home-assistant.log
2019-01-15 09:19:56 DEBUG (Thread-16) [custom_components.device_tracker.life360] Checking Places
2019-01-15 09:19:57 DEBUG (Thread-16) [custom_components.device_tracker.life360] Adding zones for Places: ...
2019-01-15 09:19:57 DEBUG (Thread-16) [custom_components.device_tracker.life360] Will check Places every: 1:00:00
What do you see?
Thanks for the prompt reply. I’m using HASSIO and not seeing any debug type logging for the life360 component in home-assistant.log. I assume I’ll need to amend my configuration.yaml to enable debug mode for the life360 component?
Would i just add
logger:
default: warning
logs:
life360: debug
EDIT: Enabled debugging and now see this
`2019-01-15 16:33:53 DEBUG (SyncWorker_7) [custom_components.device_tracker.life360] Adding zones for Places: Hospital:
I have removed “places with alerts” from the Life360 app and now just have 5 “places without alerts”. None of the places appear in HA.
The debug logs are
2019-01-15 16:47:58 DEBUG (SyncWorker_8) [custom_components.device_tracker.life360] Life360 communication successful!
2019-01-15 16:47:58 DEBUG (SyncWorker_8) [custom_components.device_tracker.life360] Configured members = None
2019-01-15 16:47:58 DEBUG (SyncWorker_8) [custom_components.device_tracker.life360] Checking Places
2019-01-15 16:47:58 DEBUG (SyncWorker_8) [custom_components.device_tracker.life360] Will check Places every: 0:15:00Interesting.
Well, my scenario is actually slightly more complex than I first described. I have two Circles - the “main” one for my family, and another one I created just for testing the code that creates HA Zones from Life360 Places. In my “main” Circle I have just one Place named Home (which a Zone is not created for because it is named “Home”.) In my other Circle I have four Places (with other, unique names.) In the Life360 app, all of these places (in both Circles) are listed under “PLACES WITH ALERTS”. The four Places in the second Circle also all appear as Zones in HA.
Even though I have four Places defined in the second Circle, and they are listed under “PLACES WITH ALERTS”, they don’t actually have any alerts set. In fact, if I click on one of them in the app, it goes to a screen that says “Sorry! You’ll need to add at least one member to your account for Places to work”, and there’s a “Invite Family Members” button. In case it’s not obvious yet, in this second Circle I have no other Life360 Members than myself. The other data point is that I added these four Places to this second Circle right after creating the Circle. I think when you create a new Circle it automatically has a free trial of Life360 PLUS associated with it, and therefore, let’s you create more than two Places. But that was done long ago enough that the free trial is over. Now when I click the ADD button it brings up a dialog to upgrade to Life360 PLUS.
Hmm… Maybe I’ve found a loop-hole in their implementation. 
The bottom line is, my Life360 platform code can only see what the Life360 server tells it. The server is being queried for all the Places defined in all the Circles associated with the username in the HA config. If the server is only reporting a subset of the Places, then that’s all HA can see. Maybe there’s a way to query the server for those other Places, but again, this server API is unsupported and undocumented, so there’s no way to know. In fact, I had to guess how to retrieve the Places in the first place. 
Am I the only one not finding the file for the low level integration? Getting a 404…
That is making sense. I think you’re right regarding the number of “PLACES WITH ALERTS” you’re able to create when you first install the app because you’re on the 7 day trial. Unfortunately, I only created 2 initially, and now the trial is over, it won’t let me create any more without subscribing. It would appear the “PLACES WITHOUT ALERTS” don’t actually get reported as places.
Oh well, l assume if I create the zones manually within HA, it’ll all work fine.
1 Like
Currently the custom component consists of just the one life360.py file (which needs to get copied to <config>/custom_components/device_tracker/life360.py, where <config> depends on your installation.) The “low level integration” now exists on PyPI, and should be installed automatically by HA when you restart. There are some indications that it might take two restarts, but I haven’t verified that yet. I do plan to spend some time before too long to see if that is true or not.
Where do you see “404”?
Hmm, maybe you’re trying to follow links at the top of this topic. Unfortunately they are no longer valid, and also unfortunate is that the forum won’t let me fix those initial posts anymore. You should check out the doc page for my custom component:
Indeed! Thank you for that clarification.
1 Like
Sorry, it’s been a while. 
I now have a Beta version that adds a new config option that will cause the datetime attributes (last_seen & at_loc_since) to be in the local timezone. The new option is times_as_local and its default is False. To have the attributes expressed in the local timezone, set it to True. E.g., add this to your config under platform: life360:
times_as_local: true
Note that since either way the attributes are Python datetime objects that are timezone aware, if you use their values in templates, for the most part, things should still “just work.” E.g., as_timestamp(states.device_tracker.life360_me.attributes.last_seen) will produce the same value either way. But, if you “get fancy” and, e.g., use the hour attribute, that will (usually) be different in the local timezone vs UTC.
Anyway, if anyone would like to try this, the beta can be obtained here. I plan to make the same change to my Composite tracker.
If you do give this a try, and run into ANY issues, please, by all means, let me know.
Hang on, can I just clarify that this change will allow us to extract the local time for the device (person) being tracked and hence inhibit ‘out of hours’ Telegram (for example) notifications to that person.
This will be great, I have been waiting to be able to do this for ages. I’d love to say I will test the new version but I have no travel plans for a while (and I’d really like it in the Composite tracker).
By “local time” I mean local to your HA installation. I don’t mean where the device (i.e., phone, whatever) is. Kind of like the difference between utcnow() and now().
Ah, I see. Ok.
Thanks.
Actually, there is a Python package called timezonefinderL that looks like it might be a reasonable way to convert GPS coordinates to a timezone. I might play around with it. Although I did a quick search and I don’t see any other HA components that use it. If it seems to work reasonably well (and doesn’t seem to chew up too many resources), I might think about using it. I could see having optional attributes that show the times in the device’s timezone as well (assuming, e.g., it is in another timezone than HA.)
1 Like
Well, I tried. I could install and use timezonefinderL on an x86 system. But when I tried to do the same on my pi, it didn’t work. timezonefinderL requires numpy, and apparently numpy doesn’t work on a pi (when simply installed via pip.) I did a quick bit of searching and it looks like there are ways to get numpy to work on a pi, but they involve installation steps that I don’t think HA can do automatically. So to avoid potential problems that I wouldn’t know how to deal with, I’m scrapping the idea.
Also, on my x86 system, numpy required 70MB of storage alone, and timezonefinderL required another 9MB, which is huge compared to all the other Python packages installed for HA.
There are other Python packages available that can determine timezone from GPS coordinates, but they query servers, and I’m not sure I want to go that route. timezonefinderL had the advantage of having its own local data set which didn’t require querying a server every time.
Ok, no problem, thanks for trying!
So, turns out, there are a couple of standard HA components (such as the binary trend sensor) that use numpy. And if you search this forum, you’ll find people have run into this same issue trying to use those components on a pi.
Long story short, to use numpy on a pi (at least one running Raspbian that isn’t too old, and which uses piwheels) requires installing an extra library, specifically libatlas – atlas stands for Automatically Tuned Linear Algebra Software. To do this, use this command:
sudo apt install libatlas3-base
(See this web page for more details.)
Once that is done, then when HA installs numpy (or if it is installed manually), it will actually work! Which means timezonefinderL will actually work, too!
So, game back on!!
So, can you tell me more about how you’d use this?
Right now the only attributes with time are last_seen and at_loc_since, neither of which is the current time. They are both timezone aware Python datetime objects. Previously they were always in UTC, whereas with the change I’m working on now they can be in the timezone from HA’s config. (There are also last_changed and last_updated fields of the state object, but those are always in UTC, and also are not really the current time.)
Let’s say I add new attributes that are influenced by the timezone where the device is physically located. Some possibilities that come to mind are adding last_seen_d & at_loc_since_d, which would be the same values as the existing attributes, but in the timezone of the device. That would be easy to add. But then, how would you use them? You could compare them to the corresponding attributes (in UTC or HA local), but as a whole, they are the same (i.e., last_seen and last_seen_d would be the same time, just in different timezones. E.g., if you subtracted them, you’d get a timedelta object whose value is effectively zero.) I suppose you could look at their hour attributes (e.g., last_seen.hour and last_seen_d.hour) to figure out the difference in the timezones in hours. Or you could use the output from their tzname or utcoffset methods; the latter might be more useful. E.g., last_seen_d.utcoffset() would return a timedelta object representing the offset from UTC of the device’s timezone.
Or do you think it might be more helpful to include other new attributes, e.g., maybe the name of the device’s timezone? Or the offset from UTC and/or HA local, as a float?
In summary, I think it would be nice just for display purposes to have the last_seen and at_loc_since values available in additional attributes where they are in the device’s local timezone. It might also be nice to have a new attribute that shows the name of the device’s timezone. But for automation purposes, I’m wondering what would be most helpful. Maybe add the three new attributes I just described (i.e., last_seen_d, at_loc_since_d & timezone_d), and one more attribute with the device’s timezone’s UTC offset as a float.
Thoughts?