feat(obd): let OBD sensors extract values by byte offset - #62
Merged
Conversation
formula variables address only the first 20 bytes of a response, which is not enough for values that sit deep in a long frame. The Hyundai 21 03 block is the case at hand: it answers on the engine ECU with DPF data and the total odometer in one response, and the odometer (OBDb's HYUNDAI_ODO_V2) lives at bytes 57-60 as a 32-bit value divided by 1000. Accept the existing `decode` block on OBD sensors and prefer it over `formula` when both are set. DecodeConfig and Decoder.decodeStructured are already used by advertisement and notify sensors, so this only wires the OBD dispatch path to them — offset, length, type, endian, scale, offset_value, bitmask and map all behave as they do elsewhere. decodeStructured returns null when offset + length runs past the response, and emit() drops nulls, so a car whose frame is too short publishes nothing rather than a wrong number. A gasoline car with a short 21 03 block therefore stays silent instead of reporting garbage. Also warn during validation when an OBD sensor has a pid but neither formula nor decode, since it can never produce a value. Presets are expanded into formula at load time, so preset-based sensors do not trip this. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
formula variables address only the first 20 bytes of a response, which is not enough for values that sit deep in a long frame. The Hyundai 21 03 block is the case at hand: it answers on the engine ECU with DPF data and the total odometer in one response, and the odometer (OBDb's HYUNDAI_ODO_V2) lives at bytes 57-60 as a 32-bit value divided by 1000.
Accept the existing
decodeblock on OBD sensors and prefer it overformulawhen both are set. DecodeConfig and Decoder.decodeStructured are already used by advertisement and notify sensors, so this only wires the OBD dispatch path to them — offset, length, type, endian, scale, offset_value, bitmask and map all behave as they do elsewhere.decodeStructured returns null when offset + length runs past the response, and emit() drops nulls, so a car whose frame is too short publishes nothing rather than a wrong number. A gasoline car with a short 21 03 block therefore stays silent instead of reporting garbage.
Also warn during validation when an OBD sensor has a pid but neither formula nor decode, since it can never produce a value. Presets are expanded into formula at load time, so preset-based sensors do not trip this.