Loadpoint: keep vehicle SoC when re-assigning the same default vehicle

[Alexxtheonly]

Problem

A loadpoint with a default vehicle: whose SoC is known (e.g. a teslamate vehicle reading SoC over MQTT) publishes vehicleSoc = 0 to /api/state (and messaging) while charging, even though the per-cycle vehicle soc: NN% debug log shows the correct value every cycle. It recovers after a clean physical connect (charger status A→B→C) but gets stuck at 0 after an evcc restart that happens mid-charge. vehicleRange/vehicleOdometer are zeroed the same way.

Root cause

setActiveVehicle() calls unpublishVehicle() unconditionally at the end of every invocation, which sets lp.vehicleSoc = 0 and publishes 0 for soc/range/limit/odometer.

vehicleDefaultOrDetect() re-assigns the already-active default vehicle on every reconnect (introduced in #27364 to fix the estimator gradient on reconnect, #27359):

// Always call setActiveVehicle even if defaultVehicle is already active.
// ... resets the estimator's initial values for the new charging session.
lp.setActiveVehicle(lp.defaultVehicle)

So when the active vehicle does not change, unpublishVehicle() still wipes a perfectly valid SoC. publishSocAndRange() only repopulates vehicleSoc on a cycle where a SoC is actually read, so whenever a same-vehicle re-assign lands without an immediately-following successful read (e.g. the repeated reconnect/charger out of sync churn after a mid-charge restart), the published value stays 0.

Fix

Only reset the published vehicle data when the active vehicle actually changes (from != to). The soc estimator is still rebuilt unconditionally for v != nil (lines just above), so the #27359 fresh-estimator-on-reconnect behaviour is unchanged. Switching to a different vehicle — or to none on disconnect — still clears the stale data as before.

-	lp.unpublishVehicle()
+	if from != to {
+		lp.unpublishVehicle()
+	}

This does not touch the vehicle-detection path: with a pinned default vehicle, vehicleDefaultOrDetect takes the defaultVehicle != nil branch and never runs detection.

Test

Added TestReassignActiveVehicleKeepsSoc, which sets a known vehicleSoc, re-assigns the same active vehicle, and asserts the SoC is preserved — then asserts it is still cleared when the vehicle changes. It fails on master (expected 71, actual 0) and passes with the fix. Full ./core/... suite passes; gofmt/go vet/modernize clean.

Reproduction

• Loadpoint with a teslamate default vehicle (SoC via MQTT), actively charging.
• Restart evcc while the car is mid-charge.
• /api/state loadpoints[].vehicleSoc stays 0 while the logs show vehicle soc: NN% every cycle.

🤖 Generated with Claude Code

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[andig]

So when the active vehicle does not change, unpublishVehicle() still wipes a perfectly valid SoC.

Does this refer to the restart? At restart, evcc simply does not know what was assigned before and doing so is hence correct. Seems I'm missing the actual root cause here.

[andig]

Can we keep comments to 2 lines please? Your AI ignores the agents.md?