yaris-obd Feature Requests

Ideas and requests for new features (distinct from bugs, which belong in BUGS.md, and the phase-by-phase implementation history in PLAN.md). Use this file to record anything that should be built eventually but isn't an active roadmap phase yet. When a feature gets picked up, create a dedicated PLAN.md phase (or fold it into the relevant existing work) and mark it here.

How to use this file

One ## FEAT-XX section per idea. Keep numbering sequential.
Status field: IDEA (brainstormed, not planned) → PLANNED (has an assigned phase) → IN PROGRESS → SHIPPED (deployed + verified) or WONTFIX/SUPERSEDED as appropriate.
Relate to roadmap: when a feature lands in a phase, note the phase here and drop a link back here from PLAN.md so the two stay in sync.
Keep each entry small and one-idea-per-entry so it's easy to pick up and scope.

Feature ideas

FEAT-01 — Parallel/concurrent chunked dashcam uploads

Status: IDEA
Area: modules/app_upload.py (Pi upload client)
Phase: n/a
Requested: noted in Phase 10 of PLAN.md as a possible future optimization; not yet requested explicitly by the owner.
Idea: upload multiple dashcam chunks (and/or multiple files) concurrently instead of the current strictly sequential one-chunk-then-one-file at a time. Would speed up the multi-hour full-backlog drain of a large local dashcam archive, at the cost of more complexity (bounded concurrency, per-file state, failure handling for the individual concurrent workers).
Outstanding considerations: memory budget on the Pi (~900MB, no swap — must stay streaming), and whether the sequential pace is actually annoying enough in practice to justify the added complexity.

FEAT-02 — QR / claim-code device pairing flow

Status: IDEA
Area: server device provisioning + Pi credential setup (Phase 25.5c)
Phase: n/a
Requested: discussed in Phase 25.5c as a possible follow-up to the manual copy/paste API-key provisioning.
Idea: zero-manual-copy provisioning of YARIS_SERVER_URL / YARIS_DEVICE_NAME / YARIS_API_KEY onto the Pi — e.g. the portal shows a short-lived claim code / QR that the Pi app (or owner) enters/scans once to adopt the device, instead of typing credentials by hand.
Outstanding considerations: bigger scope than the current copy/paste flow; ship copy/paste first, add pairing only if provisioning still feels annoying.

FEAT-03 — Manual start odometer fallback when OBD odometer is unavailable

Status: IDEA
Area: Settings page / odometer display (Pi app_settings, /api/stats, trip odometer)
Phase: n/a
Requested: owner — the 2013 Yaris's ECU is (as expected) NOT exposing OBD PID 0xA6 odometer (see Phase 24.6), so the odometer reads nothing.
Idea: allow the owner to enter the vehicle's current odometer reading once in the Settings page; the app then computes a rolling odometer by adding subsequent trip distances (from trips table cumulative distance) to that entered baseline, instead of relying on the unavailable OBD odometer PID.
Outstanding considerations: what happens when the user's entered value comes from the car's instrument cluster vs the OBD one being absent — this would be the only odometer source in that case; needs a clear "this is a manual baseline" indicator in the UI so it's not mistaken for a live OBD reading; decide whether it should also sync to the remote device config (Phase 25.5) or stay local.

Ideas that landed

(No entries yet — shipped features land here. Keep the original idea text intact and add the shipped phase/date.)

3.7 KiB Raw Blame History