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:
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!
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!
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.
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.
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.
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…
In your example config it uses it, but you mention the default is false. What would make most sense? What advantage is there over the other ?
and 2, i added your composite tracker as the one to use to the persons section in HA. Can i then refer to the person.name sensor and would it show the right states? I ask because the person and life360 entities have a nice picture attached to it and composite doesn’t :-).
NM i have my answer, this works great. So happy that this is working again! Thanks!
I would leave it out; i.e., leave it at its default value of false. I added the feature for someone a long time ago, and as I’ve said elsewhere, I really don’t like the feature. It’s intended to attempt to filter out small changes, e.g., when a device is sitting at home, or in some other place, and not really moving, yet the GPS coordinates keep changing by small amounts, typically back and forth around its actual position. I’ve never found it necessary.
)
