Logger - Home Assistant (home-assistant.io)
E.g.,
logger:
default: info
logs:
life360: debug
homeassistant.components.life360: debug
Add that to configuration.yaml, then restart HA. Then look in home-assistant.log for messages related to life360.
What i see is only this:
2022-05-31 04:22:21 ERROR (MainThread) [custom_components.life360] Error fetching life360 ([email protected]) data:
2022-05-31 05:20:45 ERROR (MainThread) [custom_components.life360] Error fetching life360 ([email protected]) data:
2022-05-31 06:31:58 ERROR (MainThread) [custom_components.life360] Error fetching life360 ([email protected]) data:
2022-05-31 06:38:46 ERROR (MainThread) [custom_components.life360] Error fetching life360 ([email protected]) data:
And this:
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
More infos from the log:
2022-06-02 06:06:14 DEBUG (SyncWorker_4) [life360.life360] Error while getting: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members: 400 Client Error: Bad Request for url: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members
2022-06-02 06:06:14 ERROR (MainThread) [custom_components.life360] Error fetching life360 ([email protected]) data:
2022-06-02 08:43:06 DEBUG (SyncWorker_51) [life360.life360] Error while getting: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members: 400 Client Error: Bad Request for url: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members
2022-06-02 08:43:06 ERROR (MainThread) [custom_components.life360] Error fetching life360 ([email protected]) data:
2022-06-02 09:14:20 DEBUG (SyncWorker_47) [life360.life360] Error while getting: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members: 400 Client Error: Bad Request for url: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members
2022-06-02 09:14:20 ERROR (MainThread) [custom_components.life360] Error fetching life360 ([email protected]) data:
2022-06-02 09:36:44 DEBUG (SyncWorker_45) [life360.life360] Error while getting: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members: 400 Client Error: Bad Request for url: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members
2022-06-02 09:36:44 ERROR (MainThread) [custom_components.life360] Error fetching life360 ([email protected]) data:
2022-06-02 10:01:44 DEBUG (SyncWorker_13) [life360.life360] Error while getting: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members: 400 Client Error: Bad Request for url: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members
2022-06-02 10:01:44 ERROR (MainThread) [custom_components.life360] Error fetching life360 ([email protected]) data:
2022-06-02 11:08:08 DEBUG (SyncWorker_30) [life360.life360] Error while getting: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members: 400 Client Error: Bad Request for url: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members
2022-06-02 11:08:08 ERROR (MainThread) [custom_components.life360] Error fetching life360 ([email protected]) data:
2022-06-02 12:15:45 DEBUG (SyncWorker_30) [life360.life360] Error while getting: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members: 400 Client Error: Bad Request for url: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members
2022-06-02 12:15:45 ERROR (MainThread) [custom_components.life360] Error fetching life360 ([email protected]) data:
2022-06-02 12:28:57 DEBUG (SyncWorker_10) [life360.life360] Error while getting: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members: 400 Client Error: Bad Request for url: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members
2022-06-02 12:28:57 ERROR (MainThread) [custom_components.life360] Error fetching life360 ([email protected]) data:
2022-06-02 12:40:33 DEBUG (SyncWorker_15) [life360.life360] Error while getting: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members: 400 Client Error: Bad Request for url: https://api.life360.com/v3/circles/22c7ec58-09f8-439a-8f2d-7e43d2429428/members
2022-06-02 12:40:33 ERROR (MainThread) [custom_components.life360] Error fetching life360 ([email protected]) data:
What version of Home Assistant are you running?
The latest of May. 2022.5.5
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…
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.
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.
The PR to convert to the new entity based implementation:
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.”
The new life360 implementation is in 2022.7.0b0+.
Has anyone using life360 updated to this release, and if so, how is it going?
HA Release 2022.7.0 introduces a BREAKING CHANGE to the Life360 integration
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.
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.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:
circlesmemberserror_thresholdwarning_thresholdmax_update_wait (and the corresponding events life360_update_overdue & life360_update_restored)show_as_state: movingThe following attributes have changed:
battery → battery_levelmoving, raw_speedThank 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?
accounts lines since this info is inputted via UI now?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):
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.
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.
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:
...
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.
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
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.