iUnreallx/ReDrive

Problem Current initialization logic relies on fixed Future.delayed calls and skips several critical ELM327 configuration commands. This works against a perfect C++ emulator but will break on real hardware with varying response times, cheap adapters, or different Bluetooth stack latencies. What's wrong specifically Future.delayed with hardcoded durations instead of waiting for actual adapter responses Missing ATS0 — spaces not explicitly disabled in responses Missing ATH0 — headers not explicitly disabled, parser relies on clean emulator output ATSP0 treated as if it completes protocol selection, when real initialization happens only on first OBD request like 0100 No extended timeout for the 0100 command that actually triggers bus initialization What needs to happen Remove all Future.delayed calls from initialization Implement proper response-based waiting in _sendAndWait Add explicit formatting configuration commands early in the sequence Move ATSP0 before the first real OBD reque

Goal: Split ObdProvider into focused OBD core modules. Scope: Extract ElmClient Extract ElmCommandQueue Extract ELM response/error parser Extract PID decoder Extract polling controller Keep ObdProvider as UI-facing state layer only Out of scope: ECU recovery logic multi-ECU transport reconnect Wi-Fi

Goal Implement a unified logging service that writes timestamped, tagged messages to a rotating file. The system will capture OBD commands, responses, transport events, and recovery attempts, enabling offline debugging of real‑world issues without a debugger attached. Motivation Currently, all communication with the ELM327 is invisible to the developer once the device is disconnected from the IDE. To diagnose problems like "zero data after re‑connection" or "adapter silence on third attempt", we need a persistent log of every command, response, timeout, and state transition. A built‑in log viewer in the settings screen will allow users to share logs directly from the app, making bug reports much more actionable. Sub‑tasks (each must be a separate PR) Logger service with file output and rotation Focus: infrastructure, no UI changes. Scope: Create LoggerService (singleton, pure Dart, no Flutter UI dependency). Accept messages with levels: debug, info, warning, error, elmtrace (f

Create a visual mockup for the Diagnostic Trouble Codes (DTC) screen, where users view and manage their car's fault codes. What we need: A static design proposal in PNG format (or a link to Figma/Penpot) showing the DTC screen. The screen should include: A list of current fault codes (e.g., P0301, P0420), each with code identifier and a short description. An indicator of code status (stored / pending / permanent), maybe color-coded. A "Clear codes" button or action. Some way to distinguish active vs historical codes (optional but appreciated). Style: consistent with the dark, modern automotive theme of the app (reference the dashboard concept if available). Information should be readable at a glance, possibly with color-coded severity levels (red = critical, yellow = warning). What we don't need (for this issue): No Flutter code or implementation. Purely visual concept. Not a final, pixel-perfect design – a high-quality mockup is enough. No need to provide the description database (t

Add basic support for multi-ECU environments by extending the data model and parser to handle CAN headers, without changing current behavior. Scope: Add optional sourceEcuId (int?) field to ObdData model, defaulting to null. Update _parseResponse to detect a 3‑byte CAN header (e.g. 7E8) at the beginning of a response when the ELM327 is in headers‑on mode (AT H1). If a header is found, extract it and set sourceEcuId; otherwise leave as null. No functional changes to polling, ECU selection, or handshake logic. Purely infrastructure preparation. Why: The current parser ignores CAN headers, which will cause data mix‑ups once multiple ECUs respond (engine, transmission, etc.). Adding sourceEcuId now makes the model ready for the upcoming ElmClient refactor, where AT H1 will be used and multi‑ECU filtering will be implemented. Completely backward‑compatible – nothing breaks. Out of scope: Enabling AT H1 or any multi‑ECU selection/filtering logic.