# 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**: Phase 27 - **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**: Phase 27 - **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**: `SHIPPED` 2026-08-11 - **Area**: Settings page, Dashboard, `modules/app_settings.py`, `modules/app_sql.py` - **Phase**: Phase 27 - **What**: Settings page now has an "Odometer baseline (km)" field. The app stores this value and computes `odometer_km = baseline + cumulative trip distance`. Dashboard shows "(manual)" label when using baseline. When baseline is 0, falls back to live OBD reading (the original behavior). Also appears in `/api/stats` response. ### FEAT-04 — Replace SIM868 2G GSM hat with 4G LTE modem (Huawei E3372h-153) - **Status**: `IDEA` - **Area**: modems / uplink (Pi `modules/app_cellular.py`, `modules/app_gps.py`, uplink switching) — replaces the current SIM868 GSM/GNSS HAT + cellular fallback path - **Phase**: Phase 27 - **Requested**: owner — just purchased a Huawei **E3372h-153 4G LTE Modem**. The 2G/3G-only SIM868 hat will not work in Canada (2G networks are decommissioned), so the plan is to make the 4G modem the working cellular uplink instead. - **Idea**: integrate the Huawei E3372h-153 as the primary cellular data uplink, replacing reliance on the SIM868's GSM (AT+HTTP) path. The E3372h-153 is a USB "stick" modem — likely supported via Realtek / cdc_ether / usb-storage based drivers and exposes a dial-up or LTE dongle interface the Pi can use for connectivity (e.g. via NetworkManager / ModemManager, or a static APN config). - **Outstanding considerations**: - Determine the E3372h-153's local mode vs stick/dial mode and the correct Linux driver/interface (hierarchical USB mode switching may be needed; it's the "153" variant which may use the RNDIS / ECM / CDC-NCM profile). - Whether to run it as the *primary* uplink or just another option in the existing phone-hotspot / home-wifi / local-AP priority chain. - What happens to the SIM868 — keep it purely for its **GPS/GNSS** role (it's the PWRKEY-toggled GNSS receiver on `/dev/serial0`) while dropping its **2G GSM** cellular path, vs removing it entirely. - The SIM868's `app_gps.py` GNSS positioning must keep working (it's the car's GPS source) even if the 2G-modem half is retired — separate the two concerns. - **Keep this feature as-is (2G/GSM fallback) for countries where 2G/3G still works** — don't remove the existing cellular fallback code; gate it so the 2G path remains available there. - LTE SIM plan/APN specifics for Canadian carriers (Rogers/Bell/Telus) and whether the modem can run the Pi's hotspot/SSID the same way `app_network.py` currently does. ### FEAT-05 — DTC history synced to remote server with code descriptions - **Status**: `SHIPPED` 2026-08-12 - **Area**: `modules/app_upload.py`, `server/sql/migrate_phase27_dtc.sql`, `server/modules/db.py`, `server/app.py`, `server/templates/dtc.html` - **Phase**: Phase 27 - **What**: Pi pushes current DTC snapshot to server via `POST /api/v1/dtc/batch`. Server diffs against stored state — new codes inserted, existing updated, missing codes auto-cleared. Portal has a new `/dtc` page showing code, description, MIL state, active/cleared status, first/last seen timestamps, and manual delete. Upload skips when OBD disconnected (avoids clearing server DTCs on Pi reboot). Snapshot is hash-compared to avoid redundant uploads. ### FEAT-08 — Predictable IP on phone hotspot (DHCP client-id) - **Status**: `SHIPPED` 2026-08-11 (Phase 22) - **Area**: `deploy/yaris_uplink.py`, phone-hotspot NM profile - **What**: `dhcp-client-id=yaris-obd` in the NM keyfile gives the Pi a consistent DHCP lease. The "Last phone IP" link on Settings shows the current address. Pixel testing confirmed same IP across disconnects. ### FEAT-09 — mDNS (yaris.local) on phone hotspot - **Status**: `WONTFIX` 2026-08-12 — hardware/OS limitation - **Area**: Avahi, phone-hotspot NM profile - **What**: Phone hotspot hosts (Android, iOS) don't relay multicast DNS. Avahi publishes correctly on wlan0 AP and home WiFi. Settings "Last phone IP" link is the workaround. Cannot be fixed in software — this is a phone-OS limitation. --- ## Ideas that landed (No entries yet — shipped features land here. Keep the original idea text intact and add the shipped phase/date.) ### FEAT-07 — Phone-hotspot auto-connect documentation - **Status**: `SHIPPED` 2026-08-11 (already implemented in Phase 22, documented here) - **Area**: `deploy/yaris_uplink.py`, Settings page, netwatch timer - **What**: The Pi auto-connects to a saved phone hotspot on wlan1 within ~60s of it appearing in range, and falls back to home-wifi when it disappears. The wlan0 AP stays up regardless. Test flow: Settings → save hotspot name + password → "Wait for hotspot" → enable phone hotspot → verify mode changes to "Phone hotspot". ### FEAT-06 — Trip ID column in history table - **Status**: `SHIPPED` 2026-08-11 - **Area**: `static/js/history.js`, `templates/history.html`, `server/templates/history.html` - **Phase**: Phase 26 - **What**: Narrow `#ID` column on server history (hidden on Pi via `data-show-id`). Checkbox column and batch-delete restored on server only.