Loadpoint: authorize charging by vehicle id

[Dodi1968]

To use the api.Authorizer it needs a corresponding function to authorize charging by the RFID of the selected / identified car.

This PR specifically introduces these changes:

loadpoint_vehicle.go

• add a new function to authorize charging by vehicle id, using the first RFID entry in car configuration

loadpoint.go

• triggering the authorization function, if the reason for charger status B is “Waiting for Authorization”
• moving the lines related to processing status reason to a position after identifying the vehicle, because the authorization function needs the RFID of the identified car as input (speeds up the authorization process)

Furthermore, this PR implements the api.Authorizer interface for the Kathrein charger to send the RFID to the charger via ModBus.
From firmware version 2.8.0 (Modbus Release Version 1.5) the Kathrein charger has 3 new registers for supporting authentication via ModBus.

Benefit: For users (e.g. company car drivers) with the charger setting “Authorize charging via RFID” it is no longer necessary to hold the RFID card/tag against the wallbox. With this PR the charging process starts immediately when a car with registered RFID has been identified.
PR implements the feature request: #20958

To use this feature for Kathrein chargers, the option “Authentication via ModBus with registered RFIDs” must be set in the user interface of the Kathrein charger. If this option is not set (default), the function has no effect (and no error either).

The authorization function is executed only if each of the following conditions is met:

• Charger status: B
• Status reason: Waiting for Authorization
• A known vehicle was selected manually or detected automatically
• At least one RFID is entered in the configuration of the selected / identified vehicle

If the (first) RFID entry in car configuration is invalid, the function has no effect. In this case the charger continues waiting for authorization.

I have been testing these changes intensively for 2 weeks with my Kathrein KWB AC-40 based on various test cases. It works very well without any errors. Especially there is no conflict with the identify (by RFID) function.

[sourcery-ai]

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

• The Update flow will call authorizeVehicle on every cycle while status B and ReasonWaitingForAuthorization are active; consider tracking an authorization state per session to avoid repeatedly sending the same RFID to the charger.
• In Kathrein.Authorize, the padding loop appending zeros to tag can be simplified and made clearer by preallocating a 32-byte slice and using copy to fill it before writing the registers.
• In authorizeVehicle, the first entry from lp.vehicle.Identifiers() is assumed to be the appropriate RFID; if Identifiers may contain different kinds of identifiers, consider filtering or tagging them so only suitable RFID-like values are used for authorization.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `Update` flow will call `authorizeVehicle` on every cycle while status B and `ReasonWaitingForAuthorization` are active; consider tracking an authorization state per session to avoid repeatedly sending the same RFID to the charger.
- In `Kathrein.Authorize`, the padding loop appending zeros to `tag` can be simplified and made clearer by preallocating a 32-byte slice and using `copy` to fill it before writing the registers.
- In `authorizeVehicle`, the first entry from `lp.vehicle.Identifiers()` is assumed to be the appropriate RFID; if `Identifiers` may contain different kinds of identifiers, consider filtering or tagging them so only suitable RFID-like values are used for authorization.

## Individual Comments

### Comment 1
<location> `core/loadpoint.go:1944-1949` </location>
<code_context>
 		}
 	}

+	// publish charger status reason
+	// authorize by vehicle id if waiting for authorization
+	if sr, ok := lp.charger.(api.StatusReasoner); ok && lp.GetStatus() == api.StatusB {
+		if r, err := sr.StatusReason(); err == nil {
+			lp.publish(keys.ChargerStatusReason, r)
+			if r == api.ReasonWaitingForAuthorization {
+				lp.authorizeVehicle()
+			}
</code_context>

<issue_to_address>
**suggestion (bug_risk):** Repeated authorization attempts on every update while waiting for authorization may be too aggressive.

In `Update`, when `StatusReason` is `ReasonWaitingForAuthorization`, `lp.authorizeVehicle()` is invoked on every cycle. This can result in excessive authorization requests depending on the update frequency and charger behavior. Consider tracking authorization attempts per session (e.g., a flag or timestamp on the loadpoint) so you only send authorization once or at a throttled rate, while still allowing retries for transient failures.

Suggested implementation:

```golang
	// publish charger status reason
	// authorize by vehicle id if waiting for authorization (throttled)
	if sr, ok := lp.charger.(api.StatusReasoner); ok && lp.GetStatus() == api.StatusB {
		if r, err := sr.StatusReason(); err == nil {
			lp.publish(keys.ChargerStatusReason, r)

			if r == api.ReasonWaitingForAuthorization && lp.shouldAuthorizeVehicle() {
				lp.authorizeVehicle()
				lp.markAuthorizationAttempt()
			}
		} else {
			lp.log.ERROR.Printf("charger status reason: %v", err)
		}
	}

```

To fully implement throttled / per-session authorization you should:

1. Add state to the `Loadpoint` struct to track authorization attempts for the current session, for example:
   - A `time.Time` for last attempt (e.g. `lastAuthAttempt time.Time`)
   - Optionally a `bool` like `authAttemptedForSession bool` if you want strictly one authorization per session.

2. Implement the two helper methods used above on `Loadpoint`:
   - `shouldAuthorizeVehicle()`:
     - Returns `true` if either:
       - No attempt has been made for the current session, or
       - `time.Since(lp.lastAuthAttempt) >= authorizationMinInterval` (e.g. 5–30 seconds, configurable if possible).
     - Returns `false` otherwise.
   - `markAuthorizationAttempt()`:
     - Updates `lp.lastAuthAttempt = time.Now()`.
     - Optionally sets `lp.authAttemptedForSession = true`.

3. Decide how to detect session boundaries and reset flags/timestamps, e.g.:
   - When the vehicle disconnects,
   - Or when charging stops / transitions from StatusB to another status.
   - In that logic, reset `lp.authAttemptedForSession = false` and possibly `lp.lastAuthAttempt = time.Time{}`.

4. Ensure you add any required imports (e.g. `time`) and, if you use an interval constant, define it in an appropriate place in `core/loadpoint.go` (e.g. `const authorizationMinInterval = 10 * time.Second` or similar).

These changes will ensure `lp.authorizeVehicle()` is not called on every update cycle while still allowing controlled retries for transient failures.
</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.}

[andig]

I don‘t think we want to do this. KEBA was a necessity at the time. I‘d rather not extend this to other chargers and rather remove KEBA if we can.

/cc @premultiply @GrimmiMeloni

[Dodi1968]

Where is the problem? I testest this for 2-3 weeks without any problems. For me it is a killer feature.

[andig]

No problem. I'm just not convinced that we want to further proliferate the use of api.Authorizer. And as a minimum we'd need to do this consistently across all devices supporting it if we want to do this.

[Dodi1968]

But there is no pressure to implement this immediately for all chargers. This PR creates only the basis for implementing the charger specific API. Do you know, how many wallboxes are there currently that support the authorization via modbus?
I would only implement this for a specific charger if there is interest among the users of the charger. And then someone will be found to implement it. It's not particularly difficult.

[andig]

Do you know, how many wallboxes are there currently that support the authorization via modbus?

In evcc: one, but unused.

If I'm not mistaken that interface is a leftover that is not used at all today. We need to make a conscious decision if we still want to maintain or want to remove it. Pressure in terms of changes always arises from chance.

[marcelGoerentz]

I would like to use this interface for my Tinkerforge WARP3 chargers too.

[premultiply]

Thanks for the PR, but we don't want to implement it this way.
Among other things, it would favour a strong identifier (RFID tag) over a weaker identifier (vehicle API heuristics).
Besides, the API function is already on the list of curiosities we'd like to get rid of.

[andig]

If we don‘t do this here, we should remove the interface altogether.