Thanks for the feedback. It’s definitely still a works-in-progress.
If your profile has advanced mode enabled, you should see debug verbosity level choices in the configure menu. Pick a higher level for more detail about what’s happening.
Hello.
I still can’t authenticate.
Manual installation, last comming, hard reset and it doesn’t work for me.
Greetings.
You might want to try again. I’ve been using this new stuff for a couple of weeks without any login errors but I got them last night. This morning, it works. Hmm. Could be the same old issue. Still too early to tell.
UPDATE: The server seems to be extremely sensitive about the request for the list of Circles. I know it rate limits it. Now it seems it will respond with the HTTP 403 “forbidden” (aka login) error, too, sometimes. But the request for Member details can still work. Obviously, I still have some work to do. Or, maybe, we’re still up against their attempts to squash unauthorized usage.
Hi, I had the same problem. What I did I changed my password and it worked. It’s a little strange.
For now, I’m guessing all you need to do is reconfigure to disable the account, then reconfigure and enable it again. You probably don’t need to change the password. Hopefully, I’ll have something better tomorrow.
I’ve added retrying for HTTP 403 (forbidden, aka login) errors when requesting Circles, similar to what it was already doing for HTTP 429 (too many requests) errors. I’m not sure this will solve the problem, but it seems reasonable, especially considering that these Circle requests seem to work differently than all the rest.
I want to let it run for a while before committing the changes. If all goes well today, I’ll do that first thing tomorrow.
1 Like
Thanks.
Once its available I’ll install and test, although the issue I had has not appeared again, but its maybe linked to the 403’s
TLDR: The changes seem to work. After 17+ hours, there were no errors where retrying didn’t work. I’ll commit the changes soon.
It ran for 17 hours, updating the Circles & their Members once an hour (so a total of 18 update cycles.) For each cycle, it’s making two Circle requests (I’m using two different Life360 accounts), and two Member requests (because there are two Circles shared between these two accounts.) So, at a minimum, each cycle does four server requests.
Of those 18 cycles, only 5 completed without having to handle any errors, finishing all four requests in under a second. (There is some parallelism, more to be added later.)
Of the remaining 13 cycles, 11 were the most typical, resulting in HTTP 429 (too many requests) errors to both Circle requests, with a Retry-After anywhere in the range of say, 20 seconds to 10 minutes. Then, after delaying for Retry-After + 10 seconds, the Circle requests worked ok.
That leaves two other cycles in which one of the Circle requests resulted in 429 (just like the other 13), but the other resulted in an HTTP 403 (forbidden) error. Since I have nothing to go on, I randomly decided that I’ll have it wait 15 minutes after one of these errors, and to retry up to 4 times. Of the two times this happened, the Circle request worked ok after the 15-minute delay one time. But the other time, it got a total of three 403 errors (resulting in a total delay of 45 minutes) before it worked.
No wonder all the previous implementations kept failing with “login” errors!!!
I may have to fine-tune the retry handling of the 403 errors. Maybe allow more retries before giving up. Worst case, it will just effectively cancel the next hourly update cycle, since it’s still working on the last.
And, as an FYI, currently, any other type of request (Members in Circle, or Member details) will consider 429 an error, and 403 a login failure, so we’ll have to keep watch if that ever happens, too, and if something else should be done in those cases.
New update committed with improved error handling.
2 Likes
Thank you Phil.
Pulled the zip and installed dirty over the top of the previous file sets and restarted HA.
Initially on startup I got ‘unavailable’ again, but I looked at the logs and a ‘429’, had been served twice, Waited 10 mins (log retry said 536s), and it started pulling data and updated the status.
I’ll post back if there are any issues from before like status being unavailble for a few hours
Ok, thanks!
FWIW, because retrieving the list of Circles, and the Members in each Circle, can take a while (due to these 403 & 429 errors), once they are successfully retrieved, the integration stores the information in a file in the .storage folder (.storage/life360, to be specific.) Then, when HA is restarted (or, I suppose, when the integration is disabled & re-enabled), the integration will read that information, and if the Circles & Members can’t be immediately retrieved from the server, it will use the values that it read from the file temporarily. The idea is it should start functioning immediately. Of course, the first time the integration is added (or if it is removed and re-added), the file won’t exist, so it will have to wait. In this case, a warning is generated so the user can see why entities aren’t created/available immediately.
Does that make sense?
Totally.
I think the first time I installed the previous version, it worked out of the box, that’s why it confused me this time (and probably spooked by the ‘unavailable’ issue I had but has not since reoccured)
I just recently noticed the unavailable states at restart again.
Well, turns out I overlooked something when using the data from .strorage/life360 when the integration is loaded (either after HA restart, or disabling & re-enabling the integration.) This bug would still cause unavailable states.
I just committed a new change that should resolve that (i.e., it adds the code I forgot when I made the huge change last time.)
Committed another change that sets the tracker’s state to driving only if the entity is not in a HA Zone. Also, made it translatable. The state itself will now be all lowercase driving, whereas the “en” translation is “title case”, i.e., “Driving”. So, in the UI it will look like before (Driving), but any automations would need to check for lowercase (driving).
I still have quite a few "TODO"s commented in the code, so there will still be quite a few changes before I’m ready to release a beta (installable via HACS.) Other than tracker entity state restoration (which I plan to do next), most of the basics should now be in place. The rest is somewhat “fluff” (like testing. 
)
6 Likes
Thanks for all your efforts Phil. If you need any testing let us all know, your efforts are really appreciated here
1 Like
Downloaded and installed thanks.
No issues this time deploying over the old version and restarting HA. Status remains available as expected.
Thanks for your great work
1 Like
The more people that try it, the more feedback I’ll be able to get as to whether or not I’m implementing it correctly. As always, this is all guesswork since the API is neither published nor supported.
If you can use the code directly from github, great. If not, I hope to have a beta release out sometime in the not-too-distant future.
1 Like
I am using it from GitHub and just doing a git pull to update and it is working great atm.
I will do some more testing later today - so far it seems reliable. It even picks up my daughter who is in the US (I am UK based) and I have a couple of automations that are triggered when she is in certain places - that is what i missed most when life360 went as I didn’t want the companion app on her phone (and frankly as she is 5000 miles away has no need for it). They are silly automations, just letting us know when she is shopping, picking up the kids from school etc, but it is great to have that in HA.
Be aware that I have changed the place attribute slightly.
If the Life360 accounts registered with the integration can see more than one Life360 Circle, then the Place names, as shown in the place attribute, will have the Circle name suffixed.
E.g., if a Member is in a Place named “School”, and it’s in Circle “My Family”, then the value in the place attribute for that Member will be:
place: School (My Family)
(where it used to be only “School”.)
And, if that Member happens to be in Places in more than one Circle at the same time, then the attribute will be a list of str, instead of a single str. E.g., if a Member is in a Place named “School” in the Circle named “My Family”, and at the same time is also in a Place named “Mary’s School” in the Circle named “My Kids”, then the place attribute for that Member will be:
place:
- School (My Family)
- Mary's School (My Kids)
But, if there is only one Circle visible, then it will be like before:
place: School
Hi Phil
First: Thanks for trying to reanimate Life360 !
Just now I installed (what I think is) the latest version that you have made available: 0.3.10
I have 1 circle and 7 users.
For al these users I checked the attributes.
The address information is not correct.
It contains “number, street name, province” instead of “street name, number, postal code, city, country”, when I compare this with your Google Maps integration.
Is this information that Life360 offers, or do you compile this yourself ?
“Place” is returning correct information.