Amend the Phase 26 progress note: BUG-03 was deployed to the Pi (pulled to
4f975ad, service active, /api/health ok) and real in-car behavior verification
is still pending; BUG-05 is code-ready but the unraid/server side is not yet
deployed (needs docker compose build api && docker compose up -d api).
BUG-03: DTC/MIL codes were never persisted; lost on OBD disconnect or reboot.
- Add new dtc table schema (code, description, MIL, first/last seen, IS_SET)
and a migration that rebuilds the original unused NAME/STATUS/DTC_ID table.
- Persist MIL + codes to SQLite on each successful OBD poll (_persist_dtc_state).
- /api/dtc falls back to the last-persisted snapshot when OBD is offline/stale.
- Fix get_overview_stats to count the real dtc table (was querying non-existent
dtc_codes table).
- Add cleared/since tracking via IS_SET + FIRST_SEEN_AT/LAST_SEEN_AT.
BUG-05: server trip replay hardcoded speed_source:'gps'; mirror Pi's
'obd if speed>0 else gps' logic in server get_trip_route.
Adds tests/test_dtc_persistence.py (7 tests).
- note that GPS thread is alive on the Pi but has no current fix
- clarify that missing live updates are currently due to absent GNSS fix data
Co-authored-by: Copilot <[email protected]>
- add /api/gps/status for thread/fix-age visibility
- surface GPS status in Pi health and live GPS cards
- add tests for app_gps status snapshots
Co-authored-by: Copilot <[email protected]>
- add portal API and UI action to delete non-default devices
- protect the configured portal default device from deletion
- document that trip/history pages still scope to the single DEVICE_NAME
Co-authored-by: Copilot <[email protected]>
- mark Phase 25.5c complete in PLAN
- record unraid migration/deploy and Pi API smoke tests
- note sync-ack metadata and temp provisioning helper validation
Co-authored-by: Copilot <[email protected]>
- add multi-device portal device management, key rotation, and sync request APIs
- add Pi settings UI for remote server URL, device name, and API key
- add local test-connection and sync-now actions
- make upload and config sync reuse dynamic shared credentials
- add Phase 25.5c migration and docs updates
Co-authored-by: Copilot <[email protected]>
- update plan with live portal route deployment status
- document fixed Pi sync blockers and successful round-trip test
- refresh passing test count after runtime sync coverage additions
Co-authored-by: Copilot <[email protected]>
- load server sync creds from db/upload_creds.env like uploads do
- fall back from YARIS_DEVICE_KEY to existing YARIS_API_KEY
- document shared credential flow for server-synced identity
- add test coverage for sync credential fallback
Co-authored-by: Copilot <[email protected]>
- use app_network status for device sync connectivity checks
- mount migrate_phase25_5a.sql in server docker compose
- document manual server upgrade migration steps
- record verified Pi and unraid SSH access details in PLAN
Co-authored-by: Copilot <[email protected]>
- Created app_device_sync.py: background sync thread with connectivity-driven scheduling (5min online, 60sec backoff when offline)
- Server /api/device-config endpoints: GET for Pi device auth, POST for admin user auth
- Database migration adds config_version, owner_name, car_model, device_name, avatar_path to devices table
- Pi syncs config from server on network availability; offline-first design (loads from local JSON at startup)
- Settings UI fields read-only when server sync enabled
All 63 tests passing. Ready for testing with actual server connection.
Co-authored-by: Copilot <[email protected]>
- Add database migration (migrate_phase25_5a.sql):
* Add owner_name, car_model, device_name, avatar_path columns to devices table
* Add config_version and config_updated_at for cache invalidation
- Add server/modules/device_config.py:
* get_device_config(device_id): retrieve config for Pi sync
* update_device_config(device_id, data): update config with validation
- Add server API endpoints:
* GET /api/device-config (authenticated with device_key, Pi fetches config)
* POST /api/device-config (authenticated as user, admin updates config)
- Enhance server/modules/db.py:
* Add get_device_by_id() function to retrieve all device config fields
Phase 25.5a enables server-side device identity management and connection-driven sync.
Pi will fetch from this endpoint when internet available, keeping config in sync.
Co-authored-by: Copilot <[email protected]>
- Settings UI now implemented for device config editing
- Sync toggle blocks field edits when enabled
- All behaviors tested and verified on Pi
- Phase 25.5a will add server-side config endpoints and connection-driven sync
Co-authored-by: Copilot <[email protected]>
- Add app_device_config.py module for managing device configuration (owner_name, car_model, avatar_path, device_name)
- Add sync_enabled flag to control whether Pi syncs config from server
- When sync is enabled, device config fields are read-only (server is source of truth)
- When sync is disabled, user can edit device config via Settings page
- Add /api/device-config endpoint (GET to retrieve, POST to update)
- Add Device identity section to settings.html with form fields for all config values
- Update settings.js to load/save device config with sync toggle
- Gracefully handles both config file (at startup) and database (live updates via settings UI)
- All 63 tests passing
Phase 25.5: Offline-first device config with eventual consistency. Config loads from JSON at startup (no network needed), can be edited via settings if not syncing, and will sync from server on next connectivity when Phase 25.5a server endpoints are implemented.
Co-authored-by: Copilot <[email protected]>
- Create config/device.json with owner_name, car_model, device_name, avatar_path
- Update app_account.py to load owner_name and avatar_path from config
- Update app_car.py to load car_model and device_name from config
- Update base.html template to use avatar_path from config instead of hardcoded
- Add graceful fallback to hardcoded defaults if config file missing
- Document in deploy/readme.md and readme.md how to customize device identity
- Update PLAN.md Phase 25.5 to reflect current implementation and future server sync
Benefits:
- No code edits needed to customize Pi (edit JSON file only)
- Offline-first: all values loaded from local file at startup
- Connection-driven sync planned for Phase 25.5a (sync when internet available, not on timer)
- Server becomes source of truth after Phase 25.5a implementation
All 63 tests passing. Database filename still based on owner_name, with migration warning in docs.
Co-authored-by: Copilot <[email protected]>
Plan for replacing hardcoded user/car/avatar with managed server-synced configuration, enabling multi-device and zero-code-edit deployment scenarios.
Co-authored-by: Copilot <[email protected]>
If no real odometer data exists (all NULL — expected on 2013 Yaris which
likely doesn't support PID 0xA6), fall back to SUM(distance_km) from the
computed trips table so the overview shows something meaningful.
Co-authored-by: Copilot <[email protected]>
COALESCE(MAX(odometer), 0) returned 0 when all tracking rows have NULL
odometer (expected before the car is connected — PID 0xA6 likely unsupported
on 2013 Yaris). Now returns NULL which the overview JS renders as '—'.
Co-authored-by: Copilot <[email protected]>
OSM tile.openstreetmap.org was returning grey tiles on the portal (likely
rate-limiting the Cloudflare tunnel egress IP). Switch to CARTO Voyager
tiles which are free, CDN-backed, and don't have the same restrictions.
Also add data-tile-subdomains attribute support in history.js so tile
provider subdomains can be configured per-deployment.
Co-authored-by: Copilot <[email protected]>
- tiles.addTo(map) now called at init instead of lazily on first trip click
(fixes blank map on page load on the server portal)
- minZoom/maxZoom read from data-min-zoom/data-max-zoom attributes with
correct NaN fallback (parseInt || default)
- Pi template: data-min-zoom=8 data-max-zoom=15 (matches cached tile range)
- Server template: data-min-zoom=3 data-max-zoom=19 (full OSM range)
Co-authored-by: Copilot <[email protected]>
Pi offline tiles only cover zoom 8-15; OSM live tiles support 0-19.
history.js now reads data-min-zoom/data-max-zoom from the #history-map div
instead of hardcoding 3/19. Pi template caps to 8-15 (prevents blank tiles
at extreme zooms), server template allows full 3-19 OSM range.
Co-authored-by: Copilot <[email protected]>
Mathieu Moran