Life360 Device Tracker Platform

I just made a Person and added Life360 with Ping to check I was on my WiFi router, got rid of false leaving my home zone, and fixed the issue with sometimes Life360 is slow to know when I got home…

It’s not perfect, but it works better… No more false leaving at all, so that’s fixed, ping won’t pick you up super fast, depends on how good your wifi signal is

thanks I got it :slight_smile:

Has anyone else noticed that the “driving” attribute always says false even if that person is driving, and it says driving in the Life360 app?

Is it a bug or just my setup?

Thanks.

Hi Phil,

Am I understanding correctly that if i had say a 300m zone for home and a 600m over the top of it for ‘Almost Home’ Life360 would report me as almost home then home?

I never thought of doing it that way or knew it was possible

Thanks

mb

As Phil suggested, I created a new zone (HomeClose) and set the radius to 3000m and will see how that works.

I will also see what I can find for Life360 settings. I noticed in the logs that there were times it had been over 20 minutes since my last update so if it is sleeping then that could definitely affect it.

Thanks!

-Tim

1 Like

You’d have to share that setup before we could say.

First, what do you have for show_as_state? Also what about driving_speed? And is your HA configured for imperial or metric?

Are you just looking at the device_tracker state, or have you also looked at its attributes, such as speed and driving? Do the attributes look reasonably correct?

First, just to be clear, the life360 integration just determines the GPS location. It’s the device_tracker component level code that determines what zone(s) you’re in, and how to set the entity’s state accordingly. (Well, the life360 integration can set the state to driving or moving if you have it configured that way, but zones take precedence over those.)

But the way I understand it, first it determines if you’re in any zones by seeing if your location “circle” (using the gps_accuracy radius) overlaps with the circles of any zones. If it does, and you’re in only one zone, then it uses that one. If it does, but you’re in more than one zone, then it picks the one you’re closest to (using just the locations and ignoring radii.) But if you’re the same distance to more than one zone (say they have the same location, as in this case), then it picks the smallest of those zones.

So the short answer is, yes. :smiley:

1 Like

Link to Life360 document for improving inaccurate location: How do I improve an inaccurate location?

Mine were already set that way. However, I did notice in the app itself that I had drive detection turned off and it said in the help bubble that having that enabled is required for speed information. I turned it on and will see if that improves anything.

Thanks!

-Tim

Do zones in HA need to correspond to locations in Life360?

I created the large “HomeClose” zone in HA with a radius of 3000m. Do I need to create it as a location in Life360 as well or is it fine just in HA?

Thanks!

-Tim

HA Zones and Life360 Places have nothing to do with each other. (They did in my earlier custom integration, but that was removed when it was submitted to become a standard integration.) Again, the HA life360 integration simply determines your phone’s location from information it obtains from Life360’s server.

If you want HA’s Zones and Life360’s Places to agree, see Home Assistant Zones & Life360 Places.

1 Like

Very good point :pensive: here is what I use:

life360:
  accounts:
    username: !secret life360_username
    password: !secret life360_password
  show_as_state:
    - driving
    - moving

I’ve not set driving speed as was hoping to rely on Life360 detecting that, but it may be one way to make it show as driving.

Yep, I’ve been looking at the driving: false attribute within the states page. This remains at false when driving and when the Life360 app says I’m driving.

All other attributes look ok - it shows the correct speed being updated along with correct lat and long. The moving attribute turns true when on the move, and all other sensors are accurate.

I’ll be happy to delve into any debug logs if required.

Thanks.

You might want to add driving_speed.

The integration has two ways to set the driving attribute to true. First, if the data it gets from the server says you’re driving, then it sets it true. But if that is not the case (which appears to be what you’re observing), and if you’ve set driving_speed, then it will also set the driving attribute to true if the estimated speed is above that value.

Honestly, I have no idea why the Life360 app would say you’re driving but not indicate that in the data its server provides. But since this is an undocumented and unsupported API…

FWIW, I’ve seen that the speed attribute is relatively good, so setting a driving_speed should work for you. But, then again, it’s only as good as the data the Life360 server provides.

Thanks Phil, I’ve set driving speed and will monitor when out tomorrow. :slight_smile:

btw, here’s a sneak preview of a button I’ve made with Custom Button Card, all thanks to your great work on the Life360 integration!

1 Like

I don’t understand this, could you give more details on this setup?

very cool custom button card… can you share your code?

In an attempt to combine multiple automations into few…

How could I have one automation that checks anyone in “HomeClose” zone AND their direction of travel is “towards”?

This is what I would start with…

- id: '1234567890'
  alias: SomeoneHomeClose
  description: Someone in HomeClose
  trigger:
  - entity_id:
    - device_tracker.life360_kathy
    - device_tracker.life360_tim
    - device_tracker.life360_michael
    - device_tracker.life360_casey
    platform: state
    to: HomeClose
  condition: []
  action:
  - data_template:
      message: "{{ now() }} {{ state_attr(trigger.entity_id, 'friendly_name') }} in HomeClose radius"
    service: notify.LogFile

This much works (I’ve done in other automations) and will put a notification in a logfile.

For the individual automations, I have a condition to check direction of travel. There is a proximity for each of us. How could I add a condition to check the appropriate proximity direction of travel based on the specific entity_id that triggered? (I know, this is complicated but seems like I should be able to concatenate the name of the proximity sensor based on the friendly_name…)

 condition:
  - condition: template
    value_template: '{{ states.proximity.timhome.attributes.dir_of_travel == "towards"  }}'

This is more of a templating question rather than specific to Device Tracker, Life360 or whatever.

Thanks!

Assuming naming consistency:

{{ state_attr('proximity.' ~ trigger.entity_id.rsplit('_', 1)[-1] ~ 'home', 'dir_of_travel') == 'towards' }}

Yup, looks like that will work. I was just messing around in the template editor which isn’t easy since the trigger is undefined.

I am pulling the friendly_name from the entity since that is our short name (the actual life360 names are first_last) but the first letter is capitalized so I have to add a .lower() to it since HA fusses over capitalization.

Thank you very much!

I will test this and see how it works:

- id: '1234567890'
  alias: SomeoneHomeClose
  description: Someone in HomeClose
  trigger:
  - entity_id:
    - device_tracker.life360_kathy
    - device_tracker.life360_tim
    - device_tracker.life360_michael
    - device_tracker.life360_casey
    platform: state
    to: HomeClose
  condition:
  - condition: template
    value_template: "{{ state_attr('proximity.' ~ state_attr(trigger.entity_id, 'friendly_name').lower() ~ 'home', 'dir_of_travel') == 'towards' }}"
  action:
  - data_template:
      message: "{{ now() }} {{ state_attr(trigger.entity_id, 'friendly_name') }} in HomeClose radius"
    service: notify.LogFile
{% set trigger = {'entity_id': 'device_tracker.life360_tim'} %}
{{ state_attr('proximity.' ~ trigger.entity_id.rsplit('_', 1)[-1] ~ 'home', 'dir_of_travel') == 'towards' }}

That’s not what you shared in your post, but whatever.

Thank you again - that helps a lot for troubleshooting.