What Happens to Geofencing Accuracy When You Disable Google Location History

Geofencing accuracy is a measurable thing: when the Home Assistant companion app reports your phone crossing into its home zone, how far off is that event in space and time? Google Location History is a separate, account-level setting — the one that records where you have been into Google Maps Timeline. The two get conflated constantly, and the confusion matters on this site because most of us run local-first stacks — Home Assistant, Zigbee2MQTT, Z-Wave JS, ESPHome, MQTT — where a privacy cleanup on the phone side can land in the same month as a presence-detection problem on the hub side. When the porch lights stop greeting you the same week you flipped a Google toggle, the toggle becomes the obvious suspect. It is usually the wrong one. What follows separates what Location History actually controls from what actually moves your geofence events, with numbers, a two-week measurement procedure, and the honest cases where a plain switch or a mechanical timer is the better tool.

The Short Answer

Disabling Google Location History does not change geofencing accuracy on a typical Home Assistant install. The companion app’s zone tracking reads live location from the phone’s operating system — Google Play Services on Android, Core Location on iOS — not the historical record stored in your Google account. Location History writes to Google Maps Timeline. It is an archive, not a sensor. Turn it off and your geofence events keep firing with the same radius, the same GPS jitter, and the same exit lag as before.

Three things do change:

• Timeline stops recording trips. If you ever used Timeline to check where you were when a routine fired at 2 a.m., that debugging record is gone going forward.
• Anything that mined Timeline loses its source. Home Assistant has no native Timeline integration, but export scripts and third-party analyses of that history stop producing data.
• Your suspicions shift. A geofence that breaks in the same month as a privacy cleanup gets blamed on the cleanup, even when the real cause is battery optimization, an OS update, or a permission reset.

If presence broke the week you flipped the toggle, the toggle is a coincidence more often than a cause. The ranked failure-mode list below covers what I actually find when these reports come in.

What Location History Actually Controls

Timeline, not real-time location

Location History populates Google Maps Timeline — the day-by-day record of places visited. Two recent changes matter here: Google moved Timeline storage from its servers onto the phone itself (a change rolled out through 2024), and on accounts that never had the setting on, it stays off. Auto-delete windows of 3, 18, or 36 months still apply. Disabling the setting stops new Timeline entries; it does not revoke any app’s permission to see your live position, and it does not stop Google from recording location through other channels — Web & App Activity can still capture coarse location when you use Maps or Search. If the goal is “Google no longer knows where I go,” this one toggle does not get you there; Google’s own Location History documentation states plainly what keeps recording after the switch (Google support: Location History).

The phone settings that do affect your geofence

• Precise vs. approximate location (Android 12+). If the companion app holds only coarse permission, fixes can be off by 1–3 km. No radius tuning survives that.
• Wi-Fi and Bluetooth scanning. These feed network-based positioning indoors. Android throttles background Wi-Fi scans to roughly four per two-minute window; disabling scanning entirely pushes indoor fixes onto GPS alone, which under a roof means 20–100 m of error.
• Battery saver and Low Power Mode. Both platforms deprioritize background location work to extend runtime.
• OEM battery managers. Samsung’s, Xiaomi’s, and OnePlus’s app killers are the leading cause of dead geofences, full stop.

How the Phone Actually Fires a Geofence Event

Android: Play Services does the work

The companion app registers your Home Assistant zones with the OS-level geofencing service and receives callbacks; the fused location provider blends GPS, Wi-Fi, and cell signals into each fix. Ballpark figures from the field: GPS yields 5–10 m under open sky, Wi-Fi-based positioning typically lands 15–50 m, and a cell-tower-only fix ranges from 500 m to 2 km. Indoors, GPS alone is unreliable, which is why the phone leans on Wi-Fi scanning. The companion app’s own documentation covers the platform specifics (Home Assistant companion app location docs).

Latency is the part people underestimate. Android batches geofence callbacks to save power: entry events commonly arrive 10–60 seconds after the boundary crossing, while exit events routinely take 2–5 minutes, sometimes longer on quiet radios. Those are observed ranges from my logs and others’ reports, not guarantees — your OS version and radio environment set the real numbers.

iOS: Core Location region monitoring

The app uses region monitoring through Core Location, blending the same sources. Low Power Mode delays background updates, and iOS throttles or resets background location for apps it judges unused — re-check permissions after every major iOS upgrade.

Why radius matters more than any toggle

Home Assistant’s default home zone radius is 100 m, and that number is not decoration. GPS jitter inside a wood-frame house commonly runs 20–100 m, so a 30 m radius will flap in and out all evening. Below roughly 50 m, expect enter/exit loops; above 150 m, expect the “home” event to fire while you are still a block away. Radius is the control with the biggest payoff per unit of effort — tune it before blaming any account setting.

What Breaks, What Doesn’t, and What Was Already Broken

Ranked by how often each is the actual cause when someone reports “geofencing got worse”:

1. Battery optimization killed the companion app. The event never fires because the app was asleep. Exclude the app from battery management and re-verify after every phone OS update.
2. Location permission degraded to approximate. OS upgrades do this silently; it converts a 100 m geofence into a kilometer-scale guess.
3. Radius too small for the radio environment. Flapping, double triggers, lights that toggle themselves.
4. Wi-Fi or Bluetooth scanning disabled. A reasonable privacy or battery choice, but it moves indoor accuracy from tens of meters to worse-than-GPS.
5. Play Services or the companion app updated. Version drift changes behavior; read the release notes before assuming hardware failure.

The Location History toggle is not on the list because I have never seen a live companion-app geofence degrade from it. What I have seen break is Home Assistant’s Google Maps device tracker, which uses Google Maps location sharing — a different setting the toggle does not touch. That integration logs in as you and trips Google’s bot detection; long issue threads document repeated lockouts. It was flaky before the privacy cleanup and remains flaky after.

If the Goal Is Fewer Google Dependencies

Disabling Location History is a privacy decision, not a reliability decision. If the underlying goal is a presence chain with no cloud account in it, change the architecture instead of the setting.

OwnTracks and GPSLogger over MQTT

OwnTracks publishes phone location straight to your MQTT broker, with circular regions you define in the app; Home Assistant consumes the results as device_tracker entities with no Google account in the loop. GPSLogger (Android) does the same with user-set distance and frequency filters. The tradeoffs are real: on Android, network-based fixes still come from Play Services, so you remove the Google account, not the Google code; and publishing intervals trade battery against freshness. The OwnTracks documentation is candid about these limits (OwnTracks booklet).

BLE presence with ESPHome

An ESPHome node scanning for a BLE beacon on your keyring gives room-level presence with latency in seconds, and it works where GPS cannot get a fix at all — apartment blocks, basements, metal shops. The tradeoff is range: BLE confirms “inside the house,” not “approaching.” Pair it with a door sensor for arrival truth.

Router and AP trackers

UniFi, OpenWrt, and similar integrations mark a phone home when it associates to Wi-Fi. Cheap and fully local, but departure detection lags by the scan or lease interval — minutes, not seconds — and a phone that sleeps its Wi-Fi radio produces false “away” states overnight.

The pattern that works is hybrid: geofence as the far trigger (pre-heat, pre-cool, disarm), door sensor plus BLE as the near confirm (lights on when the door actually opens), and motion-plus-timer for shutdown instead of a departure geofence that lags by minutes.

And the concession: for loads where a wrong trigger costs money or safety — a space heater, an aquarium, a freezer — presence logic is the wrong tool regardless of accuracy. A $6 mechanical timer, a plain wall switch, or a dusk-to-dawn sensor does the job with no radio, no cloud, and no log to interpret. I have replaced more than one clever presence flow with a mechanical timer and slept better for it.

Measure Before and After: A Two-Week Procedure

Run this before you flip anything, and again after:

1. Baseline for two weeks. Let the logbook or recorder capture every zone transition, and keep a manual note of actual door-crossing times — a sticky note on the door frame is fine.
2. Compute three numbers: arrival lag (door opened to “home” event), exit lag (door closed to “away” event), and false transitions per week. On my install: arrival lag median 20–40 s with the geofence alone, under 5 s with the door-sensor confirm; exit lag 2–4 min, which is exactly why departure should not drive lights-off logic.
3. Change one variable. Disable Location History, or tune the radius — never both in the same window, or you learn nothing.
4. Rerun two weeks and compare. If the numbers are unchanged, the toggle was innocent, as expected. If they moved, you have a documented, reproducible regression instead of a hunch.
5. Write the result into your runbook with dates and phone OS versions. Presence behavior shifts with OS updates more than with settings; the date-stamped note is what tells you which changed.

This is the same one-variable-at-a-time discipline the audit procedure in How to Audit the Small Systems That Quietly Run Your Week applies to every other subsystem. Presence detection is just the one where people most often skip the baseline.

FAQ

Does disabling Google Location History break Home Assistant presence detection?

No. Companion-app geofencing reads live location through the phone’s OS location services; Location History is an account-level archive that writes to Google Maps Timeline. If presence breaks after the toggle, check battery optimization first and location permissions second — in that order.

Will Google Home “Home & Away” presence sensing still work without Location History?

Generally yes: presence sensing in the Google Home app runs on the location permission granted to that app, not on your Timeline archive. I have not verified every account configuration, so test it directly — toggle Location History off, leave the house, and watch whether the routine fires. A five-minute test beats any forum thread.

What radius should my home zone use?

Keep the 100 m default as a floor. Below about 50 m, GPS jitter causes enter/exit flapping in most residential radio environments; above about 150 m, “home” fires while you are still a block away. Size it from your own two-week log rather than from someone else’s forum post.

What is the most reliable presence setup with no Google dependency?

A hybrid: OwnTracks or GPSLogger publishing to your own MQTT broker for the far trigger, an ESPHome BLE node plus a door sensor for arrival confirmation, and a router or BLE drop for departure. Expect the departure side to be the slow one and design around it rather than fighting it.

Should I use geofencing at all, or is a schedule smarter?

It depends on the cost of a wrong trigger. For porch lights, a dusk-to-dawn sensor beats geofencing outright. For thermostat pre-heat on the drive home, geofencing earns its keep, because lead time is the whole point. If the failure mode is comfort, use a schedule; if it is money or safety, use a plain switch or a mechanical timer and keep presence logic out of the path.

Where This Goes Next

Presence detection is the most common reader question I get, and the answer is always a measurement, not a product. The next installment in this column covers exit-event latency in depth — why “away” is structurally slower than “home,” and how to design departure logic that tolerates the lag. If you run the two-week procedure above, send me your three numbers (arrival lag, exit lag, false transitions per week) with your phone model and OS version; anonymized results go into the follow-up so the ranges on this page stop being just mine. For the full subsystem walkthrough in the meantime, start with the audit procedure and treat your zones, trackers, and geofence callbacks as line items in the same runbook.