Life360 Device Tracker Platform


lol! I just realized what I was looking at was not the speed attribute from my device_tracker entity, but that times another 2.25! This is from a template sensor from before I changed the speed attribute from the raw speed value from the server to the estimated mph speed. (I.e., from when I was doing testing before the release.) So the 150 was actually only 67 mph. :smile:


still trying to settle my automations down on this device_tracker, I am surprised as to how many states it can have…
I believed Moving, Driving and Away to be attributes, but now I re-read I understand why they pop-up. Away btw isn’t listed, but I take it thats HA itself, changing not_home to Away? Had to add it to the templates logic though to not have it notify something like

Marijn left Home and arrived at Away…

using this

  - service: notify.m
      title: 'Presence Tracking:'
      message: >
        {% set name = trigger.to_state.attributes.friendly_name %}
        {% set to_state = trigger.to_state.state %}
        {% set from_state = trigger.from_state.state %}
        {{as_timestamp(now()) | timestamp_custom("%X") }} :
        {% if to_state == 'not_home' %}
          {{-name }} left {{from_state}}
        {% elif from_state == 'not_home' %}
          {{-name }} arrived at {{to_state}}
        {% else %}
          {{-name }} left {{from_state}} and arrived at {{to_state}}
        {% endif %}

to be sure, the devices can be home and not_home, Away, Moving, Driving (with capitals), and in any of the defined zones, is that correct?

I created below conditional value_template to prevent triggering in case of:

  - condition: template
    value_template: >
      {{ trigger.to_state.state is not none and
         trigger.from_state.state is not none and
         trigger.to_state.state not in ['Moving','Driving','Away'] and
         trigger.from_state.state not in ['Moving','Driving','Away'] and
         trigger.to_state.state != trigger.from_state.state }}

other than that, the Component is been a huge improvement! Too bad the attributes driving, moving and speed aren’t very accurate, otherwise it is a near perfect tracker. Thanks!


moving and driving are attributes, and when True they can cause the entity’s state to be Moving or Driving if you have show_as_state set that way. It’s your choice if you want the state to be able to take on these values or not. So the attributes are always there, but you can control which, if any, might show up as the state as well.

device_trackers can have the states 'home' and 'not_home' (among others.) Those are the actual states, and what you need to use in automations, etc. But they display in the frontend usually as ‘Home’ and ‘Away’. See Device tracker states. This is not unique to this platform.

Close, but no. 'not_home', 'home', a HA zone name, 'Moving', 'Driving', a Life360 Place name, or a Life360 check-in name. The first three are generic features of the device tracker component. The rest are features of the Life360 platform and are optional (depending on what you set in show_as_state.)


I updated the state chart to (hopefully) make it a bit clearer. Note that if show_as_state is removed from the config, the three rows that remain describe the generic behavior of the device tracker component.


thanks Phil, will check and see/test further.
btw, after the latest update, I still go a raw speed of -1 today? just letting you know.


Yep, raw is raw, i.e., not filtered or processed in any way.



i misread this:

sorry. my bad.


getting back to you about the updating ‘issue’ when and displaying ‘Home’ while not connected. I have a phone in repair now… been away for 4 days, and it is wiped. The life360 website displays that correctly as it states:

'User' is not connected to Life360
This user has lost connection to Life360. Visit our troubleshooting guide to help them reconnect.
*Last updated 4 days ago near Home,*

the device_tracker in HA still shows home though. and confuses all other logic based on that. I can set the state manually to get things back on track for the HA session, but after a reboot the device is back home again. I cant help thinking this is not expected behavior for your CC, and somehow could be changed to reflect the status of the life360 server, at least sense ‘Lost connection’ ?


last_seen is correct:
last seen: 2018-09-30T18:30:31+00:00

thanks for considering again…

have some feature requests, maybe you could give a thought:

  • automatically create a Map_url to be able to use in a camera: still_image card? like @tenly2000 does in his CC Places Would be way cool if possible. Especially if we could stay away from Google
    Related would then be new attributes distance_from_home and direction… I know we can use the device_tracker in Proximity and Waze travel time etc, but how nice would it be if all that would be unnecessary , and be provided by 1 complete tool?

anyways, thanks!


I think what you’re seeing is the recorder is restoring the last known state of the entity (like it does for other entities at restart.) If the last update from the Life360 server showed you at home, then it will still be that. If there’s been no further update from the Life360 server, then there’s nothing to update the state of the device_tracker.

But, you should have seen an error – basically the same error you’re seeing from the Life360 website. I’ve definitely seen that myself in HA.

Also, when the entity is restored by the recorder, it won’t have all the same attributes. It will only have a basic set of attributes. E.g., it shouldn’t have all the Life360 unique attributes (like moving, driving, even last_seen.)

I’ll have to give this some thought. I don’t think the state should be changed (e.g., to something like ‘unknown’) for every communication error. And like I said, I have seen this error before. But I suppose maybe if it happens for a minimum number of samples or a minimum amount of time, then it might make sense to do something.

But if you’re seeing the errors in HA…


check, that must be it.

no I haven’t seen anything other than the first error we discussed before, and the component suppressing further errors …which, as I have just discovered, isnt displayed any longer in the log ?

here’s what’s showing:


Can you remind me exactly what that error was?

If you have debug turned on, can you do this:

grep -F '[custom_components.device_tracker.life360]' home-assistant.log

And let me know what that looks like? Maybe it would be best to start a private message session for this.

If the device_tracker entity has all the usual attributes, then unless I’m overlooking something, I think that means that my CC was able to communicate to the Life360 server and was able to retrieve a “normal” response that basically just said, “hey, here you go, here is the last information I have for this member.” I’m not sure that there’s anyway for my CC to determine from the server response that it has lost connection with the device. But, …

As I said, I have seen the “lost connection” error before, but I’m wondering if a change I made to deal with a member who is in multiple circles, but only shares their location in a subset of those circles, might have prevented the “lost connection” error. Hmm. I’ll do some more testing to see how the current version of my CC reacts in these various scenarios.


see Life360 Device Tracker Platform

and your repo issue#12 to suppress it

will do the debug later on, thanks!


So, turns out there is a “disconnected” field in the response from the Life360 server. It might be possible to use that. Unfortunately this is going to be difficult to test. I’ve seen updates for a device stop for over 5 hours, and I don’t think (although I’m not sure) that the “lost connection” error happened during that time. (Certainly I don’t know what happened in the “disconnected” field because I haven’t been monitoring it.) It might take a long time before the server decides to mark a device as disconnected. And the only way for me to test that is to put my phone in airplane mode and wait for it to happen. But I’m not really willing to be without service for that long! :slight_smile: (I just tried it for an hour, but neither the Life360 website, nor the disconnected field has indicated anything is wrong, other than the last update was an hour ago.)

I can try implementing something that might work. Is your phone still in the same condition, and if so, would you be willing to test it? Or have you got the phone back up and running (or will so soon)?


I’m still struggling with the same old argument, though. A lack of updates is not an update. And you do have at least two indications already that the data is excessively stale: the device_tracker.life360_update_overdue event, and the last_seen attribute. Either or both could be used in your logic to decide, based on your own requirements, to ignore the state of the corresponding entity, or otherwise alter the response of your system accordingly.

And regarding potentially adding a new “connected” attribute based on the “disconnected” field in the response from the server, that runs into the same old problem – the only way a device tracker platform has to change the state of a device_tracker entity is to call the component’s see method. But that means the device has been “seen”, and it hasn’t. It could try and do an “end run” around the component code and update the entity’s state directly in the state machine, but that is asking for trouble, and probably wouldn’t work anyway.

I still can’t see what I can do differently. The platform code is constrained by the component code in what it can do. I think you just need to use the existing indications (the overdue event and/or the last_seen attribute) and take them into account in your system logic.

But if you still feel strongly about this, then do as I suggested before – open an issue with the device tracker component code. If it is enhanced to allow platform code a way to tell it the device has issues, then I’d be happy to implement that on the Life360 platform side.


i might have misunderstood you here, thought you wrote that component code… hence my issue on your repo. I now take it you advise me to raise an issue at life360’s address?

will do. ask them to change the state when the component had established a Lost connection. Cause thats what it is. And thats the only thing that is 100% positively true. When its lost, it’s lost, and not home, not_home or any other zone. It might, but it isn’t 100% positively true…

other than, would you have a link for their repo,/forum/community?


No, I’m not talking about opening an issue with Life360. Remember, the API we’re using is not officially documented or supported by Life360. This is a reverse engineering project.

“Platform” and “component” are HA terms. Device trackers (like many components) are implemented at two levels: component code and platform code. See Components Architecture. When I refer to the device tracker component code, I’m talking about components/device_tracker/ And my “custom component” is really a device tracker platform.

So the issue is that the component code provides a limited API for the platform code. There are no provisions for a platform to tell the component that a device has lost connection. It can only say a device has been seen. And losing a connection is the exact opposite of being seen.

EDIT: This has all pretty much already been discussed on my github issues #20 and #21. And I don’t see how trying to use the “disconnected” field in the server response changes anything. And to be clear, I was suggesting opening an issue on the HA github repo.


Just to put my input into this idea of how to handle a device that’s not reporting…

When a device is disconnected, it could be home, not_home, some other HA zone, or Mars for all the system knows.

So there’s two options:

  1. Last known state is kept (current implementation)
  2. Set state to unknown, offline, whatever

The device going into state offline (option 2) shouldn’t make much difference because as was mentioned you could just look at the last_seen attribute for automations, so lets look only at how going out of a state would behave with each option. With the current behavior, if a device goes offline, nothing should trigger because nothing changes - unless of course you use last_seen as a trigger to explicitly handle that occurrence. With the proposed behavior however, when a device goes offline (lets say while it’s ‘home’) the state would change and any from: home triggers would fire. The problem is, we don’t know if the device actually left home.

Ultimately, I don’t think there’s a good solution for this and you could argue it either way. To me the question is; when a device goes offline, is it more likely that it goes offline and stays at its last location, or is it more likely that it goes offline and then leaves that location? Keep in mind, although this component is typically used to determine where people are, it’s ultimately a device tracker. Until we all get bio-powered GPS chips embedded in our bodies we’re not actually tracking people, we’re tracking devices. My personal opinion is that if a device goes offline, it’s more reasonable to assume that it has remained at that location rather than assume that it’s left. Option 1 allows for people to make this assumption and write automations accordingly, and it allows people to assume a device is no longer at that location by using the last_seen attribute in automations. Option 2 however, doesn’t allow for people to make the assumption that a device is still in the same location when it goes offline because there’s no real provision for state history.

So if we’re voting, I vote that it should remain as-is and if desired the last_seen attribute should be used.


yes, I follow completely, argue both ways :wink:

only thing left in this might be that this device_tracker is the only one displaying as if its connected, while not being connected (read: show state its latest seen state, in my case ‘home’, while it could be anything). All other device_trackers I use show at least not_home or offline when disconnected.

I fully understand that could cause undesired triggers, but to that I could argue, the undesired non triggering when in a disconnected state… Both ways, I know.

If I then see that this device_tracker is the only one that knows of a certain state under which condition this happens with 100% certainty, the state I posted the screenshot of: Lost connection, I’d wager that enough reason to at least have that be reflected in its state, so automations could be triggered from that.

If I where to use a template where the state would say it is in a zone, but the attribute last_seen is overdue, that would overcomplicate things unnecessary I feel.

Then again, it is possible. Both worlds.
A device_tracker stating a state, while it knows it has a lost connection simply isn’t reliable…
But, it is the most reliable one up to now, so I am gratefully and happily using it as my main presence tracker :+1:


Out of curiosity, what other device tracker platforms are you using that behave that way? I’d like to take a look to see if there’s something I’m overlooking.



iOS app Homeassistant
Places (only since yesterday, but so far seems to report correctly)

mqtt device_tracker (hand made)
and several other composite trackers

have to admit owntracks and the homeassistant app sometimes report false positives (or negatives) too, but that’s because I have set these explicitly not to update in the back, and only when in_use.

All other trackers show not_home when not connected. Bottomline: no connection = not tracked.

for this particular family member:


Not to start this all over, but I was wondering if the ‘Lost connection’ from my screenshot is based on a dedicated server data attribute ‘connected’ / ‘not_connected’, or if thats calculated, based on an algorithm on the last_seen attribute.

If it would be a dedicated attribute, you might be able to show that in the list of attributes of the component? That way the state of the component could stay as it is, namely the state life360 sent lastly, and yet providing a direct indication of the lost_connection. Which could be used on the user side logic for automations and representation.

Anyways, hope this helps, let me know if I could be of further info for you.