Could you elaborate?
Do you think that Life360 is not a good service?
Or do you mean something else?
I’ve never used it. I see a lot of people using it. I was just curious why you’d use that over any other gps system.
Here what I am using:
- Companion App. Absolutely not reliable in iPhone 5s\6s+ (iOS 12.x), iPad Air (iOS 15.x), iPhone 12 (iOS 16.x). Not updating a position. Even when staying at home - not updating battery_level, need to open Companion App to update.
- Life360. More or less reliable. Sometimes not updating data, need to open Life360 app. Stopped working in Russia since March 22, need to use VPN on clients and HA.
- Traccar. Reliable. Draining a battery on a client, but this is what I can live with.
My family has been using Life360 for many years, long before I started using any home automation software. When I started using SmartThings, it was a natural choice, since they had an integration. When I moved to HA, there was no official integration. There were some attempts to provide an integration, but I didn’t like what was available (actually, can’t remember the details), which is why I started working on it.
The main thing I like about the Life360 integration (and Google Maps, which I also use), is it has a last_seen attribute which indicates when the GPS coordinates were last updated. This becomes very important when combining more than one (with the Person integration, or my own custom composite integration. EDIT: BTW, the Person integration doesn’t bother looking at the last_seen attribute, which is one of the main reasons I don’t use it to combine device trackers.) E.g., without a last_seen (or similar) attribute, one device tracker may provide an update, and then another might update, but with older GPS data. In this case there’s no way to know to ignore the update from the second tracker, so the “composite” entity will “jump back” to where it was before, not where it is. This can cause problems with automations. E.g., the composite arrives home, but then jumps back outside the home zone, even though the device did not.
IMHO, ALL device tracker integrations should be required provide an attribute like last_seen which “timestamps” when the GPS data was known to be accurate. Using the time the HA entity is updated is problematic, especially since it can be seconds, or even minutes, from the time the GPS coordinates were accurate to when the HA entity actually updates. (To say that another way, when a device tracker updates, the GPS data it contains could be seconds or minutes old.) Also note that these entities can update for other reasons besides new GPS coordinates (such as battery level), further exacerbating the problem.
2 Likes
Released 2.7.0
- Add angle & direction attributes to speed sensor.
- Better filter out speed value outliers, especially when a pair of location updates comes from different input entities.
Released 2.7.1
Fixed a minor bug that happens when writing a certain debug message to the log.
Released 2.8.0b0
Adds support for a last_timestamp attribute. Some device tracker integrations (e.g., tile) include this attribute that records when the location information was last updated. Use this the same way as the last_seen attribute of other integrations (e.g., Life360 & Google Maps.)
This can help when using both a phone and a Tile in a composite tracker, where the Tile might get accidentally left behind.
EDIT: Just discovered the new last_timestamp attribute was just recently added to the tile integration in the last two weeks and is only in HA’s dev branch. Oh well, I’m ready for it when it gets released! 
Released 2.8.0
Per above.
I’m considering an update to the implementation of the require_movement feature. (I was never fully happy with it as it is.) If anyone has any comments, feedback, thoughts, etc., by all means, I’d love to hear it.
The current implementation is based on, what I’ll call, a device’s “location circle.” I.e., the location data – latitude, longitude & accuracy (or radius) – effectively defines a circle wherein the device is likely to be. Almost never is the accuracy less than a few meters; in my experience, typically 10 meters or more.
When require_movement is true for a GPS based entity, location updates will only be used if the old and new location circles do not overlap. The idea being, if the device is not truly physically moving, even though the GPS fixes won’t necessarily be perfect, the device should always be within these location circles (as the GPS fixes move around a bit), and therefore, two consecutive location circles should always overlap in this case. (Think of the actual location as you standing there, and the location circles being a hula hoop you’re twirling around. If you put a strobe light above you, every time you see the hula hoop, it will always overlap with the position of the hula hoop you saw on the previous flash. 
)
Anyway, although this implementation probably satisfies many, if not most, cases, it does have a couple of major flaws.
First, at least for the GPS based device trackers I’ve used, it’s not uncommon for “outlier” location fixes. I.e., every once in a while the location update might “jump” to a location where the device really isn’t (and the accuracy value doesn’t reflect this), such that the device really isn’t inside the “location circle.” Again, in my experience, the next update will “jump back” to where it should be. If this happens when the device isn’t really moving, the require_movement feature will be fooled and update the composite entity when it shouldn’t.
Second, if the device is moving, but very slowly (maybe you’re walking slowly), then it’s theoretically possible for all location updates to always overlap with its predecessor, causing the require_movement feature to reject all these updates when it shouldn’t. (E.g., let’s say the accuracy is 25 m. For an update to be accepted, you’d have to move more than 50 m in the time it takes for the device to update. If you’re walking at 0.5 m/s, then if the device updated every 100 s or faster, then you could walk for days, and it would still think you were at your starting point.)
The updated implementation I’m thinking of is to keep not just the previous location circle, but the last three (or maybe more???)
If the new location circle overlaps with the previous location circles, then it will be considered stationary. Once “stationary”, location updates will be ignored until the last couple (or few??) updates do not overlap with the previous updates. When considering “previous updates”, might need to use a “majority of the previous updates” to filter out those potential “jumps.” And requiring more than one update to not overlap the previous updates also would have the same effect of filtering out jumps for the new updates.
I guess the biggest downside to this new implementation would be that it would take a couple (or a few) updates after the device has been considered stationary for the composite to start updating from it again.
Anyway, haven’t started anything, just trying to think it through. I’d appreciate any thoughts on the subject.
I think there is going to always be a trade-off between speed and accuracy. And there is never going to be the perfect balance. the best you can hope for is reasonably good enough.
I don’t see any glaring issues with your thoughts on it but I’m definitely not an expert. 
1 Like
Released 2.8.1
A race condition can cause the following error during startup:
Exception in _update when dispatching 'composite_speed-NAME': (None, None)
This release fixes that bug.
Released 2.8.2
- Fix timezonefinder doing file I/O in async_setup.
- Catch timezonefinder timezone_at exception.
Phil, recently I noticed a new entity created by this integration - “speed” sensors.
Is it possible to add an option to prevent creating “speed” sensors?
I do not need them…
Per usual HA conventions, if you don’t want an entity created by an integration, you should disable it.
so simple, thank you))
1 Like
Hi there,
I don’t know what i’m doing wrong but I cant get the most simple configuration to work;
composite:
trackers:
- name: Mathias Home
time_as: device_or_local
entity_id:
- entity: binary_sensor.mathias_connectedToHomeRouter
all_states: true
template:
- binary_sensor:
- unique_id: mathias_connectedToHomeRouter
name: Mathias Phone Connected To Home Router
state: >
{% if (states('sensor.galaxy_munk_s10e_wifi_bssid') == "XX:XX:XX:XX:XX:XX") %}
on
{% else %}
off
{% endif %}
icon: mdi:wifi-check
The binary sensor works flawlessly between on and off, but the device tracker keeps being unknown;
You appear to be using an incorrect entity_id for the composite. I think this:
- entity: binary_sensor.mathias_connectedToHomeRouter
should be this:
- entity: binary_sensor.mathias_phone_connected_to_home_router
1 Like
Thanks!
Although now it’s just always set as “away”.
Seems like Composite is still getting information from a “restored” entity, that I keep deleting on every HA restart (even after removing it from the .storage/core.entity_registry).
As a C# dev I’m still getting used to the quirks of working with these configs and no IntelliSense.
Any suggestions for a preferred method for debugging these types of issues?
(Please feel free to ignore this question - it’s pretty off-topic)
One problem might be an incorrect template for your template binary sensor. I believe it should be:
state: "{{ is_state('sensor.galaxy_munk_s10e_wifi_bssid', 'XX:XX:XX:XX:XX:XX') }}"
The template for a template binary sensor should evaluate to true or false, not on or off. Hmm, I just checked the docs, and I guess on is ok, but that’s not generally, or at least, traditionally, how it’s been done. What you have I guess should work, but to be consistent with how people generally use HA, I’d recommend changing it per above.
If the binary sensor is working correctly / how you expect, then the composite tracker should work as you expect, too (assuming, of course, you corrected the entity ID.)
You can enable debug for composite, and then you should see messages like the following in home-assistant.log (in your config directory. Or you can click the button to view the full log in the UI.)
2023-03-08 16:49:25.652 DEBUG (SyncWorker_1) [custom_components.composite.device_tracker] Updating device_tracker.xxx from binary_sensor.yyy
If you don’t see those messages, then that would confirm the composite tracker is not updating.
The composite tracker will restore its last state when HA restarts. Then when it continues to start up, if the binary sensor has already initialized, it should update per its state. After that, the composite updates whenever the input entity (in this case, the binary sensor) updates.
If you’re still not seeing the composite update, then double check you have the entity ID of the input binary sensor configured correctly. (Note that the composite will only re-read the config file after a HA restart. It doesn’t yet allow updating “live”. That’s a relatively new feature in HA that I haven’t utilized yet for this custom integration.)
You might also check the history of the binary sensor to see if it’s updating like you expect.
If none of that helps, let me know, and I can try to provide other suggestions. Honestly, though, I don’t use composite with binary sensors. I implemented that for others, and I haven’t gotten a whole lot of feedback as to how well that works.
Is there a way to prioritize a tracker for the state of the composite tracker? I’ve not found a perfect GPS tracker - both the HA app and now life360 generally work but both occasionally mark someone away when they are still at home. So I created a wifi tracker as a binary sensor and it seems to be working but if the GPS tracker updates to away then the composite tracker is updating to away as well even though the wifi sensor has remained on the whole time. I do have the composite tracker set to allow all states from the binary sensor but is there any other setting or configuration I can do with this to have it prioritize the binary sensor? Basically if that says its home then I’d like to be marked as home, otherwise use the GPS tracker.
Edit - sorry, this is likely user error. I didn’t realize that the binary sensor names I made for my wife and I were actually slightly different naming conventions so I didn’t have hers included correctly in the composite tracker config.