Feel free to comment on the issue itself.
At some point, I do hope to enhance that integration to allow the user to specify which pieces of data they’d like to see. But right now, it’s just on my “To Do” list, which is “taking a back seat” to the current work on the Life360 integration.
I’m going to go ahead and get rid of the “background” Circles & Members updates. (I.e., updating the lists of Circles & Members. The Member data itself, which is used for the device_tracker entities, will, of course, continue to be updated every 5 seconds.)
And, good point, an integration reload (or, indirectly, deleting & re-adding the integration, or restarting HA) can be used to get it to update those lists. No service or button required.
But, FYI, I’m also going to make another rather large implementation change. The main reasons are: 1) I’m not using the “Enable polling for updates” system option correctly, and 2) I’m not using the homeassistant.update_entity service correctly. Those two, of course, are meant to be used together to allow the user to control if/when entities are updated (e.g., via automations.)
This will result in (at least) one breaking change. I.e., I’ll need to add a unique service to request “frequent updates” for a device_tracker entity (instead of using the generic update_entity service.)
Of course, this will also cause it to take longer before I can release a beta. But this internal reorganization has kind of been wanting to happen for a while now for various reasons.
Incredible, all these efforts you put into this project. How sure are you that, what you are creating, will continue to function? Aren’t you afraid that Life360 will change things again, breaking what you are making?
0% and yes. 
My hope is, though, that what we experienced before may not have actually been their attempt to block us, but rather, our misunderstanding of how their API works. They may have been happy we gave up, or just didn’t care. No way to know for sure.
Committed 0.4.0.dev9 & 0.4.0.dev10.
Committed 0.4.0.dev11
life360.update_location service. It takes one parameter, entity_id, which can be a single entity ID, a list of entity IDs, or the word “all” (for all Life360 device_tracker entities.) Targets (such as areas, etc.) should also work.homeassistant.update_entity.device_tracker entities.Committed 0.4.0.dev12
Note that I’m working on writing more tests and fixing (hopefully minor) bugs along the way. After I get some reasonable coverage, I’ll push out a beta release.
Committed 0.4.0.dev13 - 0.4.0.dev15
When a login error occurs while getting Member data, a repair issue will be created and the account that was used in the request will be disabled. Unfortunately, the binary “online” sensor for the account was also getting removed. Now it will still exist, but its state will change to off. It will only get removed if the associated account is removed (not just disabled.)
Note that this only happens for login errors while getting Member data, not while getting the list of Circles & Members.
Also, more tests were added.
FYI, when an account is disabled and a repair issue is created, the recovery is going to the Life360 integration entry options and updating the problematic account. It’s possible just re-enabling the account might work (which checks that the credentials are still valid.) Or maybe the password or authorization string need to be updated.
Hopefully, though, this never happens anymore! 
At least, that’s the whole point of all these recent changes.
Committed 0.4.0.dev16 - 0.4.0.dev18
Adding tests has definitely been worth it! 
Finished the init module tests. Found & fixed one other bug in the login error handing (which, again, hopefully nobody will ever have to worry about. I have done some manual testing, but the automated testing definitely makes it easier to find these kinds of issues.)
When a login error occurs while getting Member data, besides the other actions described above, it also cancels any other pending server requests using the same account (since requests for all Members are done in parallel.) There was a bug in the task cancelling sequence which has now been fixed.
Just installed the latest version. So I’ll be testing it also. Currently only with an account with the old (email password) login. Thank you @pnbruckner for all your hard work so far! I really really appreciate it!
For various reasons, I’m probably going to have to change the “domain” of this custom version of the Life360 integration from “life360” to something else (probably “life360cc”.) I’m sure this will cause all kinds of havoc, but I feel like I may not have a choice. If I can find a reasonable way to do this, I want to get it done before releasing a beta.
Although I haven’t tried doing this yet, my guess is, at a minimum, installation details will have to be updated manually. E.g., if you cloned the repo and created a symbolic link, or you have an entry in your compose.yml file, those details will have to change to the new folder name (custom_components/life360cc instead of custom_components/life360.) I will try to make the integration automatically “move” the integration config entry (i.e., in .storage/core.config_entries) from life360 to life360cc, but that may not be possible. If it is, it will probably require you to add the life360cc integration, which will then hopefully find and migrate the life360 entry. There will probably be errors about not being able to find “life360” until this is done.
I’ll try to make entity names and IDs stay the same, but the service, at least, will probably have to change (life360cc.update_location instead of life360.update_location.)
And, FWIW, I don’t feel like this integration will ever be accepted as a “core” integration again. So, as long as it will have to continuing living as a custom integration, it will have to have its own unique name (i.e., domain), that doesn’t conflict with the life360 core integration, which is still “reserved”, even if it doesn’t really exist anymore, and may never exist.
UPDATE: Never mind. I tried to get the life360 icons back (in the HA brands repo), but I couldn’t as they were. So, I thought I’d need to move them to a custom integration with a different name. But now it seems I’m allowed to move them to a custom integration with the same name. If that goes through, then I won’t need to make this extremely messy change.
Ok, Life360 icons should be back. For some reason, it may not show up on the Integrations page, but it should show up on the Life360 page. For some reason the icon is hidden on the Integrations page. I’ve seen this happen before (with some of my other custom integrations), so I think it will eventually show back up at some point all by itself. Magic!
Bottom line, I shouldn’t need to change the integration domain. 
What is the “Life360 page”? I see the Integrations page under Devices & Services (and no, I don’t see an icon there for this integration).
-Tim
On the integrations page, click on the Life360 box. That takes you to the Life360 integration page. There you should see:
Thank you Phil, I see the icons now.
Hypothetical question for you…
My one son (being funny) had changed his name in Life360 to “The Favorite”. So his device is named device_tracker.life360_the_favorite.
If I or we change his name in Life360, will the system pick that up automatically or will he forever be “the_favorite”?
-Tim
so it’s not just in my house then
Not sure about Life360 but you can always change the entity name (and friendly name) in HA irrespective of what’s in Life360…
Just posting back, to say been deploying the various versions, and no further issues to report
When a Member is first seen a device_tracker entity will be created for that Member. Internally, HA will use a “unique ID” for the entity (not to be confused with the “entity ID”), which in this case, is a unique ID that Life360 created for that Member. That ID will (or, at least, should) never change.
Initially, the entity ID & friendly name will be based on the Member’s name. This all gets written to HA’s “entity registry.”
As @Gav_in said, you can override the entity ID and/or friendly name via the entity’s settings. (What you’re actually doing by making changes in the entity’s settings is changing the corresponding data in the entity registry.)
If the Member changes their name in Life360, the HA integration will see that, but honestly, there’s a lot of code between the integration and the entity registry. I’d have to review the code to see what would actually happen. My guess is that if you have not overridden the entity’s name via its settings, it might change to the new name, but the entity ID will probably not change. But right now, that’s just a guess. On the other hand, if you have overridden the name or entity ID via the entity’s settings, they will definitely not change if the Member changes their name in Life360.
Updated to the latest version. Thx a lot Phil.
