After upgrading to 0.94.0 I am getting
Platform not found: device_tracker.composite
Platform not found: device_tracker.ping_arp
when doing a configuration check, device trackers are not being updated.
This may be due to the same changes that I had to prepare life360 for. I’ll look into it.
Hi there, since 0.94 composite seems to report the wrong state. I am getting always away regardless the attached trackers are home. I can’t spot any error in the logs. Can I help troubleshoot this in any way? 
Released 1.7.5
Updated to be compatible with changes in HA 0.94.0 release.
FYI, for some reason when a custom integration cannot be loaded there are no visible error messages. However, if you run Check Config, it will tell you.
After you upgrade to 1.7.5 let me know how it works for you.
1 Like
I was just coming back as I spotted that not_found error in the config check, however your speed was astonishing!!! I can confirm I have updated to 1.7.5, reverted the config for person to use the composite component trackers, and it is working well again! Thanks @pnbruckner !
1 Like
I have been testing the component and I am wondering what logic is it using, let me give you an example.
I have attached a nMap tracker and a GMaps tracker, the first doesn’t see the phone since 11hrs 58m as the phone left the house, therefore it is in “not_home” since then, however since the phone exceptionally does not have mobile data today, maps has not updated its status since about the same time and shows still “home”. As a result, composite shows the main device as at home. Is this expected? I thought it was going to grab the result from the not_home nMap tracker which does update often.
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?