diff --git a/PLAN.md b/PLAN.md index cd7e450..5f5dd78 100644 --- a/PLAN.md +++ b/PLAN.md @@ -1860,61 +1860,21 @@ phase roadmap. --- -### Phase 26: Road-test bug fixes — 🚧 PLANNED -**Renumbered/added 2026-08-10 after the Phase 25 owner road test.** This phase (the former Phase 26 -Android slot, which is now **Phase 27**) is a targeted bug-fix pass for the defects surfaced by the -in-car road test. Each item references its tracking entry in `BUGS.md`; distinct fixes should be -committed individually with a `fix(bug-N): ...` prefix and each closed out in `BUGS.md` as it -lands. The current known issues from the road test (also recorded in `BUGS.md`): +### Phase 26: Road-test bug fixes — 🚧 IN PROGRESS (6/8 closed) +Targeted bug-fix pass for defects surfaced by the Phase 25 in-car road test. +Each item tracked in [BUGS.md](./BUGS.md). See that file for full symptom/root-cause/fix details. -1. **BUG-01 (WiFi/hotspot reachability).** While cell data is on, a phone connected to the Pi's - no-internet hotspot cannot load `yaris.local`, `10.42.0.1`, or the Pi's DHCP address at all — - the phone OS keeps cellular as the default route (Phase 11/22 "smart network switching" - behavior). It only works once the user disables cell data, then `http:///` loads but - `yaris.local` and `10.42.0.1` still do not. Also: the live hotspot subnet is `10.112.0.x`, not - the documented `10.42.0.1`. Fix scope: make the documented/reachable address correct, surface - the real DHCP address in the Pi UI, document the cell-data behavior, and see if `yaris.local` - unicast fallback can be extended to the AP subnet. -2. **BUG-02 (micro-USB power port damaged).** Hardware-only (worn power connector). Action is - documentation + owner hard-wiring 5V/GND to the GPIO header pins; no code. -3. **BUG-03 (DTCs not persisted).** ✅ FIXED (`e2f2314`) — The SQLite `dtc` table is created but never - written or read; - DTC codes/MIL live only in memory in `app_obd.py` and vanish on OBD disconnect/reboot. - `get_overview_stats` also queries a non-existent `dtc_codes` table. Fix: persist on each poll, - read back when disconnected, fix the stats query, add a "cleared/since" concept. -4. **BUG-04 (server merges two trips into one).** The Pi splits trips by *motion* (OBD wheel - speed + sustained GPS displacement, inactivity gap); the server splits only by *time gap* and - filters by duration. Parked idle tracking rows bridge two drives into one server-side trip. - Fix: mirror the Pi's motion-boundary logic server-side. +**Closed (2026-08-11):** +- BUG-03: DTC/MIL persistence (`e2f2314`) +- BUG-04: Server trip merge — motion-aware logic (`96fb897`) +- BUG-05: Server speed_source (`e2f2314`) +- BUG-08: Pi trip deletion (`c5c478b`) +- BUG-09: Geocode pre-caching for fast scrubber +- BUG-10: GPS-only false trips gated on OBD presence -5. **BUG-05 (server replay speed_source).** ✅ FIXED (`e2f2314`) — Server `get_trip_route` hardcodes `speed_source: "gps"` - even when OBD speed is present (it already returns raw `speed`). Fix: mirror the Pi's - `obd if speed>0 else gps` logic. -6. **BUG-06 (server timezone is UTC-shifted).** `tracking_points.recorded_at` is `TIMESTAMPTZ` - but the Pi sends naive local (Montreal) time with no offset; Postgres (UTC container) treats - it as UTC, so server times/trip boundaries are off by the EDT offset. Fix: Pi sends - timezone-aware timestamps; server displays/stores in `America/Toronto`; optional one-time - migration to correct already-stored rows. -7. **BUG-07 (trip replay sometimes does nothing).** Intermittent `/history` replay failure — - needs reproduction/diagnostics (likely an API/DB race or map-not-ready timing). Add targeted - diagnostics before fixing. -8. **BUG-08 (no trip deletion on the local Pi).** The Pi's `components.html` `data_table` macro - lacks the `deletable` arg, `base.html` lacks `window.confirmDelete`, `history.js` hardcodes the - *server* delete endpoint, and there is no `DELETE /api/trip/` route on the Pi. Fix: add all - four pieces and make the delete endpoint configurable in `history.js`. +**Still open:** BUG-01 (hotspot/phone), BUG-02 (hardware power), BUG-06 (timezone), BUG-07 (intermittent replay). -**Progress (2026-08-11, 6/8 closed):** -- **BUG-03** ✅ CLOSED (`e2f2314`) — DTC/MIL persisted to SQLite, `/api/dtc` fallback, stats fixed. -- **BUG-04** ✅ CLOSED (`96fb897`) — Server trip detection now mirrors Pi's motion-aware logic. -- **BUG-05** ✅ CLOSED (`e2f2314`) — Server `speed_source` matches Pi: `obd if speed>0 else gps`. -- **BUG-08** ✅ CLOSED (`c5c478b`) — Pi trip deletion: `deletable` macro, `confirmDelete`, `DELETE` route, configurable endpoint. -- **BUG-09** ✅ CLOSED — Geocode pre-caching in `history.js` for fast scrubber. -- **BUG-10** ✅ CLOSED — GPS-only false trips gated on `was_car_ever_connected()`. -- **BUG-01/02/06/07**: Still OPEN. See `BUGS.md`. -Both pending deploy/verify. The remaining items (BUG-01, 02, 04, 06, 07, 08) stay open. - -**Acceptance for Phase 26:** every `BUGS.md` entry in scope is fixed, regression-tested, deployed, -marked resolved, and the corresponding fix recorded here. +**Acceptance:** every `BUGS.md` entry in scope is fixed, regression-tested, deployed, and marked resolved. --- diff --git a/readme.md b/readme.md index acd0671..42004da 100644 --- a/readme.md +++ b/readme.md @@ -1,6 +1,6 @@ # yaris-obd -A Raspberry Pi 3-based OBD-II, GPS, and dashcam system for my 2013 Toyota Yaris. It reads live +A Raspberry Pi 3-based OBD-II, GPS, and dashcam system for a 2013 Toyota Yaris. Reads live vehicle data over USB, tracks position with a SIM868 GNSS/GSM HAT, logs everything locally, and serves a web UI over the car's own WiFi hotspot. The dashboard and pre-cached map work fully offline, while trip data and dashcam footage sync to a self-hosted remote server whenever an @@ -195,53 +195,12 @@ rm db/sql/quoije_Yaris2013.db ## Project status -The build is now at the endgame stage: the Pi app, remote server, and device-management/sync work -are implemented and verified on the real Pi/unraid setup. The remaining roadmap phases are the -road-test bug-fix pass (Phase 26), feature additions (Phase 27), and the low-priority Android companion (Phase 28). The owner has -already completed the Phase 25 real-vehicle test; the bugs it surfaced are tracked in -[BUGS.md](./BUGS.md). +The Pi app, remote server, and device-management/sync are all implemented and verified on real +hardware. Phase 25 (in-car road test) is complete; Phase 26 (bug fixes) is in progress with 6 of +8 resolved. Phase 27 (features) and Phase 28 (Android, low priority) follow. -- **Phases 1–23.5**: core Pi system — GPS, OBD, dashcam, trip history, web UI redesign, WiFi upgrade, cellular fallback, alerts, settings, upload -- **Phase 24**: remote web portal at `https://yaris.ceaf.dev/` — login-protected, trip history with CARTO live map, dashcam archive, delete, overview stats -- **Phase 24.5**: full code audit — 6 bugs fixed across Pi modules and server, 63 tests passing -- **Phase 24.6**: Yaris 2013 OBD compatibility hardening — `_decode_odometer` no longer kills the OBD session on unsupported PIDs, sensor globals reset on reconnect, `OBD_SKIP_VOLTAGE_CHECK` escape hatch for clone ELM327 adapters -- **Phase 24.7**: diagnostic script (`scripts/diagnose.sh`), map tile switch to CARTO, zoom limit fix -- **Phase 24.8**: deployment/readme cleanup and uplink interface consistency -- **Phases 25.5a–25.5d**: offline-first device identity sync, remote portal device settings, - Pi-side hot-reload, multi-device provisioning, one-time API key rotation/registration, local - Settings UI for remote credentials, Sync now / Test connection, GPS live-status verification, - dedicated local Status page, and status-page quick actions -- **Current known limitation**: the remote portal's device-management page is multi-device, but the - main remote overview/history/dashcam browsing views still follow one configured `DEVICE_NAME` - until a later portal-wide device selector/filter is added - -**Next**: Phase 26 — road-test bug fixes (6 of 8 resolved, see [BUGS.md](./BUGS.md) -for remaining issues). Phase 27 (feature additions from FEATURES.md) and Phase 28 (Android companion app) follow after that. - -Phase 14 is partially complete: the Pi's hardware watchdog is deployed and reboot-verified. -Read-only-root storage hardening is deferred until persistent storage is moved off the SD root -partition, and clean shutdown still needs delayed-power or ignition-sense hardware. - -The browser-based phone relay was removed after real-world testing confirmed that mobile browsers -cannot reliably use the Pi's WiFi and cellular data simultaneously. A native Android companion is -planned later instead (Phase 28). - -The local web UI includes a Settings page for safe runtime configuration: dashcam uploads, -uploaded-video retention, cellular APN fallback, optional ntfy delivery, alert thresholds, local -device identity, and remote server credentials/API key. Notification secrets remain write-only in -the browser API. When cellular is configured, small ntfy notifications use the SIM868 first and -WiFi/Ethernet only as fallback; that modem path is implemented and mock-tested but still needs -real-SIM/carrier verification. - -The Pi can also join a configured phone hotspot for outbound internet when no SIM is available, -including trip synchronization and WiFi dashcam uploads, with automatic recovery to home WiFi or -the Pi-hosted local hotspot. - -The Phase 25 real-vehicle compatibility test has been completed by the owner (road test). The -bugs it surfaced are tracked in [BUGS.md](./BUGS.md) and scheduled for fixing in Phase 26. The -final low-priority Android companion follows in Phase 27. Permanent installation is owner-handled -and is not a roadmap phase. Full phase history, verification notes, and current scope live in -[PLAN.md](./PLAN.md). +Full phase history and verification notes live in [PLAN.md](./PLAN.md). Open issues in +[BUGS.md](./BUGS.md). Feature requests in [FEATURES.md](./FEATURES.md). ## Diagnostics & recovery