Life360 Device Tracker Platform

maurizio53 · June 2, 2022, 1:46pm

The latest of May. 2022.5.5

pnbruckner · June 2, 2022, 2:27pm

Actually, I forgot you’re using this as a custom integration. (I’ve been working on the PR to submit this formally, so I thought “homeassistant.components.life360” by default. lol) So, the debug config should be different:

logger:
  default: info
  logs:
    life360: debug
    custom_components.life360: debug

Try again with that. There should be more details in the log this time.

But even with just the details available so far, I can draw a few conclusions…

First, the “Executor shutdown has been called” error might be just from when you were trying to stop Home Assistant. Unless that happens often, I’m going to ignore that error for now.

The other error tells me a few things…

It is able to communicate with the Life360 server.
It is able to successfully log into the server.
It is able to successfully retrieve the list of Circles.
The error happens when it tries to retrieve the Members and their data from one of the Circles (or the only Circle).

I’ve had reports of this problem from time to time for years. But so far I’ve never been able to conclude what causes it. There is some speculation that it has to do with Members not having location sharing enabled, but I’ve tested that scenario and have not been able to duplicate the problem. For more details, see:

and

github.com/home-assistant/core

After latest update Life360 error logs

opened 10:02AM - 17 Feb 22 UTC

closed 03:50PM - 10 Mar 22 UTC

thorrrr

integration: life360

### The problem After latest update now getting Life360 errors never had any is…sues or logs before Logger: homeassistant.components.life360.device_tracker Source: components/life360/device_tracker.py:176 Integration: Life360 (documentation, issues) First occurred: 09:19:51 (1 occurrences) Last logged: 09:19:51 get_circle_members "User Name": CommError: 400 Client Error: Bad Request for url: https://api.life360.com/v3/circles/019124cd-b300-489c-8a8c-2a8c2d76c814/members ### What version of Home Assistant Core has the issue? ## System Health version | core-2022.2.8 -- | -- installation_type | Home Assistant OS dev | false hassio | true docker | true user | root virtualenv | false python_version | 3.9.7 os_name | Linux os_version | 5.10.98 arch | x86_64 timezone | Europe/London <details><summary>Home Assistant Community Store</summary> GitHub API | ok -- | -- Github API Calls Remaining | 5000 Installed Version | 1.22.0 Stage | running Available Repositories | 977 Downloaded Repositories | 25 </details> <details><summary>Home Assistant Cloud</summary> logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | ok </details> <details><summary>Home Assistant Supervisor</summary> host_os | Home Assistant OS 7.4 -- | -- update_channel | stable supervisor_version | supervisor-2022.01.1 docker_version | 20.10.9 disk_total | 30.8 GB disk_used | 16.3 GB healthy | true supported | true board | ova supervisor_api | ok version_api | ok installed_addons | Samba share (9.5.1), Check Home Assistant configuration (3.10.0), SSH & Web Terminal (10.0.2), Home Assistant Google Drive Backup (0.105.2), Studio Code Server (4.1.0), MariaDB (2.4.0), InfluxDB (4.3.0), Grafana (7.4.1), Mosquitto broker (6.0.1) </details> <details><summary>Lovelace</summary> dashboards | 3 -- | -- resources | 16 views | 75 mode | storage </details> ### What was the last working version of Home Assistant Core? Last before this one ### What type of installation are you running? Home Assistant Core ### Integration causing the issue Life360 ### Link to integration documentation on our website https://www.home-assistant.io/integrations/life360 ### Diagnostics information Not avaiabe for this ### Example YAML snippet _No response_ ### Anything in the logs that might be useful for us? ```txt Nothing in main log ``` ### Additional information _No response_

Are you sure this only happens when you try to use this custom integration version? Or have you seen this problem using the standard, built-in integration as well?

maurizio53 · June 2, 2022, 2:54pm

No, i’m not sure of this, but never saw those errors before (when using the legacy one).
One question about circles… in the app am i forced to have the same circles as the configured zones in HA?

pnbruckner · June 2, 2022, 3:04pm

Hmm. That’s been the problem with these “400” errors – they come and go with no rhyme or reason.

Sorry, I don’t understand the question. Do you mean the same Places as configured zones in HA?

Life360 has Places, and HA has zones. They are separate things. They do not need to agree, although it can help your sanity if they do. See Home Assistant Zones & Life360 Places.

But again, no, they do not need to agree. The state of the device trackers in HA will be solely based on HA zones (and possibly the driving attribute, if you so configure it.) If the device is in a Life360 Place, then that will be shown in the place attribute only.

maurizio53 · June 2, 2022, 3:10pm

Yes i was meaning that. Btw your explanation toggle off my doubts…
I will let you know other logs if they appear.
Thanks for all for now.

pnbruckner · June 29, 2022, 5:10pm

The PR to convert to the new entity based implementation:

Convert life360 integration to entity based by pnbruckner · Pull Request #72461 · home-assistant/core (github.com)

has been approved and merged, and could, therefore, make it into the 2022.7 (or maybe 2022.8) release.

Note that some features have been removed or slightly modified. See the “Breaking change” section at the top of the PR for a “heads up.”

pnbruckner · July 1, 2022, 4:16pm

The new life360 implementation is in 2022.7.0b0+.

Has anyone using life360 updated to this release, and if so, how is it going?

pnbruckner · July 6, 2022, 8:58pm

HA Release 2022.7.0 introduces a BREAKING CHANGE to the Life360 integration

Overview

The Life360 integration has been converted from the old “legacy” implementation (i.e., that uses the known_devices.yaml file in the config directory) to the newer entity-based design, similar to what was done for many other device tracker integrations when the new design was first introduced in release 0.94.0 over three years ago! (Interesting fact: the Life360 integration was first introduced in release 0.95.0, so was implemented while the device tracker component was in the process of being reorganized. So, this change is long overdue!)

When you upgrade to 2022.7 or newer for the first time, all your existing Life360 device_tracker entities will become non-functional. Unfortunately, given the implementation of the device tracker component level code there was no way to avoid this.

But there will also be new entities that are functional.

Take a look on the STATES tab of the Developer Tools page, or the Entities page under Settings, and you should see both the old and new entities. The old entities will have the same entity IDs as before, and so anything that used those entities (person entities, automations, etc.) will no longer be getting updates.

Steps to replace old entities with the new ones

Edit the known_devices.yaml file in your configuration directory to remove any Life360 related entries. Or, if there are only Life360 entries in this file, simply delete the file entirely.
Restart Home Assistant. All the old, non-functional Life360 entities should now be gone.
Go to the Entities page (under Settings → Devices & Services → Entities) and change the entity IDs for the new Life360 entities as desired.

Removed/changed functionality

Configuring Life360 via YAML files is no longer supported. Any settings that were in YAML will be automatically migrated to the config entries. Once you upgrade you should remove the Life360 related entries from your YAML files. You can see or change the migrated settings by going to Settings → Devices & Services → Integrations and clicking CONFIGURE on a Life360 entry.

Which brings us to the next point – some settings are no longer supported, specifically:

circles
members
error_threshold
warning_threshold
max_update_wait (and the corresponding events life360_update_overdue & life360_update_restored)
show_as_state: moving

The following attributes have changed:

Renamed: battery → battery_level
Removed: moving, raw_speed

Ildar_Gabdullin · July 6, 2022, 10:52pm

Thank you very much, Phil, for your efforts.
My question is for these options which I used to keep in yaml:

life360:
  max_update_wait:
    minutes: 15

  interval_seconds: 12

  show_as_state:
    - driving
    - moving

  accounts:
    - username: !secret life360_ildar_login
      password: !secret life360_ildar_password

What should I do?

Should I simply remove the accounts lines since this info is inputted via UI now?
What should I do with interval_seconds & max_update_wait values since there is no UI input for them?

Here these interval_seconds & max_update_wait attributes are not specified as supported.
OK, assume that interval_seconds is supported by the device_tracker platform.
But what about max_update_wait ?

And what about events “life360_update_overdue”, “life360_update_restored”? Are they deprecated?
These events are not mentioned here (as they were before).
But these events are displayed in HA (dev tools):

pnbruckner · July 6, 2022, 11:27pm

You should remove the entire life360 section from yaml after you’ve upgraded to 2022.7.x and the (supported) settings are automatically migrated into the corresponding config entry/entries (in config/.storage/core.config_entries).

I was not allowed to keep support for interval_seconds. It now updates every 10 seconds. If you want it to update at a different rate, then you have to do like you’d have to do with any other integration that supports config entries: i.e., click the CONFIGURE button on the integration, then System Options, then disable polling, then create an automation that triggers at the rate you want and have it call the homeassistant.update_entity service with appropriate options.

For max_update_wait and its corresponding events I don’t really have an answer. The implementation changed significantly enough that keeping that functionality was not going to be easy, and honestly, I didn’t think it would have been used much, and even it it were, it wasn’t that important. Since I got no feedback relative to this feature in my “testers needed” topic, or during the beta period, I concluded my assumption was reasonably valid. BUT, if this is a huge problem for you, or others, by all means, open an issue and if there is enough interest I can look into trying to add back the functionality.

The reason those events are shown on the dev tools page is because you have things listening for them, even if there’s nothing in the system that can currently generate them.

Ildar_Gabdullin · July 7, 2022, 12:02am

Here it is specified as “12”.
Is it an error?

Listening to these events is the ONLY way to set update alert for me.
Earlier these events were generated if there is no any updates from some client within XXXX time.

See, the platform could monitor these updates and set some ERROR flag after that XXXX timeout (like a similar “Traccar” platform) - then HA could just monitor this ERROR flag and set/withdraw an alert.
Alternatively, the platform may send events - like the Life360 platform used to do…

For me - both variants will be OK.
But currently we do not have any info “are these data valid or outdated”.

I will create an issue for restoring (or replacing) the “alert” functionality.
DONE - Life360: restore a functionality to send "overdue/restored" events (or propose a corresponding status) · Issue #74554 · home-assistant/core · GitHub

BTW - removing these events is a BREAKING CHANGE, not mentioned in Release notes.

pnbruckner · July 7, 2022, 12:17am

That does not apply to this integration. That only applies to device tracker integrations that are configured via yaml as a platform under device_tracker:.

The breaking change mentions that max_update_wait is no longer supported. Those events were only generated by using that option. So, no, it does not explicitly say those events can no longer be generated, but I think it’s pretty obvious if max_update_wait is no longer supported then you can’t expect those events to be generated any more.

For ALL device trackers, they are ALWAYS outdated, except for the instant in time they update (and even then the HA update is probably delayed from when the data was actually generated.) The only question is HOW out of date the data is.

One way, I suppose, to get the same or similar functionality is to use the last_seen attribute. It tells you exactly when the Life360 client on your device last told the Life360 server where it was. If you subtract that from now() you can see how out of date the data is. And you can use that to trigger an automation, and you can even have the action of that automation send the same events and data that the integration used to do. E.g.,:

- trigger:
  - platform: template
    value_template: >
      {{ (now() - state_attr('device_tracker.xxx', 'last_seen'))
         .total_seconds() > 30*60 }}
  action:
  - event: life360_update_overdue
    event_data:
      ...

Eoin · July 7, 2022, 12:23am

Thank you @pnbruckner for the instructions, worked perfectly for me!

Ildar_Gabdullin · July 7, 2022, 12:29am

Agree, this is a possible solution.
I am doing the same for a Companion App integration: if a “battery_level” sensor (the least rough choice…) is updated more than XXX minutes ago - then the corresponding alert “data from companion app - not valid” is set to ON.

Probably I will have to implement a similar functionality for Life360 too.

photo64 · July 7, 2022, 1:30pm

@pnbruckner

I upgraded to HA 2022.07 on my dev setup, which is where I had made the changes to try your new integration prior to being released. After the upgrade I added the LIfe360 integration then commented out the config.yaml setup and removed the known devices file and restarted. My device_tracker entities appear to be correct as prior however they are showing as “not_home”.

Is there something I missed in the setup? They should be showing as “home”.

**edit - I should also mention no attributes are being shown

pnbruckner · July 7, 2022, 1:38pm

Did you back out the test implementation and revert the config before upgrading as I warned you should?

If not, then you should definitely make sure you’ve removed the test implementation in your custom_components folder, restart HA, and probably completely delete your Life360 entries on the Integrations page and re-add them because the config entries in the .storage folder are probably bad as I had explained (i.e., wrong version number.)

Let me know if that solves the problem.

photo64 · July 7, 2022, 1:59pm

So I missed removing the the Life360 folder from the custom_components folder. I have now removed this and restarted HA. If I remove the entities from the integration page how do I go about re-adding them?

pnbruckner · July 7, 2022, 2:01pm

You need to delete the integration(s), not the entities. I.e., do this on the Integrations tab, not the Entities tab.

To re-add, click the plus sign in the bottom-right corner of the page, then select Life360 from the list, etc. You’ll need your Life360 account info – username & password.

photo64 · July 7, 2022, 2:02pm

Ah, that makes more sense, I thought you wanted me to just delete the entities. I’ll try this.

pnbruckner · July 7, 2022, 2:03pm

Sorry, I said “entries”, not “entities.” That was a bit confusing I guess. lol!