Bug: Driving status unset during above threshold speed

[sshaikh]

In this chart:

Why does the driving status get unset when the speed increases between 1751 and 1752?

[pnbruckner]

What did you enter for "Driving speed" in the integration's configuration entry?

[sshaikh]

I did forget to mention - 6, for 6km/h.

But the odd thing is how it is driving at 5m/s but then unset when this increases to 11m/s.

The blip at 17:52:30 is also curious. I am tracking a person rather than a direct device tracker if that means anything.

[pnbruckner]

Yes, this is unexpected.

It would help if you could enable some debug settings and then share the details. You can send via email if you'd rather not share the details here.

Please enable debug for the composite integration, and it would be extremely helpful if you could also enable debug for homeassistant.core. The latter especially will generate a lot of debug messages, so you'll want to disable afterwards.

I'm interested in any composite related messages, and any related state_changed events, when this problem happens. For the state_changed events, it would be useful to see the state changes for both the "input" entity (e.g., the person entity), as well as the composite entity.

[pnbruckner]

BTW, what version of HA and what version of the composite integration are you using? You should always share those details when opening an issue. Thanks!

[sshaikh]

HA: 2025.2.3
Composite: 3.4.5

I've enabled debugging for the integration, but it seems a very obscure finding that doesn't happen all the time (most of the time it works as expected) so it might require some luck to find it again!

[pnbruckner]

Can you please also enable debug for homeassistant.core? It will be very helpful, when this happens, to know exactly how the input entity changed.

[sshaikh]

I was hesitant with that as due to the nature of the bug it means turning it on for the long term. But will do so - can you guide me on how? From memory it required a yaml flag?

[pnbruckner]

FWIW, I run with this on all the time.

Yes, you can do it in configuration.yaml, but you can also do it from Developer tools -> ACTIONS:

[sshaikh]

It happened again yesterday, but unfortunately I have since rebooted HA so lost the logs.

That said I think I understand what's going on (and it's peculiar to my system). If you want the excruciating detail (to confirm or it may give insight to an approach or bug):

1. I have a proximity sensor attached to HA's persons to see how far away they are from the home, as well as whether they are coming toward or away from the home.
2. The way proximity works is to update the direction on each GPS update, and if it receives two updates in a row within a radius it considers that person to be stationary.
3. This is reasonable until you have the situation where HA loses GPS updates just before you stop moving (eg on entering a building). Even though you have stopped, proximity will say you are still heading in a direction.
4. To solve this, I created a "stale GPS proxy" device tracker per person, added these to the list that tracks a person, and then if I don't receive a GPS update on the main device tracker after say 5 minutes I "touch" the proxy device (with see) and copy over the last known GPS location. This "counts" for proximity and it sets the direction as stationary. Since this copied location becomes old very quickly, HA seems to ignore it
5. For composite, I add these persons. My suspicion is having this stale proxy device tracker in the person confuses composite somehow.

This is all theory until I get those logs, but I'd appreciate your insight if that's obviously it. I could also try setting composite directly on the device tracker to see if it fixes the issue.

In the meantime, two questions:

1. How would composite deal with multiple trackers under a person like this?
2. I'll probably wrap a template sensor around composite's speed sensor to translate into states like stationary, walking and driving and therefore do away with these proxy shenanigans. How would you feel about composite doing that instead? Having driving in the main sensor (that is otherwise the zone name) kind of seems awkward as it stands.

[pnbruckner]

Do I understand correctly that you have multiple device_tracker entities per person entity, and one of the device_tracker entities per person is a "fabricated" entity using the device_tracker.see service? And then you combine all those person entities into a device_tracker entity using the Composite integration?

[sshaikh]

Yes, except when I created the composite tracker I only provided it the person.

[sshaikh]

action: logger.set_level
data: {homeassistant.core: debug}

Unfortunately the above kills my HA instance so I can't use it.

I'll leave the Composite debug on though. Once I do manage to capture the log output, is there anything I can search for?

[pnbruckner]

So, there is one composite device_tracker entity, whose input is all the person entities? Or there are multiple composite device_tracker entities, each with one person entity as input?

If the former, that doesn't make sense. If the latter, why are you combining multiple device_tracker entities via the person integration? That is what the composite integration is for. Typically, people use the composite integration to combine multiple entities per individual. Then, if they also want a person entity, they use the composite entity as the one and only input to the person integration.

[sshaikh]

The second. The reason is as a workaround to the (what I see as incorrect) proximity integration behaviour in how it treats sparse GPS updates.

But you make a good point about using the composite integration for this (the solution predates my use of it), but I'm a bit weary of adding such a "mock location" workaround to it.

I'll flip them around, but it's interesting if that is the reason for the original issue I'm having (ie the driving state being overwritten).

[pnbruckner]

Note that the composite integration uses "last seen" attributes from its inputs (if they exist), whereas the person integration does not.

Note also that the composite integration predated the existence of the person integration.

It's unfortunate that your system can't handle enabling debug on homeassistant.core. That may be the only way to really understand the conditions that cause the composite integration to result in unexpected values. Still, debug for the integration itself should help. If/when the problem happens again, share whatever log messages you think might help shed light. And please make copies from the full log, not just what shows up on the logs page by default. I really need the raw messages.