fix(smart): correct inverted v.b.power sign on SQ/SE (issue #40) - #44
Draft
kezarjg wants to merge 1 commit into
Draft
fix(smart): correct inverted v.b.power sign on SQ/SE (issue #40)#44kezarjg wants to merge 1 commit into
kezarjg wants to merge 1 commit into
Conversation
Both OVMS smart modules (453/forfour = SQ, ED/fortwo = SE) report v.b.power with an inverted sign: negative while driving (consuming), positive while charging - the opposite of the OVMS core / Iternio convention. ABRP uses power for consumption calibration, so it read consumption as regen and the calibrated reference consumption drifted toward zero. overrideMetricMap now corrects power for these vehicles by keeping the module's power magnitude and taking its sign from v.b.current, which the same modules report correctly. Because v.b.current is correct in both the buggy and a future upstream-fixed firmware, the correction is self-healing: once v.b.power's sign is fixed upstream it becomes a no-op, with no plugin change needed to retire it. Only power is affected. Upstream firmware bugs filed separately against vehicle_smarteq and vehicle_smarted.
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
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.
What & why
Fixes the inverted battery-power sign on smart 453/forfour (
SQ) and smart ED/fortwo (SE), which causes ABRP's calibrated reference consumption to drift toward zero (#40).Both OVMS smart modules report
v.b.powerwith the wrong sign - negative while driving (consuming), positive while charging - the opposite of the OVMS core / Iternio convention (positive = output/discharging). ABRP usespowerfor consumption calibration, so it reads consumption as regen and the reference consumption decays.This was confirmed with on-device captures from both cars (telemetry as received by ABRP):
median( power / (V*I) )current > 0power > 0Driving is net discharge (must be positive by convention), so
v.b.currentis the correctly-signed metric andv.b.poweris inverted on both cars.The fix
overrideMetricMapnow correctspowerforSQ/SEby keeping the module's power magnitude and taking its sign fromv.b.current:Self-healing:
v.b.currentis correctly signed in both the current (buggy) firmware and a future upstream-fixed firmware (the fix only touchesv.b.power). So once the module'sv.b.powersign is corrected upstream, this override returnsv.b.powerunchanged - it becomes a no-op with no plugin change needed to retire it.Scope is limited to
power;current,is_charging, andis_dcfcare unchanged.Upstream
The root defect is in the OVMS vehicle-module firmware; separate firmware bugs are being filed against
vehicle_smarteqandvehicle_smarted. This PR is the plugin-side workaround so affected users get correct calibration now.Tests
Added
overrideMetricMapcoverage for the smart override (driving correction, charging correction, post-fix no-op, zero-current,SEshares the override, unsupported when current absent, and non-smart passthrough). Full suite: 71 passing.VERSION->2.3.1, CHANGELOG updated.