I’m using the Ubiquiti Unifi direct AP (https://www.home-assistant.io/components/unifi_direct/)
Not as I think you are asking, the UniFi Controller.
I do plan to move to using that soon. One of my growing list of things to do is to migrate my controller to it’s own machine…
Ok, it was someone else that was using unifi then. I had added support for the last_seen attribute of the unifi platform (now called an integration) which was formatted differently than life360 & google_maps.
The reason I ask is, I’m looking into how well the new person component will work for me (instead of continuing to use this custom component, which predated the person component.) One thing I found is, it’s not taking into consideration the last_seen attribute that life360, google_maps & unifi provide, but rather is just using the state’s standard last_updated field. That’s fine for trackers that “push” data to HA. But for trackers that poll, and are provided a timestamp when the data actually changed (not just when HA found out about it), the person component, in my mind, should really be using that when determining which of the “input” trackers changed last. I’m considering submitting a fairly simple PR to the person component to add this.
I’m also very interested in this. Good as the Composite component is, and it is good and was ahead of it’s time 
) I’d always rather use standard core components platforms integrations.
Perhaps you could keep this thread updated with any findings/PRs/updates?
Same here. 
Will do.
… and rejected.
Well, after more consideration, I didn’t think the Person component would work for me anyway. It only uses states, not GPS data, which to me is a fundamental flaw. But I guess it’s meant to solve a different problem. Oh well.
I guess I’ll have to move this to HACS.
Oh well.
Thanks for keeping me updated, I’ll look forward to seeing it in HACS
is there any benefit in using this “underneath” the person entity as the only tracker?
This can certainly be used “underneath” a person entity. However, it doesn’t really “track” by itself. It relies on one or more other device_tracker or binary_sensor entities. If you do have a GPS-based device_tracker entity, then yes, this can add features “on top of” it, and then be used “underneath” a person entity. E.g., it can determine time zone and report times in the time zone in which the device is located. I actually use it for that, even when I only have one device_tracker for a given device. Of course, it’s main purpose in being created was to combine multiple device_tracker or binary_sensor entities for a given device. IMHO it does a better job of this than the person component.
This custom integration has been moved to a new HACS-compliant repo and released as version 1.8.0:
… and released 1.9.0 which updates timezonefinderL to the latest version (4.0.2.)
sorry - I should have been clearer - I’m aware it isn’t a tracker in its own right.
I have a (working!) google maps tracker, plus nmap for home, with all the associated issues that go with each. Which of course the person entity doesn’t really fix, hence the PR you raised.
So, my question is - do I put the two trackers under the composite and then the composite under person? I think the answer is yes…
as a side note , but related to this update: Ive not seen an ‘incorrect’ time_zone_name after updating to 4.0.2 manually in the life360 CC.
good stuff!
Ok, understood. Yes, you can do that. Not sure what the person entities adds in that scenario, but you can certain do that.
And you never saw one before either.
You keep saying the time zone name was incorrect, which is an incorrect statement. I’ll say this one more time. Names for a time zone are just aliases. A time zone can, and often does, have more than one name. They all refer to the same time zone. Any name that refers to a given time zone is just as good as any other name that refers to the same time zone. In fact, if you look at the timezonefinderL’s repo, it says it returns “the most common name” for a time zone. It never states that it returns the name that is the closest match for the GPS coordinates, which is what you seem to want it to do.
Now, having updated this custom integration to use the newer version of timezonefinderL, I’ve noticed that I’m now getting incorrect time zones when I never did before. My daughter’s GPS coordinates are in another time zone, yet it’s reporting a time zone name that is for the time zone that I am in. This is not just a case of using a different time zone name to refer to the correct time zone as you were reporting, it’s returning the wrong time zone, both name and time zone itself.
I don’t know what that authors of timezonefinderL did (at the very least I know that they completely changed the implementation), but they seem to have broken it. I will probably downgrade back to 2.0.1, at least until I see some evidence that the latest version is working correctly.
ok.ok.
You do understand what I am after. The thing is, we are humans, and not computers, for which the time zone name is just an alias.
Humans prefer to have a correct alias then. 
Is it so awkward to want the alias to read Europe/Rome when one is in Italy, and not have it read Europe/Berlin. Or Africa/Zambia for that matter…
too bad its not performing correctly after all, as you have experienced. Maybe it was just plain coincidence. And, as said before, it didn’t happen too often, at least I hadn’t noticed it before, until I started watching it…
So sorry if I caused havoc. seriously.
I’m totally with you on what you want. That would definitely be preferable. But it’s not incorrect (or, at least, wasn’t). That’s my point. It was doing its job correctly. It’s just that what it was trying to do was not as useful as we would have wanted. But, to be fair, I only used it as a stepping stone to get the correct time zone (i.e., tzinfo.) Publishing the name as another attribute was only an “added bonus.”
I’m going to look into using timezonefinder instead of timezonefinderL (the latter is a “light” version of the former. Or, at least, that’s what it claimed.) I’m even going to see how practical it is to dynamically load/install the package (instead of listing it in manifest.json, which HA uses to do that.) If this is possible then those that don’t want to use the time zone feature won’t have the package installed on their system in the first place. And it (and numpy) are rather big. But the other thing it would allow is for the user (via another config variable) to choose which package to use, since timezonefinderL & timezonefinder have the same API. I would assume that timezonefinder does a much better job than timezonefinderL, but with the burden of being even larger and probably requiring other packages as well.
I did some quick testing with timezonefinderL 2.0.1 & 4.0.2 and the latest timezonefinder (4.0.3), with and without numba (a package that can speed up numpy calculations.)
| pkg: | tzfL 2.0.1 | tzfL 4.0.2 | tzf | tzf + numba |
|---|---|---|---|---|
| size: | 79M | 71M | 115M | 200M |
| time x86: | 17 mS | 10 µS | 120 mS | 390 µS |
| time rpi: | 24 mS | 30 µS | 160 mS | — |
I ran the tests on both a relative beefy x86 platform and my rpi. The sizes are from the x86 install. I didn’t use numba on the rpi (see below.)
Also, I just used one GPS location, so not very thorough. Mostly just trying to see if it’s worth supporting timezonefinder vs timezonefinderL, and whether or not to make it configurable.
As you can see timezonefinderL 4.0.2 is much faster than 2.0.1, but it does so at the loss of accuracy. The size comparison above somewhat hides the details, because most of the space is used by numpy. timezonefinderL 2.0.1 was 8.9M, whereas 4.0.2 is only 360K. Obviously it’s thrown away a lot, which explains the much lower accuracy.
Although timezonefinder itself (46M) is much bigger than either version of timezonefinderL, the total space required is only about 60% more. And, yes, although timezonefinder is about 10x slower than timezonefinderL 2.0.1, it’s still not that unreasonable, at least in my opinion. What’s a tenth of a second between friends? 
So, that brings up numba. As I mentioned, this is a package that can (and obviously does) make numpy, and hence timezonefinder, much faster. And, as you can see, it (and its own requirements) increases the total space by another 85M. Still, that’s not much these days considering typical disk sizes.
The downside to numba, though, is its installation can be a little more involved, especially on non-x86 platforms. (On x86 it’s as simple as pip install numba.) So I think I won’t try to automatically install, or require, numba. I’ll make note of it in the instructions and point to its install instructions. If someone wants the improved speed, and doesn’t mind the extra space, and possibly more involved installation process, then they can choose to do that themselves.
Anyway, consider this a Works In Progress for now. Comments, good or bad, appreciated. 
I came up with this. If you add this to your configuration:
composite:
tz_finder: timezonefinder==4.0.3
you can specify which package/version you want to use. Right now the reasonable choices are:
timezonefinderL==2.0.1
timezonefinderL==4.0.2
timezonefinder==4.0.3
If you don’t include this in your config then it will default to timezonefinderL==2.0.1, which is the original version I used.
Also, the package is removed from manifest.json (so HA doesn’t try to install it), and I’ve added code to install the package at run-time based on the choice made in the configuration, and only if you’re using time_as: device_or_utc or time_as: device_or_local in at least one of your composite tracker configurations. Which, BTW, leads to the next point:
You still set up the composite tracker(s) the usual way:
device_tracker:
- platform: composite
...
Lastly, I leave installing numba to the adventurous.
What do you think?
all in for an adventure, it simply never ends using HA and your components
If trying, how do we setup numba? On Hassio I mean…