eweri

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.

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.

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

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?

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

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

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

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.

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

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

Hallo rtrbt! Hat sich erledigt, der Zähler läuft jetzt. Ich habe den Zähler entfernt und gespeichert, dann startet die WARP neu, dann habe ich den Zähler hinzugefügt und vergessen zu speichern, das Debug-Log runtergeladen. Dann dachte ich "oh, du hättest speichern müssen" - also noch einmal Zähler entfernt, gespeichert, die WARP startet neu, Zähler hinzugefügt, gespeichert, Debug-Log runtergeladen .... "Moment, wenn die WARP neu startet ist doch das Debug-Log leer... also noch einmal" - ich wollte gerade den Zähler entfernen, da sehe ich das er jetzt doch etwas anzeigt. Keine Ahnung wo es geklemmt hat - jetzt geht es.

Moin! Habe mein "WARP4-Upgrade" am Laufen - alles prima. Aber jetzt ist mir aufgefallen, dass mein elgris Smart Meter, dass in meiner WARP3 problemlos funktioniert hat, in der WARP4 keine Werte liefert. Beim Hinzufügen gibt es die Fehlermeldung "Verbindung zu 192.168.51.169:502 getrennt: ProtocolError", trotzdem läßt sich das Smart Meter hinzufügen. Da es mit der WARP3 immer funktioniert hat, vermute ich, dass sich dieser Fehler durch einige Firmware-Updates eingeschlichen hat. Kann aber auch sein, dass sich mein elgris Smart Meter nicht genau an die SunSpecs hält und ältere WARP-Firmwares da großzügiger waren. Ich habe mal ein Bildschirmfoto und das Protokoll angefügt. warp4-87s6-SunSpec-Gerätesuche-2026-08-11T11-34-37-728.txt

SUPER!! Vielen Dank - Du hast mir das Wochenende gerettet! Wenn ich es nicht ganz so eilig gehabt hätte und ich einfach mal etwas nachgedacht hätte, hätte ich eigentlich selber darauf kommen müssen, dass "DC" nicht die Stromversorgung für den Brick meint sondern den Fehlerstrom-Sensor Mich brachte das zusätzliche Kabel an der WARP3 für die Stromversorgung des Bricks etwas durcheinander NFC-Tags hat sich geklärt, die tauchen an einer anderen Stelle jetzt auf als ich Sie in Erinnerung hatte. Nochmal Danke und ich stelle immer wieder fest, es hat sich gelohnt eine WARP zu kaufen!

Ah - und die DC-Brücke wird nicht mehr gebraucht?

Am NFC-Modul leuchte eine blaue LED und wenn ich ein Tag dran halte leuchte zusätzlich eine gelbe LED, aber in der Web-Oberfläche wird kein NFC-Tag erkannt oder angezeigt. Scheint, dass weder NFC-Modul noch DC-Sensor mit dem Board kommunizieren können. Ich nehm das noch einmal auseinander...