Template "scanner" device_tracker: presence-only tracking (is_connected + zone) without faking GPS

[bzumik1]

Describe your core improvement

Problem

Since the legacy device_tracker.see / known_devices.yaml API was deprecated (removal in 2027.5), there is no config-entry-free way to declare a presence-only device tracker (home / not_home / zone) that does not pretend to be GPS. The recommended replacement, Template device_tracker, is built on TrackerEntity and is GPS-only (_attr_source_type = SourceType.GPS, which integrations are not supposed to override). That has two consequences:

• You can only express presence via latitude / longitude / in_zones, not a simple connected/home state.
• Because it reports source_type: gps, it competes with real GPS trackers in person and regresses presence for BLE/router/ping sources. Details + reproduction: Recommended migration from deprecated device_tracker.see to Template device_tracker regresses person presence for non-GPS sources core#179771.

Request

Add a Template variant built on the newer ScannerEntity model (tracking_type = CONNECTION, _attr_source_type = SourceType.ROUTER) instead of TrackerEntity. Minimal contract:

• is_connected: a template returning bool | None (the only required member of BaseScannerEntity).
• an optional configured zone (defaults to zone.home).
• in_zones is then derived by the base class exactly as for real scanners: connected → configured zone (+ enclosing zones), disconnected → not_home, None → unknown.

Why this shape

• It matches Home Assistant's own new device-tracker entity model (2026.6) rather than fighting it, and needs no override of TrackerEntity's GPS source_type (which the dev blog explicitly forbids). A "template scanner" fits the declared direction far better than "add source_type to Template device_tracker".
• A ScannerEntity reporting a zone lands in latest_connected, the highest-priority bucket in person — so BLE/router presence reliably wins over GPS, which is the entire point of room/beacon presence.
• It covers the whole class of use cases orphaned by device_tracker.see: BLE beacons (ESPresense), ping-based presence, Wi-Fi/router presence — all of which are "is_connected + zone", exactly what a template can express.
• The contract is already just "a bool + a zone", trivially templatable; zone binding via in_zones only became available in 2026.6, so this option only recently became feasible.

Related

• Core bug: Recommended migration from deprecated device_tracker.see to Template device_tracker regresses person presence for non-GPS sources core#179771
• Device tracker lack of functionality core#173495 (closed, needs-more-information) — the same limitation from the user side.

Current limitations

• The simple presence primitive is going away. device_tracker.see (legacy platform API) is deprecated and removed in 2027.5. It was the only easy way to push a plain home / not_home state from an automation for a non-GPS source.
• The recommended replacement is GPS-only. Template device_tracker is built on TrackerEntity, which hardcodes source_type: gps and must not be overridden. Presence can therefore only be expressed via latitude / longitude / in_zones — there is no way to say "connected / home" without inventing coordinates.
• It actively regresses person. Because the template tracker reports source_type: gps, it falls into the latest_gps bucket and competes with real GPS trackers (Companion App), instead of taking precedence like the old bluetooth_le state did. See core#179771.
• ScannerEntity is code-only. The connection/router entity model that would express this correctly is available only to config-entry integrations implemented in Python — there is no template / YAML way to create one.
• Documented, unresolved. #173495 reports the same user-facing gap ("I cannot create a state home/not_home unless using the longitude/latitude") and was closed as needs-more-information.
• Existing workarounds are heavier than they should be. Restoring the old behaviour today requires an MQTT device_tracker wrapper (extra broker round-trip, retain handling) or a full custom integration (e.g. Bermuda) — disproportionate for what used to be one service call.

Technical benefits

• Fits the existing entity model instead of fighting it. It builds on ScannerEntity (tracking_type = CONNECTION, source_type = ROUTER), so it needs no override of TrackerEntity's GPS source_type — which the "device tracker entity models" dev blog explicitly forbids. No contract is bent.
• Correct person resolution. A ScannerEntity reporting a zone lands in the latest_connected bucket, the highest-priority path in person._update_state. That is the semantically correct outcome for BLE/router presence and avoids the current regression where a Template device_tracker forces source_type: gps and competes with real GPS trackers (see core#179771).
• Minimal new code, maximal reuse. BaseScannerEntity already derives in_zones from is_connected + the configured zone. The template variant only needs to feed a templated bool | None and a zone into that existing machinery — no new entity semantics.
• No GPS spoofing. Presence is expressed as connected/not-connected + zone, so history, logbook and the map are not polluted with fake latitude/longitude, and zone geometry is not abused to fake a home/not_home state.
• Closes the whole device_tracker.see migration gap. One template primitive covers the entire class orphaned by the legacy API removal in 2027.5 — BLE beacons (ESPresense), ping, Wi-Fi/router presence — reducing future bug reports, forum churn and custom-integration proliferation.

Additional context

No response

[carefulcomputer]

Concrete case for this. I have an OpenWrt AP running wifi-presence. It publishes one message per device saying whether that device is connected to the wifi. That is the entire signal: a boolean.

There is no declarative way to turn that into presence today. So I run it through Node-RED and call device_tracker.see, just to convert a boolean into a home state. That bridge exists for no other reason, and it stops working in 2027.5.

On the proposal itself: the "optional configured zone" half already exists in core. BaseScannerEntity has it:

_scanner_option_associated_zone: str = zone.ENTITY_ID_HOME

It is overridable per entity, and the end result is already tested. In the person tests, test_scanner_associated_with_other_zone asserts that a scanner bound to zone.office resolves the person to state office with in_zones: ["zone.office"] and no coordinates of its own. So the capability works today. The only thing missing is a way to declare it from a template.

I also run nmap_tracker for the same devices. It is a ScannerEntity, reports in_zones: ["zone.home"] with no coordinates, and lands in latest_connected exactly as intended. Same setup, same devices: the in-tree scanner does the right thing, and the see bridge is the part I have to maintain and replace.

[KevinCathcart]

Just a bit of clarification here. If a template scanner device tracker entity were added, it would most likely be based on BaseScannerEntity, as the funky mac address related logic of ScannerEntity wouldn't be desired.

You should be able to do just basic home vs not home with the existing template entity via in_zones returning an empty array, or one with home in it, while fully omitting lat/long. If that isn't working properly it is a bug. It is true that the doing this would leave inaccurate source type and a debatable tracking type attribute, and won't be prioritized by person, but it should be otherwise functional. This still doesn't address the desired prioritization though, so it is not a full solution.

Allowing the existing position based tracker entity to override source type should be fine. Specifically, if an integration has device trackers that use a mixture of connection status and GPS (possibly even varying over time), then deriving from TrackerEntity and keeping the source type up-to-date is totally appropriate. The downside being of course that it doesn't get special prioritization by person. But also not really a perfect solution for this, since the legacy home logic is person may well change once legacy device tracker support is removed.

I do have to wonder if the fixed logic implemented by person is just a bit too inflexible for some people's needs. But typically the workaround for an inflexible entity that wraps multiple is to put custom calculation logic in a template entity, and have it the inflexible entity wrap that template.