Life360 Device Tracker Platform

Honestly, I’m not sure at this point.

I have two systems running this code: my “production” system and a test system. The production system seems to be running along smoothly. But I’m seeing the same problems on my test system. And they are BOTH using the SAME authorization string. (The test system is also using a second account w/ username & password.)

I think I found a couple of possibly related issues with the b1 code, but “fixing” them doesn’t seem to have completely solved the problem.

WAIT: UPDATE:

So, last night I was getting the “login” error (actually 403 Forbidden) when trying to retrieve the list of Circles & Members. This is retried every 15 minutes. It ran all night that way until I disabled the integration this morning.

Now when I re-enabled it (about 1.5 hours after disabling it), I got one “too many queries”, which was retried after a couple of minutes, and IT WORKED!!

So, seems like Life360 just sometimes likes to be difficult. :person_shrugging:

EDIT:

The “good” news is that, once the list of Circles & Members is retrieved, the normal Member update requests seem to work fine, although I have to say, I have seen a couple of “login” errors lately. I may end up having to retry those, too.

BTW, one of the “fixes” I mentioned above involves the use of a separate query that I was using only in the config flow, specifically the “me” query. I was using that as sort of a test to make sure the authorization entered (either username/password or authorization string) worked, but it, just like the request for Circles, seems to sometimes cause login errors, so I simply deleted it (since I had never used it before.)

Released 0.5.0b2

A couple more fixes:

  • Fix a bug with updating Circles & Members data update coordinator. This bug could sometimes prevent properly creating or deleting device_tracker entities after configuration account options were changed.
  • Do not use “get_me” query in config flow to test authorization since it also sometimes causes error 403 “Forbidden” (aka login error.)
2 Likes

Everything works fine now. Thank you for your work.

Hi Phil,

I’ve had some issue with this release. All changes involved a restart of HA afterwards.

I did a dirty upgrade over the previous version 0.5.0b1 and I could no longer get status for the entity trackers that were created and it disabled the integration.

I tried reenabling the account (username and password), but the same issue persisted.

So I removed the service, and did a fresh install however when logging in again I am only getting a binary sensor for one of the users pulled in, and then no device items created for the users linked to then account.

Logs seem to indicate it can’t get the members and circles as you describe above after the clean install, but there were no errors on when installing over the previous version (where the data would have been in a local file from previous requests), just that the entities were unavailable

I’ll leave it a while, but may revert back a couple of revisions if the issue continues

OK I was getting 429 requests all the time.

Disabled the Integration for 5 mins, reenabled and it worked first time. I also opened the life360 app on my mobile during disablement, not sure if that kicks something to work also

Yes, I have seen that, too, a few times, but not very often. It seems sometimes the first Member update can result in an error 403 (forbidden, aka login), which will, indeed, cause the account to be disabled. That’s not the whole integration that gets disabled, but just the corresponding account. You should also see an ERROR in the log about the login error while getting data for the Member. And, of course, there should be a repair issue as well.

Currently, the integration only retries error 403 while fetching the lists of Circles & Members, but I’m considering retrying all of these errors. There seems to be no rhyme or reason to when the server will return this error, although it seems to happen way more often while fetching the list of Circles.

Yep, when you remove the integration entry, the file that saves the list of Circles & Members gets deleted. So this is not unexpected. It won’t be able to create the tracker entities until it can retrieve new lists. And that can’t complete until the server stops returning error 403 or 429.

Nope, no errors, just warnings until it can complete the retrieval of the lists of Circles & Members.

Ah, then you were lucky! :laughing: I’ve never seen a case where an error 403 happens immediately after an error 429, and I’ve never seen a case where error 429 doesn’t go away when the integration waits the amount of time the servers says to wait (which, BTW, you can see in DEBUG messages in the log.) You can disable and re-enable the account, but it will just get another error 429 with the remaining time (if there is any.) If the time is up, it will work, whether or not the account was disabled/re-enabled. Bottom line is, when it gets in this state where it’s retrieving the list of Circles & Members, but it’s getting these errors, you just have to wait. Could be a couple minutes, could be hours.

Having said that, I’m trying one other thing (which I haven’t released yet.) I.e., when it gets an error 403 while retrieving Circles, it will clear the network session’s cookies. I have no idea if this will have any positive effect, but I don’t know what else to try.

Thanks for the explanations they will definitely help others. The cookies thing may work, would make sense if Cloudflare are assigning affinity in their DC to a server and it may reset that connection. Its certainly a trick I try when testing load balancers at work when we giving them a cookie as part of the first connection request

1 Like

Released 0.5.0b3

Sometimes the Life360 server will continually respond with error 403 (forbidden/login) to requests for the list of Circles an account can see. Other times, however, it will respond with just one error 429 (too many requests), or it will simply work. In both error cases, the integration will retry (after 15 minutes for error 403, or the amount of time the server says after error 429) as many times as necessary until the query works. There doesn’t seem to be any rhyme or reason as to how the server will respond at any given time. Sometimes the first request works, sometimes there’s one error 429, sometimes there’s a few error 403’s, sometimes it seems like it will respond indefinitely with error 403. As an attempt to deal with this, the integration will now clear the network session’s cookies when it gets an error 403 after a Circle request. No idea if this will help, but it’s worth a try.

Also, when selecting an account to modify or delete, show which accounts are disabled.

Lastly, when an error 403 occurs while retrieving Member data, all activity with the associated account is stopped and the account is disabled. However, in some rare circumstances, a “foreground” Circles & Members update may be in progress, and that was not being stopped properly. This update fixes that.

Released 0.5.0b4

In an attempt to minimize the effects of HTTP error 403 (forbidden, aka login):

  • Clear cookies after all 403 errors, not just in response to request for Circles list.
  • Reduce retry delay after 403 error after Circles request from 15 to 5 minutes.
  • Immediately retry all other requests after 403 error up to 2 times.

I don’t know if any of this will help, but it’s an attempt to avoid login errors after a HA restart which seem to sometimes happen while fetching Member data.

1 Like

Updated to b4… Had to disable my account and then re-enable it…

All is well after that.

Why do you say that?

What version did you have before? Any errors or warnings?

All entities were disabled after I updated… I reviewed the config settings and it said that my account was disabled.

I selected modify account to re-enter my credentials and all was well after that.

I updated from b3… I generally use your composite tracker, so it ‘may’ have been disconnected/disabled from the b2(?) - b3 update and I did not notice it.

Ok, thanks for the details.

same here…

@JasonMeudt @maurizio53 when an account gets disabled, there should be an ERROR in the system logs, and a repair issue should get created. Also, the corresponding “online” binary sensor should change to disconnected (i.e., off.) Did you not see any of that? The account should not get disabled without some sort of indication.

Released 0.5.0b5

  • Skip account type selection when modifying an existing account.
  • Bump life360 package version to 7.0.0.
  • Add explanation of when to use “Access type & token” to config flow.
  • Update info.md.
  • Improve login error test.

Sorry been really busy for the last week, so not really kept up with the testing of this. Is it still only available as a custom repo ( i cloned the GiHub branch and mounted it in docker) or are we able to use HACs yet? No biggie, just want to update it ( I am about 10 days behind) and don’t know which way to go.

Cheers!

mb

EDIT: Answered my own question sort of as for now I have just done a git pull and a restart :slight_smile:

It’s still a “custom repo” (i.e., it’s not a built-in integration), but since I’ve released beta versions it can now be installed/maintained via HACS.

If you previously “manually” installed it, I would strongly recommend disabling the integration first (by which I mean, go to the Life360 integration page, click the three-dots next to “CONFIGURE” and select Disable. You should not have to delete the integration entry.) Then, after restarting HA, you can go through the process of removing the manual installation, and then adding it via HACS.

Oh, and then, once it has been installed by HACS, and you’ve restarted HA, you should be able to re-enable the integration entry. You’ll probably need to show disabled/hidden integrations to find it.

1 Like

Thanks Phil.

I just did a quick git pull and then a docker-compose pull to update both HA & Life360 quickly as about to jump into another meeting :slight_smile:
I’ll move it to HACs later tonight!

Thanks

mb

1 Like

Just added the following to the docs. It will be available in the next release:

Note on Updating Circles & Members Lists

The current implementation differs from previous versions in the way it retrieves the list of Circles visible to the registered accounts as well as the list of Members in each of those Circles. This is due to the fact that the server seems to severly limit when the list of Circles can be retrieved. It is not uncommon for the server to respond to a request for Circles with an HTTP error 429, too many requests, or an HTTP error 403, forbidden (aka a login error.) When this happens the request must be retried after a delay of as much as ten minutes. It may even need to be retried multiple times before it succeeds.

Therefore, when the integration is loaded (e.g., when the integration is first added, when it is reloaded, or when HA starts) a WARNING message may be issued stating that the list of Circles & Members could not be retrieved and needs to be retried. Once the lists of Circles & Members is retrieved successfully, there will be another WARNING message saying so.

Device tracker entities cannot be created until the lists of Circles & Members is known.

Once this process has completed the first time, the lists will be saved in storage (i.e., config/.storage/life360). When the integration is reloaded or HA is restarted, this stored list will be used so that the tracker entities can be created and updated normally. At the same time, the integration will try to update the lists again from the server, so WARNING messages may be seen again.

Due to the above, new Circles or Members will only be seen (and corresponding tracker entities created) when the integration is loaded. Therefore, if the registered accounts are added to any new Circles, or any Members are added to the known Circles, the integration will not be aware of those changes until it is loaded. This will happen at the next restart, or you can force it to happen by reloading the integration. I.e., go to Settings → Devices & services → Life360, click on the three dots next to “CONFIGURE” and select Reload. Please be patient since it could take a while due the above reasons before any new tracker entities are created.