Phil,
Just letting you know that the custom_updater worked great to update life360.py to the latest version.
I wasn’t able to find a legacy UI component to perform an automatic check for updates, but there several services available, such as custom_updater.upgrade_single_component to update manually in a few clicks via the services UI.
There is also a Lovelace tracker-card, and it worked nicely. 
Thanks again for this update!
HI Phil,
Ive setup your CC (thx!), all working fine, (changed from Google Travel time and iCloud to Waze and Life2360 in 1 day. wow, what a difference a day makes!) except for 1 small detail.
My wife and I set up the apps on our devices, but the respective entity_picture only shows on my account. I know there’s an entity_picture on my wife’s account too, set it up myself 
She hasn’t got her own login in the CC setup, but was invited by means of the circle invite code in the App.
Any detail I missed in the setup?
This Life360 platform will pass whatever picture URL Life360 provides for each member to the Device Tracker component at every member update. However, the Device Tracker component will only use that when the device/member is first “seen” and added to known_devices.yaml. If you changed the picture via the Life360 app or website after the corresponding device was added to known_devices.yaml, the change will be ignored by the Device Tracker component. The only way to get the new picture to be used would be to delete (or temporarily comment out) the corresponding entry in known_devices.yaml and restart HA.
Bingo, thx! Like a charm.
small but annoying thingy:
one of my circle members has a connection issue and this is what floods the log consequently:
Lost Connection: This user has lost connection to Life360. Visit our troubleshooting guide to help them reconnect.
could some sort of check be made to not flood the log when this is happening?
also, maybe nice to add:
show_last_changed: true/false as configurable option?
I suppose that would be possible, but it doesn’t seem to be the norm. E.g., I also use Google Maps Location Sharing, and it basically does the same thing when it detects problems. When any type of entity has problems updating, as far as I know, it’s very typical for it to write an error message to the log on each update until the problem goes away. To add some sort of error filtering would require keeping track of the error message for each user, because if there’s a new type of error, you’d want that to show up.
As an alternative, you can use the members parameter to include all the members except the one having issues until that user gets it fixed. Of course that doesn’t help if the situation is dynamic.
Can you explain what this would do? It’s not obvious (at least to me) what feature you’re asking for here.
nothing fancy, just last_changed in the frontend… which is quite useful info for a presence tracker 
about the error: I appreciate your answer. Don’t want to excluded just yet, maybe ill set the timing a bit lower, though i dont want to slow down the tracking, which is very very accurate right now, just what i was missing with all the others 
Sorry, but I’m not following you. The device_tracker entity, like any entity, already has a last_changed field. And it’s already displayed in the frontend, as you show. Also, Life360 device_tracker entities have a last_seen attribute (which is also displayed in the frontend if you click on the entity to see the “more info” dialog), which gives the time that Life360 last updated the member’s details. So I’m not understanding what functionality you would like me to add that isn’t already there.
Regarding the error messages, I’ll play around with the idea. I’ve never really been happy with the general situation of entities flooding the log with the same error over and over, but like I said, that seems to be the norm. Still, I think it would be good if for a given member, if the exact same error message is happening one after another to just show it the first time, and then maybe log an INFO message when the error stops.
hmmm, it’s there, because I’ve set it in the customize part for this device_tracker. As for all device_trackers I like to display the last_changed field. It’s not there by default is it? Device tracker - Home Assistant
as said, no big deal, it is available through customization. I simply thought it might have been nice to have it set in this component. Haven’t played around with the last seen yet, guess we can template that out into a dedicated sensor. But to have it show under the entity in the front-end needs the customization. Or what am I not seeing here… sorry.
thats exactly what i was hoping for!
And yes, you’re right, would be even better if that were to be default behavior in HomeAssistant for all entities flooding the logs…
last_changed is actually a field of all State Objects. It’s not unique to device_trackers. As to your customizations, I don’t know what that might be. E.g., I have no customizations for my device_trackers, or my frontend, and it shows last_changed as a relative time if you click on the entity and open its “more info” dialog. (I guess it’s not exactly what you showed, then.) So maybe what you’re talking about is customization of the device_tracker view in the frontend. I really don’t know about that. But it looks like you’ve already done it. Or are you wanting some custom frontend component/view/widget/whatever? If so, that’s outside the scope here, and I would think that would apply to any device_tracker, not just Life360. Bottom line, I really can’t help you there.
Regarding error filtering, I created an issue in my repo: #12: Filter repeated error messages. You, or anyone, feel free to comment. I started a test to filter out “get_circles” errors, which tends to happen when my local Internet access goes out, or the Life360 server is unavailable. Depending on how that goes I’ll try to add something similar for individual member errors.
you can use the members parameter to include all the members
been trying to do so, but I receive errors regarding the name I enter not being a member.
Seems to have to do with the fact I dont use a username, or login name, but an emailaddress and phone number which was al I got when loggin in.
I do have a device_tracker name with life360_name. Should I use that to include the members I select? And if yes, do I need the whole device_tracker.life360_name, or only the life360_name bit.
thx,
Marius
The only error you could see related to the members: config option is “Invalid member name: XXX”, where XXX is one of the values you provided for this parameter. And per the doc page, the only requirements of these values are that they are a string which contains one, and only one, comma. Per the example provided:
members:
- mike, smith
- Joe,
- , Jones
These names come from Life360. That is, they are the First Name and/or Last Name provided in the members’ account information.
If you already have device_trackers from before you added the members: parameter, then the object_id’s will include those names. Again, per the doc, for a member with both a First Name and Last Name, the device_tracker object_id will be prefix_firstname_lastname. In this case the members: entry should be FirstName, LastName. For a member with only one name, it will be prefix_name. In this case the members: entry should be either FirstName, or , LastName, depending on whether it was a first or last name.
Basically, you need to know what the First Name and Last Name are in the corresponding member’s Life360 account. If the member only has one name in their Life360 account, and you don’t know whether it’s the first or last name, then try both – first try Name, and if that doesn’t work, then try ,Name. In fact, you could just enter it both ways. These names don’t have to be members. But members retrieved from the server have to match one of these entries to be tracked. So putting:
members:
- xxx,
- ,xxx
will track a member with a single name of “xxx”, whether it’s a first name or a last name.
Hmm, maybe I should add a new feature whereby if a member only has one name entered in Life360, you can just enter that single name (with no comma), and they will be tracked if it matches either the first or last name… 
Component has been updated (to 1.2.0) to filter excessive error messages (like when your Internet goes out, or the server becomes unresponsive.)
If there are two consecutive errors for the same operation, the second one will include the message “Squelching further errors until OK”. Then, when that operation succeeds, another error message will be logged that says "OK again’. (It’s purposely categorized as an ERROR so that it shows up on the Info page.)
I think it was the comma I forgot, didn’t think that to be correct yaml somehow…
will try, along with your new update.
btw, can’t thank you enough for the CC, even my other half was happy as can be, arriving home from work today laughing because she hadn’t needed to power her iPhone today…
cool.
Component has been updated (to 1.3.0) to allow names in members: list to leave out the comma if the corresponding member only has one name entered in their Life360 account. A name entered this way (i.e., without a comma) will only match a member with a First Name, or a Last Name, but not both.
cool! much better… duh, starting to feel rather jealous of all these programming capabilities and ease you’re displaying here…
Phil, just a follow-up to the use of the custom_component tracker_card. It’s working great, but one thing that you might not be aware of is when an update is shown as available, it also provides a link to the release notes if you click on the version (1.3.0)
Currently, this github page just shows “There aren’t any releases here”.
It would be nice if the release notes were populated here in some fashion.
Thanks!
Sounds great.
Now I need to figure out how to display adress name and show it in UI.
How can i display last_changed in frontend like this.
I don’t use the tracker card, but I knew it provided some sort of link for new versions. I guess it makes sense it would use that link from the JSON. I’ll have to do it a little differently since all my custom components are in one repo, but I’ll work on it: Issue #17. Thanks for the feedback!