Have you read this?
Yes.
1 Like
Further to my recent weirdness I have ‘caught’ the Composite appearing to be behaving in an unexpected fashion.
Cutting straight to the chase, the Composite is reporting Away when the only router based device tracker is showing Home.
Briefly, both Life360 and Google Maps have drifted on this phone to be just outside the Home zone. I am not sure what information you might be interested in (if any 
) so I will wait to hear from you before flooding you with information that will in any case not have changed from my previous post a week or so ago.
I should add that the Composite has been giving me perfect service for many months and it has only been since I lost my Bluetooth tracker* that things began to show signs of strangeness.
*Since I moved to a NUC running Proxmox. At some point I plan to get it back by moving to Ubuntu and Docker but I need to not only learn a bit more about how that works but also find time to actually do it.
I’m not sure why you say that is unexpected. It’s exactly what I’d expect, given that both Life360 and Google Maps updated after UniFi changed to home. The composite tracker doesn’t look at the status of the input trackers (other than at startup.) It only looks at when they change state.
Remember, trackers are only accurate when they change state. Then immediately they become “stale.” And furthermore, router type trackers are only accurate when they change to home. Changing to not_home is just a guess based another guess as to how long between responses they’ll go when they’re still actually home.
The composite only changes when an input changes, since at that moment the input tracker is believable, and the most believable, because the length of it being stale is less than the length of all the other input trackers being stale.
2 Likes
“only accurate when they change to home”
Yes, of course they do. Sorry, It was late last night…
Thanks there, this also explains the above, while I had already read the logic explanation on GitHub, I was still a bit confused as I thought it would rely on the latest updated tracker, rather than following the logic above related to the accuracy of the trackers! It does make sense all in all and am happy with that 
hi @pnbruckner
please let me ask about the device_tracker Hue, fully appreciative you’re not the creator of the Hue custom component. An expert in device_trackers though, and many miles in the conversion between old and new device_tracking in HA.
My issue is this: since 94.3 probably 94.0 I get an error message the device_tracker.huesensor isn’t found, config error, and won’t restart. Only option for now is to disable it.
please see Hue motion sensors + remotes: custom component if you could spare a few minutes. Made you see in 1 glance what should be changed to get HA to recognize the device_tracker? I haven’t got a clue, and none of the listed HA release changes indicate what we should do.
thanks for any hints you might have.
of course you can be assured I have all the files in the right places, and named everything accordingly. sensor and binary_sensor are working fine, only device_tracker errors out.
If not, thanks anyways
Sorry, I don’t understand that. It does effectively “rely on” the latest updated tracker (because it only updates when an input tracker updates, except in the case where there are both GPS and non-GPS trackers, and then it ignores non-GPS trackers when they update to 'not_home'.)
My point was that any device tracker can only be 100% believed when they update (well, and sometimes not even then, but that’s another discussion.) Immediately after that the information is stale. What the composite tracker tries to do is to effectively use the least stale information. And when it comes to non-GPS trackers, it must be understood that they are only believable when they change to 'home'. They don’t change to 'not_home' when they know you’ve left. They guess as to when you must already be gone. Hence, when there is a mix of GPS-based (that know when you leave) and non-GPS-based trackers, the to 'not_home' transitions of the non-GPS-based trackers are ignored. When there are only non-GPS-based trackers then it basically reverts to the guessing about being away.
My guess is that the device_tracker.py file has ImportError’s since the device_tracker and zone component code has been slightly reorganized. I had to update this custom component (as well as my custom life360 component) to be compatible with 0.94.x.
1 Like
Ok thanks!
which looks rather serious…If you don’t mind, Ill link to this post in the issue I filed, to shorten the search for a solution. appreciate your help.
1 Like
No problem.
BTW, you’re using the unifi device_tracker, right? Does your unifi configuration specify last_seen in monitored_conditions?
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.
2 Likes
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.
1 Like
… 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.
1 Like
This custom integration has been moved to a new HACS-compliant repo and released as version 1.8.0:
1 Like