Life360 Device Tracker Platform


#1

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.

The integration consists of two pieces - the lower level Python integration, and the Device Tracker platform. See details below for the files and where to place them.

Configuration parameters:

Add the following (adjusted to your needs) to your configuration.yaml file:

device_tracker:
  - platform: life360
    username: your_life360_username
    password: !secret life360_password
    interval_seconds: 10
    filename: life360.conf
    show_as_state: places, driving, moving
    max_update_wait:
      minutes: 30

interval_seconds is optional. The default is 12. This defines how often the Life360 server will be queried. The resulting device_tracker entities will actually only be updated when the Life360 server provides new location information for each member.

filename is optional. The platform will get an authorization token from the Life360 server using your username and password, and it will save the token in a file in the HA config directory (with limited permissions) so that it can reuse it after restarts (and not have to get a new token every time.) If the token eventually expires, a new one will be acquired as needed. The default filename is life360.conf, but you can change it to something else if you like.

show_as_state is optional. Without it entities’ states will be strictly determined by the device_tracker component. If specified must be one or more of: places, driving and moving. If places is specified then whenever Life360 reports a member is in a Life360 defined Place, the name of that Place will become the state of the device_tracker entity. If driving is specified and Life360 reports isDriving as true, then the entity’s state will be driving. If moving is specified and Life360 reports inTransit is true, then the entity’s state will be moving. If multiple options are specified and more than one becomes true at the same time, driving takes precedence over moving, being in a HA zone takes precedence over those two, and places takes precedence over all the others.

max_update_wait is optional. If you specify it, then if Life360 does not provide an update for a member within that maximum time window, the life360 platform will fire an event named device_tracker.life360_update_overdue with the entity_id of the corresponding member’s device_tracker entity. You can use this in an automation to be notified, e.g.:

- alias: Life360 Overdue Update
  trigger:
    platform: event
    event_type: device_tracker.life360_update_overdue
  action:
    service: notify.email_phil
    data_template:
      title: Life360 update overdue
      message: >
        Update for {{
          state_attr(trigger.event.data.entity_id, 'friendly_name')
        }} is overdue.

Also, once an update does come another event (named device_tracker.life360_update_restored) will be fired including the event_id, and another data item named wait that will indicate the amount of time spent waiting for the update. This could be used in an automation like:

- alias: Life360 Update Restored
  trigger:
    platform: event
    event_type: device_tracker.life360_update_restored
  action:
    service: notify.email_phil
    data_template:
      title: Life360 update restored
      message: >
        Update for {{
          state_attr(trigger.event.data.entity_id, 'friendly_name')
        }} restored after {{ trigger.event.data.wait }}.

prefix is optional. Default is to name entities device_tracker.<first_name>_<last_name>, where <first_name> and <last_name> are specified by Life360. If a prefix is specified, then entity will be named device_tracker.<prefix>_<first_name>_<last_name>.

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.

Implementation:

The first file you need, which is the low-level integration, is:

Place it in <config>/custom_components/life360.py, where <config> is your HA config directory.

The second file you need, which is the Device Tracker platform for Life360, is:

Place it in <config>/custom_components/device_tracker/life360.py.


Life 360 support
Show all attributes?
Life360 Error messages in my log
Should I Upgrade from 49.1 to newest Home Assistant
Life 360 support
Input.boolean statement when home using Life360
Simple thing, spent hours to no avail
Life 360 support
More than one ASUSWRT
Device tracker - Owntracks
Improving Blue Iris with Home Assistant, TensorFlow, and Pushover
Double trigger? home, not_home
#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?


#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.


#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


#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.


#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…


#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.


#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?