wolkenschaufler

Vielen Dank! Ich teste damit jetzt mal eine Zeit lang und gebe dann Rückmeldung. Eine Frage hätte ich aber noch: Wenn ich das richtig verstehe, dann ist die CP-Trennung davon nicht betroffen, wenn mit z.B. der WEM schon auf 3p steht und die Ladung nach einer Pause startet?

Da er in der Nacht auf den 10.01.2024 auch wieder nicht geladen hat, versuche ich das ganze nochmal zusammenzufassen: Mit gesetztem minimalem Strom von 8 A im WEM war das Problem ziemlich konstant reproduzierbar. Solange diese gesetzt waren, wurde nicht geladen. Ich hatte hier 8 A drin stehen, da das ein Relikt der Zoe war, die auch an dieser Wallbox geladen wurde. Mit dem herausnehmen der 8 A, war das Problem anscheinend weg. Dachte ich zumindest... Seitdem ist das nichtladen noch zweimal aufgetreten: In der Nacht zum 10.01. 2024 und in dem Log vom 13.12.2023. Von der Nacht auf den 10ten habe ich leider kein Log. Ich habe jetzt die 8 A wieder gesetzt, den WEM in den verbose Modus gesetzt. Es ist aber zum Mäuse melken. Ich habe gestern und heute min. 3 h versucht, das Problem zu reproduzieren. Ich habe es nicht geschafft. Es wurde aber auch immer gleich mit 16 A geladen, sofern ich das aus den Logs entnehmen kann. Was ich noch dazu gefunden hätte, zielt immer auf die Dauer der CP-Trennung ab. Das hier und das hier. Ggf, wäre doch hier eine konfigurierbare CP-Trennung mal zu testen? Das habe ich ja nie ausprobiert, weil ich durch die manuelle Steuerung der CP-Trennung den WEM deaktivieren musste und da das Problem dann weg war. Dachte ich zumindest... Aber anscheinend ist es dann auch nicht weg, tritt aber nicht mehr so gehäuft auf. Ich bin schön langsam soweit, dass ich mir ein Skript baue, dass mich in der Nacht anruft wenn nicht geladen wird. Und ich dachte immer die Zoe ist als Ladezicke bekannt. Aber bis auf die 8 A macht die alles wie Sie es soll.

Danke, kann ich verstehen und habe so etwas schon befürchtet. Trotzdem irgendwie unbefriedigenden nicht zu wissen woran das genau liegt und ob das nicht wieder einfach auftritt. Einen Grund, warum der WEM zuerst nur 8 A anstatt der von evcc zugewiesen 16 A frei gibt konntet ihr auch nicht finden? Ich kann mir nur erklären, dass das irgendwie am Timing hängt und das man das im Log nicht sieht.

Könnt ihr hierzu noch etwas sagen? Wenn ich noch etwas testen soll, kann ich das gerne machen. Danke!

Ich möchte hier nochmal eine Rückmeldung geben: Mit deaktivieren der 8 A Mindestladestrom im WEM ist das Problem behoben und der Peugeot wacht bisher immer zum Laden auf. Nichtsdestotrtoz würde ich gerne verstehen, warum das so ist. Ich konnte das Verhalten auch nicht reproduzieren wenn er durch evcc einphasig mit niedrigen Strömen geladen wird. Da wacht er auch auf. Viele Grüße und schöne Weihnachten🎅🎄!

Kein Problem. Ich bin ja schon froh, dass ihr da so eine Ausdauer habt beim unterstützen. Das ist man von anderen Firmen nicht so gewohnt. Dafür habe ich jetzt auch einen Log wo wieder nicht geladen wurde, dafür aber gleich mit 16 A😭 ;-) energy_manager-debug-protocol-wem-26ud-2023-12-13T16-39-53-870.txt evse-debug-protocol-warp2-22qS-2023-12-13T16-39-53-256.txt

@MatzeTF Hier die Logs wie in deiner privaten Nachricht geschrieben. Allerdings hat er in diesem Fall zu laden begonnen, es wurden aber zuerst nur die 8 A gesetzt. Ich denke aber auch, dass ich zu wenig lang gewartet habe bis er eingeschlafen ist. Ich hoffe, das hilft zumindest mal dabei rauszufinden, warum zuerst mit 8 A geladen wird. Irgendwie ist das echt schwierig, ich kann einfach keine Konstante in dem Problem finden. evse-debug-protocol-warp2-22qS-2023-12-13T16-22-30-969.txt energy_manager-debug-protocol-wem-26ud-2023-12-13T16-22-31-944.txt

Hier noch der Debug-Report vom WEM wenn das Fahrzeug nicht aufwacht. Ich kann es noch nicht 100% sicher sagen, aber das Problem tritt wohl nur auf, wenn im WEM 8 A Mindeststrom gesetzt sind. debug-report-wem-26ud-2023-12-12T21-14-25-554.txt

Ich hab das jetzt zweimal versucht mit 6 A konfiguriertem Ladestrom. Kann aber das Verhalten nicht reproduzieren, es wird immer gleich losgeladen. Mir ist aufgefallen, dass da aber keine CP-Trennung gemacht wird: evse-debug-protocol-warp2-22qS-2023-12-12T20-25-29-909.txt

Ich hatte ja noch die Tests an meiner zweiten Wallbox austehend. Ich habe das bisher zweimal getestet, er ist jedes Mal aufgewacht. Ich denke auch, dass das Auto geschlafen hat, da die LED am Ladeanschluss aus war. Meine Frage, warum der pwm duty cycle sich ändert kann ich mir auch selbst beantworten: Der freigegebene Ladestrom ist ein anderer. Mir ist aufgefallen, dass hier gleich mit 16 A losgeladen wird und nicht zuerst mit 8 A und dann mit 16 A. Ich hab daher die Einstellungen im WEM mal verglichen: Im "problematischen" WEM war unter Energiemanager -> Wallboxen ein minimaler Ladestrom von 8 A konfiguriert. Ich hatte das da vermutlich drin, weil hier die Zoe zuerst meist geladen wurde und die ja dafür bekannt ist, unter gewissen Strömen nicht zu laden. Die erste Frage wäre hier: Warum macht der WEM das, obwohl von evcc 16 A freigegeben werden? Ich könnte mir vorstellen, dass das das Problem war. Wenn ja, verstehe ich aber nicht warum das ein Problem ist, wenn der freigegebene Ladestrom "nur" 8 A ist. 6 A sollten meines Wissens die Grenze sein und ich kenn nur Zoes die das nicht aktzeptieren. evse-debug-protocol-warp2-28kb-2023-12-11T18-45-01-482.txt evse-debug-protocol-warp2-28kb-2023-12-11T17-54-43-067.txt

Nachtrag: Gerade ist er wieder nicht aufgewacht. Aber selbiges Verhalten wie zuvor: Sobald ich das Lastmanagement deaktiviert habe, hat er zu laden begonnen. Ich hab bei dem Log zu spät auf aufzeichnen gedrückt, da war die Ladefreigabe schon da. evse-debug-protocol-warp2-22qS-2023-12-10T20-14-11-162.txt

Ich kann das Verhalten aktuell kaum mehr reproduzieren. Das einzige was sich geändert hat ist die Außentemperatur und der WEM hängt jetzt am Kupfer und nicht mehr im WLAN. Bei ersterem kann ich mir kaum vorstellen, dass das was mit dem Problem zu tun hat. Mir wäre noch etwas aufgefallen, als ich den PWM Duty Cycle im Diagramm ergänzt habe: Da hing der WEM auch am Kupfer und er hat nicht zu laden begonnen. Bei ~2317 hab ich dann das Netzwerkkabel abezogen und das Lastmanagement deaktiviert und er hat zu laden begonnen. Warum ist da der PWM Duty Cycle auf einmal ein anderer? Der ist beim "ersten" Start 133 und nach dem deaktivieren vom Lastmanagement 267. Ich hätte erwartet, dass der bei 133 bleibt.

Wahnsinn, vielen Dank für deine ausführliche Antwort, damit habe ich jetzt nicht gerechnet. Ich habe jetzt den WEM via Kupfer im Netzwerk, vorher war alles im WLAN, war bisher nur zu faul das umzubauen. Ich habe damit dein Prozedere mal durchgespielt. Merkwürdig war, dass beim ersten Test der Ladevorgang trotz aktiviertem WEM sofort gestartet hat. Ich hab dann wieder eine Weile gewartet und dann nochmal gestartet. Da hat er dann nicht mehr geladen und ich konnnte das von dir beschriebene durchführen. Hier ist dann folgendes passiert (Ich hab das auch mal grafisch aufbereitet): Wie du siehst, wurde zuerst nicht geladen. Durch abziehen des Netzwerksteckers vom WEM und umstellen des Lastmanagements ändert sich anscheinend auch charger_state und er hat trotz ausbleibender CP-Trennung zu laden begonnen. Bisher habe ich es noch nicht mit meiner zweiten Wallbox getestet, werde ich aber noch machen. evse-debug-protocol-warp2-22qS-2023-12-08T21-04-45-725.txt

Kein Problem, aktuell ist auch nicht so dringlich, da der WEM hauptsächlich im Sommer wegen der Phasenumschaltung zum Einsatz kommt. So grundsätzlich sollte es aber trotzdem funktionieren 😉 Ich habe das jetzt zweimal versucht, er hat aber jedes mal zu laden begonnen. Ich denke daher nicht, dass das die Ursache ist. Das mit der CP-Trennung kann ich auch so nachverfolgen. Ich glaube zwar, dass das nichts bringt, aber im Anhang der Log dazu. Kann es nicht doch auch an evcc liegen? Ich weiß nicht, was evcc genau alles steuert, aber CP-Trennung ist wohl auch mit dabei. Auszug aus evcc trace log von meiner zweiten Wallbox: [warp ] TRACE 2023/12/06 19:11:48 recv warp2/Stellplatz/info/features: '["evse","cp_disconnect","button_configuration","ethernet","meter","meter_phases","meter_all_values","nfc"]' Wenn es euch die Fehlersuche erleichtern würde, könnte ich euch einen VPN-Zugang zur Wallbox und WEM einrichten. evse-debug-protocol-warp2-22qS-2023-12-06T18-45-20-522.txt

Hier jetzt nochmal mit WEM und aktiviertem Fahrzeugweckruf wo nicht geladen wurde. Das andere wieder mit aktiviertem Weckruf und deaktiviertem WEM wo wieder geladen wurde. evse-debug-protocol-warp2-22qS-2023-12-05T18-32-10-741_w_wem.txt evse-debug-protocol-warp2-22qS-2023-12-05T19-47-55-238_wo_WEM.txt

Danke, ich versuche das Ganze noch mit aktiviertem Weckruf abzubilden. Hat aber gerade nicht mehr funktioniert, hat jetzt immer zu laden begonnen trotz aktiviertem WEM. Aber das war vorher auch schon so, manchmal ging es, manchmal nicht.

Genauso ist es. Sobald der WEM mit ihm Spiel ist, wacht er nicht mehr auf. Die beiden Protokolle sind im Anhang. Wie in dem mit WEM zu sehen, wird die Freigabe um 16:10:27 erteilt und um 16:12:10 habe ich es wieder beendet ohne dass die Ladung gestartet hätte. Das war jetzt sehr kurz, aber es hätte sich auch nichts geändert, außer ich hätte das Fahrzeug manuell aufgeweckt. Edit: Habe gerade gesehen, dass ich den Fahrzeug-Weckruf nicht aktiviert hatte. War aber in beiden Fällen deaktiviert. evse-debug-protocol-warp2-22qS-2023-12-05T15-54-40-200_ohne_WEM.txt evse-debug-protocol-warp2-22qS-2023-12-05T16-12-13-995_mit_WEM.txt

Was kann ich noch tun, um den Fehler zu finden? Auch heute Nacht wurde ohne den WEM wieder einwandfrei geladen.

Heute Nacht nochmal den Test gemacht: WEM ausgetragen und manuell auf 3p geschaltet. Fahrzeug hat ohne Probleme geladen. Sobald ich den WEM wieder aktiviere, geht es nicht mehr. Der WEM und die Wallbox sind aktuell via WLAN im Netzwerk. Kann das ein Problem sein? Sollte alles aktuell sein, der WEM: 0,482 **** TINKERFORGE WARP ENERGY MANAGER V1.0.8-653faee7 **** 0,483 324K RAM SYSTEM 305820 HEAP BYTES FREE 0,493 READY. 0,493 Last reset reason was: Software reset via esp_restart. 0,576 Mounted data partition. 32768 of 3538944 bytes (0.9 %) used 0,745 WARP Energy Manager config version: 1.0.2 (wem) 0,746 ESP32 Ethernet Brick UID: 26ud und die Wallbox: 0,482 **** TINKERFORGE WARP2 CHARGER V2.1.5-653faf69 **** 0,483 319K RAM SYSTEM 298348 HEAP BYTES FREE 0,494 READY. 0,494 Last reset reason was: Software reset via esp_restart. 0,934 Mounted data partition. 77824 of 3538944 bytes (2.2 %) used 1,177 WARP2 Charger config version: 2.1.3 (warp) 1,178 ESP32 Ethernet Brick UID: 22qS

Ich kann zu 90%, bestätigen, dass es nur im Zusammenhang mit dem WEM auftritt. Ist das Lastmanagament in der Wallbox deaktiviert, wacht das Fahrzeug problemlos auf. Sobald man hier fremdgesteuert einträgt und der WEM übernimmt, wacht er nicht mehr auf. Ich kann somit die CP-Trennung selbst gar nicht testen, weil diese nur zulässig ist, wenn das Lastmanagement deaktiviert ist. In diesem Fall wacht er ja wieder auf.

MIt den curl-Befehlen ist das irgendwie schwierig. Ich habe mir ein Bash-Skript gebaut, mit denen ich bei Bedarf die Befehle absetzen kann. Dabei ist mir aufgefallen, dass das nur geht, wenn man den WEM austrägt. Also den Lastmanagement-Modus auf deaktiviert stellt. Dabei konnte ich aber das Verhalten nicht mehr reproduzieren. Ich werde jetzt mal versuchen, den WEM wieder zu aktivieren und schauen ob da das Verhalten wieder auftritt. Ggf. ist es ein Bug im WEM? Es ist ja ohnehin nicht immer, manchmal lädt er auch sofort los. Natürlich seit gestern wieder jedes mal. Das macht die Fehlersuche irgendwie nicht einfacher...

Vielen Dank! Ich wäre auch gerne bereit, verschiedene Zeiten zu testen und könnte mir die Firmware auch selbst bauen. Wie schon gesagt, ich weiß nicht wie belastbar die 125 s sind. Das war das einzige, was ich dazu gefunden habe.

Auch heute Nacht wurde an der Mennekes wieder einwandfrei geladen. Nach dieser Quelle sollte die CP-Trennung für minimum 125 s stattfinden. Haben eure Corsas schon neue OBCs? In meinem Fall ist der OBC von 03/2023 und hat auch die neueste Firmware drauf. Wenn das mit den 125 s CP-Trennung stimmt, könnte das die Ursache sein. Wie lange macht ihr die CP-Trennung?

Eine Frage zu evse/control_pilot_disconnect: Sollte das nicht kurz true werden, wenn zu laden begonnen wird und evse/ev_wakeup auf true steht? Und: Wird die CP-Trennung überhaupt ausgeführt, wenn eine übergeordnete Instanz (in meinem Fall evcc) die WB steuert? Wird die CP-Trennung denn geloggt? Alles was ich zu einem nicht aufwachenden e208 finde, hat immer mit der fehlenden CP-Trennung zu tun. Ich konnte auch irgendwie nicht feststellen, ob das überhaupt stattfindet.

Ich habe heute mal bei meinem Nachbarn geladen mit den gleichen Bedingungen. Auch evcc aber eine Mennekes Amtron Xtra. Nur wurde diesmal auch kein WakeUp über die Stellantis API getriggert, weil mein Auto da nicht eingebunden ist. Er hat ohne Probleme geladen. Ich werde das morgen Nacht nochmal machen. Es scheint mir aber, wie wenn es an der Wallbox liegt.