If you click on one of the device trackers in the frontend, it will open a “more info” display. In there will be shown all the attributes, including the address, as well as the relative time since the last state change. You can always uses template sensors to pick out and display attributes from other entities. Or, I suppose you can customize the UI, but I haven’t done any of that myself so I couldn’t help you with that.
thats no issue at all, simply customize as follows:
homeassitant:
customize:
device_tracker.life360_marijn:
show_last_changed: true
Does that only work in lovelace, or with a custom device_tracker card? Because I just tried that and it made no difference.
No I don’t use Lovelace. But do use the custom-ui by @andrey . See: home-assistant-custom-ui/docs/features.md at master · andrey-git/home-assistant-custom-ui · GitHub
do all sorts of nice stuff:
binary_sensor.family_home:
show_last_changed: true
templates:
icon: >
if (entities['sensor.family_home'].state === '0') return 'mdi:account-off';
if (entities['sensor.family_home'].state === '1') return 'mdi:account';
if (entities['sensor.family_home'].state === '2') return 'mdi:account-multiple';
if (entities['sensor.family_home'].state === '3') return 'mdi:account-multiple-check';
return 'mdi:account-group';
icon_color: >
if (state === 'on') return 'rgb(251, 210, 41)';
return 'rgb(128, 128, 128)';
_stateDisplay: >
if (state === 'on') return 'Occupied';
return 'Home alone';
Ok, I added what I hope are valid links to useful release information for my custom components. It doesn’t follow the usual pattern because all my custom components are in one github repo, whereas it looks like the norm is to put each in its own repo. Anyway, would you mind running the custom_updater.check_all service and then see if the links work? Of course, if there are no updates to the actual components (which there aren’t), … Well, at least keep an eye on it and let me know if I need to change/fix anything. Thanks!
Sure Phil, I will keep an eye on it.
I did manually test this link: https://github.com/pnbruckner/homeassistant-config/blob/master/docs/life360.md#release-notes which is an appeciated addition to the doc. Thanks!
I will confirm if the tracker_card link for device_tracker/life360.py will point here in the next update.
1 Like
not trying tho hijack, but do you have a list or example of cards and components this custom_updater can track? Up to now I only have this repo and the hue.py component, but am short of several important custom cards, like the custom-ui and custom_weather-card…
any pointers would be appreciated!
See:
thx, made contact for some extra non-lovelace info.
about the life360 component: I’ve noticed that when switching the device to airplane mode, the sensor doesn’t switch to not_home or offline. It stays Home… which makes the sensor, which I had hoped to be “the one to replace them all” somewhat unreliable … Is this a bug, or expected behavior?
thx
Ha ha! Great Minds… (which means I have the same question 
as I have today set up Life360)
My code comment:
#=== Home made 'One Device Tracker to rule them all'
#=== using the most accurate device tracker available
1 Like
Do you have an airplane that takes off from within your house? Wow! Very nice!! 
So, I never switch my phone to airplane mode, or turn it off, while at home (and leave it that way when I leave.) So I’ve never seen this as an issue.
I wouldn’t particularly classify this as a bug, or even “expected” behavior – more like, it is what it is. The Life360 device tracker platform is just reporting the GPS coordinates (and possibly Place name) that the Life360 server tells it, and the device tracker component determines that means your home.
I can do some testing to see if there’s a way to tell that the phone is off or in airplane mode from the query results returned from the Life360 server. If there is then, well, then, I’m not sure. Basically a device tracker platform can tell the device tracker component code when a device is seen, but I don’t recall there being an API to say the device has effectively gone missing. And before you ask, the way I read the device tracker component code, the consider_home parameter is ignored for GPS based devices, which this is.
In any case, I’ll try to see if something can be done about this scenario.
EDIT: Hmm, just thought … if it can tell when the phone is off or in airplane mode, I suppose it could just make that (i.e., ‘offline’) the “location name”, which would become the state, which would not be ‘home’. 
great.
thanks.
we mostly do that at night (not to be disturbed or tracked…) or when charging (much faster) Some even say its safer to do when the phone is near you’re head… anyways.
when airplane mode is on, the device should be untraceable even on GPS. The Life360 website sees the phone being offline, so I guess it ought to be possible to reflect that in the CC. I hope.
Again, thanks!
I’ve created Issue #20 per the suggestions from @Mariusthvdb and @klogg above. Since this could potentially be a BREAKING CHANGE, I’d like to get some more input from other users. If you use this custom component, and you feel strongly either way, please comment via the issue noted. THANKS!
Hi! It’s been a while. 
I wanted to check back in with you on this topic. First, are you still using this platform, and if so, do you still have it working with other device trackers and configured to always update?
The reason I ask is, the more I look into how the device tracker component level code works, and how other device tracker platform code works, it appears what you had asked for is the way it’s supposed to be done. I’m considering changing the Life360 code to work this way. So I’m wondering what your experience has been since we last spoke, and if there’s any other considerations I should be aware of.
Of course, anyone else that has comments on this, positive or negative, please feel free to chime in.
EDIT: I opened this issue if anyone is interested or would like to comment.
One thing I will say, though. Just because this platform code can successfully communicate with the Life360 server and retrieve valid data does not mean that data isn’t somewhat stale. The data does contain a timestamp that indicates when the rest of the data was last updated. That is what I have been using to decide whether or not to update. If I make the change, although the platform code would be “updating” the device, it would still contain the “last_seen” attribute which indicates exactly how old the rest of the data is.
Ok, I’ve concluded not to make any changes for either of these two recent issues, which I actually consider two different scenarios of the same basic thing.
(@Mariusthvdb, @klogg & @e1miran, I’m tagging you specifically since I opened the issues in response to your comments. And e1miran, specifically to your original comment, I think the proper way to handle the scenario you describe is to lengthen the consider_home time for the network-based tracker, not to change the GSP-based tracker to pretend stale data isn’t stale. Obviously, though, you’re free to do that if you like.)
If you’re interested, and/or want to try to convince me otherwise , you can see my reasoning in issue #21. I’m leaving the issues open for a while if anyone cares to add comments.
1 Like
please see https://github.com/pnbruckner/homeassistant-config/issues/20#issuecomment-422173112 don’t want to crosspost too much…
thanks! really enjoying your CC and device_tracker!
This is a great custom component. It works great.
For some reason when one of my family members driving in a car then Life360 always sends ‘false’ for ‘driving’ tag and ‘true’ for ‘moving’ tag. I am not sure why Life360 does like this. Did anyone run into this issue?
"moving": true,
"driving": false,I’ve been out of the loop for a bit but firstly I have only just started using Life360 and am nowhere near finished integrating it into my device tracking or working out it’s intricacies, but
I agree with that, and
I think I am experiencing this too, but as I said it is early days for me.
1 Like
This has been my experience, too. I even enabled Life360’s drive detection (which I’m not crazy about) for a while to test it and still I never saw the driving field returned by the server being true. I don’t know if this is an unused field, if it requires a premium Life360 plan (which I don’t have), or what. But, since it was there I left it in in case it did work for someone. I’d be interested to hear if anyone has ever seen this true. If not, maybe I should take it out. Remember, the REST API I’m using is not officially supported or documented, so it’s a bit of a reverse engineering project.
I don’t disagree with your logic. However, I still prefer to configure your component to allow it to work with HA’s logic for multiple trackers. The reason for this is primarily that using consider_home is hit or miss, in my experience.
We have all IOS devices on our network and they disconnect at random intervals from WiFi when the phone is not active, assumedly to extend battery life. So, it’s difficult to establish an accurate consider_home interval. And, what ends up happening is a length of time that is too long, therefore making the state of the entity less accurate. I’d much rather have an option to have your component act either of the two ways discussed.