Composite Device Tracker Platform

Do you mean when the device/phone is actually in your home, Life360 temporarily returns a GPS location outside your HA Home zone?

If so, yes, that does seem to happen with any GPS-based device (but luckily, at least in my experience, not very often.) Sometimes the GPS fix is wrong and there’s not a whole lot a service like Life360, or the HA life360 integration, or the composite integration, can do about it. Bad data is bad data, and AFAIK, there’s not any way, or any good, reliable way, to determine the data is bad, so it just has to be believed.

This question does come up from time to time, but that’s not how the composite tracker works. Its design is based on the assumption that newer data is “better” than older data. It does not try to “prioritize” input data (although it does have some mechanisms for trying to ignore data that is known to likely be useless, like home-to-away transitions on network/router-based trackers, and unavailable & unknown states.)

But, looks like you got it working. Let me know if you have any other questions.

1 Like

Hello everyone,

I’m still trying to understand the logic of this tracker, so forgive me if I’m thinking something wrong…

I have the companion app and getting the GPS and wifi data from it. I also created a binary sensor that collects the data from the wifi sensor of the phone and it is working as it should be. The point that I couldn’t figure out is that; if the GPS data shows that I’m home, it is not important what the binary sensor shows, composite tracker always shows that I’m home. Then I used a fake gps app and showed myself away but kept my wifi connection, so the binary sensor was showing that I’m home, but this time composite sensor showed that I’m away. Because of that I couldn’t understand the the purpose of the wifi tracking. If the composite device tracker favors gps data all the time, I can use the gps data alone, why would I need the composite tracker?

I’m almost sure that I’m missing out something here so I would be happy if you can guide me.

Best regards.

Here is my binary sensor config;

template:
  - binary_sensor:
      - unique_id: "bbbb_binary_wifi_tracker"
        name: "Bbbb binary wifi tracker"
        state: "{{ is_state('sensor.phone_wifi_connection', 'ABCD') }}"
        icon: mdi:wifi-check

And also my composite tracker config is as follows;

composite:
  trackers:
    - name: bbbb_tracker
      time_as: local
      require_movement: false
      entity_id:
        - entity: sensor.bbbb_binary_wifi_tracker
          all_states: true
        - entity: sensor.phone_wifi_connection
          all_states: true

First, the design basis of the composite tracker is “newer data is better.” So, when one of the inputs provides newer data than the composite has seen so far, it will use the newer data. It bases this on the “last_seen” attribute, or the entity’s “last_updated” field if it doesn’t have a “last_seen” attribute.

Binary sensors (or “router” type trackers), however, are typically much better at indicating when a device has come home than they are determining when a device has left home. So, by default, only the “to home” transitions are used for these types of inputs. So, e.g., when a GSP tracker shows the device has left home, a lagging binary sensor or router type tracker won’t prevent the composite from also changing to not home. Setting “all_states” to “true” can override this default and cause all state transitions of these inputs to be used. That is only recommended for inputs that don’t have a serious lag changing from home to not home.

Looking at your composite configuration, I don’t see you using the GPS device tracker. So, I’m confused about how you’re trying to use it.

Dear Phil, thank you for your kind explanation. About your question; when I was masking my data while posting, I accidently changed the both entities to wifi, my real configuration is like this;

      entity_id:
        - entity: sensor.bbbb_binary_wifi_tracker
          all_states: true
        - entity: device_tracker.sm_g950f
          all_states: true

second entity is the phone gps tracker, sorry for my mistake.

From your explanation, I understand that if a new data comes from a tracker sensor, composite tracker favors it. I checked this logic and it works perfect, thank you for your explanation.

Kind regards.

Can anyone explain the difference between this integration and the “People” feature in HA? It seems as though that does the same thing (assigning/combining multiple trackers to one person).

Hi Sean,

This custom integration and the built-in Person integration, at a high level, do basically the same thing, which is to combine multiple device trackers for a given person. However, the way they do it is different. Also, the Person integration is more “integrated” into Home Assistant, being a standard component.

For a bit of background, this custom integration was created well before the Person integration existed, so at that time it filled a need that the standard system didn’t supply. But, even after the Person integration was created, its algorithm for combing multiple “trackers” was somewhat less than optimal. In my opinion, it still is. What many people do is to use this customer integration to do the combining of the multiple trackers, and then use the resulting “composite” tracker as a single input to the Person integration. That way you get the “best of both worlds.”

1 Like

Dear Phil,

some years ago, you found a way to determine the time difference between a composite device_tracker (using the last_seen) and a local HA instance. (as explained in the docs)

In the mean time a lot has changed in HA templating, we got to see the mobile_app with some useful sensors (geocoded_location), so I wonder what would currently be the best method.

I’ve explored the options, but don’t think there’s anything other than last_seen in your CC?

Sorry, not following you at all.

sorry…

was referring to GitHub - pnbruckner/ha-composite-tracker: Home Assistant Composite Device Tracker

and trying to figure out if your CC is still the only way to calculate that.

seems that even having a mobile_app sensor returning the time zone name ‘Europe/Amsterdam’ or lat/lon combination on a tracker can not realize this.

meanwhile Ive discussed this a bit more and maybe that will help me out anytime in the future, using mobile_app on an iOS platform (Android does have native entities for that TZ manipulation)

Ok, I think I understand what you’re talking about. I don’t know if there is any other way in HA, especially using only built-in components, to determine the time zone for a device tracker or person entity, and hence its offset to the time zone configuration of your HA installation. FWIW, my custom integration uses either the timezonefinder or timezonefinderL Python package to determine time zone from GPS coordinates.

yes, thanks Phil, I had been using the integration purely for that logic alone (not even mentioning the better/more reliable performance when using with wifi trackers)

was wondering if that offset attribute on couldn’t be made default in your CC? why have us use those templates, and not add it to the attributes right away?

taking that 1 step further, (and considering Petro’s suggestion of ‘an integration’ taking care of that):

what would you think of adding these to your CC:

these are attributes made by the Android app on the Home Assistant tracker.

Composite is already using that external library, maybe these attributes could be added too?

Ive just re-installed the latest CC version, and please let me ask this:

given the fact these entities are now UI configurable, wouldn’t it be better if ‘name’ were an optional field? we can override it in the UI, and yet the yaml config would be set fixed.
Ive tried to leave it out, but that errors on a required config option. (which ofc is correct given the current requirements)

Compare this to eg the template: integration.
We can leave name: out, and the name is derived from the used unique_id, with an additional template_ prefix. Set it up, and take out the prefix part is what I always do. Or, alternatively, set name: once, to have a new entity created and use that name, and next comment that in the yaml, so the UI can always override that, without having this fixed yaml name living in the config somewhere.

considering the above: wouldn’t it be useful to have id changed to unique_id? setting a user configurable ‘object_id’ , the purpose of the id field, can also be done from the UI after all?

composite:
  trackers:

    - name: Marijn
      id: marijn_composite
      time_as: device_or_local
      require_movement: true
      entity_id:
        - device_tracker.marijn_wifi
        - device_tracker.marijn_gps
        - device_tracker.ping_marijn

results in:

using:

composite:
  trackers:

    - unique_id: marijn_composite
      time_as: device_or_local
      require_movement: true
      entity_id:
        - device_tracker.marijn_wifi
        - device_tracker.marijn_gps
        - device_tracker.ping_marijn

would do the same.

as to the template examples you show in the docs, I seem to be misunderstanding what the last one does, as these return the exact same info:

{{ state_attr('device_tracker.marijn_composite', 'last_seen').astimezone(now().tzinfo) }}

{{ state_attr('device_tracker.marijn_composite', 'last_seen')}}

I think I’m pretty much done with working on Home Assistant related software. It’s just gotten too complicated. I’ll probably still try to keep my custom integrations working when they break due to core changes, but that’s about it. And even there I don’t make any promises.

2 Likes

I understand, and appreciate any effort you make to keep things working properly. thanks!

You shouldnt have mentioned that Phil…
there is a new issue raised after HA 2023.7.2 just now:

2023-07-14 09:29:47.593 ERROR (MainThread) [homeassistant.setup] Error during setup of component composite
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/setup.py", line 288, in _async_setup_component
    result = await task
             ^^^^^^^^^^
  File "/config/custom_components/composite/__init__.py", line 218, in async_setup
    await hass.async_add_executor_job(create_timefinder)
  File "/usr/local/lib/python3.11/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/composite/__init__.py", line 205, in create_timefinder
    from timezonefinderL import TimezoneFinder
  File "/usr/local/lib/python3.11/site-packages/timezonefinderL/__init__.py", line 3, in <module>
    from .timezonefinderL import TimezoneFinder
  File "/usr/local/lib/python3.11/site-packages/timezonefinderL/timezonefinderL.py", line 8, in <module>
    from importlib_resources import open_binary
ImportError: cannot import name 'open_binary' from 'importlib_resources' (/usr/local/lib/python3.11/site-packages/importlib_resources/__init__.py)

I have this same error in my HA logs since updating to 2023.7.2. Is there a fix?

@Mariusthvdb @msl2424 can you share your composite config?

Looks like the TimezoneFinderL package is trying to import something (importlib_resources) that is no longer being indirectly installed by HA, or the version of that package has changed such that what TimezoneFinderL is trying to use from it (open_binary) is no longer available or in the same way.

Until I get a chance to look into this, you might try changing your composite config to not use the TimezoneFinderL package (e.g., remove the use of device_or_utc or device_or_local.) Or maybe try changing which timezone finder package you’re using, or its version.

Update: See ImportError: cannot import name ‘open_binary’ from ‘importlib_resources’ with Core 2023.7.2 · Issue #47 · pnbruckner/ha-composite-tracker (github.com)

Hi Phil,

Sure:

composite:
  trackers:

    - name: Marijn
      id: marijn_composite
#       time_as: device_or_local
      require_movement: true
      entity_id:
        - device_tracker.marijn_gps
        - device_tracker.marijn_wifi
        - device_tracker.ping_marijn

I’ve now commented the time_as config option, but sure hope you can find a fix, because its one of the main options for me to use your CC (which is the only one providing that functionality…)

Please see issue linked above with update & new suggested work arounds.

The following work around seems to work:

composite:
  tz_finder: timezonefinder
  tz_finder_class: TimezoneFinderL
  ...