Feat/dtc multi module scan - #204
Merged
Merged
Conversation
Previously DTC read/clear only ever targeted a single, fixed ECU. This
wires the app up to the new multi-module scheduleDTCAction(actions,
modules) added in obd-metrics 11.25.0-SNAPSHOT, reusing the existing
Diagnostic Request ID table (Settings > Adapter) as the module list -
every configured mapping (eg. "ABS" -> 18DA28F1) becomes a scan target,
so no new settings screen was needed.
WorkflowOrchestrator.scheduleDTCRead/Cleanup now accept a set of module
names to restrict the scan to, threaded from the DTC dialog through
DataLoggerService's Intent-based dispatch. The dialog shows a checklist
("Select Modules to Scan") before both Refresh and Clear when any modules
are configured, pre-checked with all of them, so a single tap reproduces
today's "scan everything configured" default; skipped entirely when
nothing's configured, preserving the original single-ECU behavior exactly.
The DTC list groups results under a module header row once a scan
actually spans more than one distinct module, and stays visually
unchanged otherwise.
Bumps the obd-metrics dependency to 11.25.0-SNAPSHOT.
The DRI table's requestKey (eg. "555", "ABS") was doubling as both the internal lookup ID and the only display label anywhere it showed up - Manage screen, DTC module picker/section headers, PID edit CAN Header dropdown - which is especially confusing for the numeric/synthetic keys. DiagnosticMappingItem gains a description field (defaults to "" for existing entries) with a displayName property (description, falling back to requestKey) used everywhere for display, while requestKey remains the only thing actually used for matching/lookup and the value persisted as a PID's canMode override. Populated default descriptions in the bundled vehicle profile .properties files for the entries I could confirm (eg. "555"/"444"/"666" verified against the "module" field on PIDs using those overrides in the obd-metrics library's resource JSON - gearbox/service/rfhub respectively). Left "DTCM" and "AAMR" undescribed - their referenced module resource files aren't present in this obd-metrics checkout to verify against, and guessing wrong for real vehicle module identity seemed worse than falling back to the raw ID. Also fixes a real bug found while wiring the PID edit form's CAN Header dropdown to show descriptions: it previously pre-filled with the literal default "01", and since the form always saves whatever's in that field, every newly-added PID silently got a canMode="01" override baked in unless manually cleared. Now resolves the box's text (whether from a clicked suggestion or the untouched default) back through a label->ID map before saving, so the field can show a friendly label while still persisting a valid ID.
Cross-referenced our DRI defaults against szrafale/StelvioOBD's ECUTarget.swift (same Giorgio platform), applied to the 10 Giulia 2.0 GME profile files (left the older 1.75 TBI profiles untouched - different engine platform, no evidence the chassis module wiring matches). Refined two descriptions with more precise detail confirmed by matching header: "555" -> Transmission TCU (ZF 8HP), "ABS" -> ABS/ESP (Continental MKC1). Filled in "DTCM", left blank previously since its header (DA1AF1) is an exact match to the reference's Electric Power Steering entry, despite the key name not obviously suggesting steering. Added four modules not previously present: Gear Selector (DA1FF1), Body Control Module (DA40F1), Airbag/SRS (DA58F1), and Headlights (DA70F1). Also added a separate Climate Control entry (DA48F1) rather than reusing/renaming the existing TRW_CLIMATE_CONTROL one (DA98F1) - the reference's climate header doesn't match ours, so both are kept as distinct, independently selectable scan targets rather than assuming one supersedes the other.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.