See GitHub - pnbruckner/ha-composite-tracker: Home Assistant Composite Device Tracker
You need to use all_states.
Im sure this may have been answered in these 500 posts, but heres my issue:
I have 4 things tied to composite: HA app, Life360, Google maps, ping.
This afternoon my wife who was home, told me HA thought she wasnt (I have a routine where when no on is detected home, it announces that if someone is home press any light switch to cancel the not home routing).
Anyway, checking her individual trackers HA, life360, and ping all had her home. Google maps had her in the almost home zone, which is what caused the “home empty” routine to start.
Is there anyway to tell composite that at least 2 of my 4 trackers need to agree before composite will change it state?
Sorry, no. That’s not the basic design of the integration. Its goal is to use the most up to date information. It can’t know that one of the inputs is inaccurate.
I myself use Life360 + Google Maps, and generally don’t have this issue. Have you set the accuracy threshold for both Life360 & Google Maps? I use a value of 30m for both, which seems to work reasonably well.
BTW, I just discovered a bug in google_maps that was introduced in Fix google maps device_tracker same last seen timestamp by tyjtyj · Pull Request #99963 · home-assistant/core (github.com), which is in the 2023.10.0b2 release and later. At startup, if the first update for a tracker doesn’t meet the set accuracy threshold, it will never update again due to this bug. I’m working on a fix.
Where is this accuracy threshold you speak of?
For Life360, click the CONFIGURE button and you’ll see:
Check the “Limit GPS accuracy” box and then fill in a value below it. See Account Options for more details.
For Google Maps, it’s the max_gps_accuracy option.
So just so i understand this settings, if I set it to 30 meter, what does that mean?
When Life360 and Google maps report my location, the report includes how accurate it is? How does it know how accurate it is? If it knows it aint accurate, why did it report my location change?
It means, if the reported accuracy value is a larger value than that (i.e., the GPS fix is less accurate than the threshold), then the update will be ignored.
Yes. It is shown in the gps_accuracy attribute of the device_tracker entities. And if you look at the tracker on a map, it’s shown as the size of the circle. The circle represents the area that your phone is somewhere within.
You’d have to ask Life360 and Google, or more to the point, your phone manufacturer.
It’s not a binary value, i.e., it’s not “accurate” or “not accurate”. It’s a degree of accuracy. You get to decide how accurate an update needs to be to be used.
Looks like this is my personal troubleshooting thread now, lol. No ones posted since my last question a month ago. lol
((I dont know if this is a composite issue))))
So weird thing happening. According to composite tracker of my wife, she entered the ‘start heating cooling’ zone at 3:11PM. Then at 3:22PM she entered home.
The problem is, to get from heating cooling zone to home, you have to pass through almost home. Red is heating cooling, blue is almost home, black is home. Her entering almost home (blue) zone never shows up in the composite entity.
But wait…theres more. In node red I have state node that triggers when either my wife or I enter the “almost home” zone. This DID trigger at 3:22PM, as you can see below. But 3:22PM from the composite log is when she was HOME. I am utterly confused. Node red, which just watches the composite entity says she was almost home at 3:22. But the composite entity shows no record of his and just shows her home at 3:22.
Don’t know what to tell you. The composite just listens for updates to the entities listed as inputs. When any of those change, it will try to update with that data, assuming it is new data. The composite does not decide what zone it is in. It only reports GPS location (assuming the input was a GPS source), and the device tracker component level code decides what zone it is in.
It is, of course, possible for one update to be in the outermost zone, and the next update to be in the innermost zone, completely missing the middle zone. That’s the nature of sampling systems, which, of course, this is.
But, given that node red saw the entity in the middle zone, I suppose it’s possible the logbook just missed that??? I don’t know. I don’t write that code either.
What you could do is enable debug for the following:
logger:
default: <whatever you like>
logs:
homeassistant.core: debug
custom_components.composite: debug
Then, looking for state_changed events in /config/home-assistant.log, you can see whenever any of the “input” entities change, when the composite entity changes and also when the composite is processing those input updates (look for custom_components.composite.device_tracker).
I’m planning on making a major update to this custom integration. Mainly I want to add UI based config flow (i.e., add entities & configure them via the UI’s Devices & services page.) I will, however, continue to support YAML based configuration. I’ll even add reload support.
One feature I plan to remove is time zone determination. This was optional, and its implementation was too complicated. But in case anyone really likes that feature, I’ve implemented a separate integration that does it. Basically you point it at any other entity that has latitude and longitude attributes (person, device_tracker, sensor, doesn’t matter) and it will try to determine the time zone the location specified by those attributes is in, as well as its offset from UTC in hours. If anyone would like to check it out (and, of course, feel free to provide feedback), a beta release (1.0.0b0) is available at:
pnbruckner/ha-entity-tz: Home Assistant Entity Time Zone Sensor (github.com)
2 Likes
2nd is very good.
1st is just great in our “appreciate inexperience” times )))
FR: add a support to show “last-updated” & “source” for “battery_level” & “battery_charging” attributes (separately).
This is what I gonna do in my own “integration”: it is just a trigger-based template sensor which listens to a set of gps/router based trackers.
Thanks for the suggestion, but I don’t think it would be very easy to do with the way the composite integration works. Really, those attributes are just informational since not all input entity types provide that data. I.e., I wouldn’t count on those attributes even being present, depending on what entities you’re using as inputs.
I just released 1.0.0b3 of my new “Entity Time Zone” custom integration. I think it’s pretty much “ready for prime time.” If anyone gives it a try, I’d appreciate any feedback.
UPDATE:
I’ll be releasing 1.0.0b4 soon. It is actually a breaking change from 1.0.0b3 or earlier, so if you want to give the new integration a try, either wait for 1.0.0b4, or if you’ve used an earlier version, first delete all the integration entries before upgrading, then add them back. Sorry, they are beta releases after all! 
UPDATE:
1.0.0b4 has been released.
I should probably create a new topic for this, which I probably will at some point, but for now, I’ve released version 1.0.0b9 of my new Entity Time Zone custom integration. It has bug fixes, of course, but I’ve also added a lot of features. I’m told some of these features may work better than the built-in Worldclock integration. 
1 Like
can confirm they do
very nice and thanks for the new integration
1 Like
Happy New Year!
I’m curious if anyone (besides @Mariusthvdb) has a) used the time zone features of the composite integration, and/or b) tried out my new “Entity Time Zone” integration. If so, please let me know, and especially, let me know what you think of the new integration.
I’ll be starting work on a major upgrade of the composite integration soon, and as mentioned above, the time zone features will be removed. The “Entity Time Zone” integration is meant to be a replacement for anyone that would still want to use those features.
UPDATE:
Just fully released version 1.0.0 1.0.1 of the Entity Time Zone Sensor integration. (Note: 1.0.0 had a bug in the manifest.json file. 
)
2 Likes
Hello!
Hello!
Hello!
Hello!
Hello!
Anyone out there? 
I’m seriously considering dropping YAML config support in the next major release. It’s getting too complicated to retain YAML config while adding UI based config (and keep up with the way HA Core wants things to be done.)
The way it would work is like this:
Any YAML based config would generate a warning, but would otherwise be ignored. Existing config entries (that, of course, originally came from YAML) would stay, but be “migrated” to a new format. Any additional entries would need to be added via the UI.
The main difference would be you’ll no longer be able to (directly) specify the entity’s Object ID (i.e., the part after “device_tracker.”) It will default to the (slugified) name/title of the config entry (and the speed sensor would be the same with _speed added.) Of course, you can always change the entity’s ID in the Entity Registry (via the entity’s settings.) Any existing entities will also change their entity ID to this default (unless you’ve already changed them via the registry, or you just happened to have set them this way in the first place.)
So, 3.0.0 will be a bit of a breaking change, but hopefully nothing too difficult to deal with. Worst case you’ll need to bring up the settings for each of the composite entities and change things back to the way you had them (if they, indeed, did change.)
Thoughts?
Speak now or forever hold your peace.
1 Like
Seems ok although difficult to say with certainty when I haven’t seen the UI. Can you share any examples?
As of right now these are the config flow windows:
EDIT: There used to be an Object Id window in the flow, which I forgot to include here, but I’ve changed that, per the discussion below, and it’s not in the flow anymore. (So, I was right in the first place. )
When you click on Entity it will show a list of all existing device_tracker & binary_sensor entities (although I also plan to add support for pretty much any entity that has latitude/longitude or lat/lon attributes.) You can select as many as you like, as long as you select at least one.
Here you can select which “input entity” you want the composite to get its picture from. You can select none or one.
Here you can select which entities you want to have all their states used. As it says, this really only applies to non-GPS based entities which use GPS data, not the entity state. By default, only “to home” state changes of non-GPS entities are used.
When you’re done and the entry is created, you can click on the CONFIGURE button to change anything in all these same windows, except for the first. The name will become the name of the config entry (and will be used for the initial names, and hence entity IDs, of the device_tracker and speed sensor entities), and you can change it via the usual method (i.e., the three-dot menu.)
I always hate to see yaml config go away in preference to UI only but you do what you need to do. And we will just deal with it.
1 Like