fix: republish Total Battery Capacity after HA number update#445
Merged
Conversation
The HA "Total Battery Capacity" number and sensor share the same MQTT state topic. The `_set` handler used to mutate the in-memory override on `VehicleInfo.custom_battery_capacity` and return `RESULT_DO_NOTHING`, relying on the next charge-status poll to refresh the shared sensor topic. As a result the HA number widget displayed the user's retained `/set` value while the sensor (and any UI binding to it) remained stuck on the previous value — typically the per-model default published from `rvs_charge_status.get_actual_battery_capacity`. Republish `vehicle.real_battery_capacity` to the state topic from the handler itself so the sensor reflects the change immediately, without forcing an extra vehicle poll. Reading through `real_battery_capacity` keeps the `payload == 0` "clear override" path consistent: it falls back to the per-model default instead of publishing `0`. The kWh-derived sensors (`SoC_kWh`, `Last Charge SoC kWh`, the two `Power Usage` sensors) still use the previous correction factor until the next charge-status update, same staleness window as before.
Stub `vehicle.real_battery_capacity` on the mock so the existing retained- replay test exercises the new state-topic publish, and add coverage for the two interesting branches: * payload `0` clears the override and republishes the per-model default * unknown model (`real_battery_capacity is None`) skips the publish
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.
Summary
VehicleInfo.custom_battery_capacityand returningRESULT_DO_NOTHING, so the sensor stayed pinned to the previously published value (typically the per-model default inrvs_charge_status.get_actual_battery_capacity) until the next charge-status poll. Result in HA: number widget shows the new value, sensor still shows the old one.vehicle.real_battery_capacityto the state topic right after the in-memory update, so the sensor catches up immediately. Reading throughreal_battery_capacitykeeps thepayload == 0(clear override) path consistent — it falls back to the per-model default instead of publishing0.SoC_kWh,Last Charge SoC kWh, the twoPower Usagesensors) still use the previousbattery_capacity_correction_factoruntil the next charge-status update — same staleness window as before, intentional for this local-only fix.Test plan
test_retained_battery_capacity_replays_to_vehicle_infoto stubvehicle.real_battery_capacityand assert the new state-topic publish.test_battery_capacity_zero_payload_publishes_model_default(payload0→ per-model default republished).test_battery_capacity_skips_publish_when_no_default(real_battery_capacity is None→ publish skipped).poetry run pytest— 276 passed.