Matching TeslaMate drives to calendar meetings for an automatic business mileage log

[gregjonesio]

I built a small read-only companion for TeslaMate that turns drives into an IRS-style business mileage log by joining them to calendar meetings: date, purpose, destination, miles, deduction, with every row traceable back to a TeslaMate drive id.

Repo: https://github.com/gregjonesio/teslamate-mileage-log (MIT, Node 20)

How it works. It reads drives joined to positions/addresses from TeslaMate's Postgres (read-only, it never writes to the database and never talks to the car), pulls meetings with a physical location from a calendar, geocodes each unique address once through Nominatim (cached forever on disk, contact email in the User-Agent per their policy), and matches a meeting to the drive that ended within 500 m of the venue in a window from 120 minutes before the meeting starts to 20 minutes after. The first later drive departing from that location becomes the return leg. Matches within 300 m are rated high, within the configured radius medium, and anything not high is meant to be reviewed rather than trusted.

Two details turned out to be the actual work:

1. Trips that continue by rail or air. If you drive to a station or airport, no drive ever ends near the meeting, so proximity matching structurally cannot see the trip. Configurable transport hubs solve this: the drive to the hub and the drive home from it get matched to the distant meeting, rated via-hub and flagged for review since the leg beyond the hub is not GPS-verified.

2. Two timezone traps in TeslaMate's schema. TeslaMate stores UTC instants in timestamp without time zone columns (Ecto's :utc_datetime), and node-pg parses that type as machine-local time, so every drive arrived shifted by 7 hours and nothing ever matched. Nothing errors, the log just comes back empty. A pg type parser for OID 1114 fixes the read side. The subtler one: binding a JS Date into a comparison against that column type makes Postgres silently discard the offset, so local-day date windows quietly revert to UTC days and evening drives fall out of their own day. The fix is casting through $1::timestamptz AT TIME ZONE 'UTC'. Unit tests cannot catch the binding half, so there is a test that asks a live database what value the comparison actually sees.

It also lists drives that no meeting claimed, so business miles do not silently disappear.

Honest scope, v0.1. Calendar input is Microsoft Graph only today (device code flow, or client credentials), the output is US IRS-style, and it is a bare Node CLI with no Docker packaging yet. On the roadmap: .ics file input for Google Calendar and iCloud users, pluggable trip sources, and an interactive review command.

What I would love from this community: if you keep meetings in Google Calendar or iCloud, what export would you realistically feed this (.ics file, CalDAV, something else)? And if anyone wants to contribute a Dockerfile or compose snippet that fits the standard TeslaMate stack, the door is open.