Life360 Device Tracker Platform

[pnbruckner (Phil)]

I don’t plan to do any more development on this custom component, nor fix any issues that come up with new releases of HA. Anyone is, of course, free to keep using it (I don’t plan to remove it from my repo), as long as it continues to work, or they fix any issues themselves that might come up, but I recommend moving to the standard component which is now available, at least in a beta release.

The existing features you’ve mentioned are also in my custom composite tracker, which I still support. Yes, it’s somewhat being replaced by the new standard person component, but at least for now I’ll try to make sure the composite tracker continues to work with new releases of HA, mainly for these additional features I can’t ever see making themselves into the person component.

Of course, they, and the new feature you’re asking about, probably belong somewhere else. At least, it feels like they should. I added them because I wanted the feature and it was the easiest way for me to do it at the time. So, I guess, at least for now, I probably wouldn’t consider adding this new feature.

@Mariusthvdb

my uses case relies a lot on the driving and moving state

Maybe you missed this:

@pnbruckner

I should probably add that the information is still available through the attributes: driving , moving & place .

Your automations can still get at this information, albeit in a different way.

[Mariusthvdb (Marius)]

@pnbruckner

Your automations can still get at this information, albeit in a different way.

if this is the new component, that’s a small relieve. But, as it stands now, Id love to be able you keep using the CC, since it behaves so perfectly.

If not added to the CC, could you help me sort this out then, Ive found a suggestion to calculate the country based in timezone here:

How to convert timezone to country code in Python?

A bit at loss how to get this into HA though, either in a python script, or a jinja template using the attribute timezone from your component.

[finity]

I think I just came up with another question related to my last one above…

Right now, I use “show_as_state” and I have combined all of my device trackers into the “person” component.

On the frontend, the state of my “person.xxx” is shown as the location I’m in based on my zones I have set up in HA. However, it also will show my state as “driving” or “moving” if I’m not home or in another defined zone and I’m actually driving, etc.

Since the “show_as_state” is removed will the state of the person component still show as “driving” like it did before? I think the answer, unfortunately, will be no but I’m hoping it’s yes.

[pnbruckner (Phil)]

Sorry, no.

[finity]

Yeah, I figured.

I guess I’ll have to create another custom sensor.

Or just keep using the custom component till it dies.

[Mariusthvdb (Marius)]

same boat here, love the custom component, don’t like it getting deprecated because of integration into HA.
Just like the Hue CC for that matter.

2 major CC’s . Hope they will live long and prosper

[finity]

@Mariusthvdb

don’t like it getting deprecated

I like the idea of it being officially integrated into HA and putting the CC to bed. And I appreciate Phil’s hard work to get it in there.

I just don’t like that some of the unique useful functionality of the CC was forced out to get it there.

[Mariusthvdb (Marius)]

+1 to that. you worded it better.

but, having read the discussions that accompanied this integration, my bets are on the long lived CC, even though my hopes are on the development of the integration.

[rotcop4u2]

not sure if i should add this as an issue to here or not. but I am having an issue with the custom component Life360. I recently just update from 0.87 to 0.94.4 and I am getting errors in about:

In my log.
Setup failed for life360: No setup function defined.

My is as follows:

- platform: life360
  username: !secret life360_username
  password: !secret life360_password
  max_update_wait:
    minutes: 30

[pnbruckner (Phil)]

Did you upgrade to the latest version of the custom component?

[rotcop4u2]

i just read on your github that there was a complete overhaul of the custom components setup. I am going to complete those steps and return if needed. I will let you know if I still need your help. Thank you for you fast response.

[SeanM]

@Mariusthvdb

which is really a pity, my uses case relies a lot on the driving and moving state. It makes a prominent part of my default Home page…

I’ve got around this by making a bunch of template sensors for the various attributes.

sensor:
  - platform: template
    sensors:
      sean_driving_status:
        friendly_name: 'Sean Driving Status'
        icon_template: mdi:gauge
        entity_id: device_tracker.life360_sean
        value_template: "{% if state_attr('device_tracker.life360_sean', 'driving') == True %}Driving{% else %}Not Driving{% endif %}"

      sean_moving_status:
        friendly_name: 'Sean Moving Status'
        icon_template: mdi:run-fast
        entity_id: device_tracker.life360_sean
        value_template: "{% if state_attr('device_tracker.life360_sean', 'moving') == True %}Moving{% else %}Not Moving{% endif %}"

      sean_wifi_status:
        friendly_name: 'Sean WiFi Status'
        icon_template: "{% if state_attr('device_tracker.life360_sean', 'wifi_on') == True %}mdi:wifi{% else %}mdi:wifi-off{% endif %}"
        entity_id: device_tracker.life360_sean
        value_template: "{% if state_attr('device_tracker.life360_sean', 'wifi_on') == True %}Connected{% else %}Not Connected{% endif %}"

      sean_battery_status:
        friendly_name: 'Sean Battery Status'
        icon_template: mdi:battery-charging-wireless-alert
        entity_id: device_tracker.life360_sean
        value_template: "{% if state_attr('device_tracker.life360_sean', 'battery_charging') == True %}Charging{% else %}Unplugged{% endif %}"

Then in your automations instead of using the state of your device_tracker you use the state of your new template sensors (ie sensor.sean_driving_status & sensor.sean_moving_status).

It’s not quite as clean as before, especially when displaying in the UI, but this one very minor drawback is totally worth it to get this as a standard integration

[rotcop4u2]

dumb me. i got it. thanks to your documentation. working well… About to upgrade to Python 3.7 now. Thank you again

[pnbruckner (Phil)]

@finity

I just don’t like that some of the unique useful functionality of the CC was forced out to get it there.

Not all of the functionality that was removed was “forced out.” I chose to remove some features that I thought would make it harder to be accepted. The “standardization” process was difficult enough as it was. Leaving those features in could easily have made it even harder.

Of the features removed, show_as_state: driving, moving might be the easiest to add back. I don’t think I’d want to add the show_as_state: places option. That’s just too close the zone issues I ran up against. Better to add HA zones that are equivalent to the Places, and I explain how that can be done in the doc.

If there’s a strong desire to have show_as_state: driving, moving added back, by all means, open an Issue. I suppose it’s not strictly a bug report, but in this case an argument could probably be made to handle it this way (since many are coming from the custom component, and moving to the standard component is causing a “deficiency.”)

I’ll admit that I kind of liked being able to see Driving and Moving, not only “live”, but in the state history.

[pnbruckner (Phil)]

FWIW, you can simplify those a bit:

sensor:
  - platform: template
    sensors:
      sean_driving_status:
        friendly_name: 'Sean Driving Status'
        icon_template: mdi:gauge
        value_template: >
          {{ '' if state_attr('device_tracker.life360_sean', 'driving') else 'Not ' -}}
          Driving

      sean_moving_status:
        friendly_name: 'Sean Moving Status'
        icon_template: mdi:run-fast
        value_template: >
          {{ '' if state_attr('device_tracker.life360_sean', 'moving') else 'Not ' -}}
          Moving

      sean_wifi_status:
        friendly_name: 'Sean WiFi Status'
        icon_template: >
          mdi:wifi
          {{- '' if state_attr('device_tracker.life360_sean', 'wifi_on') else '-off' }}
        value_template: >
          {{ '' if state_attr('device_tracker.life360_sean', 'wifi_on') else 'Not ' -}}
          Connected

      sean_battery_status:
        friendly_name: 'Sean Battery Status'
        icon_template: mdi:battery-charging-wireless-alert
        value_template: >
          {{ 'Charging' if state_attr('device_tracker.life360_sean', 'battery_charging')
             else 'Unplugged' }}

[SeanM]

Awesome, thank you! That’s a much cleaner way of doing things.

[atomicpapa (Glenn Morrison)]

I’m not a template master, but couldn’t the 2 moving and driving sensors be combined into one with a simple elif?

sean_status:
  if (device_tracker.sean = moving)  Moving
  elif (device_tracker.sean = driving) Driving
  else (state.device_tracker.sean.state) (i.e. if state = home, leave it home)

(this is not meant to be anything close to an actual template, just an expression of an idea)

and then you could use the new sensor as your display in the UI for your location

[Mariusthvdb (Marius)]

@pnbruckner

Of the features removed, show_as_state: driving, moving might be the easiest to add back. I don’t think I’d want to add the show_as_state: places option. That’s just too close the zone issues I ran up against. Better to add HA zones that are equivalent to the Places, and I explain how that can be done in the doc.

yes Phil, that would truly be awesome. Having these as state makes life so much easier, and, probably more robust also. Life360 sometimes has some latency regarding these and using these as markers between being in a Zone, or simply being Home/Not Home natively is certainly the way forward.

the device can then be either Home, Moving, Driving, in a Zone, or Not Home. which would be perfect.

where do you want the issue to be filed? ( it isn’t yet in the release so can’t do it on the provided link?) If gladly do it simply referring to this thread if allowed. update Done: new Life360 integration missing 'Moving' and 'Driving' attributes · Issue #24698 · home-assistant/core · GitHub

as an illustration my Buttons for location/presence:

      - type: custom:button-card
        template: button_picture_family
        entity: device_tracker.life360_name
        entity_picture_template: >
          return '/local/tiles/family/name_' + entity.state.toLowerCase().replace(' ','_') + '.png';

color based on the template button_picture_family deciding Home: Green, Zone or Moving or Driving: Life360 Purple, Not home: Gray.

[pnbruckner (Phil)]

@finity

Or just keep using the custom component till it dies.

If you want to keep using the custom component with 0.95+, you’ll need to rename it. Change the name of the folder in <config>/custom_components from life360 to something else. Then change this line in your configuration:

  - platform: life360

to match.

This is necessary because the standard life360 uses config flow, and therefore you can’t have a custom component with the same name (because it’s not supported and won’t load if it’s the same name.)

[Mariusthvdb (Marius)]

we can already do that?
in which case I would call it
- platform: life360_custom and have the appropriate folder of course.

That we we can now (as in not yet on HA .95+) prepare for the future update?