If there’s a user need for it, it could be added. The core team wants to see user engagement before it’s added. So I recommend making a feature request that I can use as an excuse to add it.
Right now, they don’t really see a need when binary sensors do the same thing and gps device trackers without lat/lon do the same thing as well.
The don't because you cannot assign them to a person. This would be even better!
I do not have great faith in FRs but I will give it a try again.
Can't be assigned to a person. therefore no parity. Literally the only way to assign it and get the zone math to work is a device tracker. Thus why we used. See.
Yeah it needs to be there.
For me the prioritisation of trackers in a person was not playing nicely at all. Main issue is that it only evaluate actual states . It doesn’t take the history into account.
Example where it fails: leaving home, where the mobile remote connection fails, or GPS updates delay a long time. State will remain home.
Solution was an own composite tracker automation (here is the blueprint) . Basic approach:
That works much better for me. Only the composite tracker is assigned to a person.
Next step is to migrate from this automation with device _tracker.see to a blueprint for a template device tracker.
Yes but you can still use gps devices trackers in a boolean way by omitting lat/lon and only using in_zones.
But would they have to constantly be updated to "overwrite" another gps-tracker with GPS drift with a more recent position.
Not really sure how that’s relevant. You can easily do that with trigger based template entities using a home or away lat/lon and random sig figs. How would router based device trackers solve that?
I will publish a template blueprint when done testing.
This is all about reliability.
GPS trackers can drift out of your home zone.
Router-trackers can fail, when wifi is disconnected.
A combination of both work very reliable (in my case for 8 years) because both conditions almost never happen at once.
The prioritization of the two different tracker types would solve that
Person - Home Assistant Person - Home Assistant
Right, but how does a router based device tracker solve that? Why can’t you do that currently with a gps device tracker?
That is exactly what my current automation blue print does (and future template will do).
Stationary 'home' prevails even if GPS telling not home
when all stationaries reported away, latest GPS update (after change to away) is used
The blueprint can handle from 1 to many trackers (device trackers or binary_sensors of the type precense or connectivity), where it discriminates automatically if the are GSP or stationary
This has been the absolute best combination. GPS plus periodic rehit when you KNOW a device is onthe home net. Near infallible.
P, best case I want to simulate force a GPS location when conditions are correct. I know I'm here. *Blam* don't argue. The eq of ‘see’
Ok, I might get what you mean.
New solutions require new thinking.
I was stuck In thinking I need two device trackers for my presence to be reliable and was replacing only one with the new template.
Replacing both with one new template solves all the problems.
Yeah, if it doesn’t end up working and you need that router entity, provide that in an explanation. If I have good ammo to take to the core team, they’ll let me add it. Right now I don’t really have good reasons to add it so they are basically saying no.
I need some time to properly test a template version as that is much harder to troubleshoot then my current automation based solution (where I have traces)
Hi
Small update: The blueprint referenced earlier is still an automation using device_tracker.see, but totally refactored.
The structure of the latest version is much more suitable to be migrated to the device_tracker template.
In order to avoid useless tracker updates (ble/routers tend to be chatty) a condition compares previous and new state for stationary trackers.
@petro, @TheFes and others 
: I can use some advice how to access the old state in the condition section of a trigger based template blueprint!
My thought so far:
Trigger based templates can only access thisat entity level (because one trigger section can set multiple entities ).
But blueprints only provide one entity. So could I use this in the condition above entity level for template blueprints?!
Or are there other ways to retrieve the previous state in conditions (without the need for an extra entity_id input field for the blueprint)?
Edit: Or can I use this to update the device tracker with exactly the same state (in order that only last reported changes without spamming the recorder with irrelevant updates). Like this:
template:
…
device_tracker:
- name: test
variables:
no_update: “{{ true if ... }}”
in_zones: “{{ this.attributes.in_zones if no_update else … }}”
latitude: "{{ this.attributes.latitude if no_update else … }}"
longitude: "{{ this.attributes.longitude if no_update else … }}"
location_accuracy: "{{ this.attributes.gps_accuracy if no_update else … }}"
Thanks in advance
Eric
I prefer to get all updates from stationary trackers.
They are generally a lot more precise and I need the updates to overwrite the less precise movable trackers as fast as possible, if there is false updates from them.
@WallyR
Yes I use all updates of them, and we have a shared concern 
: reliable detecting without false positives was the main goal of my blueprint.
But said that, updating the composite tracker (aggregate of all trackers) for every stationary update is really not needed for reliable zone detection. My blueprint will use every update to detect zone changes, based on both combined states and the order of events:
GPS updates are always handled for the new coordinates. BUT stationary zone info prevails (unless the GPS distance exceeds zone radius +gps accuracy. This gives some hysteresis for entering and leaving)!
Stationary tracker updates only update the composite tracker when the zone will be changed (preserves latest GPS coordinates in most cases):
While you don’t reside home or in another zone, stationary not_home updates are ignored to preserve the last zone and GPS info
Note that Bluetooth trackers can update several times per second! Router trackers up to several times per minute. They only report home or not home (optional area info is to be handled by separate sensors)
I hope this clarifies
I made the home zone evaluation configurable with this optional blueprint input:
gps_home_filter:
name: What is leading for home determination atm that GPS reports away (just outside the home zone)
default: "[]"
selector:
select:
options:
- label: GPS is leading
value: "[]"
- label: BlueTooth (LE) can overrule
value: "['bluetooth','bluetooth_le']"
- label: Router can overrule
value: "['router']"
- label: Both BT and Router can overrule
value: "['bluetooth','bluetooth_le','router']"
Selected stationary trackers can overrule the zone to home when GPS reports away.
This only happens if the distance is less then the zone radius + gps accuracy, and at least one selected tracker has the state home
This creates a hysteresis for home/leaving.
Note: try to match your home zone radius with your WiFi coverage (a larger radius is fine, less gives issues)
not technically fully able to explain, but I've always been using custom component Composite by Phil Bruckner that made those pesky trackers way more reliable than person entity with several GPS and network trackers.
Might be worth the trouble to see how that is done, now you are discussing the new workings of this template tracker?