So, the life360 integration has been a built-in integration in Home Assistant for a long time now. When you say you were “using the old integration”, do you mean the built-in one, or my custom version from way back before it was added as a built-in one?
In any case, the Home Assistant life360 integration (whether the old one, the current built-in one, or this new version, which will hopefully replace the built-in one) gets location information from the Life360 server. It cannot operate independent of Life360. In order to use the integration, you must have a Life360 account, and for it to be useful, yes, you’d need to have the Life360 app installed on your phone(s.)
I’ve never had any issues with battery usage from the Life360 app, and I’ve been using it for almost 9 years. AFAIK, they go to great lengths to minimize battery usage while maximizing useful location updates. If you have battery issues you should check their FAQs.
Um, how do you expect the Life360 server to get location information from your phone if the app (that supplies that information) is deactivated? I think you’re misunderstanding how this works. The app sends location information to the Life360 server, and the HA integration periodically queries the Life360 server for that data. This is basically the same model that most, if not all, tracker systems use. E.g., I also use Google Maps, and it works exactly the same way. (Moreover, I use both apps on the same phone, which I’ve been doing for years, and do not have any battery issues.)
Of course, using any app that periodically runs, uses GPS, and sends information to a server, is going to use some battery. Nothing is free. But, in my experience, I wouldn’t classify either Life360 or Google Location Sharing as “BIG” wastes of battery.
I am pretty sure that L360 will respond with the latest location data that it has. My wife’s phone ran out of battery a few days ago and L360 was still reporting her location as “at work”.
I get ‘unavailable’ state very often since i switched from legacy integration to yours and i am foced to reload the integration to have again the device available.
2022-06-02 00:08:00 ERROR (MainThread) [custom_components.life360] Unexpected error fetching life360 ([email protected]) data: Executor shutdown has been called
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 191, in _async_refresh
self.data = await self._async_update_data()
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 150, in _async_update_data
return await self.update_method()
File "/config/custom_components/life360/__init__.py", line 154, in async_update_data
return await get_life360_data(hass, api)
File "/config/custom_components/life360/helpers.py", line 134, in get_life360_data
for circle in await retrieve_data(api.get_circles):
File "/config/custom_components/life360/helpers.py", line 124, in retrieve_data
return await hass.async_add_executor_job(func, *args)
File "/usr/src/homeassistant/homeassistant/core.py", line 479, in async_add_executor_job
task = self.loop.run_in_executor(None, target, *args)
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 807, in run_in_executor
self._check_default_executor()
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 514, in _check_default_executor
raise RuntimeError('Executor shutdown has been called')
RuntimeError: Executor shutdown has been called
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
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?
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?
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.
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)
But, in my experience, I wouldn’t classify either Life360 or Google Location Sharing as “BIG” wastes of battery.
