Life360 Device Tracker Platform

Third party integrations
441

So, can you tell me more about how you’d use this?

Right now the only attributes with time are last_seen and at_loc_since, neither of which is the current time. They are both timezone aware Python datetime objects. Previously they were always in UTC, whereas with the change I’m working on now they can be in the timezone from HA’s config. (There are also last_changed and last_updated fields of the state object, but those are always in UTC, and also are not really the current time.)

Let’s say I add new attributes that are influenced by the timezone where the device is physically located. Some possibilities that come to mind are adding last_seen_d & at_loc_since_d, which would be the same values as the existing attributes, but in the timezone of the device. That would be easy to add. But then, how would you use them? You could compare them to the corresponding attributes (in UTC or HA local), but as a whole, they are the same (i.e., last_seen and last_seen_d would be the same time, just in different timezones. E.g., if you subtracted them, you’d get a timedelta object whose value is effectively zero.) I suppose you could look at their hour attributes (e.g., last_seen.hour and last_seen_d.hour) to figure out the difference in the timezones in hours. Or you could use the output from their tzname or utcoffset methods; the latter might be more useful. E.g., last_seen_d.utcoffset() would return a timedelta object representing the offset from UTC of the device’s timezone.

Or do you think it might be more helpful to include other new attributes, e.g., maybe the name of the device’s timezone? Or the offset from UTC and/or HA local, as a float?

In summary, I think it would be nice just for display purposes to have the last_seen and at_loc_since values available in additional attributes where they are in the device’s local timezone. It might also be nice to have a new attribute that shows the name of the device’s timezone. But for automation purposes, I’m wondering what would be most helpful. Maybe add the three new attributes I just described (i.e., last_seen_d, at_loc_since_d & timezone_d), and one more attribute with the device’s timezone’s UTC offset as a float.

Thoughts?

442

My idea for this came to me in the summer. I have an irrigation system controlled by HA which will send Telegram notifications every time it runs (up to twice a day).

It occurred to me that those notifications could be intrusive given the time difference so it would be good to either not send them at inappropriate times or to wait until it was appropriate.

I didn’t get far with it as I remember asking you about the times provided by device trackers, assuming local time of the device itself would be easy to extract.

For me that would be the main use case but as you say there are some very attractive cosmetic uses too.

I wrote a load more here but when I read it back and then read your post again before saving, I realised that actually I was probably just restating what you summarised:

For automation purposes I would only need the difference in hours from the HA local time to do the calculations I want, or the actual device local time to make it even easier.

Simply put: I’d like to know the local time of the recipient before sending a notification (albeit that it is only the last seen time)

I don’t know if this is helpful, I must admit to not expecting such a full response from you. But then I really should have known better :slight_smile:

443

LOL! Yes, I do tend to go on a bit. :wink:

I think what might make the most sense (besides additional attributes in the device’s timezone, just for display purposes) is to have an attribute with the offset between HA’s timezone config and the timezone the device is in. I think this might be easier to use, or more appropriate, than the offset to UTC.

And it would make sense to do this in the composite tracker, too. Actually, what would make the most sense is for this feature to be added to the device_tracker component-level code… :thinking:

1 Like
444

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…

445

@klogg @leSourCil

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.

446

@klogg @leSourCil

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.

447

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

1 Like
448

Sorry, I’ve been completely unavailable today but I’ve just seen this and will try and give it a go tomorrow…

1 Like
449

Just added time zone support to the composite tracker, too. See details here.

1 Like
450

xxxx
xxxx878×176 10.7 KB

How to display battery capacity on lovecase.
Sorry I’m a new user of HA

451

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.

452

thanks you .
I will try it

453

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 :worried:

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.

454

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?

455

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.

456

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 :slight_smile: :wink:

Maybe it’s time to once again look at alternatives to hassio on Pi…

1 Like
457

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.

458

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
459

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…

460

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