Repository navigation
Health/range: estimators merged ahead of use never run in the app, and "full range" has three inconsistent definitions #122
Description
Code that never runs in the app
FullRangeScaleEstimator(core/history/FullRangeScale.kt)`` has no caller inapp/.TeslaCommands.Charge.chargingMphhas no caller.charge_rate_mph(_float)is parsed but never stored inBatterySample.chargeProjection(samples, chargeRateMph, fullRangeMiles)is always called with the default arguments (CarScreen.kt#L531), so its miles-first branch never runs.healthSummary(samples)is always called withoutepaRatedRangeMilesornewCapacityKwh(CarScreen.kt#L110), and nothing in the UI can set them. As a resultRatedRangeEstimatorand the SoH branch ofEnergyDeltaEstimatornever execute, andHealthFusion.fuseis only ever called with(null, null). The health card still promises "A state-of-health percentage appears once the car's factory range is set" (BatteryHealthCard.kt#L100-L104).``
Each of these has its own tests (FullRangeScaleTest, RatedRangeEstimatorTest, HealthFusionTest, parts of BatteryChartTest and HealthSummaryTest). Coverage therefore looks healthy, but those tests don't exercise anything the app actually does. The master plan calls the range backbone "Core landed", which is true of the code but misleading about the product.
"Full range" is computed three different ways
The same data can give three different answers:
FullRangeScale: intersection of brackets derived from integer-SOC rounding;ChargeSession.fullRangeMilesin the app's health code: rated miles added ÷ SOC swing;- the single-sample fallback in
healthSummary:ratedRange / (level / 100).
Robustness once it is wired
FullRangeScaleEstimator.estimate intersects brackets across all samples, with no window. Any real drift — degradation, a firmware rescale, temperature effects, all raised in docs/research/range-as-soc-signal.md — or a single outlier makes upper <= lower. From then on the estimator returns null permanently, and rejectsContradictorySamples tests for exactly that. The UI shouldn't depend on it until it uses a window (e.g. the last N sessions) or an outlier-tolerant fit.
Smaller leftovers in the same area
BatterySample.percentis a pure alias forbatteryLevel(its KDoc says "derived for the chart…") and has its own test (Tests: Go vectors aren't wired to expected.txt, the request path has no oracle, and several tests are tautological #121).- The
BatterySample.vehicleIdKDoc says "Empty on rows written before per-vehicle history existed", but the 12-column parser rejects such rows.
Proposal
- Land each estimator in the same PR as the code that uses it, or delete it until then (the pre-1.0 policy allows this).
- Keep one definition of "full range", in
core/health, and move the app's charge-session segmentation there too (Health: capacity and full range are over-estimated when a charge session is first seen mid-way #114). - Mark unwired items as such in the master plan.
Activity
dzid26 commentedon Oct 21, 2026
Checked against main (8cbaab0) on 2026-10-21.
Done
FullRangeScaleEstimatornow has callers inCarScreen.kt,DriveHistoryCard.kt,TripNotification.ktandHealthSummary.kt.chargeProjectionis called withfullRangeMiles = scale?.fullRangeMiles, so its miles-first branch runs.Still open
healthSummaryis still called withoutepaRatedRangeMilesornewCapacityKwh(CarScreen.kt:164), so the rated-range and SoH branches andHealthFusionwith real inputs still never run.TeslaCommands.Charge.chargingMph/charge_rate_mphhas no app caller.BatterySample.percentis still a pure alias ofbatteryLevel(BatteryHistory.kt:43).Keeping this open for the remaining items.
Generated by Claude Code
dzid26 commentedon Oct 21, 2026
Update:
BatterySample.percent(the pure alias ofbatteryLevel) is removed, with callers moved tobatteryLevel(#322, merged as 239bb90).Generated by Claude Code
dzid26 commentedon Oct 21, 2026
#333 is merged. It closes the "full range has three definitions" and "estimator never wired" points:
FullRangeScalestores one slope (milesPerPercent) and an offset. The range at a level comes fromratedMilesAt, and the range at 100% frommilesAtFull. The Health card, the trip estimate, the past-trips card, the chart cursor and the charge projection all read those.FullRangeScalesfits each car once and shares the result with every card, the health summary and the trip notification.Still open in this issue:
epaRatedRangeMilesandnewCapacityKwhare never passed tohealthSummary, so the state-of-health branch ofEnergyDeltaEstimatorandHealthFusionnever run in the app, and the health card text promises a percentage it can't show.charge_rate_mphis parsed but never stored, so the miles-first branch ofchargeProjectionis only reached from tests. Next step is a decision on what to keep, listed in the project thread.Generated by Claude Code
dzid26 commentedon Oct 23, 2026
Closing as done, checked against
mainat 9162ac2:FullRangeScaleEstimatorruns in the app (FullRangeScales), and its fit is a weighted line over level steps, so one outlier no longer makes it return null for good.chargeRateMphis stored inBatterySampleand drives the charge projection.healthSummarynow gets the rated range from the new Edit car dialog (feat(app): edit car dialog with VIN, new-car range and capacity #354), so SoH shows. The health footer's promise only appears while it is missing.HealthFusion, the energy-delta SoH and the typed capacity were removed: SoH is the fitted range over the EPA rated range.BatterySample.percentalias and the stalevehicleIdKDoc are gone.Generated by Claude Code