ok, my problem was that device tracker requires float numbers, while sensors were already given with units in which they are measured.
I did not make composite device tracker working. I thought it would just read the GPS coordinates with altitude but it did not created the device tracker. Maybe for the same reason? I will give it a try
So, you have latitude & longitude in some form in some existing sensor entity or entities. Is that correct? If so, please share the details. E.g., how many entities? What does the state value look like, and does it have any related attributes, and if so, what do they look like?
To use an entity as an “input” to the composite tracker integration, it must have three attributes. One must be gps_accuracy or acc, and contain the accuracy of the GPS “fix”, in meters (just as a number.) The other two must be latitude & longitude, or lat & lon, containing the latitude & longitude of the GPS fix, respectively, in degrees (just as numbers.)
If you don’t have an entity in this exact format, then you can create a template entity from your other entity (or entities) that contain the values. If needed, you can just “hard code” the gps_accuracy attribute with the value 0 (i.e., zero.)
Hi Phil, can I ask a quick question?
Sometimes in Composite I have trouble working out WHICH device trackers are configured against a person because of the way the UI uses a friendly name rather than the full sensor name - is there any way to see the FULL sensor names?
Thank you!
If you mean in the configuration flow, when you click on one of the boxes on the “Input entities” page, it shows the friendly name, as well as the entity ID, for each possible selection. If, however, you have multiple entities with the same friendly name, once you pick one, unfortunately, no, you can’t see which entity ID it corresponds do.
Of course, if you know how to look in config/.storage/core.config_entries, you can see the details, including the selected entity IDs.
Also, the composite entity has an attribute, namely entities (which is displayed as “Seen entities” in the UI), that lists the entity IDs of all the input entities that have been “seen”.
Thanks, that did the trick, and is exactly what I was after. I have a tracker, device_tracker.iphonemed_3 that jut appears as iphoneMED in Composite (after it’s initially entered). Thank you
Released 3.5.0b0
Sorry, this was released back in March, but I forgot to announce it here.
Hi Phil,
testing ha 2025.9 in beta, we now have lat/long on device_trackers being ‘home’ .
see: https://github.com/home-assistant/core/pull/134075
this is rather a significant feature, as before the trackers lost that, and that was reason for us to install your fine custom component. for years…
did you already check the new feature?
I have it running since last Wednesday, and can confirm it to behave properly, states changing in perfect sync with the trackers I setup with your component.
In the past you had comments regarding the way HA sets trackers states, and I was wondering of you still feel your component would be preferable over the core system with this new lat/long on home.
what I did before:
have composite create a person tracker based on all relevant wifi/gps trackers
and use that composite tracker as sole entity in the person configuration
what we can do now:
create a person tracker based on the same relevant wifi/gps trackers directly, and leave out the middle man…
seems better from a HA perspective, be as efficient as can be, and use only core elements.
Hope you can find the time and share your thoughts with us.
There are still other ways in which composite & person behave differently. Sure, if you’re comfortable with the person integration, and it does what you need, then no point in using composite. However, if composite still does what you need/want and person doesn’t, then by all means, feel free to keep using composite.
Released 3.5.0
Released 3.6.0b0
Fixes a bug wherein the device tracker’s driving state may incorrectly change back to away if input updates are too close together, even though the speed is above the configured threshold. See PR #99 & related issue #93 for more details.
The 3.6.0 release will probably address all these bugs & feature requests (thanks @kilowatt_w & @sshaikh !):
They are all related to the speed sensor and the related (optional) device tracker states.
Released 3.6.0b1
Add an option to delay ending driving state. See issue #92
UPDATE: Oops! Seems that release has a bug. I’ve deleted it and will replace it with 3.6.0b2 as soon as I can figure out what I did wrong. Sorry!
UPDATE:
Released 3.6.0b2
Fixes bug that was in 3.6.0b1.
Released 3.6.0b3
Add option to set maximum time between speed sensor updates. If set, once this maximum is exceeded, speed sensor’s state will be cleared (i.e., state will become unknown , and angle & direction attributes will become null.
Released 3.6.0
Released 4.0.0b0
device_tracker’s source_type attribute to supported values only.binary_sensor is not officially supported as a value of the device_tracker’s source_type attribute, it will now be reported as router instead.Hi
I have a question about your component. I’ve been using it for a while, I have a phone app and its location is sometimes flakey (it reports me as not home when I am in fact home). So I have set up a binary sensor that tracks if the phone is on home wifi and then a composite tracker with the GPS entity from phone and binary entity from wifi. But anytime the GPS goes away, the composite tracker also goes away no matter the state of the binary entity.
Is that correct behavior? I’d expect the composite to be home when at least one entity is home/on.
Thanks!
The design philosophy of the composite integration is “last update wins”.
The idea is, the most recent update is considered the best. Its goal is not to make up for bad inputs, but to use multiple inputs to “fill in the gaps” between each input’s updates.
E.g., I use Life360 & Google Maps (on the same phone.) Surprisingly, they don’t update at the same rate, or at the same time. It’s not uncommon to get a few updates from one, then while it’s not updating, to get some updates from the other. When they get put together, the result is a tracker that updates more frequently (and, hence, is less “stale”.)
Regarding binary sensors, by default, their updates are only used when they change to home. If you want them to use all their state changes, there is an option for that. But, of course, in your scenario, that’s not an issue.
Regarding GPS based inputs, the integration doesn’t care what their “state” is. I.e., it doesn’t care if they are home, in some other zone or not in any. It only uses the GPS inputs (latitude, longitude & GPS accuracy.) The “system” decides where the tracker is based on the coordinates.
So, again, it really doesn’t try to “make up” for bad inputs. The only real exception to that (at least in your scenario) is the “max accuracy” setting. If a GPS based input updates, but its GPS accuracy is more than the max accuracy setting, the update is ignored. (Note that a higher accuracy number is misleading. It actually means the location is less accurate. That’s because it defines the radius of a circle such that the device is somewhere within that circle. So, the higher the reported accuracy, the bigger the circle wherein the device is located, and hence, the less accurate the location is known.)
Therefore, you should monitor the GPS accuracy attribute of the input to see what it usually is, and if when it reports you’re not home when you are, its value is significantly higher. Then you can set a max accuracy threshold to try and reject those bad readings.
Thanks for the response, I understand.
The max_accuracy setting seems promising, however, I cannot find it in your integration. Is it something slated for next release or is it something else?
Sorry, you’re right. That’s not part of the composite tracker integration. It’s in the Life360 & Google Maps integrations.
What integration are you using that is sometimes providing bad location data?
It’s just HA app but I assume the phone loses track when I’m inside and sometimes sends me 200m away. I don’t really want to increase the home zone because that would catch too much space around me (I live in an appartment in a dense residential zone).