Person: Use the home zone lat/lon coordinates when detected home by a stationary tracker

[Hypfer]

Proposed change

When playing around with the demo instance, I saw that person entities had this map view when opening the more-info dialog

When playing around with my HA instance, they didn't.
This confused me, so I looked at the person implementation.

I'd argue that if the latest tracker is home and there is also a latest gps tracker that is also home, there is no point in not using the gps tracker, as it will provide a superset of the data the other non-gps tracker could provide.

The architecture discussion sparked by this PR (home-assistant/architecture#1179) led to the decision that stationary trackers should remain prioritized, but also, to solve the issue of vanishing lat/lon attributes, the zones lat/lon shall be used.

The PR has been updated to reflect that.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: N/A
• This PR is related to issue: N/A
• Link to documentation pull request: N/A

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[edenhaus]

Can you please explain why we should use the GPS-Tracker over a non-gps one if both specify that the person is home

[Hypfer]

@edenhaus Sure!

While the state of the entity is the same, the difference is that the person only has latitude/longitude attributes if the source of the location data is a gps tracker.

Without those two, it simply vanishes from the default map view.

You also just get a boring history more-info pop up like this one:

instead of the small map like in the screenshot from the demo instance.

[edenhaus]

Instead of using the GPS coordinates, we could also use the coordinates of the zone, where the non_gps one belongs too

[ildar170975]

the difference is that the person only has latitude/longitude attributes if the source of the location data is a gps tracker.

As it was already explained - currently a person entity is not shown on a Map when it is definitely home - which is rather confusing.
Thank you, @Hypfer

[Hypfer]

Instead of using the GPS coordinates, we could also use the coordinates of the zone, where the non_gps one belongs too

True, but since zones can be of arbitrary size, the user might conceivably still be interested in the gps position within that zone instead of just the center of it.

[edenhaus]

For example due the big walls in my house the gps accuracy is bigger than the actual zone, so in my case I would prefer the zone coordinates.

Also using the zone coordinates would be more consistent as with your proposal only coordinates would be available if also the gps device is home. In my opinion we should use the zone coordinates but I will discuss this topic internally

[frenck]

Instead of using the GPS coordinates, we could also use the coordinates of the zone, where the non_gps one belongs too

☝️ This makes a lot of sense to me.

That said, this is en entity component and for changes to that model (especially fundamental changes like this), we require an architectural proposal and discussion that have been approved prior to creating a pull request.

Therefore, I suggest to start by creating a architectural proposal and discussion in our architecture repository first.

../Frenck

[edenhaus]

As the architecture discussion home-assistant/architecture#1179 was answered, can you update the PR to match the discussion?

[Hypfer]

Done. The remaining failing test seems to be an issue with the dev branch and unrelated to this PR

[Mariusthvdb]

just adding #61299 which was closed ages ago because 'being worked on' ;-)
makes it tie together nicely

can only cheer for this PR now, thx!

[PeteRager]

The number of code line in update_state is starting to get big, consider moving this logic into a helper method?

[frenck]

Wondering, why only the home zone?

[Hypfer]

Because - at least to my understanding - stationary trackers don't support being in any other zones than the home zone.

Honestly that confused me too, because the architecture discussion sounded like they could be linked to any zone but they don't seem to be able of doing that.

[PeteRager]

It is a good question. In PR #138475 there is a stationary tracker of source type bluetooth_le that is reporting a non home zone and that causes the person to be "away" rather than in the non-home zone. So yes, it appears that a stationary tracker can report a non home zone.

[Hypfer]

@PeteRager A bit more context building would go a long way here. I did not understand the previous review from you but now after looking at your PR (which you didn't label as yours) that makes a lot more sense.

Something like "Hey btw I'm also touching this feature right now for a different reason and that might require additional changes. Specifically, it seems that there are these assumptions, however those might not hold true under these circumstances"

Or just a "In My PR 1234" instead of just "In PR 1234". That's just one word making a lot of difference

[PeteRager]

The docs https://www.home-assistant.io/integrations/device_tracker/ have conflicting information. First they state it is either Home or Not Home; but then in the first bullet it says that a presence based system that includes coordinates it could be any zone name.

"A device tracker with router as a source can have one of two states: Home, or Not home.

• Home: Your tracked device is in the home zone, detected by your network or Bluetooth-based presence detection. If you’re using a presence detection method that includes coordinates: when it’s in a zone, the state equals the name of the zone (case sensitive).

• Not home: When a device isn’t at home and isn’t in any zone."

So there seems to be two cases of stationary trackers; one without coordinates - which is the case you are solving - and that is documented as being home / not_home only. In context of this PR it should be ok to only use the home zone. or to future proof you could just use the tracker state to lookup the zone and pull that. It would be nice if I have a router in my garage it would mark me as being "garage" or "not in the garage"

The case being addressed in #138475; is related to stationary trackers than have coordinates; and by definition since that has coordinates the logic being proposed here would not run.