Life360 Device Tracker Platform

Third party integrations
1

Current link to custom Life360 integration:

pnbruckner/ha-life360: A Home Assistant integration for Life360.

The information below is obsolete and kept for historical reasons

Life360 is now a standard integration

This custom integration is now obsolete. It has been converted into a standard integration starting with Home Assistant release 0.95.

See these instructions for moving from the original custom integration to the standard integration.

Original topic…

There are a few different existing integrations for Life360. However they either depended on additional components (such as MQTT, which, granted, may provide useful additional features, but there seemed to be quite a bit of extra setup for a first time user) or they seemed a little inefficient by having to spawn shell commands.

So I found a lower level Python library that interacted directly with Life360 (using requests.) I took that as a starting point, enhanced it, and wrote a custom Device Tracker platform. I’ve been using it for a while now and thought others might find it useful as well.

Details can be found here:

One caveat: This depends on a cloud API that Life360 doesn’t seem to publish. Having said that, all the other integrations I found depend on the same thing, so hopefully it keeps working for us all! :slight_smile:

I’m open to any comments, suggestions, criticisms, etc.

16 Likes
2

Awesome! Any chance you could add an is_charging attribute (such as in the Hass.io addon)?

3

Sure. How does the attribute show up when using the Hass.io add-on? on/off? true/false? 1/0? Something else?

2 Likes
4

1/0 but it’s not a big deal (for me at least) to change my code, so if you’re thinking about submitting this as an official integration and true/false or something else would be the “proper” way to do it then I would go with that.

5

Ok. Yeah, Life360 provides that attribute with a value of “0” or “1” (i.e., strings.) I’m not really sure what the “proper” way is (I’ve only been using HA for a month or so :slight_smile:), but looking at attributes of other existing components it seems true/false would be the way to go for this attribute. I’ve already implemented it and now I’m testing (i.e., waiting for my phone to discharge enough so I can see an update while it’s charging! lol!)

Edit: Seems to work. Updated code above.

1 Like
6

@pnbruckner Yea, what I was saying in the other thread was that I was looking for one sensor/tracker that would directly talk to home assistant without something like mqtt in the middle but would also optionally post to an mqtt server like the code in https://github.com/skalavala/smarthome/blob/master/custom_components/sensor/life360.py does. (Lines 158-218 or so)
I use the own tracks recorder software as a logger and need to get the data to that, but like the integration of a device_tracker component for day to day automations.
So I am running the hass.io add-on from the other thread (which publishes owntracks_http directly to HA) along with that sensor. This means I hit the life360 api twice for each interval.

7

@shaddow, do you need the Life360 integration to directly post to MQTT, or can you set up an automation that does that? I.e., whenever a device_tracker entity changes have an automation take that entity’s info and then use a service to post the data to MQTT?

8

Yea probably a better idea. I added your code and then on event_state change I call mqtt.publish defining the topic and then a payload template

“payload_template”: “{“t”:“p”,“tst”:{{as_timestamp( now() ) | round(0) }},“acc”:{{ state_attr(‘device_tracker.name’, ‘gps_accuracy’) }},”_type":“location”,“alt”:“0”,"_cp":“false”,“lon”:{{ state_attr(‘device_tracker.name’, ‘longitude’) }},“lat”:{{ state_attr(‘device_tracker.name’, ‘latitude’) }},“batt”:{{ state_attr(‘device_tracker.name’, ‘battery’) }}}",
“topic”: “owntracks/name/name”

So far seems to work

1 Like
9

Also, can you add is_driving, is_intransit:, and wifi_state: the same way the charging is done?

10

Sure, I can do that. But I’m thinking of adding a monitored_condition parameter to control which attributes are added to the device_tracker entities. Besides the “standard” ones that the device_tracker component already supports, and last_update which I think should always be added, there could reasonably be another half dozen (or more) that people could want. That would put the total at around 14 attributes. That seems a bit excessive. On the other hand, I’m not really sure what is considered reasonable (for the number of attributes an entity should have.) Thoughts?

BTW, I’m dropping the circle attribute. I just did an experiment with multiple circles (I added myself to a temporary circle), and although in theory I could list which circle or circles each member is in, I don’t think it’s worth it. The way it is now only the first circle discovered would be listed, which is useless. And, besides, I don’t think the HA device_tracker entity needs this information anyway.

11

Never mind about the idea of adding a monitored_conditions list. I just went ahead and added the few extra attributes. I also changed is_charging to just charging. So now the list of attributes (besides the standard device_tracker ones) is:

last_update
at_loc_since
in_transit
charging
wifi_connected
driving

The first two are local datetime strings, and the others are true/false. I’ll update the code above next.

1 Like
12

Yea, I figure if it is something exposed in the api, might as well. I was planning on trying out the is_driving to use as a condition or check on my garage door opening automation to avoid it triggering if we leave out the back door and go for a walk. Or sticking a tile tracker in the car so if it’s moving as well…

1 Like
13

Just wanted to know how someone might use these attributes?

Say for example I wanted to show the state of the device in HA? As in, is it charging, is it connected to wifi, what is the battery level.

Also, is there a way that I could use these attributes to update the device tracker entity to display ‘driving’ or ‘in transit’ as well as ‘away’ and ‘home’?

Just trying to figure out how I’d do those things.

Also, can we force the device to check in to get an updated location? Or is that not possible with the api?

14

Well, a couple of disclaimers first: 1) I’m very new to HA, and 2) I don’t “use” any of these attributes, other than to look at them. Oh, and 3) my answers tend to be a little long-winded! :slight_smile:

You can, of course, use the attributes in automations and scripts just like you can use attributes of other entities. Nothing special here. Why would you use them? Check out @shaddow’s reply above for one idea. Or are you asking for a concrete YAML example (i.e., are you asking about the mechanics of actually using them)?

Regarding displaying/seeing them in the “frontend”, well, you can see them on the States page:

image

And you can see them in the entity:

image

Those are both stock HA things.

Regarding updates, this platform only supports polling. It periodically polls (based on the interval_seconds you set in configuration.yaml) the Life360 server for the status of members. The data it gets back, besides the location and all those other attributes, includes a “last update” timestamp. This is when Life360 itself updated its own database as to the whereabouts of the member. My platform effectively updates HA when it sees a newer timestamp since the last time it polled.

BTW, if you set logging to the debug level, you can search the HA log to see the activity of this platform. You will see a “Checking members” message every interval_seconds. Then, whenever a newer “last update” timestamp is retrieved from the server you will see an “Updating …” message. E.g.:

2018-05-09 11:35:52 DEBUG (Thread-11) [custom_components.device_tracker.life360] Checking members.
2018-05-09 11:36:03 DEBUG (Thread-8) [custom_components.device_tracker.life360] Checking members.
2018-05-09 11:36:04 DEBUG (Thread-8) [custom_components.device_tracker.life360] Updating phillip_bruckner. Time since last update: 0:13:47.
2018-05-09 11:36:14 DEBUG (Thread-16) [custom_components.device_tracker.life360] Checking members.
2018-05-09 11:36:25 DEBUG (Thread-4) [custom_components.device_tracker.life360] Checking members.

It’s kind of a neat way to see how often Life360 actually updates its information. FWIW, I’ve noticed, if you’re moving, the updates seem to come about every 45 seconds. But if you’re not moving, then the updates tend to be more in the 10 to 30 minutes range. I believe this is how they keep the information relatively accurate without draining your battery! :slight_smile:

Anyway, I don’t use the Life360 check-in feature, but I suppose if you do, that will cause their database to be updated, and then the next time this platform polls it should see a new “last update” timestamp, and hence, update the corresponding device_tracker entity.

1 Like
15

You would use value_templates sensors and pull the attributes.
I am not sure if you can trigger a location update. I don’t believe there is an official documentation as far as the API. I think most of the work on this has been what people have figured out? I do know the app itself can request updates so it may be possible.

16

I should probably also mention that if the data retrieved from the Life360 server indicates that the member is in a Life360 “Place”, my platform will report that to the Device Tracker component as location_name. (I made sure the platform reports the Life360 Place named “Home” as “home”, because that name is special.) So if you have any Life360 Places defined besides Home (which I don’t), and you enter one of those Places, the corresponding device_tracker entity’s state should be shown as the name of that Place.

17

I believe you are correct. At least, this is how I’m doing it. I found various implementations that show how to query the Life360 server for the list of circles, and the details of each circle. I then used Postman to retrieve the data, and based my implementation on what I got. I’ve searched high and low and I can’t find anywhere that this API is documented. In fact, I tend to think that Life360 is keeping it “secret” on purpose, which if it’s true, I don’t understand. They must know that people are pinging their server, because you have to have a valid “API key”, and there appears to be one that everyone is using. I’m just hoping they don’t decide to invalidate that key, because if they do …

18

That would be a sad day. They even said in december on twitter that they do not have a public API. I looked and couldn’t determine where that authorization token originated from so I don’t know what it would take to get a new one if it did change. I am getting ready to augment life360 with geofency and use Bayesian sensors along with seeing phe phone on my unifi controller to take some of the risk of the api disappearing one day away. Thing is they have some secret sauce that lets them do location better and more frequent with less battery than anything else I have found. Owntracks used 17% of my battery doing background location in the last 7 days and barely gave any location updates and life360 used 1% and this thing polls it like every 12 sec.

19

Totally agree. I’ve been using Life360 for almost 5 years. First by itself. Then integrated with Nest. Then integrated with SmartThings, and now with HA. Yes, sometimes the Android or iOS apps get into a state where they don’t update the server, but that doesn’t happen very often. In general, it works great.

FWIW, the Nest integration was “official”, and advertised by both parties. But a year or so ago (I lose track of time) it broke and neither party would admit it or do anything about it. That was fairly frustrating. But then I started using ST and that integration was also “official” (I think), and worked “ok”, but with all the cloud servers involved, it was extremely sluggish and sometimes just didn’t work. One of the reasons I’m on HA now.

Unfortunately, like you say, the other options don’t seem to be very good either. I’ve tried using IFTTT, with two different kinds of "THIS"s (connect or disconnect from home WiFi, and enter or leave a location), but I’ve found it to be extremely unreliable. I haven’t tried Owntracks because I’ve seen the reports of terrible battery usage. And the HA Ping presence sensor isn’t a very good option either because cell phones have this nasty habit of trying to save battery power and, hence, not always responding to pings.

At some point I may be forced to do what you’re doing, but for now I’m keeping my fingers crossed that, even if Life360 doesn’t officially support what we’re doing, they keep looking the other way and letting it happen. Now that’s a strategy! :blush:

20

Thanks for the responses guys.
I know how I’ll use this now.

Just need ot figure out why it’s not loading the platform.

I have:
/config/custom_components/life360.py
and
/config/custom_components/device_tracker/life360.py

but I keep getting ‘Unable to find component device_tracker.life360’

Have I got that config wrong?

1 Like