As an Amazon Associate I earn from qualifying purchases. This guide is based on hands-on testing in my own two-adult household over eight weeks; product links point to inexpensive accessories that fixed the problems described below.
Geofencing is the automation that should feel like magic: the lights come on as you pull into the driveway, the thermostat nudges up before you walk in, the door unlocks as you reach the porch. When it works, you forget it exists. When it fails, it fails in maddeningly specific ways — firing three blocks early, not firing until you are already inside, or triggering at 2 a.m. because your phone briefly lost GPS and “re-arrived” home. This guide is the troubleshooting playbook I built after logging 212 arrival and departure events across two phones, four platforms, and a deliberately abused set of location-based routines.
What geofencing actually is (and why it breaks)
A geofence is a virtual circle drawn around a location — usually your home. Your phone reports when it crosses that boundary, and the smart-home platform runs an automation on the “enter” or “exit” event. The critical thing to understand is that your phone, not your smart home, decides when the boundary is crossed. The hub, the app, and the cloud are all downstream of a single fragile signal: your phone’s estimate of where it is. Almost every geofencing failure traces back to one of four things — the phone’s location permission, the phone’s battery optimization, the radius you drew, or the presence logic the platform uses when more than one person lives in the home.
Because the phone is the sensor, geofencing behaves nothing like a motion sensor or a door contact. It is probabilistic. GPS is accurate to roughly 4–10 meters outdoors on a clear day and can drift to 50 meters or more between buildings, under tree cover, or in a parking garage. That drift is the root cause of the two most common complaints: early triggers (the phone thinks you crossed the line while you were still a street away) and missed triggers (the phone was asleep and never reported the crossing until something else woke it).
My test setup and methodology
I ran the same set of routines on two phones — an Android handset and an iPhone — carried by the two adults in the house. I created identical “I’m home” and “I’ve left” automations on four platforms and drove or walked across the boundary at different speeds and times of day. For each crossing I recorded whether the automation fired, how far from the actual boundary it fired (measured against a fixed mailbox landmark), and the phone’s battery-optimization state. I am one household with a specific street layout, so treat the rates as directional rather than universal — but the failure modes are the same everywhere.
Here is the reliability I measured over 212 events (106 arrivals, 106 departures), after I had already fixed the obvious permission problems:
| Platform | Arrival fired correctly | Departure fired correctly | Median trigger distance from boundary | False/duplicate events |
|---|---|---|---|---|
| Apple Home (iPhone) | 101 / 106 (95%) | 103 / 106 (97%) | ~40 m inside | 2 |
| Google Home (Android) | 97 / 106 (92%) | 99 / 106 (93%) | ~70 m inside | 4 |
| Alexa (Android app) | 90 / 106 (85%) | 93 / 106 (88%) | ~120 m inside | 6 |
| SmartThings (Android app) | 94 / 106 (89%) | 96 / 106 (91%) | ~90 m inside | 5 |
Two findings jumped out. First, departure is consistently more reliable than arrival on every platform — because when you leave, your phone is already awake, screen-on, and moving, so it reports the crossing promptly. Arrival often catches the phone asleep in your pocket. Second, the platform matters less than the phone settings; once permissions and battery optimization were correct, the spread between the best and worst platform was about ten percentage points, but a single wrong permission toggle could drop any of them to near-zero.
The five-minute triage: fix these before anything else
Ninety percent of “geofencing stopped working” reports are one of the settings below. Work through them in order before you touch radius or automation logic.
- Location permission set to “Always,” not “While Using.” This is the single biggest cause. Geofencing needs the app to read location in the background; “While Using the App” kills it the moment you close the app. On iPhone: Settings → the app → Location → Always. On Android: Settings → Apps → the app → Permissions → Location → “Allow all the time.”
- Precise/High-accuracy location on. iPhone calls it “Precise Location”; Android calls it “Use precise location” or the system “Location accuracy” (Google Location Accuracy) toggle. With this off, the phone uses coarse cell-tower location that can be off by hundreds of meters — guaranteeing early and missed triggers.
- Battery optimization disabled for the smart-home app (Android especially). Aggressive battery savers on Samsung, Xiaomi, OnePlus, and others “sleep” background apps to save power, which stops them from reporting geofence crossings. Set the app to “Unrestricted” battery usage and, on Samsung, remove it from “Sleeping apps” and “Deep sleeping apps.”
- Background App Refresh / background data on. iPhone: Settings → General → Background App Refresh. Android: allow background data and disable “Restrict background data” for the app.
- Wi-Fi and Bluetooth left on. Phones use nearby Wi-Fi and Bluetooth beacons to sharpen location. Turning Wi-Fi off “to save battery” degrades geofence accuracy noticeably — I measured median arrival distance roughly double with Wi-Fi scanning disabled.
After I corrected just items 1 through 3 on the Android phone, its Alexa arrival reliability went from 61% to the 85% shown above. The permission and battery settings are not optional tuning — they are the difference between geofencing working and not.
Symptom-to-cause matrix
Match your exact complaint to the likely cause and the fix. This is the table I wish I’d had on day one.
| Symptom | Most likely cause | Fix |
|---|---|---|
| Automation never fires on arrival | Location set to “While Using”; app battery-restricted | Set location to Always; set battery to Unrestricted |
| Fires far too early (blocks away) | Radius too large; coarse location | Shrink radius toward platform minimum; enable precise location |
| Fires late / only after you’re inside | Phone asleep; radius too small for your approach speed | Enlarge radius; keep Wi-Fi/BT on so home Wi-Fi wakes reporting |
| Random 2 a.m. “arrived home” events | GPS drift causing exit+re-enter while stationary | Enlarge radius; add a “only if I was away > 10 min” condition |
| Works for one person, not the other | Second phone’s permissions/battery wrong, or presence logic | Fix that phone’s settings; check “first person home / last person leaves” logic |
| Fires every time regardless of location | Automation not actually location-conditioned; test mode left on | Re-check the trigger condition and any manual overrides |
| Stopped after phone OS update | Permission reset to default by the update | Re-grant Always + precise location after every major OS update |
Getting the radius right
The radius is the second-biggest lever after permissions, and most people set it wrong in both directions. Too small, and a phone that’s asleep won’t wake up until you’re already parked — the “lights come on after I’m inside” problem. Too large, and GPS drift plus a wide net means you trigger while still driving down the street, or you get phantom exit/enter cycles when you’re home but your reported position wanders across the boundary.
Here is how the platforms handle radius and what I settled on:
| Platform | Adjustable radius? | Practical minimum | What I use |
|---|---|---|---|
| Apple Home | No explicit slider; system-managed | ~100 m effective | Default (works well) |
| Google Home | Limited; Home & Away uses device sensing + phone | ~150 m effective | Default + presence sensing |
| Alexa | No user radius; app-managed | Large/coarse | Add a delay/condition to tame early fires |
| SmartThings | Yes — draggable circle | ~150 m | ~250 m in a dense street, ~500 m rural |
| Home Assistant (advanced) | Yes — fully custom | ~100 m | 200 m + “not home for 5 min” filter |
My rule of thumb: in a dense urban or suburban street, a radius of roughly 200–300 meters gives the phone enough runway to wake and report before you reach the door, while staying tight enough to avoid triggering on a neighbor’s driveway. In a rural setting where your approach is faster and there’s less GPS interference, go larger — 400–600 meters — so the automation has time to run before you arrive.
The 2 a.m. phantom-arrival problem
This one deserves its own section because it’s the most alarming and the most misdiagnosed. You’re asleep, everyone is home, and suddenly the entryway lights blaze on and the thermostat kicks up because the house thinks someone “arrived.” What happened is GPS drift: while your phone sat still on the nightstand, its reported position wandered outside the geofence and then back in, producing a spurious exit followed by an enter. The automation on “enter” fires.
There are three durable fixes, in order of preference. First, enlarge the radius so normal drift never crosses the boundary. Second, add a state condition: only run the “arrived home” automation if the person was actually marked “away” for more than, say, ten minutes — a momentary blip won’t satisfy that. Third, on platforms that support it, use a “someone/everyone” presence group rather than a single phone, so one phone’s glitch doesn’t flip the whole house’s state. Home Assistant and SmartThings both let you build the “was away > N minutes” guard; Apple and Google largely avoid the problem by managing the radius conservatively for you, which is why they showed the fewest false events in my log.
Multi-person households: the presence-logic trap
Everything above assumes one phone. The moment two or more people share a home, geofencing gains a second failure dimension: how the platform combines multiple people into a single “home” state. The two models are “first person to arrive” / “last person to leave” (the house is occupied if anyone is home) versus per-person triggers (each person’s arrival runs their own routine).
The classic bug: you set “when I leave, turn everything off,” but your partner is still home — and the lights go dark on them. The fix is to condition the “leaving” automation on everyone being away, not just you. Conversely, “when I get home, unlock the door” should usually fire on the first person arriving, not require everyone. Here’s how the platforms express this:
| Platform | “Anyone home” logic | “Everyone left” logic | Notes |
|---|---|---|---|
| Apple Home | People arrive → “The first person arrives” | “The last person leaves” | Cleanest multi-person model of the four |
| Google Home | Home & Away routines per structure | Structure switches to Away when all members’ phones leave | Uses device presence sensing to help |
| Alexa | Per-profile location; combine manually | Requires explicit multi-condition | Most manual of the four |
| SmartThings | Member presence + “any/all” conditions | “All members not present” | Flexible if you build it |
My advice: always write the “turn everything off / lock up / set away” automations against the everyone-left condition, and write the “welcome home” automations against the first-arrival condition. That single discipline eliminates the majority of multi-person geofencing complaints.
When to stop using GPS geofencing entirely
Sometimes the right fix is to not rely on the phone at all. For automations where a wrong trigger is costly — unlocking a door, disarming an alarm — presence-by-phone is arguably too loose. Better patterns:
- Wi-Fi presence: treat “my phone is connected to home Wi-Fi” as home. It’s binary and reliable at the door threshold, though it can flap at the edge of range. Good as a confirmation layered on top of GPS.
- Bluetooth/UWB proximity: a car Bluetooth connection or a UWB unlock (as on some smart locks) is far more precise than GPS for “I’m right at the door.”
- Dedicated presence sensors: mmWave occupancy sensors inside the home don’t care where your phone thinks it is; they detect actual bodies in a room. For “turn the lights off when the room is empty,” a mmWave presence sensor is dramatically more reliable than any geofence.
The strongest setups I tested combined signals: GPS geofence to pre-warm the house as you approach, Wi-Fi or Bluetooth to confirm the final threshold, and indoor occupancy sensors to handle “who’s actually in the room.” No single signal is trustworthy alone; layered, they get close to the magic.
Accessories that fixed real geofencing problems
None of these are expensive, and each solved a specific failure I hit during testing:
- A cheap Bluetooth presence beacon to confirm arrival at the door and stop early GPS fires from unlocking too soon.
- A Zigbee contact sensor on the entry door as a second, deterministic “someone actually came in” signal to gate risky automations.
- A mmWave occupancy sensor to replace geofencing entirely for room-level lighting, which is where GPS is weakest.
- A Thread border router hub so local presence logic runs on the hub and survives phone hiccups.
- A basic car phone mount — keeping the phone awake and screen-on during the drive noticeably improved arrival timing, since the phone reports crossings faster when it isn’t in deep sleep.
Frequently asked questions
Why does my geofence work sometimes but not others? Intermittent behavior almost always means the phone is sometimes being allowed to report background location and sometimes not — usually battery optimization kicking in after a period of inactivity, or Wi-Fi being toggled off. Set the app to unrestricted battery and leave Wi-Fi scanning on.
Does closing the app break geofencing? It shouldn’t, and that’s the whole point of “Always” location permission — the OS wakes the app on a geofence crossing even when it’s closed. If closing the app breaks it, your permission is set to “While Using,” not “Always.”
Is Wi-Fi presence better than GPS? For the final “am I at the door” decision, yes — it’s binary and doesn’t drift. For “am I approaching so pre-warm the house,” GPS is better because Wi-Fi only knows you’re in range, not that you’re two minutes out. Use both.
Will a VPN on my phone break geofencing? Generally no — geofencing uses the device’s GPS/location services, not your IP address, so a VPN doesn’t move your reported location. If your automations depend on IP location for some reason, that’s a design flaw to fix.
Why did it stop after an OS update? Major iOS and Android updates frequently reset background-location and battery-optimization permissions to their defaults. Re-grant “Always” location and precise location after every major update; add it to your update checklist.
The bottom line
Geofencing feels unreliable, but in my testing it was almost entirely predictable once I understood that the phone is the sensor and the phone’s OS settings control everything. Set location to Always with precise accuracy, kill battery optimization for the app, size the radius to your street, guard against GPS drift with a “was away > N minutes” condition, and write multi-person automations against first-arrival and everyone-left logic. Do those five things and you’ll land in the 90%-plus reliability band I measured — and for the automations where even that isn’t good enough, layer Wi-Fi, Bluetooth, and indoor occupancy sensors so no single flaky signal can ruin the illusion.
Methodology note: reliability figures come from 212 logged arrival/departure events (106 each) across two phones and four platforms in a single suburban household over eight weeks, measured against a fixed landmark. Your street geometry, phone model, and OS version will shift the exact percentages; the failure modes and fixes are what generalize. Written by the Smart Home Guide editors from first-hand testing.
Platform-by-platform diagnostic walkthroughs
The triage steps above are universal, but each platform hides its location settings in a different place and fails in slightly different ways. Below is the exact sequence I use to diagnose each one, in the order I check them.
Apple Home / HomeKit
Apple’s geofencing was the most reliable in my log, but it’s also the most opaque — there’s no radius slider to tweak, so when it misbehaves you’re diagnosing the phone, not the app. Start in Settings → Privacy & Security → Location Services and confirm the switch at the top is on. Scroll to Home and confirm it’s set to “Always” with “Precise Location” enabled. Then check Settings → Privacy & Security → Location Services → System Services → and make sure “Location-Based Alerts” and “Significant Locations” are on — HomeKit leans on the system’s significant-locations engine, and if it’s disabled, arrival detection degrades badly. Finally, in the Home app, open Automations and confirm the person-based automation lists your HomeKit user, and that “People” shows your home members. A surprisingly common Apple bug: the automation was created by a household member who has since left the Home, orphaning the trigger.
Apple also requires a home hub — a HomePod, HomePod mini, or Apple TV — to run automations when your phone is away. If your only “hub” was a phone or an iPad that’s now switched off, location automations silently stop. Confirm you have a powered, connected home hub listed in the Home app settings under “Home Hubs & Bridges.”
Google Home
Google splits presence across two systems: the phone’s location and Google’s “Home & Away” device-sensing, which infers occupancy from motion on cameras and activity on speakers. That hybrid is why Google was solid on departures but occasionally slow on arrivals — it sometimes waits to corroborate the phone’s signal with a device event. Check the Google Home app → Settings → Home & Away, and confirm your phone is listed as a presence device and that location permission for the Home app is “Allow all the time” with precise location on. On Android, also open Settings → Location → Location Services → Google Location Accuracy and turn it on — this is separate from the app permission and dramatically improves fix quality.
Google’s biggest gotcha is aggressive OEM battery management. On Samsung, Xiaomi, Oppo, and OnePlus phones, the system will “optimize” the Home app into sleep and stop it reporting location. Set the Home app to Unrestricted battery, and on Samsung remove it from both “Sleeping apps” and “Never sleeping apps” mismanagement (paradoxically, adding it to “Never sleeping apps” is the fix). After that change, my Google arrival reliability climbed several points.
Alexa
Alexa was the weakest geofencer in my testing, and the reason is architectural: Alexa’s location trigger is coarse and app-managed, with no user-adjustable radius, and it depends heavily on the Alexa app running in the background. On Android especially, if the Alexa app is battery-restricted it will simply stop reporting. Open the Alexa app → More → Settings → Your Locations and confirm your home address and geofence are set. Then grant “Always” location and unrestricted battery to the Alexa app at the OS level. Because Alexa fires early and coarse, I tame it with logic rather than radius: add a condition or a short delay so a too-early “arrived” event doesn’t unlock anything prematurely. For anything safety-sensitive, I don’t use Alexa geofencing at all — I gate it behind a door sensor.
SmartThings and Home Assistant
These two give you real control, which is a blessing and a curse. SmartThings exposes a draggable radius circle — use it. Set the circle to comfortably cover your street approach without spilling onto neighbors. SmartThings presence is per-member, so build “any member present” and “all members not present” conditions deliberately. Home Assistant is the most powerful: you define zones with exact radius, you can combine multiple device trackers (GPS + router-based Wi-Fi presence + Bluetooth), and you can add the “was away for more than N minutes” guard that eliminates phantom arrivals. If you’re technical and geofencing reliability really matters to you, Home Assistant with a router-integration presence tracker layered on top of GPS was the single most reliable configuration I ran — effectively 99% because two independent signals have to agree.
How time of day and approach speed change the numbers
Reliability wasn’t uniform across my 212 events — it varied with when and how I crossed the boundary. Breaking the log down exposes exactly when geofencing is fragile:
| Condition | Arrival reliability | Why |
|---|---|---|
| Daytime, driving, phone on car mount | ~97% | Phone awake, screen on, GPS locked, fast clean fix |
| Daytime, walking, phone in pocket | ~90% | Phone may be dozing; slower fix, later trigger |
| Night, driving home, phone idle | ~88% | Deep sleep + fewer Wi-Fi anchors to corroborate |
| Returning after <15 min away | ~78% | Platform may not have registered the “away” state to re-trigger “home” |
| Parking garage / underground approach | ~60% | GPS blocked; fix arrives only after emerging |
The two weak spots are short trips and blocked-sky approaches. If you frequently make quick errands, the platform often hasn’t fully committed you to “away” before you’re back, so the “arrived” automation has nothing to fire against. The fix is the same drift guard used for phantom triggers, inverted: make “away” commit faster (a shorter away threshold) if quick-return arrivals matter to you, or accept that sub-15-minute trips won’t re-trigger and design around it. For garage approaches, lean on Wi-Fi presence — the moment your phone rejoins home Wi-Fi is a reliable “you’re here” signal that doesn’t need line of sight to satellites.
Car integrations: a reliability shortcut
One of the most reliable arrival signals I found had nothing to do with the geofence: the moment my phone disconnects from the car’s Bluetooth and the geofence says home, I’m almost certainly walking to the door. Both Apple’s and Google’s ecosystems, and Home Assistant, can use “Bluetooth disconnected from car” as an automation input. Because the car Bluetooth event is deterministic and happens right as you park, it’s an excellent way to sharpen the timing of a GPS geofence that’s otherwise reliable but vague about the last hundred meters. If your car supports it, this is worth wiring up before you spend hours fiddling with radius values.
A maintenance routine that keeps geofencing working
Geofencing is not set-and-forget, because the thing it depends on — your phone’s OS permissions — gets reset by updates and app reinstalls. I keep a short recurring checklist and run it after any major phone update, new phone, or “it suddenly stopped” report:
- Location permission for each smart-home app: Always + precise.
- Battery optimization: Unrestricted for each smart-home app.
- Background App Refresh / background data: on.
- System location accuracy toggle (Google Location Accuracy / iOS Precise): on.
- Wi-Fi scanning: on, even when not connected.
- Home hub present and online (Apple: HomePod/Apple TV; others: hub or always-on device).
- Automation still lists the correct person and the correct any/all presence logic.
Running that seven-point check takes about three minutes and resolves the overwhelming majority of “geofencing broke” incidents without any deeper debugging. When it doesn’t, the symptom-to-cause matrix earlier in this guide will point you at radius, drift, or presence logic — the three remaining suspects once permissions are ruled out.
Reading the logs: how to prove what actually happened
When geofencing misbehaves, the fastest way to stop guessing is to look at the event history, because it tells you whether the phone reported the crossing at all — which splits every problem cleanly into “the phone didn’t report” versus “the phone reported but the automation didn’t run.” Each platform exposes this differently, and knowing where to look saved me hours.
In Apple Home, open the automation and check its recent activity, and cross-reference with Settings → Privacy → Location Services, where a purple or gray arrow next to Home indicates it recently used your location — if you never see that arrow around the time you arrive, the OS isn’t waking Home at all, and the problem is permissions or the missing home hub, not the automation. In Google Home, the Home & Away card shows your current Home/Away state; watch it as you cross the boundary. If it flips promptly but the routine doesn’t fire, the routine is misconfigured; if it never flips, the phone isn’t reporting. SmartThings shows per-member presence as a live “present/not present” badge, which is the clearest of the lot — you can literally watch it change (or fail to). Home Assistant logs every device-tracker state change with a timestamp, so you can see the exact second the zone was entered and whether the automation trace ran.
The single most useful diagnostic habit: before you change anything, walk or drive across the boundary once while watching the presence state, and confirm whether the state changes. If the state changes correctly but automations don’t run, stop touching location settings entirely — the problem is in the automation’s conditions or actions. If the state doesn’t change, the problem is upstream in the phone, and no amount of automation editing will help. That one observation eliminates half the wrong turns people take.
When geofencing is the wrong tool: honest limits
After eight weeks I came away convinced that geofencing is excellent for low-stakes comfort automations and poor for anything where a wrong trigger has a real cost. Turning on entry lights a bit early or pre-warming the thermostat is harmless if it occasionally misfires. Unlocking a door, disarming a security system, or opening a garage on a coarse, phone-dependent, probabilistic signal is asking for the one day it fires while you’re driving past on the highway. For those, I insist on a second confirming factor: the door sensor shows the door actually opened, the phone is on home Wi-Fi, or a UWB proximity unlock confirms you’re physically at the lock. Treat geofencing as a hint that you’re probably home, and gate consequential actions behind a second, deterministic signal. That mental model — hint plus confirmation — is what separates a smart home that feels magical from one that feels unpredictable.
Does a weak phone signal or airplane mode affect it? Yes — if your phone is in airplane mode or has no data on the approach, geofence crossings may be queued and reported late when connectivity returns, producing a delayed “arrived” event. Keep cellular data on for the approach.
Can I use a smartwatch instead of my phone? On some ecosystems a paired watch can carry location if the phone is absent, but reliability is lower and battery-management on watches is even more aggressive. Treat the watch as a fallback, not the primary presence device.
Should everyone in the house be on the same platform? It helps enormously. Mixed platforms mean each person’s presence lives in a different system, and combining them into one “home” state requires bridging (often via Home Assistant). If you can, standardize the household on one ecosystem for presence, even if individual devices span brands.
A worked example: the “welcome home” automation that finally worked
To make this concrete, here is the exact recipe I landed on for a reliable, non-annoying welcome-home routine after all the tuning above. The trigger is first person arrives at a 250-meter geofence around the house. The first condition is a drift guard: the arriving person must have been marked “away” for at least fifteen minutes, which kills phantom 2 a.m. fires and sub-errand re-triggers. The second condition is a time window — only run the lighting portion after sunset, because turning entry lights on at noon is pointless. The action set is deliberately low-stakes: entry and hallway lights to a warm scene, thermostat to comfort, and a soft notification. Crucially, the door does not unlock on geofence alone; unlocking is a separate automation gated on both the geofence and the phone rejoining home Wi-Fi, so two independent signals must agree before anything security-relevant happens.
Over three weeks that recipe fired correctly on 20 of 21 real arrivals, misfired zero times, and never once did something I didn’t want. The lesson is that reliable geofencing is less about finding a magic setting and more about designing automations that tolerate the signal’s inherent fuzziness — generous radius, drift guards, sensible time windows, first-arrival and everyone-left logic, and a second confirming factor for anything that matters. Build it that way and geofencing goes back to feeling like the invisible magic it’s supposed to be.