Definitely agree with this. The composite tracker has as far as I am concerned effectively become the de facto device tracker. I can’t see any reason at all for not using it if you have more than one method for providing location.
And yes, that would be nice…
So I’ve been thinking about this whole “device timezone” topic some more and there’s a significant issue with adding an attribute that would contain the offset to the device’s timezone from HA’s configured timezone (or from UTC, for that matter.) The main problem is that that information could easily become wrong if either timezone changes DST between updates. Now I know that there usually isn’t much time between updates, and DST usually changes when people are sleeping and probably don’t care, and usually the two timezones would probably change DST at (roughly) the same time, so the relative offset wouldn’t change, and therefore, still be correct (or, at least, not be wrong for long), but… I think there are enough cases where this could be wrong that I’d rather not chance it.
Right now I’m thinking of keeping the same attributes, but instead of adding the times_as_local config option, change it to times_as with options of utc, local & device, where utc would be as things were before, local would represent the (last_seen & at_loc_since) time attributes in the timezone of HA’s configuration, and device would represent the time attributes in the timezone where the device’s GPS coordinates indicate.
If you want to know the current timezone offset to the device’s location, you could do that with this (assuming you used the times_as: device option):
{% set n = now() %}
{{ (n.astimezone(state_attr('device_tracker.XXX', 'last_seen').tzinfo).utcoffset() -
n.utcoffset()).total_seconds()/3600 }}
That would show the offset from HA’s configured timezone to the timezone where the device is located (in floating point hours.) This works because, even if the device’s timezone has gone through a DST change since last_seen was updated, the tzinfo member is still valid, and can be used in the astimezone method to get the current timezone offset. To be clear, this would result in the current offset at the time the template is evaluated, regardless of how long ago the device_tracker was updated.
Now, the only remaining issue I see is, what if you want to display the (last_seen & at_loc_since) times in both the device’s timezone and HA’s configured timezone (i.e., the “local” timezone)? First, you’d have to use the times_as: device option, and then the device_tracker’s “more info” display would only show the times in the device’s timezone. But you could still display the times in the local (HA) timezone in a template sensor with something like:
{{ state_attr('device_tracker.XXX', 'last_seen').astimezone(now().tzinfo) }}
Anyway, I think I’ll head in this direction unless I run into a snag, or someone has feedback to the contrary.
Ok, the third beta version is now available. This implements the times_as config option whose choices are utc, local or device (as previously discussed, and replaces the times_as_local option in the earlier beta.) Besides controlling which time zone the last_seen & at_loc_since attributes will be in, if device is chosen then there will be a new attribute named time_zone which is the name of the time zone where the device is located. If it can’t be determined, then it will be unknown, and the datetime attributes will default to HA’s local time zone.
If anyone would care to give this a try, please let me know how it works for you.
Hey, I tried it with times_as set to device, all 3 of our device_tracker entities are in the same time zone at the moment but I am seeing it correctly reported as time_zone: America/Chicago
Beautiful, thanks
Sorry, I’ve been completely unavailable today but I’ve just seen this and will try and give it a go tomorrow…
I don’t use Lovelace, but you can retrieve the battery value through a template like this:
{{ state_attr('device_tracker.life360_mrtuan', 'battery') }}
You may need to turn that into its own entity through a Template Sensor first, and then display that entity in Lovelace.
thanks you .
I will try it
Opinions requested:
Above I describe how I’m adding a new feature to this custom platform, specifically the ability to determine the time zone in which a device is located (base on GPS coordinates), and then being able to report times (such as last_seen and at_loc_since) as time zone aware datetimes in that time zone. It seems to work well, however there is one side effect I’d like to get feedback on before I “officially release” it.
And that is that this feature requires two additional Python packages, namely timezonefinderL and numpy. numpy is used by some standard HA components, and if you use any of those, then numpy is probably already installed on your system. However, I believe nothing else uses timezonefinderL.
I mention this because both of these packages are kind of large. numpy is definitely big, and timezonefinderL is on the large side (due to its “offline” data set.) If I release this change, even if you choose not to use it (it’s configurable), both of these packages will always be installed (the first time you restart after upgrading.)
As a point of reference, on a Raspberry Pi, timezonefinderL is 8.9 MB, and numpy is 28 MB (plus about another 3 MB for the libatlas library it requires.) On this same system, the entire site-packages folder in the HA venv is about 250 MB. So these two packages increased my install by about 40 MB, or an additional 20%. (Your mileage may vary.) Remember, though, that numpy is most of that and may already exist if you use standard HA components that use it. So, really, timezonefinderL by itself (assuming numpy was already installed) would only add less than an additional 4%.
Anyway, since this size increase would come even if you don’t use the feature, I figured I should ask if anyone cares. Let me know … I’m listening 
As far as how much this effects overall performance, I don’t know that I have anyway to easily determine that, but FWIW, I haven’t noticed any side effects in that respect. At the very least, timezonefinderL uses an installed data set, so it doesn’t have to query any external websites.
Well as one of those who was very interested in this I’d like to say first of all that it works well and I am (as always) very appreciative of all the work you put into your components.
I am running the beta (composite) and yes it has increased the size of my installation by I’d say closer to 30% which is a shame but hardly really a problem.
However, I don’t know if it is the new Python libraries or the recent upgrade to 0.85.1 which I did at about the same time but I feel like my HA restarts are taking a fair bit longer which to me is an issue.
Hassio on a Pi is already at the limits of bearability when it comes to restarts. Testing changes is a complete pain.
Further, I had a ridiculously obvious realisation the other day. The reason I wanted this was to restrict out of hours Telegram notifications when travelling. That can of course be managed (better) by ‘do not disturb’ hours on the phone itself! DOH!!!
So for me it is still really nice to have the extra information but I am not convinced it is worth the overhead, especially if it is this that is causing the longer start up time.
That is only my opinion, given only because you asked. As I said I am very grateful for the work you put in and will have no objections if others want to keep it.
And… if you do decide not to release this, how would I uninstall the extra packages? Or will that happen automatically when I next upgrade HA?
I can’t imagine the extra restart time you’re experiencing is due to my changes. The install step only happens the first time HA is restarted after upgrading my component (or, if you’re using the Custom Updater, then it happens when you update, since that component attempts to install component requirements, even though HA normally takes care of it.) In any case, future restarts do not have the install hit, which can sometimes be big.
Now I suppose it is possible that importing these packages can cause significant more startup time, but I tend to doubt that. But, that’s easily determined – change the config to utc or local, in which case the packages are not imported. See if that noticeably reduces restart time.
So, regarding “overhead”, I tend to doubt what you’re seeing is due to this. But I suppose I can try to use timeit to see how much time it takes to import the modules, and to call the method to determine a time zone. I was kind of thinking of doing that anyway.
Regarding uninstalling the extra packages, no, I don’t think that would happen automatically. You can do it manually, but it depends on how you installed HA, if you’re using hass.io, etc. E.g., for a more traditional install (i.e., a Python venv), then you can do this:
sudo -u homeassistant -H -s
source /srv/homeassistant/bin/activate
pip3 uninstall timezonefinderL
pip3 uninstall numpy
deactivate
exit
You can skip uninstalling numpy if you’re using that for something else. On the other hand, if you are, and you uinstall it, HA will just re-install it, so no real harm done.
Oh, as I think I mentioned somewhere, numpy on pi (usually) requires installing libatlas. (I’ll cover this in the docs. Again, this is not unique to my code.) If you do uninstall numpy (and don’t need it for something else), then you may want to uninstall libatlas, too.
Ok, well I’m not sure it is possible to uninstall those packages if you are on hassio so it all becomes immaterial to me. As I said though it is a really nice thing to have and installation size really isn’t a big deal, if it isn’t impacting my start up times I’m more than happy to keep it.
It turns out I may not have an option anyway 
Maybe it’s time to once again look at alternatives to hassio on Pi…
Ok, results from using timeit:
EDIT: I guess I’m not 100% sure how to interpret the importing time results. So let’s just say, on my pi, it was under a second (closer to a half second.) Since this happens only once per restart, I’d say it’s negligible.
First of all thanks for all your support!
About your question, so far from what I read in the posts above, I think that it doesn’t affect (significantly) the responses of HA, but only the capacity.
Although I am 99% not going to use it, I would say to add it and if you get “complaints” about lag issues, then remove it in the next update?
Hello all,
I am new to HA and the Life360 Device Tracker but am liking and learning more about them each day. I have a few automatons setup which use the Life360 tracker. We haven’t been using either system long, but it seems like after updating to 0.85.1 that our locations haven’t been as rock solid as before. We are both running the free Life360 app on our Iphones. I have expanded the
Home “Zone” to 3540 ft in the Iphone app (not in HA). We have followed the instructions on the Life360 website for incorrect locations and made sure neither of us close out of the app. My location hasn’t been bad with one or two false locations a night, however, my wife may have 5-10 false locations a night. Any help would be greatly appreciated!
I should note that I have commented out the following lines in my configuration.yaml file…
As an early adopter of your Life360 component I have been very happy with the basic functionality and reliability that was provided when you first released it. I am only using device tracking to trigger critical security automations based on simply home or away and find all these other new features mildly interesting.
Initially you said “this size increase would come even if you don’t use the feature”, then later you said
“change the config to utc or local, in which case the packages are not imported.”
I would prefer to not have to add extra bloat that I’m not using, so please clarify what config changes (if any) should be done before the next update to avoid importing those large packages.
Thanks!
Hi @rossmatt06, I’m glad you’re finding my Life360 custom HA platform useful. As you may or may not have read, I’ve been using Life360 long before using HA – by itself, with SmartThings, and now with HA. We use it on Android phones and an iPhone. In general it’s been very good, but it’s not perfect. That’s why I mostly use both Google Maps Location Sharing and Life360 (on the same phone!), combined with my custom Composite tracker. I’ve found that to be the best for us.
Hopefully you’ve already seen the docs for my custom components, but if not, look here.
I can’t really comment on that because I’m still on 0.84.6.
Yeah, I misspoke. HA automatically installs required packages by looking at a module’s REQUIREMENTS attribute. Usually it’s a simple list of package names (and version numbers.) So in order to potentially use timezonefinderL it would be in the list, and that would cause it to get installed, even if it wasn’t used.
I tested a way to avoid having timezonefinderL (and numpy) installed if you’d rather prefer it wasn’t, but it’s not pretty. Unfortunately the standard mechanism only checks the REQUIREMENTS attribute when the platform is loaded, which is done before the config for the platform is processed. Therefore avoiding the install can’t be based on the config (unless I’m overlooking something.) The idea I came up with is: add a file named life360_no_tz to the directory containing configuration.yaml. I could then adjust the REQUIREMENTS list by whether or not that file exists (because this can be done when the platform is loaded, which happens just prior to the requirements processing.) Like I said, not pretty, but it would provide a way to avoid having these large packages installed if you don’t intend to use them, and you care about the space they take up.
Now having said that these two packages are “large”, and they are compared to other packages used by HA, in the grand scheme of things, we’re only talking about 40 MB, when most disks are in the GB’s. My current SD card is 32 GB, and only 3.7 GB is used – for everything. So 40 MB represents less than 1% of the used space, and only about 0.1% of the disk size. So I’m not sure implementing an unusual mechanism to avoid taking up that space is worth it.
But, I really do appreciate the feedback. I’m going to wait a while before releasing anything to see if a consensus forms.
I don’t see an issue either way. I don’t know if I’ll ever use the new feature but the DL size won’t impact me at all so either way…meh…