Align docs with ESP32-S3 dashboard architecture
This commit is contained in:
+45
-509
@@ -1,526 +1,62 @@
|
||||
# Roadmap
|
||||
|
||||
This roadmap tracks planned Overland Controller development.
|
||||
## Phase 1: Solid Local Cargo Controller
|
||||
|
||||
The roadmap is flexible and may change as the project evolves.
|
||||
- Reliable relay control
|
||||
- Reliable DS18B20 temps
|
||||
- Reliable JBD/Xiaoxiang BMS BLE
|
||||
- WPA2 AP mode
|
||||
- Stable WebUI
|
||||
- Stable HTTP API
|
||||
- Clear status/config/control model
|
||||
|
||||
## Phase 1: ESP32 Controller Foundation
|
||||
## Phase 2: Waveshare ESP32-S3 Dashboard
|
||||
|
||||
Status: mostly complete
|
||||
|
||||
Goals:
|
||||
|
||||
- Establish ESP32 firmware structure
|
||||
- Implement relay control
|
||||
- Implement status reporting
|
||||
- Implement local configuration
|
||||
- Implement BMS telemetry
|
||||
- Implement generic relay/sensor naming
|
||||
- Establish HTTP and UART communication models
|
||||
|
||||
Completed:
|
||||
|
||||
- Relay control
|
||||
- JSON status API
|
||||
- Configuration persistence
|
||||
- Factory reset
|
||||
- BMS BLE telemetry
|
||||
- Cell voltage telemetry
|
||||
- Generic relay IDs
|
||||
- Generic temperature sensor IDs
|
||||
- HTTP API
|
||||
- Serial console commands
|
||||
- Documentation cleanup
|
||||
|
||||
Remaining:
|
||||
|
||||
- Finish UART parity
|
||||
- Improve BLE setup reliability
|
||||
- Add stronger config validation
|
||||
- Add better command help output
|
||||
|
||||
## Phase 2: UART Parity
|
||||
|
||||
Status: next priority
|
||||
|
||||
Goal:
|
||||
|
||||
The Pico dashboard should be able to configure and control the ESP32 over UART without relying on WiFi.
|
||||
|
||||
Minimum UART v1 messages:
|
||||
|
||||
- status_request
|
||||
- set_relay
|
||||
- config_request
|
||||
- config_device
|
||||
- config_relay
|
||||
- config_temp
|
||||
- config_bms
|
||||
- save_config
|
||||
- factory_reset
|
||||
- enter_bms_setup
|
||||
- scan_ble
|
||||
- select_bms
|
||||
- exit_bms_setup
|
||||
|
||||
Expected result:
|
||||
|
||||
The Pico can:
|
||||
|
||||
- Read full system status
|
||||
- Display current configuration
|
||||
- Control relays
|
||||
- Rename relays
|
||||
- Rename temperature sensors
|
||||
- Configure BMS
|
||||
- Run BMS setup workflow
|
||||
- Save configuration
|
||||
|
||||
## Phase 3: Temperature Sensors
|
||||
|
||||
Status: partially started
|
||||
|
||||
Goals:
|
||||
|
||||
- Complete DS18B20 hardware wiring
|
||||
- Add proper 4.7k pull-up resistor
|
||||
- Detect connected sensors
|
||||
- Report sensor addresses
|
||||
- Assign sensors to config slots
|
||||
- Persist sensor address assignments
|
||||
|
||||
Planned serial commands:
|
||||
|
||||
- scan temps
|
||||
- assign temp 1 <address>
|
||||
- clear temp 1
|
||||
|
||||
Planned UART messages:
|
||||
|
||||
- scan_temps
|
||||
- assign_temp
|
||||
- clear_temp
|
||||
|
||||
Expected result:
|
||||
|
||||
A user can connect multiple DS18B20 sensors, identify each one, name it, and save the configuration.
|
||||
|
||||
## Phase 4: Pico Dashboard Bring-Up
|
||||
|
||||
Status: not started on hardware
|
||||
|
||||
Goals:
|
||||
|
||||
- Bring up Pico 2 W
|
||||
- Bring up touchscreen
|
||||
- Establish UART connection to ESP32
|
||||
- Display status response
|
||||
- Display battery data
|
||||
- Display relay states
|
||||
- Display temperature data
|
||||
- LVGL project scaffold
|
||||
- WiFi client to Cargo ESP32 AP
|
||||
- Poll /status
|
||||
- Display battery, relays, temps, and alarms
|
||||
- Send relay commands
|
||||
- Handle offline/stale/failed-command states
|
||||
|
||||
Initial dashboard screens:
|
||||
UI direction:
|
||||
|
||||
- Main overview
|
||||
- Battery screen
|
||||
- Temperature screen
|
||||
- Relay control screen
|
||||
- Settings screen
|
||||
- Dark theme
|
||||
- Large readable text
|
||||
- Circular SOC gauge
|
||||
- Card-based layout
|
||||
- Smooth subtle animations
|
||||
- No stock LVGL demo look
|
||||
|
||||
## Phase 5: Pico Configuration UI
|
||||
## Phase 3: Vehicle Data
|
||||
|
||||
Status: planned
|
||||
- Connect Waveshare CAN to OBD-II CAN-H/CAN-L
|
||||
- Keep CAN termination disabled
|
||||
- Read coolant temp via PID 0105
|
||||
- Read RPM via PID 010C
|
||||
- Read vehicle speed via PID 010D
|
||||
|
||||
Goals:
|
||||
## Phase 4: Transmission Temperature
|
||||
|
||||
- Configure device name
|
||||
- Configure relay names
|
||||
- Configure temperature names
|
||||
- Configure BMS
|
||||
- Run BLE scan workflow
|
||||
- Save config
|
||||
- Factory reset
|
||||
- Install dedicated sender
|
||||
- Read through exposed ADC or ADS1115 over I2C
|
||||
- Convert resistance to temp with lookup interpolation
|
||||
- Add alert thresholds
|
||||
|
||||
Expected result:
|
||||
## Phase 5: Future Home Server
|
||||
|
||||
A new installation can be configured from the dashboard without using a laptop.
|
||||
- Cargo ESP32 outbound connection
|
||||
- Remote read-only dashboard first
|
||||
- Optional commands later
|
||||
- HTTPS reverse proxy/PWA
|
||||
- Possible MQTT/WebSocket bridge
|
||||
- Optional Grafana/Home Assistant/InflDB
|
||||
|
||||
## Phase 6: Vehicle Inputs
|
||||
## Phase 6: Optional Enhancements
|
||||
|
||||
Status: planned
|
||||
|
||||
Possible inputs:
|
||||
|
||||
- Ignition signal
|
||||
- Vehicle battery voltage
|
||||
- OBD-II
|
||||
- CAN bus
|
||||
- microSD logging
|
||||
- GPS
|
||||
|
||||
Potential data:
|
||||
|
||||
- Ignition state
|
||||
- Engine RPM
|
||||
- Coolant temperature
|
||||
- Vehicle speed
|
||||
- Fuel level
|
||||
- Diagnostic trouble codes
|
||||
- Location
|
||||
- Trip data
|
||||
|
||||
## Phase 7: Logging and History
|
||||
|
||||
Status: planned
|
||||
|
||||
Goals:
|
||||
|
||||
- Log battery history
|
||||
- Log temperature history
|
||||
- Log relay events
|
||||
- Log alarm events
|
||||
- Show historical charts
|
||||
|
||||
Possible storage:
|
||||
|
||||
- ESP32 flash
|
||||
- SD card
|
||||
- External service
|
||||
- Future InfluxDB integration
|
||||
|
||||
## Phase 8: Integrations
|
||||
|
||||
Status: planned
|
||||
|
||||
Potential integrations:
|
||||
|
||||
- MQTT
|
||||
- Home Assistant
|
||||
- Grafana
|
||||
- InfluxDB
|
||||
- Node-RED
|
||||
|
||||
Design goal:
|
||||
|
||||
Integrations should consume the same generic status/config model used by HTTP and UART.
|
||||
|
||||
## Phase 9: Enclosure and Installation
|
||||
|
||||
Status: planned
|
||||
|
||||
Goals:
|
||||
|
||||
- Design ESP32 enclosure
|
||||
- Design Pico dashboard enclosure
|
||||
- Design wiring harness
|
||||
- Document installation
|
||||
- Create BOM
|
||||
- Create printable STL files
|
||||
- Validate thermal and vibration behavior
|
||||
|
||||
## Phase 10: Public Release
|
||||
|
||||
Status: future
|
||||
|
||||
Goals:
|
||||
|
||||
- Clean documentation
|
||||
- Stable API
|
||||
- Stable UART protocol
|
||||
- Installation guide
|
||||
- Wiring guide
|
||||
- Build guide
|
||||
- Example configurations
|
||||
- Versioned releases
|
||||
|
||||
Potential release name:
|
||||
|
||||
Overland Controller v1.0
|
||||
|
||||
## Long-Term Ideas
|
||||
|
||||
Potential future features:
|
||||
|
||||
- OTA firmware updates
|
||||
- Multi-controller support
|
||||
- Expansion modules
|
||||
- Water tank monitoring
|
||||
- Inverter monitoring
|
||||
- Solar charge controller monitoring
|
||||
- Starlink diagnostics
|
||||
- Bluetooth sensor support
|
||||
- Mobile web dashboard
|
||||
- Plugin-style integrations
|
||||
|
||||
---
|
||||
|
||||
## Networking Roadmap
|
||||
|
||||
### Current
|
||||
|
||||
The ESP32 currently operates as a local access point.
|
||||
|
||||
Default local access:
|
||||
|
||||
http://192.168.4.1
|
||||
|
||||
This provides a reliable recovery/setup path even when no other WiFi network is available.
|
||||
|
||||
### Planned: AP + STA Mode
|
||||
|
||||
The ESP32 should support AP and STA mode at the same time.
|
||||
|
||||
Access Point mode:
|
||||
|
||||
Overland-Controller
|
||||
192.168.4.1
|
||||
|
||||
Station mode:
|
||||
|
||||
Connects to a configured WiFi network such as Starlink, home WiFi, or shop WiFi.
|
||||
|
||||
The AP should remain enabled even when STA mode is connected.
|
||||
|
||||
Reason:
|
||||
|
||||
- Always available recovery path
|
||||
- Easier setup
|
||||
- Less risk of locking yourself out
|
||||
- Useful when Starlink/home WiFi is unavailable
|
||||
|
||||
### Planned: Multiple Saved WiFi Networks
|
||||
|
||||
The controller should eventually support multiple saved WiFi profiles.
|
||||
|
||||
Example priority order:
|
||||
|
||||
1. Starlink
|
||||
2. Home WiFi
|
||||
3. Shop WiFi
|
||||
|
||||
Expected boot behavior:
|
||||
|
||||
Start AP
|
||||
Try Starlink
|
||||
If Starlink fails, try Home WiFi
|
||||
If Home WiFi fails, try Shop WiFi
|
||||
If all fail, remain AP-only
|
||||
|
||||
The ESP32 only connects to one STA network at a time, but it can remember and try multiple networks.
|
||||
|
||||
### Planned WiFi Configuration
|
||||
|
||||
Future configuration should include:
|
||||
|
||||
ap_enabled
|
||||
sta_enabled
|
||||
hostname
|
||||
saved networks
|
||||
priority order
|
||||
|
||||
Future setup options:
|
||||
|
||||
- Serial console
|
||||
- HTTP API
|
||||
- Pico dashboard UI
|
||||
- Embedded web dashboard
|
||||
|
||||
### Planned mDNS
|
||||
|
||||
The controller should eventually support mDNS.
|
||||
|
||||
Example:
|
||||
|
||||
http://overland-controller.local
|
||||
|
||||
This would avoid needing to look up the controller IP when connected through Starlink or home WiFi.
|
||||
|
||||
---
|
||||
|
||||
## Embedded Web Dashboard
|
||||
|
||||
### Current Direction
|
||||
|
||||
The ESP32 should serve a lightweight mobile-friendly dashboard.
|
||||
|
||||
Purpose:
|
||||
|
||||
- Check battery status from a phone
|
||||
- Check fridge/temp status from camp
|
||||
- Toggle relays if needed
|
||||
- View alarms
|
||||
- Provide fallback UI without the Pico display
|
||||
|
||||
Design limits:
|
||||
|
||||
- No React
|
||||
- No external libraries
|
||||
- No images
|
||||
- Small inline HTML/CSS/JS
|
||||
- Poll /status every few seconds
|
||||
- Use existing relay endpoints
|
||||
|
||||
This dashboard is not intended to replace the physical Pico dashboard.
|
||||
|
||||
---
|
||||
|
||||
## Optional Future Pi Zero Module
|
||||
|
||||
The base system should not require a Pi Zero.
|
||||
|
||||
Base system:
|
||||
|
||||
ESP32 controller
|
||||
Pico 2 W dashboard
|
||||
|
||||
Optional future advanced module:
|
||||
|
||||
Pi Zero 2 W
|
||||
|
||||
Possible Pi Zero functions:
|
||||
|
||||
- Rich web dashboard
|
||||
- Historical logging
|
||||
- Graphs
|
||||
- SQLite database
|
||||
- MQTT bridge
|
||||
- Home Assistant bridge
|
||||
- Advanced configuration UI
|
||||
|
||||
The core controller should remain functional without the Pi Zero.
|
||||
|
||||
---
|
||||
|
||||
## Configuration Backup and Restore
|
||||
|
||||
Planned future feature.
|
||||
|
||||
Goals:
|
||||
|
||||
- Export configuration JSON
|
||||
- Import configuration JSON
|
||||
- Backup install-specific setup
|
||||
- Restore after factory reset
|
||||
- Make support easier for future users
|
||||
|
||||
This is important if the project becomes shareable or sellable.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Post-0.4.0 Roadmap
|
||||
|
||||
### Near Term
|
||||
|
||||
- Verify complete WebUI setup workflow.
|
||||
- Add config backup/export/import.
|
||||
- Improve BMS out-of-range behavior without reducing NimBLE connection reliability.
|
||||
- Build permanent DS18B20 distribution board.
|
||||
- Test multiple temperature probes.
|
||||
- Update enclosure wiring layout.
|
||||
|
||||
### Pico Dashboard MVP
|
||||
|
||||
- UART status request.
|
||||
- Battery summary screen.
|
||||
- Temperature screen.
|
||||
- Relay control screen.
|
||||
- Alarm indicators.
|
||||
- Screen sleep based on ignition signal later.
|
||||
|
||||
### Future
|
||||
|
||||
- mDNS hostname.
|
||||
- OTA update workflow.
|
||||
- Optional Pi Zero logging module.
|
||||
- Historical graphs.
|
||||
- MQTT/Home Assistant bridge.
|
||||
- Ignition sense.
|
||||
- House battery voltage sense.
|
||||
|
||||
---
|
||||
|
||||
## Pico Dashboard MVP Plan
|
||||
|
||||
MVP means Minimum Viable Product.
|
||||
|
||||
Goal:
|
||||
|
||||
Prove Pico 2 W can reliably read ESP32 status over UART and display live data.
|
||||
|
||||
Phase 1:
|
||||
|
||||
- MicroPython on Pico 2 W / RP2350
|
||||
- UART to ESP32 dashboard UART
|
||||
- USB debug output
|
||||
- Request status from ESP32
|
||||
- Parse status JSON
|
||||
|
||||
Phase 2:
|
||||
|
||||
- ST7796S display bring-up
|
||||
- Backlight control
|
||||
- Hello World screen
|
||||
- Static dashboard layout
|
||||
|
||||
Phase 3:
|
||||
|
||||
- Live battery card
|
||||
- Runtime / time-to-full card
|
||||
- Temperature list
|
||||
- Relay state list
|
||||
- ESP32 connection indicator
|
||||
|
||||
Phase 4:
|
||||
|
||||
- Touch support using FT6336U
|
||||
- Page navigation
|
||||
- Relay controls
|
||||
- Alarm details
|
||||
|
||||
Do not start with touch or config UI on the Pico. The WebUI is the preferred configuration workflow.
|
||||
|
||||
|
||||
|
||||
## Revised Dashboard Roadmap
|
||||
|
||||
### Phase 1
|
||||
ESP32 cargo controller backend
|
||||
- WiFi
|
||||
- WebUI
|
||||
- Relay control
|
||||
- JBD/Xiaoxiang BMS
|
||||
- DS18B20
|
||||
- Config persistence
|
||||
|
||||
### Phase 2
|
||||
Waveshare 5" ESP32-S3 Dashboard
|
||||
- Connect to cargo ESP AP
|
||||
- Read /status API
|
||||
- Basic dashboard
|
||||
- Battery SOC
|
||||
- Voltage/current
|
||||
- Temps
|
||||
- Relay status
|
||||
|
||||
### Phase 3
|
||||
LVGL Dashboard UI
|
||||
- Touch support
|
||||
- Relay controls
|
||||
- Alarm screens
|
||||
- Config/status pages
|
||||
|
||||
### Phase 4
|
||||
Extended Vehicle Telemetry
|
||||
- OBD-II
|
||||
- Coolant temp
|
||||
- GPS
|
||||
- Trip data
|
||||
- Vehicle metrics
|
||||
|
||||
### Phase 5
|
||||
Advanced Integrations
|
||||
- Home Assistant
|
||||
- MQTT
|
||||
- Grafana
|
||||
- InfluxDB\n\n- Added docs/dashboard-esp32s3.md as the primary dashboard implementation plan for the Waveshare 5 inch ESP32-S3 display.\n
|
||||
- OTA updates
|
||||
- Dashboard alert sounds
|
||||
- More vehicle PIDs
|
||||
- Historical charts
|
||||
|
||||
Reference in New Issue
Block a user