97 lines
5.7 KiB
Markdown
97 lines
5.7 KiB
Markdown
# 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.
|
|
|
|
### 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**: n/a
|
|
- **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.
|
|
|
|
---
|
|
|
|
## Ideas that landed
|
|
|
|
(No entries yet — shipped features land here. Keep the original idea text intact and add the
|
|
shipped phase/date.)
|