Sorry, I’ve been completely unavailable today but I’ve just seen this and will try and give it a go tomorrow…
1 Like
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…
1 Like
Ok, results from using timeit:
- Importing timezonefinderL takes less than a second.
- Determining time zone name and tzinfo (for my location) takes less than 25 ms.
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?
1 Like
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!
1 Like
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…
1 Like
Been reading this with much interest, and my feedback would be: as an accountholder of a family circle that has spread around the world in more than 2 timezones, that change more frequently than I would have ever imagined… I would give a big +1 for that extra timezone option most certainly.
Disksize is of no consequence, using 64Gb SD’s which are nowhere near any sort of capacity threshold, and I wouldn’t imagine this feature would add to that. what are we talking about…
As a user of your component, I have found myself using and comparing the Composite component also because, as you said, Life360 isn’t perfect. Well, they both are very fine, and tbh, I could live with Life360 alone, In my setup, which is not very simple, with 6 family members each having more than a couple of device_trackers, Life360 is always correct on its own 
So, iow, to cut it short: please add that feature, and the standalone Life360 component will grow even stronger and more useful. No competition.
Thanks for this great component.
Cheers, and happy traveling!
1 Like
Got this setup perfect thank you for your work.
I do have one slight issue, iv added a family member to my circle and they do show and track in home assistant but doesn’t grab their icon ?
I’ve had a similar issue with french location named “domicile”
I configured on my family in life360 my home adress, but when I was at home homeassistant registered my location as “domicile” but not “home”.
I think the best way to use Life360 with Homeassistant is to use only zones from one or the other solution.
For me, I just deleted all the zones configured in Life360 and just used the zones from Homeassistant
Just wanted to point out that I am not at all concerned with the ~40MB extra impacting available space. And since your timing tests show negligible impact on performance, then I guess there is no issue here one way or the other.
Thanks for the clarification that there currently isn’t a config option to avoid loading the extra packages if they are not going to be used.