482 lines
8.3 KiB
Markdown
482 lines
8.3 KiB
Markdown
# Roadmap
|
|
|
|
This roadmap tracks planned Overland Controller development.
|
|
|
|
The roadmap is flexible and may change as the project evolves.
|
|
|
|
## Phase 1: ESP32 Controller Foundation
|
|
|
|
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
|
|
- Send relay commands
|
|
|
|
Initial dashboard screens:
|
|
|
|
- Main overview
|
|
- Battery screen
|
|
- Temperature screen
|
|
- Relay control screen
|
|
- Settings screen
|
|
|
|
## Phase 5: Pico Configuration UI
|
|
|
|
Status: planned
|
|
|
|
Goals:
|
|
|
|
- Configure device name
|
|
- Configure relay names
|
|
- Configure temperature names
|
|
- Configure BMS
|
|
- Run BLE scan workflow
|
|
- Save config
|
|
- Factory reset
|
|
|
|
Expected result:
|
|
|
|
A new installation can be configured from the dashboard without using a laptop.
|
|
|
|
## Phase 6: Vehicle Inputs
|
|
|
|
Status: planned
|
|
|
|
Possible inputs:
|
|
|
|
- Ignition signal
|
|
- Vehicle battery voltage
|
|
- OBD-II
|
|
- CAN bus
|
|
- 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.
|