Skip to content

Build a Commute Context Logger Using Bluetooth, Wi-Fi, and Calendar Signals

7:15 AM. The engine is running, the windshield is fogging from the inside, and a time-tracking app sits open on the passenger seat waiting for a thumb that never arrives. By the time the defroster wins, the car is already two blocks from the driveway and the log entry is a guess.

That missed tap is the whole design brief. Manual tracking collapses precisely when the day is moving fastest, which is exactly when the data would be most honest. So the objective for this run of entries is narrow: build a mobility log that records departure and arrival without asking for anything.

Log Entry 01: The Friction of Manual Departure

The expedition format matters here. Rather than shipping one clever automation and declaring victory, this project runs as a sequence of dated entries — rig a trigger, live with it, note where it lies, adjust. Passive tracking earns trust slowly, and the only way to know whether a rule works is to let it fail on a Tuesday.

The schema stays deliberately thin. Each trip is stored as four fields: departure timestamp, arrival timestamp, trigger path, and confidence state. The trigger path is the field most people skip and later regret skipping, because when a record looks wrong six weeks on, the only useful question is which signal wrote it.

Evaluation window: five to seven scheduled workdays, and at least one of those days has to include a departure that shifts by thirty minutes or more. A rule set that only survives a metronomic routine is not a logger, it is a coincidence.

Log Entry 02: Rigging the Bluetooth Triggers

The car becomes the primary anchor for one reason: its Bluetooth connection event lands closer to actual departure than a calendar reminder or the slow fade of home Wi-Fi. Doors close, head unit wakes, phone bonds. That handshake is the most temporally accurate thing available without burning GPS.

On platforms that expose hardware identifiers, the rule matches a single bonded vehicle. This is the part worth being pedantic about.

  • Match one specific bonded vehicle identifier, not a device class.
  • Reject generic conditions such as "connected to any audio device" — that net catches headphones, a kitchen speaker, and a partner's soundbar.
  • Write the pending departure within 5 to 15 seconds of the connection event, while the timestamp still means something.

In iOS Shortcuts this lives as a personal automation keyed to the vehicle's Bluetooth connection; in Tasker it is a state-based profile rather than a task loop. The distinction is not cosmetic.

Anchor Signal Hygiene

Listen for connection events, not connection status. Scan loops that poll every 30 to 60 seconds wake the radio hundreds of times a day for information the operating system already broadcasts for free. The battery cost of a badly written trigger will end the experiment faster than any logging error.

Log Entry 03: Navigating Wi-Fi Handoffs and Calendar Beacons

Bluetooth establishes that the phone has joined the car. It says nothing about whether the car went anywhere. Corroboration comes from the network layer.

The rule waits for the saved home SSID to drop and the handset to fall back to cellular. Both transitions have to occur within 2 minutes of the vehicle connection, which is generous enough for a slow garage door and tight enough to exclude sitting in the driveway on a phone call.

Calendar handles the sanity check. Before the record is promoted from pending to real, the script checks two conditions: the timestamp falls inside a departure window of 5:30 AM to 10:30 AM, and a work event begins within 90 minutes before or after the Bluetooth event. A Saturday run to the hardware store fails both tests and never enters the dataset. This is the cheapest classifier in the entire stack — it costs nothing at runtime and removes an entire category of noise.

Image showing trigger_chain

Arrival closes the loop when the device associates with the office network and stays associated for 20 to 45 seconds. That dwell requirement exists because parking-lot edge coverage produces brief, flickering associations that would otherwise stamp an arrival while the driver is still looking for a space.

Arrival behavior turns out to be the most location-dependent piece of the system. Some office Wi-Fi associates from the far end of the lot, some only after the badge reader and two sets of doors, some never — a detail that reshapes the rule set more than any code change.

Log Entry 04: Weathering the Storm of False Positives

The first bad records showed up almost immediately. Walking through the garage while the car electronics were still awake produced a departure. Starting the engine for ninety seconds to read the odometer produced another. Neither trip existed.

The correction is a persistence threshold. Each Bluetooth connection stays in a pending state and only becomes a log entry once the link has held for three minutes. If the car disconnects before that, the pending record is cancelled outright. Critically, when the threshold is met, the system writes the original connection timestamp rather than the moment the timer expired — otherwise every departure in the archive drifts three minutes late, and the drift compounds across a year of data.

Validation used three controlled cases over two to four days:

  1. A 30-second pass through the garage, phone in pocket. Expected result: no record.
  2. A 90-second engine start to check mileage. Expected result: pending record cancelled.
  3. A drive of at least 8 minutes. Expected result: clean departure and arrival pair.

GPS geofencing sits in reserve as a backup arrival signal, not a primary one. Continuous location monitoring reads well on paper and drains a battery in practice; a low-frequency geofence checked only after a trip has already become active costs a fraction of the same coverage.

One catch worth naming before anyone commits a weekend to this: phones with restricted background automation, or workplaces without a stable employee SSID, will need that alternative arrival signal from day one. The Bluetooth-plus-Wi-Fi chain assumes infrastructure that not every commute actually has.

Pending Beats Certain

Every trigger should be able to change its mind. A system that writes immediately and corrects later produces a messy archive; a system that holds state for three minutes and then commits produces a clean one.

Log Entry 05: The Silent Observer

After the validation run, the stable sequence reads like a short checklist: Bluetooth connection, three-minute persistence, home-network departure, calendar confirmation, office-network arrival. Five conditions, no interface, no notification.

Housekeeping rules keep the archive honest. An unresolved commute gets flagged after 90 minutes, and stale records close automatically after 4 hours rather than bleeding into the daily summary as a phantom four-hour drive.

What The Log Bought

The value of passive collection is not the file. It is the removal of the decision to record — the small behavioral tax that made manual tracking fail at 7:15 AM in the first place. Context-aware triggers move the cost from the user to the radio stack, where it belongs.

Which raises the question of scale. The U.S. Census Bureau's 2019 American Community Survey put the average one-way commute at 27.6 minutes for workers traveling to work. Two legs a day, across something like 220 to 240 commuting days, lands somewhere around 200 to 220 hours a year spent in transit — roughly five working weeks, previously undocumented, now logged by a rule that never asks for a thumb.

Join Our Newsletter

Be the first to know.

No spam, just thoughtful updates.

Join the Conversation

No comments.

Write a Comment

Cookie settings