Feature Request: SD Card Store-and-Forward for HTTPS POST / MQTT Destinations

[homelabforge]

Problem

When using WiCAN PRO with HTTPS POST (or MQTT) to push autopid telemetry to a self-hosted server, there's a complete data gap whenever the device loses WiFi connectivity — which happens every time the car leaves the home network.

For users running fleet telemetry, trip logging, or driving session analytics, this means the only data captured is the brief window at start and end of each trip when you're within WiFi range. The entire drive is missing.

Current State

The hardware for solving this already exists on WiCAN PRO:

• microSD card slot with 4-bit SDIO
• RTC for accurate timestamps even during power interruptions
• HTTPS POST push (working great in 4.47 beta) with Bearer token auth

SD card logging via SQLite is partially implemented, and I saw discussion about evaluating FlashDB as an alternative due to SQLite's 50-record query cap on ESP32.

Issue #486 requested store-and-forward for Home Assistant and was closed as completed, but the actual replay-on-reconnect behavior doesn't appear to have shipped.

Proposed Feature: Store-and-Forward

When WiFi is unavailable, WiCAN PRO should:

1. Continue polling PIDs on the normal autopid cycle
2. Buffer payloads to microSD with RTC timestamps, using whatever storage format works best (FlashDB, flat JSON-lines file, binary format — whatever performs well on ESP32-S3)
3. On WiFi reconnect, replay buffered payloads to configured HTTPS POST / MQTT destinations in chronological order
4. Include the original timestamp in each replayed payload (the timestamp field already exists in the HTTPS POST JSON schema)
5. Delete buffered entries after successful delivery (HTTP 2xx / MQTT PUBACK)

Why This Matters

The HTTPS POST feature made WiCAN PRO a legitimate telemetry device for self-hosted applications — not just a Home Assistant accessory. But without store-and-forward, it's only useful for stationary/garage monitoring, not actual driving telemetry. The hardware already has everything needed (SD + RTC), it just needs the firmware to tie them together.

Suggested Payload for Replayed Data

The current HTTPS POST payload structure already works — just populate the timestamp field that's already in the schema:

{
  "autopid_data": {
    "0C-EngineRPM": 2150,
    "0D-VehicleSpeed": 65,
    "05-EngineCoolantTemp": 88
  },
  "timestamp": "2026-02-07T14:23:45Z"
}

Receiving servers can use the timestamp to place data correctly in the timeline rather than using arrival time.

Additional Considerations

• Buffer size management: Configurable max SD usage (e.g., 100MB), FIFO eviction if full
• Replay rate limiting: Don't flood the server — a small delay (50-100ms) between replayed POSTs prevents overwhelming low-power backends
• Replay indicator: Optional flag in payload (e.g., "buffered": true) so servers can handle replayed data differently if needed
• Status during offline: Continue sending can/status on reconnect so the receiving server knows the session was continuous, not two separate starts

My Setup

• WiCAN PRO on firmware v4.47p beta
• HTTPS POST push to a self-hosted FastAPI backend
• Bearer token authentication
• Backend already supports optional timestamp field for exactly this use case

Thanks for the excellent work on the HTTPS POST feature — it's exactly what the self-hosted community needs. Store-and-forward would make WiCAN PRO the definitive OBD2 telemetry device.