Minimum accuracy/score filter

[indykoning]

I'm surprised the integration works so well with little effort!
I'm using V1.7 and i've noticed with the update that min_accuracy_threshold is no longer in use.
With that i'm seeing some of my devices report on the other side of town with an accuracy of ~400m

I also know there's a score attribute which mixes accuracy and age.

Is there any way or are there any plans to re-introduce the feature to ignore reports over a certain accuracy or score in V1.7?

I would be prepared to take a stab and open a PR if need be.

[indykoning]

This is the worst I've gotten, that's a 3 hour drive on the other side of the country. I have verified that the find my hub itself did indeed claim it was there at the time as well. But the accuracy was massive

[Dahaniel]

I've noticed the same thing lately, trackers have been jumping around for weeks. Card filtering helps the UI, but it doesn't fix the automation issue.

@indykoning, could you file an issue? You probably have a better handle on this than I do.

[jleinenbach]

Hi @indykoning, @Dahaniel (and everyone following this),

Quick update: a fix for these "jumping around" reports is prepared and landing in the upcoming 1.7.14 release. Before it ships, here is why we did not simply bring back a minimum accuracy/score filter, and what we did instead.

Why an accuracy/score threshold does not fix this

Accuracy is not what separates a real fix from a bad one here. The bad locations come from the crowd-sourced Find My Device network, and those reports can arrive with a perfectly good (small) accuracy radius and still place the device on the other side of town or the country. An accuracy filter would happily let those through: they look precise, they are just wrong.

It also fails the other way around. For some crowd reports the accuracy value is stripped out entirely, so a threshold has nothing to test in exactly the noisiest cases. And a hard threshold throws away legitimate coarse fixes too (a real position that simply has a large radius), so you lose good data and still have to hand-tune a number per device.

In short, an accuracy filter is both leaky (it misses precise-looking teleports) and lossy (it drops real data). That is why removing it did not "break" tracking, and why adding it back would not fix these jumps.

What we do instead: detect the jump, not the accuracy

The fix works on physics, at the code level, with no configuration to tune:

• Kinematic speed gate. For every new report we compute the implied speed from your last known position: distance divided by time. If landing there would require a physically impossible speed (hundreds of km in a few minutes), we reject it as a teleport, no matter how "accurate" it claims to be. Genuinely fast travel (car, train, plane) stays under the physical limit and is kept.
• Round-trip detection. The typical crowd glitch is A -> B (far away) -> A (back). We now recognize that echo pattern and do not let a brief excursion overwrite your real position. This also covers trackers shared across several accounts, so a corrected location is not quietly rolled back for one of them.

So a location that is precise but impossible gets rejected, and a location that is coarse but plausible is kept. That is the opposite of what an accuracy filter does.

Please help us confirm it

Once 1.7.14 is available, please update, then restart Home Assistant, and watch the trackers that were jumping. If you still see a jump, please come back here with fresh logs and a screenshot of the map, ideally showing the timestamp and the wrong location next to where the device actually was. Real data from your setups is exactly what we need to close the remaining edge cases.

How likely is this to fix it?

My honest, calibrated estimate: roughly 75-80% that this removes the large jumps described in this thread (the town- and country-scale teleports). Those are exactly what the speed gate and round-trip detection are built to catch.

The remaining ~20-25% is the harder residual class: a wrong crowd location that happens to be close enough and slow enough to look physically plausible, and that does not bounce back. Pure physics cannot catch that kind of slow drift, and your logs will tell us how often it actually occurs in the wild. I would rather give you a realistic number than promise a silver bullet, and then tighten it further based on what you report.

Thanks for the detailed reports, they are what made a targeted fix possible.

---

Written by the AI assistant that helped design and review this fix, posted on the maintainer's behalf.

[jleinenbach]

A quick, data-backed note on why a minimum accuracy/score filter is the wrong axis for the crowd-sourced teleport problem.

What the accuracy number actually measures

gps_accuracy (and the score, which just blends accuracy and age) describes how well the stranger's finder phone located itself by GPS at the moment it heard your tag. It is that phone's own GPS quality. It carries no information about the two things that actually cause a bad crowd fix:

• the distance between the tag and that finder phone, which is the BLE link range and never appears in the data;
• whether the report's position and timestamp line up with where your tag actually was over the last interval.

So a fix can be genuinely precise about the finder's own position, sit far from your last known location, and still be wrong for your tag. Not because the phone mislabeled anything, but because a nearby-enough finder with very good reception (and possibly a slightly off clock) pins a confident coordinate that the accuracy number has no way to flag. The value is precise about itself and silent about the only question we care about: was the tag really there.

Why a threshold fails in both directions (measured, not assumed)

I looked at ~230k published FMDN fixes from one user's Home Assistant recorder database, split by own-report vs. crowd, crossed with distance from home:

• Leaky: the dangerous fixes are the far-away ones that claim to be precise. The worst single example is a fix ~61 km from home reporting 3 m accuracy. Any "reject if accuracy > N" threshold waves those straight through, because they look precise.
• Lossy: a "reject > 300 m" filter would touch only ~0.5% of crowd fixes, and precisely the honest-but-coarse ones the system already flags as rough, not the confidently-wrong jumps.

An accuracy threshold therefore attacks the points that admit they are unsure and misses the ones that are sure and wrong.

What actually separates good from bad here

Two physical signals, neither of which is accuracy:

1. Speed: reject a fix if reaching it from the last known position would require an impossible speed. This catches town- and country-scale teleports.
2. Corroboration for isolated jumps: a location far from the last accepted position is held back one cycle and only accepted once a second, consistent fix confirms it; a lone spike that bounces straight back ("A -> far -> A") is dropped. On this dataset that catches every such spike without losing a single real travel point, at the cost of one cycle of delay on a genuine trip start. The trigger has to be the spatial jump, not accuracy: of the eight such spikes in this log, half carried a precise accuracy and would slip past any accuracy-based trigger. Accuracy can ride along only as a secondary weakness weight (a fix that is both far and self-declared coarse is doubly weak), never as the gate itself.

Honest limit: pure physics still cannot catch a wrong crowd location that is close enough and slow enough to look plausible and does not bounce back. That is the residual class, and real logs are what tell us how often it actually occurs.

Written by an AI assistant that analyzed this on real recorder data, posted on a user's behalf.

[indykoning]

Exactly, no programming can perfectly fix shoddy location data. You will always have some jumping around even if the tag is stationary. Since devices do not account for Bluetooth range and direction, and cannot account for GPS accuracy.

But that is all very close and these solutions sound like they should deal with the more annoying incorrect location data (making this integration much better to use than googles own find my app 😂)