Completely agree, out of band channel is what would seem to make most sense. Connection status should be decoupled from home/away/driving state.
I’ll setup the composite tracker, that should resolve these issues. Thanks Phil.
2 Likes
@pnbruckner Qq, not sure if i should put
require_movement: true
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.
1 Like
The composite integration is still a “legacy” device tracker platform, so it creates entries in known_devices.yaml. You can edit the file and set the picture key to point to a “local” image file (in the www folder) or you can give it an URL, such as the one you get from life360.
2 Likes
Even though you’re composite tracker seems to work really well (no unknowns seen yet!), i wonder if i need to investigate this life360 error. Is anyone else getting it ? Wonder if there is an outage. This seems to be the reason for the alternating states, but i can’t be sure.
I guess it would be tidy if i can remove it from the logs either by fixing or ignoring it 
But if it’s an outage or API change i guess we will have to live with it.
ogger: homeassistant.components.life360
Source: helpers/update_coordinator.py:151
Integration: Life360 (documentation, issues)
First occurred: 21:19:36 (3 occurrences)
Last logged: 21:28:24
Error fetching life360 ([email protected]) data:
Try enabling debug. Also update to 2022.10 and the error messages should be a little better. But basically your system is having trouble talking to the server, for whatever reason.
How much more common is it with 2022.10 that the life360 tracker entities change to unavailable? I’m getting reports that it happens very often.
One of the biggest changes in 2022.10 is changing from the requests package to the aiohttp package for network communications. That, in and of itself, should not be the problem, but it’s possible the details have something to do with it. E.g., the way timeouts are done is different, and with the requests package it used to be able to do retries at that level which I did not find available with aiohttp.
So, basically, I may need to adjust the timeout and/or add some “manual” retries in the life360 integration or the life360 package. When I tested, I did not see these issues, but I may just have a better than average Internet connection.
1 Like
FYI, just submitted:
Hopefully this gets accepted & released and resolves most, if not all, of these intermittent “unavailable” states.
2 Likes
PR was just approved and is marked for 2022.10.6. 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.
UPDATE: There was no 2022.10.6 release, but it did make it into 2022.11.0b0.
2 Likes
So, it appears although the increase in the overall timeout to 10 seconds may have reduced the number of occurrences of this timeout/unavailable issue, it hasn’t eliminated it.
I just submitted a new PR:
I’ve changed the details of the timeout (from one overall timeout to a separate timeout for socket connections of 15 seconds and an overall timeout of 60 seconds.) I’ve also enabled retries for client connection errors, including timeouts, to a maximum of 3 (i.e., a maximum number of attempts of 4.)
Hopefully the PR is accepted, and hopefully it resolves the issue once and for all. 
Of course, if your network ever goes out, or the Life360 server does go down, you’ll still see an error (although it will take longer to appear), and the device_tracker entities will still change to unavailable, but again, that is the design the core team wants. I’m just hoping to eliminate that happening unless there is a real network problem.
Oh, I’ve also asked for it to be included in the 2022.11.3 release.
2 Likes
Perfect Phil.
FWIW mine kept showing unavailable every 30-60 seconds between 10pm and 11:30pm in the UK last night (I am on 2022.11.1) and in the end I changed my Node Red automation to ignore unavailable - the issue I have is i look normally for
Previous state is not ‘home’, current state is ‘home’ = I am now home (so disarm the alarm etc)
Previous state is ‘home’, current state is not ‘home’ = I am away (so arm the alarm etc)
The reason I use is not home is that when away I can be not_home or at a place in Life 360 if that makes sense. I have configured the composite sensor, I really should use this for this particular automation.
Cheers
mb
Note that PR 81799 was accepted and merged. Hopefully it will make the 2022.11.3 release. If/when it does, I’d appreciate feedback from users that have experienced the timeout/unavailable issue as to whether or not this helped.
1 Like
2022.11.3 was released a couple of days ago. Has anyone, who was experiencing the timeout/unavailable issue, updated, and if so, has it solved the problem, or at least, significantly reduced it?
FYI, it appears the Life360 server had a problem between about 5:15 PM and 6:20 PM CST yesterday. Unfortunately, the error message wasn’t very useful because of a bug I just found in the underlying Python package the HA Life360 integration uses to communicate with the Life360 server. I’ve created a fix I’m testing now and hopefully will submit it soon. But I was able to catch the error while it was happening and the real error was an HTTP 502 error, which means “Bad Gateway”. Basically, the server had hiccups. 
I might implement a retry for that error since it did seem to be very intermittent and retries might have been able to insulate the HA integration from the problem, at least partially.
That server issue last night hit me also and I had to scramble to shut down some automations. Similar to what happened a couple of weeks ago. Prior to that it had been working rock solid with the last update.
Yeah, I’m very unhappy that the integration is required to set the entities to unavailable when there is a server communications problem, but there isn’t anything I can do about that. This is one of the main reasons I use my composite tracker custom integration “on top of” life360 (and/or googe_maps.) It ignores unavailable & unknown states, so the rest of my system is insulated / isolated from this design flaw.
1 Like
Do you have a link or instructions on how to set this up with Life360?
3 Likes
What Gary said. 
If you have any questions about it, see:
I’m happy to provide any assistance via that topic.
FWIW, I’d recommend something like:
composite:
trackers:
- name: My Name
id: my_name_composite
entity_id:
- entity: device_tracker.my_name
use_picture: true
This assumes your life360 device tracker’s entity ID is device_tracker.my_name.