Updates to away from non-gps state unexpectedly

[cmatte]

Hi Phil,

HA 2025.2.0 here and composite 3.4.5.
The composite device tracker is updating to away from a non-GPS item when it has six:

1. GPS tracker from HA companion app
2. GPS from Google Maps
3. non-GPS from UniFi
4. non-GPS from NMap
5. non-GPS from UniFi n.1
6. non-GPS from NMap n.1
   (where n.1 is a second connection the same phone makes itself to improve WiFi speed).
   Require Movement set to true.
   All states not set (so it defaults to false).

The tracker is marked as away from items 3-6 when those are excluded (all states false) and movement is required (set to true) from item 1 or item 2 above. Re-reading documentation, can't tell why these are considered. The composite tracker shows last seen the 3-6 items, while 1-2 kept "home", and yet the tracker is flipping to away. Few relevant screenshots attached.

Am I missing anything or is this unexpected?

Cheers,
Matteo.

composite device tracker as of last evening - showing away as a status and history but not in the logbook, changed around 19:53:

composite device tracker as of this morning - showing away still at 6.25am:

item n.5 device_tracker.matteo_xiaomi_14_ultra_1_ui - the non-GPS that seems to have triggered the away state of composite unexpectedly (as per last seen), however per log/history it goes away around 18:08 and back at 20:42:

item n.1 the GPS (HA Companion App) item that never became away post 8:25am:

item n.2 the GPS (GMaps) item that also never became away post 8:25am:

composite settings:

[pnbruckner]

Those pictures are all very confusing. Is the first one the composite entity? If so, the "seen entities" attribute says it's only seen updates from device_tracker.matteo_xiaomi_14_ultra_1_ui, whichever one that is.

[cmatte]

They are indeed confusing, well, for me too! I added a description for each to clarify what they are.

First question is why did composite become away at 19:53, when no item became away at that time supposedly, and why does it list the indicated seen changes of device_tracker.matteo_xiaomi_14_ultra_1_ui which is a non-GPS item that changes very wildly (it's a secondary WiFi network the phone picks up on its own and likely a phone bug, cause the functionality isn't needed and is disabled but it gets active randomly, by the way!) and should of have been discarded due to both the require movement = true and no GPS moved, and the all states = false settings?

Secondly, why does the logbook not show up when composite goes "away" but it shows when it goes back "home"?

[pnbruckner]

The descriptions are only partially helpful. I need to know what the entity ID is for each. The composite works with entity IDs, not names. (Although, I can kind of figure out what the IDs probably are, but it's best to be explicit.) Even so, the "Seen entities" (entities) attribute only lists one entity, so as far as the composite is concerned, that is the only one for which it has seen a change that it has used (at least up until the time you captured that first screen shot.)

To help explain a bit about how composite works, the "Require movement" option only applies to GPS trackers. Also, the "Use all states" option doesn't apply when only non-GPS entities have been seen, and they are all not home.

So, in your case, since there has only been a single non-GPS entity seen, the composite will basically follow it, changing to home or not as that entity changes.

Why the Logbook entries don't show all the state changes, and don't agree with the history line, in some of your screen captures is something I can't explain. That is not something decided by the integration. That's one of the reasons I said the captures are confusing.

Have you enabled debug for the composite integration? If not, please do. Then check the logs for composite DEBUG messages. That might help explain more about what it is seeing and how it is using the data / state changes from the input entities.

[cmatte]

Thanks for your walk-through, helpful indeed. I will add the precise entity IDs for the screens, sorry that they were still confusing! I thought from the configuration screenshot it would work well to appreciate the other entities as actually we can only read the "name" rather than entity_id in there and that matches the screenshots - I will add the entity id to dig into further though, including the debug logs that I will enable to capture a bit of useful data to look at Indeed, good idea! To be frank my first thought was that I could have got some config/mechanism wildly wrong and that'd explain it all 😅

One major question rolling in my mind is around the explanation around composite only seeing a single non-GPS entity, why would that happen when there's two fully working GPS entities that have been home the whole time with no movement - under what conditions these would be ignored and the non-GPS changes considered exclusively?

Secondly, most of the readme explains how these settings would leverage non-GPS trackers to mark the composite device tracker "home" and never away, in the presence of GPS trackers, is this a wrong simplification?

Thanks again!

[pnbruckner]

One major question rolling in my mind is around the explanation around composite only seeing a single non-GPS entity, why would that happen when there's two fully working GPS entities that have been home the whole time with no movement - under what conditions these would be ignored and the non-GPS changes considered exclusively?

Just that. You said it, "with no movement." The composite typically only reacts to input changes. I.e., it (may) update when one of the input entities updates. If they are not updating, then they won't cause the composite to update.

Having said that, at startup, the composite will read the current states of all the input entities and will effectively use them as "new states" (or changes), so if all those entities exist (and are in HA's state machine) at the time composite initializes, then they should be listed in the "seen entities" attribute. But they're not, so...

Secondly, most of the readme explains how these settings would leverage non-GPS trackers to mark the composite device tracker "home" and never away, in the presence of GPS trackers, is this a wrong simplification?

By default, non-GPS entities can only change the state of the composite to home if the composite has already seen GPS entities. If it hasn't, then it gets a little more liberal about non-home state changes of the non-GPS entities, and the "Use all states" option can also override some of this behavior.

The basic idea is that most non-GPS tracker entities are pretty good about knowing when a device comes home, but they are typically lousy about knowing when a device leaves home. They often have algorithms that assume the device must have left if it hasn't been seen for some time period. But that's not the same as knowing it has left, and it's often way after the fact. If these non-GPS "leaving home events" are used all the time, they can really mess up the functionality of the composite tracker. Hence, they are typically ignored, although they will be used in some circumstances, such as when there are only non-GPS entities and they are all away. Or, if you know you have some non-GPS entities that are good about knowing when the device has left home, you can add it to the "Use all states" list.

[ffries]

I am facing the same problem. We have 7 trackers and only 2 are GPS. The composite tracker is Family. The presence of my wife is calculated with iPhone Device Tracker. Require movement is not enabled.

My wife enabled WIFI on here iPhone at 7:25 therefore was detected present. When she left at 7:31 all other members of the family where home and Family composite tracker suddenly became Away.

This is very confusing. All this is probably a documentation problem, we need more information how the composite tracker reacts.

I would expect the status of Family composite tracker to stay home as long as a single member of the family is home. It seems that the composite tracker flips to away too easily, when it is first and mostly designed to tell when the family is home, not away.

Just that. You said it, "with no movement." The composite typically only reacts to input changes. I.e., it (may) update when one of the input entities updates. If they are not updating, then they won't cause the composite to update.

This is not the requested behavior (or I don't understand). One tracker should not be able to set status of the composite tracker to away and take precedence. The only reason for misbehavior is that the house could include untrusted/bad trackers. But this is misbehavior, we should not take bad trackers into account and users should simply not use them.

The normal feature is that all trackers need to be away to set presence to away (good behavior).
We should trust all trackers and when a single tracker is home, the composite tracker is home.

[ffries]

Should I rather use Groups or trackers and the is the advantage of composite tracker over basic programming?

group:
  famille_present:
    name: Famille Présente
    entities:
      - device_tracker.membre_1
      - device_tracker.membre_2
      - device_tracker.membre_3

device_tracker:
  - platform: template
    trackers:
      famille:
        friendly_name: "Famille"
        value_template: >
          {% if is_state('device_tracker.membre_1', 'home') or
                is_state('device_tracker.membre_2', 'home') or
                is_state('device_tracker.membre_3', 'home') %}
            home
          {% else %}
            not_home
          {% endif %}
        icon: mdi:account-group

[pnbruckner]

@ffries please see my response in the other issue you opened (#90).

[ffries]

Thanks, I read your answer and now I understand, so please discard my remarks.

[pnbruckner]

@cmatte do you still need help with this? If not, feel free to close the issue.

[pnbruckner]

@cmatte since you haven't responded recently, I'm going to close this incident. Feel free to reopen it, or open a new one if needed.