I’m running 2022.7.7, but I’ve had this issue with all 2022.7 builds.
Periodically if the internet flakes out, or perhaps an issue with life360 cloud, the entities for my people goes unavailable and they show as away in HA. If I ‘reload’ the integration they immediately recover and are ‘home’ again. Did not have this issue with the older-style integration on 2022.6 and prior.
I can reproduce the issue pretty consistently by killing internet access to HA and then restoring it. It requires a restart of the integration for the entities to update correctly again.
Here is debug output when I bounce my internet connection - It looks like it has an issue and recovers eventually, but the entities still show as unavailailble until i reload the integration.
2022-08-02 20:53:39 DEBUG (MainThread) [homeassistant.components.life360] Finished fetching life360 ([email protected]) data in 0.286 seconds (success: True)
2022-08-02 20:53:49 DEBUG (MainThread) [homeassistant.components.life360] Finished fetching life360 ([email protected]) data in 0.256 seconds (success: True)
2022-08-02 20:53:59 DEBUG (MainThread) [homeassistant.components.life360] Finished fetching life360 ([email protected]) data in 0.269 seconds (success: True)
2022-08-02 20:54:22 DEBUG (MainThread) [homeassistant.components.life360] CommError: HTTPSConnectionPool(host='api.life360.com', port=443): Max retries exceeded with url: /v3/circles.json (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f907d856170>: Failed to establish a new connection: [Errno -3] Try again'))
2022-08-02 20:54:22 ERROR (MainThread) [homeassistant.components.life360] Error fetching life360 ([email protected]) data:
2022-08-02 20:54:22 DEBUG (MainThread) [homeassistant.components.life360] Finished fetching life360 ([email protected]) data in 13.065 seconds (success: False)
2022-08-02 20:54:32 INFO (MainThread) [homeassistant.components.life360] Fetching life360 ([email protected]) data recovered
2022-08-02 20:54:32 DEBUG (MainThread) [homeassistant.components.life360] Finished fetching life360 ([email protected]) data in 0.651 seconds (success: True)
2022-08-02 20:54:42 DEBUG (MainThread) [homeassistant.components.life360] Finished fetching life360 ([email protected]) data in 0.369 seconds (success: True)
2022-08-02 20:54:52 DEBUG (MainThread) [homeassistant.components.life360] Finished fetching life360 ([email protected]) data in 0.591 seconds (success: True)
2022-08-02 20:55:02 DEBUG (MainThread) [homeassistant.components.life360] Finished fetching life360 ([email protected]) data in 0.418 seconds (success: True)
2022-08-02 20:55:12 DEBUG (MainThread) [homeassistant.components.life360] Finished fetching life360 ([email protected]) data in 0.960 seconds (success: True)
2022-08-02 20:55:22 DEBUG (MainThread) [homeassistant.components.life360] Finished fetching life360 ([email protected]) data in 0.364 seconds (success: True)
2022-08-02 20:55:32 DEBUG (MainThread) [homeassistant.components.life360] Finished fetching life360 ([email protected]) data in 0.395 seconds (success: True)
Ok, thanks for the info. I’m not sure how this can happen but I’ll try to reproduce it and see if I can’t get to the bottom of it.
I wonder, if after this happens, and the entities are all unavailable, what happens if you call the homeassistant.update_entity service on one of the entities (i.e., without, or before, reloading the integration)? Does it (and the others) become correct? And, if so, do they continue to update again, or do they just maintain the values they had right after calling the service?
Calling homeassistant.update_entity seems to fix the entity without needing to reload the integration. i will monitor next time someone leaves the house and see if the integration updates also.
Ah, I think I might see what’s happening. I’m trying to setup up a test system where I can reproduce this behavior, but I’m pretty sure if you just wait long enough the entities will eventually update correctly – i.e., change from unavailable. This should happen the next time last_seen (and probably other attributes) change. You may be able to force this to happen by opening the Life360 app on your phone. When I do that it usually immediately provides new, updated data to the Life360 server, and the HA integration will get that on the next update (up to 10 seconds.)
I dont see my device trackers anymore of Life360! Reload integration won’t help, restarted many times too…
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 235, in _async_setup_component
result = await task
File "/usr/src/homeassistant/homeassistant/components/device_tracker/__init__.py", line 50, in async_setup
await async_setup_legacy_integration(hass, config)
File "/usr/src/homeassistant/homeassistant/components/device_tracker/legacy.py", line 161, in async_setup_integration
legacy_platforms = await async_extract_config(hass, config)
File "/usr/src/homeassistant/homeassistant/components/device_tracker/legacy.py", line 306, in async_extract_config
raise ValueError(
ValueError: Unable to determine type for life360: None
you still use life360 after they have been caught selling their users’ information? don’t you value your privacy? if i had been a user, i would have dropped them like hot potato.
2022.11.0 increased the timeout from 3.05 seconds to 10 seconds. Although that seems to have solved the problem for some people, or at least, in most cases, it doesn’t seem to have solved the problem completely. FWIW, in my own testing I never saw timeouts (except when I purposely disabled the network), so it’s very difficult for me to know how to fully address the problem, or when it’s been completely fixed.
I do plan to submit another change that uses the timeout parameters differently, as well as to enable retries. I hope, first that it will be accepted, and second that it solves this problem once and for all.
Thanks for the insight, and great work on the integration! I think this problem only started with 2022.11 off memory in my case. I looks like my devices are going to and from unavailable frequently, which is causing a heap of state changes and therefore alarm automations to run.
The problems started with the 2022.10.0 release when the integration changed from using the requests HTTP package to the aiohttp package. As mentioned above, the single, overall request timeout was increased in 2022.11.0, but that apparently wasn’t enough to fully resolve the problem. A new PR was submitted and accepted and will hopefully be in the 2022.11.3 release that increases the overall timeout to 60 seconds, adds a socket connect timeout of 15 seconds, and enables retries on client connection errors (which includes these timeouts) up to 3 times.
Again, since I’m not able to reproduce the same errors others have seen, and I’ve only had limited success getting others to try the changes before submitting them, I really have no way to know if this will finally resolve the problem. Here’s hoping!