compare vehicle status with charger status

[kaindl]

exactly compare charger status with vehicle status for identifying candidates instead of selecting all vehicles in states B and C

marked as draft as the Features are not yet tested with real cars and chargers, only in the evcc-demo with demo vehicles on my laptop

[andig]

PR in error state, no obvious progress. Lets reopen once clean.

[kaindl]

PR in error state, no obvious progress. Lets reopen once clean.

@andig it was marked as "draft" for a reason...

I tested in the last days with real cars and adapted the testcases now -> please reopen

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• Consider passing the charger status (e.g., lpStatus api.ChargeStatus) into identifyVehicleByStatus instead of the full loadpoint.API to keep the function more focused and easier to reuse/test in isolation.
• With the new strict status == lp.GetStatus() condition, it might be worth thinking about how to handle transient mismatches (e.g., brief timing differences between vehicle and charger state) so that candidate identification does not become too brittle.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider passing the charger status (e.g., `lpStatus api.ChargeStatus`) into `identifyVehicleByStatus` instead of the full `loadpoint.API` to keep the function more focused and easier to reuse/test in isolation.
- With the new strict `status == lp.GetStatus()` condition, it might be worth thinking about how to handle transient mismatches (e.g., brief timing differences between vehicle and charger state) so that candidate identification does not become too brittle.

## Individual Comments

### Comment 1
<location path="core/coordinator/coordinator.go" line_range="149-150" />
<code_context>

-			// vehicle is plugged or charging, so it should be the right one
-			if status == api.StatusB || status == api.StatusC {
+			// vehicle is plugged or charging and has the same state as the charger, so it should be the right one
+			if (status == api.StatusB || status == api.StatusC) && status == lp.GetStatus() {
 				if res != nil {
 					c.log.WARN.Println("vehicle status: >1 matches, giving up")
</code_context>
<issue_to_address>
**suggestion (performance):** Cache the loadpoint status outside the loop to avoid repeated calls and potential inconsistency.

`lp.GetStatus()` is called for each vehicle during matching. If this is non-trivial or can change mid-loop, it adds overhead and makes the match timing-dependent. Read it once before the loop (e.g. `lpStatus := lp.GetStatus()`) and use `status == lpStatus` in the condition to keep the logic consistent and avoid repeated work.

Suggested implementation:

```golang
func (c *Coordinator) identifyVehicleByStatus(available []api.Vehicle, lp loadpoint.API) api.Vehicle {
	var res api.Vehicle

	c.mu.RLock()
	lpStatus := lp.GetStatus()

```

```golang
			// vehicle is plugged or charging and has the same state as the charger, so it should be the right one
			if (status == api.StatusB || status == api.StatusC) && status == lpStatus {

```
</issue_to_address>

---

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.}

[kaindl]

suggestions from sourcery-ai make sense to me -> marked as draft, will include them tonight

[andig]

Really no need for comment noise- just do it ;)

[kaindl]

changes to coordinator_test.go overlap with #29592, further changes will be necessary here if #29592 will be merged -> waiting for decision on #29592

[kaindl]

As after the review #29592 won't be merged in it's current state, this one does not have to wait anymore :)

[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]

exactly compare charger status with vehicle status for identifying candidates instead of selecting all vehicles in states B and C

As mentioned numerous times before, this breaks with the inherently slow apis.

[kaindl]

@andig we already discussed that in slack? 🤔

I can see 3 possible scenarios:

1. If the vehicle API is very slow to update, state of vehicle will still be read with A, when the autodetection is done -> this behaviour won't change with this PR
2. When charger will only be disabled, after the car is recognized successfully and we did not run into case 1, vehicle will be read with state B when autodetection is executed -> also no change in behaviour with this PR
3. When charger gets enabled immediately, car state will traverse states A -> B -> C very fast and state could still be read with state B when autodetection takes place. -> in this case the detection for a single car will be worse with this PR.

I don't know, how relevant the precondition for case 3 (charging starts before detection is successful) is.
On the other hand it is an improvement for everyone having more than one car registered in evcc where one of them is charging at other places regularly.

When I asked for opinions on this tradeoff, your answer was "Gerne PR, Beides ist am Ende irgendwie falsch."

So how to proceed from here?

[andig]

3. is still relevant. Imho this should be the immediate fallback even in den first cycle.

[kaindl]

@andig

So how to proceed from here?