yaris-obd/FEATURES.md

# 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.