60 Location Awareness: Context and Geofencing

60.1 Start With the Decision

A geofence event can arrive late or fire near a boundary. Context logic must handle uncertainty before it changes a user workflow.

60.2 Route Overview

This is part 3 of 3. Review Location Awareness: Technology Tradeoffs for the preceding evidence.

60.3 Learning Objectives

• Design entry and exit rules with boundary hysteresis.
• Test context and geofence events against user needs.

60.4 Chapter Roadmap

• MVU: Context Detection and Geofencing
• Key Takeaway
• Cross-Hub Connections
• Code Example: Geofence Trigger Engine
• Indoor Positioning Cost Tradeoffs
• Geofencing Needs Dwell Time
• Checkpoint: Tune the Fence
• Interactive Quiz: Match Concepts
• Interactive Quiz: Sequence the Steps
• Knowledge Check
• Quiz: Location Awareness Fundamentals
• Concept Relationships
• See Also
• In 60 Seconds
• Try It Yourself
• Checkpoint: Validate in the Field
• Common Pitfalls
• Overbuilt Initial Prototypes
• Security During Development
• Failure Modes and Recovery
• Label the Diagram
• What’s Next
• Code Challenge

60.5 Code Example: Geofence Trigger Engine

This Python class implements circular geofencing with dwell-time filtering, the core pattern behind smart home automations like “turn on lights when I arrive home.” The dwell-time requirement prevents false triggers from driving past a location:

import math
import time

class GeofenceEngine:
    """Circular geofence with dwell-time to prevent false triggers.

    Uses the Haversine formula for GPS distance calculation and
    requires the device to remain inside/outside the fence for a
    minimum dwell period before firing the trigger.
    """
    def __init__(self):
        self.fences = {}
        self.state = {}  # fence_name -> {inside, entered_at}

    def add_fence(self, name, lat, lon, radius_m, dwell_sec=30):
        """Register a circular geofence.

        Args:
            name: Fence identifier (e.g., "home").
            lat, lon: Center coordinates in decimal degrees.
            radius_m: Fence radius in meters (100-150m recommended
                      for GPS to avoid false triggers).
            dwell_sec: Minimum seconds inside/outside before trigger.
        """
        self.fences[name] = {
            "lat": lat, "lon": lon,
            "radius": radius_m, "dwell": dwell_sec
        }
        self.state[name] = {"inside": False, "changed_at": 0}

    def _haversine_m(self, lat1, lon1, lat2, lon2):
        """Calculate distance between two GPS points in meters."""
        R = 6371000  # Earth radius in meters
        phi1, phi2 = math.radians(lat1), math.radians(lat2)
        dphi = math.radians(lat2 - lat1)
        dlam = math.radians(lon2 - lon1)
        a = (math.sin(dphi / 2) ** 2 +
             math.cos(phi1) * math.cos(phi2) *
             math.sin(dlam / 2) ** 2)
        return R * 2 * math.atan2(math.sqrt(a), math.sqrt(1 - a))

    def update(self, lat, lon, timestamp=None):
        """Process a GPS fix and return any triggered events.

        Args:
            lat, lon: Current device position.
            timestamp: Unix timestamp (defaults to now).

        Returns:
            List of (fence_name, event_type) tuples where
            event_type is "enter" or "exit".
        """
        if timestamp is None:
            timestamp = time.time()

        events = []
        for name, fence in self.fences.items():
            dist = self._haversine_m(lat, lon, fence["lat"],
                                      fence["lon"])
            currently_inside = dist <= fence["radius"]
            state = self.state[name]

            if currently_inside != state["inside"]:
                # Position changed -- start dwell timer
                if state["changed_at"] == 0:
                    state["changed_at"] = timestamp
                elif timestamp - state["changed_at"] >= fence["dwell"]:
                    # Dwell time met -- confirm transition
                    event = "enter" if currently_inside else "exit"
                    events.append((name, event))
                    state["inside"] = currently_inside
                    state["changed_at"] = 0
            else:
                state["changed_at"] = 0  # Reset if bounced back

        return events

# Usage: Smart home automation
engine = GeofenceEngine()
engine.add_fence("home", lat=51.5074, lon=-0.1278,
                 radius_m=120, dwell_sec=30)
engine.add_fence("office", lat=51.5155, lon=-0.1419,
                 radius_m=150, dwell_sec=60)

# Simulate arriving home (30+ seconds inside fence)
events = engine.update(51.5075, -0.1279, timestamp=1000)
# No events yet (dwell timer started)
events = engine.update(51.5074, -0.1277, timestamp=1035)
# Returns: [("home", "enter")] after 35 seconds inside

Design decisions for reliable geofencing:

60.6 Indoor Positioning Cost Tradeoffs

One of the most common mistakes in location-aware IoT projects is over-specifying accuracy. A hospital that needs to know which room a wheelchair is in (3-meter accuracy) does not need centimeter-precise UWB tracking. The cost difference is dramatic.

Real-world deployment cost comparison for a 10,000 m2 building (e.g., a hospital floor):

Decision framework — match accuracy to actual need:

The 80/20 rule for indoor positioning: 80% of indoor location use cases are satisfied by room-level accuracy (3-5 meters). Only 20% truly need sub-meter precision. Starting with BLE beacons at $4,600 and upgrading later if needed is almost always better than deploying $50,000 UWB infrastructure and discovering that room-level was sufficient.

Hidden costs to budget for:

The 3-year TCO difference between BLE and UWB can be 5-7x. For a hospital with 200 tracked assets, that means spending $55 per asset per year (BLE) versus $350 per asset per year (UWB). Choose the accuracy your application actually needs, not the accuracy that sounds impressive in a vendor demo.

# BAD: No dwell time
if distance < fence_radius:
    trigger_arrived_home()  # Fires on any GPS spike inside fence

# GOOD: 30-second enter dwell, 45-second exit dwell
if distance < fence_radius:
    if not currently_inside:
        start_dwell_timer('enter', 30)  # Must stay inside for 30s
    elif dwell_timer_expired('enter'):
        trigger_arrived_home()  # Only fires after 30s inside
else:
    if currently_inside:
        start_dwell_timer('exit', 45)  # Must stay outside for 45s
    elif dwell_timer_expired('exit'):
        trigger_left_home()  # Only fires after 45s outside

Checkpoint: Tune the Fence

You now know:

• GPS accuracy of 5-15 meters makes immediate geofence triggers unreliable near boundaries.
• Home automation usually needs a 100-150 meter radius plus 30-60 second enter dwell and longer exit dwell.
• Field testing should measure false arrivals, false departures, battery impact, support load, and user disablement.

60.7 Knowledge Check

Checkpoint: Validate in the Field

You now know:

• Exercises should compare the zone boundary, the displayed uncertainty, and the action the user expects.
• Battery tests matter because scan cadence can change whether a location feature is useful all day.
• A good rollout records enough evidence to explain false triggers without keeping unnecessary movement history.

60.8 What’s Next

Continue to GPS and Outdoor Positioning to learn how GPS satellites enable global positioning with 5-10 meter accuracy, including the physics of time-of-flight ranging and the challenges of multipath interference.

60.9 Continue Your Route

This final part closes the route from MVU: Context Detection and Geofencing through Code Challenge. Return to Location Awareness: Technology Tradeoffs or continue from the ux-design module index.