illusion2001

Sieht für mich so aus, ja. Ich habe dort eine Pull Request erstellt, das muss jetzt noch durch das approval und wenns durch geht, kannst du das in der nächsten EVCC nightly Version testen.

Die Logik in evcc ist so gebaut, dass sie es erlaubt, sowohl die mac als auch einen zusätzlichen RFID tag auszuwerten. Dazu sucht evcc in "charge_tracker/current_charge" and der "tag_id" und in "ev/state" nach der "mac". Hier sehen wir nun, dass in "charge_tracker/current_charge" die "mac" statt der "tag_id" gesendet wird. Gibt es überhaupt Konstellationen, in der die WARP beides sendet? Bswp. Autorisierung per RDIF tag, aber dennoch wird die mac gesendet? Passiert das, wenn man "Automatische Ladefreigabe per Fahrzeugidentifikation aktivieren" deaktiviert und RDIF freigabe aktiviert? Kommt dann in "charge_tracker/current_charge" die "tag_id" und dennoch in "ev/state" die "mac"? Wenn ja, macht die Implementierung in evcc Sinn und es muss nur das Thema "veraltete Daten" behoben werden.

GitHubIssue · evcc-io/evccsolar charging ☀️🚘. Contribute to evcc-io/evcc development by creating an account on GitHub.

Ich denke evcc benutzt Daten aus einer alten Session [warp-ws] TRACE 2026/09/24 23:22:38 websocket: event charge_tracker/current_charge: {"user_id":1,"meter_start":16367.78223,"evse_uptime_start":547734036,"timestamp_minutes":29838082,"authorization_type":4,"authorization_info":{"mac":"00:7D:FA:09:FD:19"},"charger_name":"87s6"}Die WARP API docs spezifizieren authorization_type 0 bis 3 und evcc erwartet "authorization_info contains tag_id and tag_type.". Typ 4 ist wie es scheint noch nicht dokumentiert und enthält "mac". Wird die API spec aktualisiert? Ich forsche noch ein bisschen und mache dann ggf. ein EVCC issue auf.

Kannst du bitte mal ein log mit dem lp-2 auf debug, warp-ws auf trace machen, bei dem di den e-up ansteckst und mit 04:68:1C:22:BC:73:80 autorisierst?

Jetzt fehlt leider der loadpoint lp-2. Sorry, war wohl nicht präzise genug.

Nächstes mal bitte warp-ws auf trace in evcc.

Auf evcc Seite wurde kürzlich (getrieben durch die WARP Integration) ermöglicht, mehrere ids zu übertragen, also die vehicle MAC und den verwendeten RFID tag. Davor wurde bei vorhandener MAC nur diese ausgewertet, der Fehler könnte so also bis vor kurzem nicht auftreten bzw. wurde maskiert. Aus Sicht von evcc sieht es so aus, als würde in charge_tracker/current_charge im Feldauthorization_info noch ein alter tag stecken (sofern eweri nicht für die aktuelle Session einen falschen vorgehalten hat). Hier die GitHub discussion dazu https://github.com/evcc-io/evcc/discussions/33912#discussioncomment-18544154. Ich warte dort noch auf ein trace log, um sicherzustellen, dass evcc auch mit aktuellen Daten arbeitet.