That is a shame Phil, as the Life360 integration has been rock solid for me, but I too am getting inflicted with the ‘unavailable’ issue. It is causing mayhem as the alarm tries to arm and VPNs are brought up etc.
I can look into my (node red) automations and see if i can mitigate it, but it would be a lot easier to do it natively, especially as it has been IMO the defacto standard for presence in Home Assistant.
Just my 2p worth
mb
Thanks. Unfortunately, I lost the argument, at least via the discussion in the PR. If anyone wants to take this further, they will have to open an architecture discussion. I’ve seen how that might go and I’m not willing to put myself through that. But feel free to try if you like.
I’ve already closed the PR and am working on a replacement that simply fixes the bug.
I’ve got other things I’d like to do with this integration (I already have another one primed to open a PR that better handles the address information coming from the server.) And I’m also working on a somewhat major overhaul of the “data coordinator” so that there is one object responsible for querying the server via all registered accounts. This allows the integration to much more intelligently handle Members that are in multiple Circles, especially where the information available for the Member is different in different Circles, or Members whose device has “lost connection” with the server (typically when they are off for an extended period of time), etc.
IMHO, the easiest work around, at least for now, is my Composite custom integration, or something like it. Unfortunately, the built-in Person integration doesn’t really help.
Phil, is there any possibility to get “historical” data?
Use-case:
– a person is at home & connected to Internet via router;
– Life360 data are available online;
– then the person leaves the home and is NOT connected to the router - and assume that there is no mobile Internet available for the device - so Life360 data are NOT available online;
– then the person comes home;
– now we can see the whole past tracking.
I wonder if it is possible with Life360.
I am asking because there is a Traccar integration which provides a similar service; and each Traccar client has an “offline buffering” feature. When a Traccar client has no Internet connection, it just collects it’s tracking data. When the connection is established - these data become available online.
(unfortunately, HA integration for Traccar does not allow to see these “historical data”, this is available for Traccar website only)
And I do not know (and haven’t tested it by myself) if it is possible with Life360 clients…
Life360 (by itself) does have the ability to see historical data via its app. I think even free Circles provide a few days of history, but not really sure. But I’m pretty sure when a device is offline the Life360 app on the device is not recording historical data to send to the server when it comes back online. The history is collected and saved on the server only, as far as I understand it (based strictly on observation.)
As far as retrieving and using that historical data in the HA Life360 integration, 1) the Life360 API is not published or officially supported, and I’m not aware of any way to get that data via that API, and 2) no, generally HA does not like to use historical data. I’ve been a bit down this road before and I was told in no uncertain terms not to go there. Maybe things have changed, but for Life360, the point is moot anyway.
In case the installation instructions aren’t working for you and you’ve been using life360 long enough to have configuration using device_tracker like this:
life360:
driving_speed: 15
show_as_state:
- driving
device_tracker:
- platform: life360
username: !secret life360_username
password: !secret life360_password
convert it to this format before trying to upgrade:
life360:
accounts:
- username: !secret life360_username
password: !secret life360_password
driving_speed: 15
show_as_state:
- driving
Or else you won’t get any entities created. This took me a couple days to figure out…
Thanks.
Yes, this has been noted before and I’ve responded each time that those old entries under device_tracker should have been removed long before. They predate the built-in integration. (At least, I think so. I can’t remember off the top of my head. At the very least that was changed long ago.) It’s just that while life360 was still a “legacy” device tracker they never caused errors (although they were completely ignored.)
BTW, you don’t have to change the config to that new format before upgrading. You can simply remove all the life360 entries. (The account info has already been in the .storage folder, so that won’t get lost.) The only thing you’d “lose” is the show_as_state setting, but you could always change that via the integration CONFIGURE page after upgrading.
Sorry you struggled with this. This whole “legacy → entity-based” transition has been harder than it should have been, but mostly that’s due to the way the component level code works, not the life360 integration itself. I’m sure many people went through similar pains when a lot of the built-in integrations were first converted, but that was so long ago I don’t think anyone remembers that pain! 
It’s unfortunate that you no longer have control over the project you worked so hard on.
What were the benefits of making your work into a built-in integration instead of leaving it as a custom integration?
If it was still a custom integration you would have had full say over what happens with it and it sounds like it would have been an easy fix.
A built-in integration is much easier for everyone to use, especially novice users. And, at the time I originally submitted it, custom integrations could not use the config/options flow infrastructure.
Also, it’s really hard to maintain a custom integration in such a way that it can work with a range of HA releases, since often very basic implementation details change, and to be backwards compatible requires extra code to deal with the different versions of built-in code. I don’t expect everyone that uses one of my custom integrations to have to be on the latest & greatest HA. (And since I’m almost always running an old HA version on my “production” system, I need to maintain backwards compatibility for my own benefit, too! 
)
With a large open-source project like this, you’re never really fully “in control” no matter what you do. I may disagree with some of the design/implementation decisions the core team has made, and I may push back on some things I really believe in, but in the end, consensus is a great thing!
FYI:
Feel free to comment/vote.
My personal opinion is the requested functionality probably doesn’t belong in the device tracker integration, but should rather be a “system” function (i.e., template sensor, etc.) But, If enough people believe this should be in the Life360 integration, I could be persuaded to add it. Now, whether or not it gets accepted is another thing. 
I know it’s been a while but recently I discovered that the Life360 server sends a pair of values for address, and it sends them on alternating queries. So, I’ve submitted a change to the HA Life360 integration that saves both values and uses them to fill in the one address attribute. The PR is #76269. It was submitted almost a month ago, but so far nobody has reviewed it, so it’s still waiting in the queue with other PRs.
FYI, I just submitted another PR, #77508, that changes the underlying network communications from the requests package to the aiohttp package. Basically, the network traffic will now run in the main “async” loop as opposed to being run in a separate “executor” thread. Although this will have no direct effect on overall server query speed, it should reduce load on the system, which is never a bad thing. 
I did find that on one phone, the life360 was taking up 1 gig of storage for the application. Not sure why and couldn’t reduce it without wiping out the whole app. Seems strange to me.
This is a question to the Life360 dev team…
Yes, that does seem strange. E.g., on my Android phone, the Life360 app uses a total of 165 MB, which includes app, data & cache.
I agree with @Ildar_Gabdullin, you should check the Life360 FAQs. The Home Assistant Life360 integration does not communicate directly with your phones; it only communicates with the Life360 server.
Three PRs should be in the 2022.10 release:
76269 - Improve Life360 address attribute
77508 - Convert Life360 to aiohttp
78550 - Bump life360 package to 5.1.1 (handles asyncio timeout better)
Well this is the first time i’m bitten by this. Life360 states seem to alternate between unknown and home.
My automations consist of any state moving to home or away, so that includes unknown. But i’m filtering on from_state to not be unknown to cover that scenario. Unfortunately it happens all the time now, and no automations run as a result.
Error fetching life360 (atv @outlook.com) data: is what i get in my logs. I have no idea what happened, but it’s been going on for 2 days now. I guess some outage at life360? Don’t really want to setup life360 again, don’t know what will happen to all my stuff.
I don’t know whether to leave my current automations intact and wait this out or setting specific states (from home to away, from away and driving to home etc (i could disable driving but i like to see that), or going with your composite tracker.
Actually i don’t know why i need to filter on unknown in the first place :-). I guess it gives flexibility…
Ofcourse as you said i don’t know why we don’t retain the last state.
I was having the same issues and set up @pnbruckner composite integration and now use Life360 and the HA companion app for presence. Works really well.
I too was bitten by the ‘unavailable’ bug that was causing my alarm to unarm in the middle of the night (house went from not occupied to occupied etc). I spent so much time looking at if…then in my automations but now I just use the composite tracker.
I might try that, this life360 thing is not going away it seems. Did you get the Error fetching error as well ?
I was thinking about setting it up all again but i shouldn’t have to do that, and it will cause major pain in redoing the automations.
So, as I’ve explained previously, the new behavior where the state of the entities becomes unavailable (whenever data cannot be retrieved from the Life360 server) is not a bug, but an intended design by the core team. I personally do NOT agree with this behavior, but I’ve lost that fight. I’ve explained to them that this causes problems for users, but they don’t seem to care. IMHO, the connectivity status should be an “out of band” signal (i.e., the device_tracker entities retain their last state, and a separate binary_sensor entity indicates connection status), but they don’t seem to get it.
Anyway, sorry that this has caused problems, but there’s nothing I can do about it.
You should NOT have to remove and re-add the life360 integration. (Don’t do that.) That will make no difference whatsoever.
Another case is when Life360 services are not available.
Due to the aggression to Ukraine, many companies like Life360 stopped providing services for Russia & Belarus.
So, to use Life360 in Russia, people have to use VPN.
Otherwise there are errors in log:
2022-10-13 07:32:38.083 WARNING (MainThread) [homeassistant.config_entries] Config entry ‘censored’ for life360 integration not ready yet: Cannot connect to host api.life360.com:443 ssl:default [Name does not resolve]; Retrying in background
and corresponding “device_trackers” are “unavailable”.
Not sure that in this case another values should be used…