Hallo!

Nach dem Upgrade meiner DIY-WARP3 auf DIY-WARP4 hat eigentlich alles super funktioniert. Unseren e-up identifiziere ich über einen NFC-Dongle und der ID.5 wird über ISO15118 erkannt. Seit der Firmware 2.13.(34) klappt das nicht mehr, sondern in evcc taucht immer der e-up auf, nicht mehr der ID.5. In der WARP wird das Fahrzeug richtig zugeordnet.

Leider weiß ich nicht mehr bis zu welcher Firmware es noch korrekt mit evcc funktioniert hat. Es ist mir auch nicht sofort aufgefallen. Es kann sein, dass die Problem mit der 2.13.1 noch nicht war. Heute habe ich noch einmal einen Test gemacht, Firmware 2.13.4 installiert und Autos umgesteckt - der ID.5 taucht in evcc immer als e-up auf. Dieser Fehler ist also mindestens in der 2.13.3 und 2.13.4 vorhanden.

Jetzt ist mir gerade aufgefallen, dass ich die WARP4 in evcc nach dem Upgrade nicht neuangelegt habe, sondern immer noch die Integration "Tinkerforge WARP3 Pro" verwende. könnte das ein Problem sein?

Schon mal Danke,

eweri

Mit dem WARP4-Template kannst du als Fahrzeug „ISO15118“ auswählen und die MAC-Adresse (bzw. den statischen Teil davon) als NFC Tag-Id hinterlegen. Damit funktioniert die Fahrzeugerkennung bei mir problemlos.

Gruß Thomas

Okay - ich habe in evcc die WARP4 neu angelegt und wieder getestet. Hat leider nichts gebracht. Der ID.5 wird von der WARP korrekt erkannt, aber in evcc taucht der ID.5 trotzdem als e-up auf.

Ich habe in der WARP den ID.5 mit seiner ISO15118-ID und einem NFC-Dongle hinterlegt. Allerdings sind beim ID.5 nur die drei Stellen konstant, die letzten drei Stellen wechseln von Ladevorgang zu Ladevorgang.

Ich bin aber etwas weiter - laut Log von evcc kennt es die ISO15118-ID und den NFC-Dongle nicht

```
[lp-2 ] DEBUG 2026/09/20 20:21:03 charge total import: 16248.364kWh
[lp-2 ] DEBUG 2026/09/20 20:21:03 charger vehicle id: 00:7D:FA:XX:XX:XX, 04:68:1C:22:XX:XX:XX (es werden die kompletten IDs übertragen)
[lp-2 ] INFO 2026/09/20 20:21:03 vehicle updated: unknown -> e-up WiCAN
[lp-2 ] DEBUG 2026/09/20 20:21:03 vehicle soc: 46%
```

Was allerdings komisch ist, denn die ISO-ID und NFC-ID ist korrekt in der Fahrzeug-Konfig hinterlegt. Was mich halt stutzig macht, dass dieses Problem erst auftrat, nach einem Firmware-Update der WARP - ich kann mich da aber auch täuschen.

So, jetzt habe ich den ID.5 in evcc als ISO15118 angelegt (bisher war es als VW EU Data Act angelegt) und auch jetzt hat es nicht richtig funktioniert. Das kann damit eigentlich nur noch ein Fehler in evcc sein.

Ich mache da mal einen Bug-Report auf

Ich habe es gerade nochmal mit der aktuellen WARP-Firmware und evcc-Version getestet - mein ID.4 wird weiterhin problemlos erkannt.

Wie hast du den ID.5 denn in evcc hinterlegt? Der statische Teil der MAC-Adresse des Fahrzeugs muss unter „RFID-Identifikation“ eingetragen werden, gefolgt von einem Sternchen (also z. B. 11:22:33:*)…

Es scheint doch ein Fehler in der WARP zu sein:

Bei der Suche nach dem Fehler im evcc Forum ist aufgefallen, dass die von der Wallbox übergebenen Tags nicht stimmen:

In meiner Wallbox sind drei NFC-Tags hinterlegt:
ID.5: 04:53:30:22:BC:73:80
e-up: 04:68:1C:22:BC:73:80
Gast: 04:69:96:72:3B:74:80

Der ID.5 hat eine ISO-ID von 00:7D:FA:XX:XX:XX (die letzten Tuppel ändern sich pro Ladevorgang)

in evcc habe ich vier Fahrzeuge:
e-up - keine RFID-Tag zugeordnet
e-up WiCAN - 04:68:1C:22:BC:73:80
Gast - 04:69:96:72:3B:74:80
ID.5 - 00:7D:FA:*, 04:53:30:22:BC:73:80

[lp-2 ] DEBUG 2026/09/20 20:21:03 charger vehicle id: 00:7D:FA:XX:XX:XX, 04:68:1C:22:XX:XX:XX (es werden die kompletten IDs übertragen)

Und im evcc-Forum ist jemand aufgefallen, dass die Wallbox die ISO-ID des ID.5 und die RFID des e-up WiCAN überträgt - manchmal sieht man den Wald vor lauter Bäumen nicht.

Also in eine der letzten Firmware-Updates der WARP muss sich ein Fehler eingeschlichen haben.

Kannst du den Fehlerfall nochmal herstellen, also dass du dein Auto anschließt und die falsche ID im EVCC-Log steht, und dann einen Debug-Report runterladen und hier anhängen?

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.

Heut kam eine neue evcc Version 0.316 raus und zumindest bei einem kurzen Test tauchte die falsche RFID nicht mehr auf, im Log von evcc stand nur die MAC vom Auto.

Morgen kann ich einen gründlicheren Test machen

Moin!

Ich bin gerade nach Hause gekommen und habe den ID.5 angeschlossen in EVCC wurde mir wieder der e-up angezeigt, bis ich manuell den Fahrzeugtyp geändert habe. Im Log von evcc kann man wieder sehen, dass anscheinend die korrekte MAC und die falsche RFID übergeben wird.

Habe das Log aus der WARP angefügt.

```
[lp-2 ] DEBUG 2026/09/23 21:39:05 charge total import: 16336.581kWh
[lp-2 ] DEBUG 2026/09/23 21:39:05 charger vehicle id: 00:7D:FA:07:CF:4C, 04:68:1C:22:BC:73:80
[lp-2 ] INFO 2026/09/23 21:39:05 vehicle updated: unknown -> e-up WiCAN
[lp-2 ] DEBUG 2026/09/23 21:39:05 vehicle soc: 74%
[lp-2 ] DEBUG 2026/09/23 21:39:05 vehicle range: 175km
…
[lp-2 ] DEBUG 2026/09/23 21:40:05 charge total import: 16336.593kWh
[lp-2 ] DEBUG 2026/09/23 21:40:05 charger status: C
[lp-2 ] DEBUG 2026/09/23 21:40:05 charge start energy: 16336.593kWh
[lp-2 ] INFO 2026/09/23 21:40:05 start charging ->
[lp-2 ] DEBUG 2026/09/23 21:40:05 wake-up timer: stop
[lp-2 ] DEBUG 2026/09/23 21:40:05 charger soc: 22%
[lp-2 ] DEBUG 2026/09/23 21:40:05 vehicle soc (estimator): 22%
[lp-2 ] DEBUG 2026/09/23 21:40:05 !! plan: plan time zero
[lp-2 ] DEBUG 2026/09/23 21:40:05 pv charge current: min 8A > 0A (2139W @ 1p, battery: false)
[lp-2 ] INFO 2026/09/23 21:40:19 vehicle updated: e-up WiCAN -> ID.5
[site ] DEBUG 2026/09/23 21:40:20 ----
[lp-2 ] DEBUG 2026/09/23 21:40:20 charge power: 1724W
[lp-2 ] DEBUG 2026/09/23 21:40:20 charge currents: [7.62 0 0]A
[lp-1 ] DEBUG 2026/09/23 21:40:20 charge power: 0W
[site ] DEBUG 2026/09/23 21:40:20 grid power: 2107W
[site ] DEBUG 2026/09/23 21:40:20 grid powers: [94 1811 201]W
[site ] DEBUG 2026/09/23 21:40:20 grid currents: [0.932 8.04 0.982]A
[site ] DEBUG 2026/09/23 21:40:20 pv 1 power: 0W
[site ] DEBUG 2026/09/23 21:40:20 site power: 2137W
[lp-1 ] DEBUG 2026/09/23 21:40:20 charger status: B
[lp-1 ] DEBUG 2026/09/23 21:40:20 charger soc: 31%
[lp-1 ] DEBUG 2026/09/23 21:40:20 !! plan: plan time zero
[lp-1 ] DEBUG 2026/09/23 21:40:20 pv charge current: 0A = 0A + -9.29A (2137W @ 1p)
[site ] DEBUG 2026/09/23 21:40:35 ----
```

warp4-87s6-Debug-Report-2026-09-23T21-44-04-369.txt

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

Okay - erledigt - um 23:22:35 Uhr habe ich den ID.5 wieder angesteckt

```
[lp-2 ] DEBUG 2026/09/24 23:22:35 charger status: B
[lp-2 ] DEBUG 2026/09/24 23:22:35 charge start energy: 16367.782kWh
[lp-2 ] INFO 2026/09/24 23:22:35 car connected
[lp-2 ] DEBUG 2026/09/24 23:22:35 vehicle api cache reset
[lp-2 ] DEBUG 2026/09/24 23:22:35 charge total import: 16367.782kWh
[lp-2 ] DEBUG 2026/09/24 23:22:35 charger vehicle id: 04:68:1C:22:BC:73:80
[lp-2 ] INFO 2026/09/24 23:22:35 vehicle updated: unknown -> e-up WiCAN
[lp-2 ] DEBUG 2026/09/24 23:22:35 vehicle soc: 75%
```

evcc-20260924-232318-trace.log warp4-87s6-Debug-Report-2026-09-24T23-28-29-416.txt

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

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?

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.

Edited September 25, 2026 at 07:35 AMSep 25, 2026 by illusion2001

GitHub

Issue · evcc-io/evcc

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

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.

Ich verstehe nur die Hälfte von dem was Du schreibst, aber ich hatte auch schon nach gedacht, ob es sinnvoll ist, ein Auto mit MAC und RFID zu hinterlegen. Mein Gedanke war, dass wenn ISO15118 mal ausfällt, das ich dann mit RFID laden kann. Den RFID-Dongel brauche ich so wie so, da ich bei meinem Arbeitgeber nur per RFID laden kann - der Dongel ist also so wie so am Schlüsselbund.

Aber wenn ich das richtig verstehe liegt das Problem im Moment wieder im Spielfeld von evcc, da dort Daten der vorherigen Lade-Aktion verwendet werden?

Am 25.9.2026 um 11:15 schrieb eweri:

Aber wenn ich das richtig verstehe liegt das Problem im Moment wieder im Spielfeld von evcc, da dort Daten der vorherigen Lade-Aktion verwendet werden?

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.

On 9/25/2026 at 9:57 AM, illusion2001 said:

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.

In "charge_tracker/current_charge" steht immer nur eine Authorisierungsinformation, nämlich die, mit der die Ladung tatsächlich freigegeben wurde. Wurde die Ladung per NFC freigegeben, steht da die Tag-ID. Wurde die Ladung per Autocharge freigegeben, steht da die Fahrzeug-MAC. Es ist nicht möglich, eine Ladung doppelt freizugeben.

Ich könnte mir vorstellen, dass evcc zusätzlich zu "charge_tracker/current_charge" noch in "nfc/seen_tags" schaut. Da würde das zuletzt gesehene Tag drin stehen, was aber nichts mit der laufenden Ladung zu tun hat, wenn die per Autocharge/MAC freigegeben wurde.

Wird die API spec aktualisiert? Ich forsche noch ein bisschen und mache dann ggf. ein EVCC issue auf.

Ja, kommt noch. Ist leider noch niemand dazu gekommen. Ansonsten ist dein Aussage richtig, dass Typ 4 Autocharge per MAC ist.

@eweri probier mal die evcc nightly aus. Du solltest zum Testen zuerst das WiCAN Fahrzeug laden, das du mit RFID autorisiert, dann abstecken, kurz warten, dann den ID5 anstecken.

Hallo illusion2001!

Ich scheitere gerade daran, der nightly die Konfiguration und Datenbank der normalen Version unterzuschieben. Ich kann wohl Daten für den Docker-Container von /data nach /addon_configs/49686a9f_evcc-nightly verschieben - aber nur wenn der Container darauf Zugriff hat. Im Moment ist mir nicht klar, wie ich die evcc.yaml aus 49686a9f_evcc der 49686a9f_evcc-nightly verfügbar mache.

Ich habe jetzt in addons folgendes liegen:

addon_configs ls -lr
total 12
drwxr-xr-x    2 root     root          4096 Sep 27 14:56 49686a9f_evcc-nightly
drwxr-xr-x    2 root     root          4096 Sep 27 14:16 49686a9f_evcc

./49686a9f_evcc:
total 8
-rw-r--r--    1 root     root           618 Sep 27 14:16 evcc-20260927.yaml
-rw-r--r--    1 root     root           618 Jan  1  2026 evcc.yaml

./49686a9f_evcc-nightly:
total 68
-rw-r--r--    1 root     root         65536 Sep 27 14:52 evcc.db
-rw-r--r--    1 root     root           618 Sep 27 14:33 evcc.yaml

aber die YAML und die DB wird anscheinend von der Nightly nicht verwendet.

Hatte die Nightly beim ersten Start ein Kennwort gegeben und dachte danach wird es die Konfiguration übernehmen, das war leider nicht so. Dann habe ich die Wallbox hinzugefügt und dachte, jetzt legt es eine YAML an, die tauscht du dann aus und fertig ist die Laube - geht auch nicht. Jetzt habe ich den Nightly deinstalliert und neu installiert und irgend wie und irgnend woher hat er sich diese minimal Konfiguration gezogen.

Ich habe Terminal und SSH-Zugriff auf Home Assistant aber keine Ahnung von Docker Containern.

Danke schon mal für deine Bemühungen

Edited September 27, 2026 at 04:29 PMSep 27, 2026 by eweri

Ich habe bei mir die DB und die yaml nach /homeassistant verschoben. Dann in der Konfiguration der beiden add-ons /homeassistant/evcc.db und /homeassistant/evcc.yaml eintragen, dann verwenden beide dieselben Daten.

Hm, ich habe auch bei beiden den gleichen Pfad eingetragen: /data/evcc.db und /config/evcc.yaml - funktioniert aber nicht.

Ich versuche mal den homeassistant-Pfad aber so wie ich das verstanden habe ist dieser Pfad eigentlich veraltet.

On 9/25/2026 at 11:15 AM, eweri said:

aber ich hatte auch schon nach gedacht, ob es sinnvoll ist, ein Auto mit MAC und RFID zu hinterlegen.

ja: mehrere wallboxen im System - und nicht alle unterstützen ISO15118 ..

dazu eine Frage - die hier nicht wirklich passt, aber dann doch wieder:
sollte die WARP4 die mac-adresse (und Soc) des Fahrzeugs über OCPP übertragen? wenn nein - scheitert es am Standard, an der Firmware, oder an evcc (in diesem Fall das OCPP backend)?

Okay - nach dem ich mir in Home Assistant die Docker etwas angesehen habe, konnte ich jetzt die evcc-nightly testen und das ist der Fehler nicht mehr drin.

Also kein Fehler in der WARP - Fehler in evcc.