InfluxDB
Three buckets, three writers, one purpose each, so raw telemetry, tool health, and lap analysis never compete with one another.
| Bucket (env var) | Default name | Written by | Measurement | Contents |
|---|---|---|---|---|
INFLUX_TELEMETRY_BUCKET | telemetry | sinks/influx_writer.py | car (INFLUX_MEASUREMENT) | Every field in schema.INFLUX_FIELDS, tagged session |
INFLUX_STATS_BUCKET | telemetry_stats | sinks/influx_stats_writer.py | middleman | Rates, totals, queue depths, sink on/off flags |
INFLUX_ANALYSIS_BUCKET | telemetry_analysis | analysis/lap_tracker.py | lap_tracking | Lap events: session_start, lap_0_start, lap_reset, and per-lap summaries |
Telemetry writes
influx_writer.py batches packets from influx_q and flushes when the batch reaches INFLUX_BATCH_SIZE (default 100) or INFLUX_FLUSH_INTERVAL seconds (default 0.5) have passed since the last flush, whichever comes first. Each point carries a session tag (the active sd_filename) so a Flux query can isolate one run.
Like every sink, the client closes when the stream goes inactive or the Influx sink is disabled, and reopens automatically once conditions are met again.
Timestamps
sinks/timestamp.py resolves the write timestamp for both InfluxDB and Marple, controlled by SINK_TIME_SOURCE in .env:
| Mode | Source | Notes |
|---|---|---|
server (default) | Server wall clock at UDP arrival | Always correct, independent of the car's GPS/RTC |
time_unix | The CSV's time_unix field, sub-second precision from time_ms | Falls back to server automatically if time_unix looks implausible (before 2020) |
field | The raw value of whichever field is marked is_timestamp in schema.py | Only correct if that field is already Unix milliseconds |
Why server is the default
The car's RTC only syncs once GPS has a fix. Before that, time_unix is meaningless. server sidesteps the problem entirely for live dashboards; time_unix exists for anyone who wants GPS-accurate timestamps once a fix is established, but it's an explicit opt-in, not the default.
Stats and analysis buckets
influx_stats_writer.py stays connected across inactivity gaps, since stats points are small and infrequent, and reconnects automatically on a write failure. lap_tracker.py opens its own write API against INFLUX_ANALYSIS_BUCKET only while the analysis sink is enabled and the stream is active.
Querying from the dashboard
The web API's /api/track and /api/latest endpoints (see Middleman) run Flux queries directly against INFLUX_TELEMETRY_BUCKET: one finds the most recent session from the last gps_lat point, the other pulls either the full downsampled GPS track or the latest value of every field for that session.