Please note that the logs above appear to be from a person entity, not a life360 entity. The life360 integration does not generate a state of “unknown”, only “unavailable”. The person entity will convert an input of “unavailable” to a state of “unknown”.
The core team required me to make the life360 integration work this way. I.e., whenever a Life360 server query fails, it is required that all corresponding entities change state to “unavailable”. I disagree with this design. IMHO, the entities should retain their last state, and the server communication issue should just be logged, or a binary sensor could be implemented to indicate the status of server communications. I.e., the communication status should be an “out of band” signal, not mixed with the data stream. (And, actually, there already is an out of band signal, which is effectively the last_seen attribute.) But at this point I can’t convince the powers that be, so there’s nothing I can do about it.
As atv mentioned, I created a “composite tracker” custom integration (long before the person integration existed) that can be “layered on top of” the life360 integration (and/or other types of tracker entities) that ignores “unknown” & “unavailable” states which can be used as a workaround to what I consider to be a forced design flaw in the current life360 integration (and others.)
Correct, i used the person entity at the time, hoping that it would be state agnostic (you would expect that right?). Unfortunately it responded the same way as the life360 integration, but using unknown instead of unavailable.
It’s looking like the change to use the aiohttp package (in the 2022.10 release) may be part of the problem. That package doesn’t appear to accurately honor the timeout parameter. I.e., it’s currently set at 3.05 seconds (a value that was recommended by the requests package that life360 previously used), but aiohttp sometimes seems to timeout prematurely, e.g., closer to 2 seconds. Also, the aiohttp package doesn’t seem to support any sort of retry mechanism like the requests package does, so retries aren’t being attempted anymore.
I’m working on increasing the timeout to 5 seconds, which hopefully will solve the problem. Anyone that wants to try that themselves, and who knows how to edit the installed code, can change the value of COMM_TIMEOUT in homeassistant/components/life360/const.py from 3.05 to 5. If you do, and it helps, I’d really like to hear about it. (Also, see Life360 frequent updates on 2022.10.x · Issue #80425 · home-assistant/core (github.com).)
I’m also implementing a retry mechanism in the life360 package (that the HA life360 integration uses.) Hopefully that will help as well.
It actually increases the timeout to 10 seconds (which is more consistent with how other integrations/packages use aiohttp), and does not implement a retry mechansim.
Hopefully this solves the problem. If not, please let me know.