Peugeot e208 vs. WARP 2 Pro: Fahrzeug wacht teilweise nicht auf

[wolkenschaufler]

Hallo Zusammen,

 

ich habe zwei WEM mit zwei WARP 2 pro die via evcc mit Tibber gesteuert werden.

An einer hängt eine Zoe R110 und an der zweiten ein Peugeot e208 (EZ 10.2021). Während die Zoe keine Probleme macht, hab ich beim Peugeot ab und an das Problem, dass er in der Nacht zum Laden nicht aufwacht.

 

Ich habe diesen Thread hier entdeckt, wollte aber keine Leichenfledderei betreiben: Sind euch Probleme mit dem Peugeot oder dem baugleichen Corsa bekannt?

Nach Aussage von Peugeot gibt es zumindest für meinen keine offenen Updates.

Gruß

bearbeitet November 28, 2023 at 08:48 von wolkenschaufler

[rtrbt]

Im Moment ist uns da nichts bekannt. Wir testen morgen nochmal mit einem der Corsas. Eventuell verhalten die sich seit einem Update anders.

[wolkenschaufler]

Danke.

Ich glaube zwar nicht, dass das zusammenhängt, aber seit es kälter geworden ist, ist es jetzt fast bei jedem Zielladen, dass er einschläft und nicht mehr aufwacht.

Eine Interaktion mit der App weckt das Fahrzeug dann und er beginnt zu laden. Auch wenn man mit dem Funkschlüssel dem Fahrzeug nähert. Hier der Auszug aus dem Ereignislog der Wallbox von heute Nacht:
 

2023-11-27 23:35:48,828  received stale (out of order?) command packet. last seen seq_num is 9297, received seq_num is 9297
2023-11-28 02:17:43,170  Charger state changed from 1 to 2
2023-11-28 02:17:43,224  Tracked start of charge.
2023-11-28 02:27:48,279  received stale (out of order?) command packet. last seen seq_num is 19577, received seq_num is 19577
2023-11-28 02:45:16,186  received stale (out of order?) command packet. last seen seq_num is 20621, received seq_num is 20621
2023-11-28 06:25:26,821  Charger state changed from 2 to 3
2023-11-28 07:01:38,187  Charger state changed from 3 to 2
2023-11-28 07:01:41,214  Charger state changed from 2 to 0
2023-11-28 07:01:41,251  Tracked end of charge.

Um 6.25 hab ich dann das Fahrzeug via psa_car_controller geweckt. Um 2:17 Uhr hätte er eigentlich beginnen sollen.

 

bearbeitet November 28, 2023 at 16:29 von wolkenschaufler

[rtrbt]

Der Corsa scheint das Problem nicht zu haben: Wir haben einem davon heute 6 Stunden lang angeschlossen gehabt und erst danach den Strom freigegeben. Er hat sofort angefangen zu laden.

Nur sicherheitshalber: Hast du unter Wallbox -> Ladeeinstellungen den Fahrzeugweckruf aktiviert? Wenn das nicht aktiv ist, wäre das eine gute Erklärung.

[wolkenschaufler]

Danke, ich habe schon fast befürchtet, dass das bei euch kein Problem ist 🤣

 

Ja, habe ich. Das war auch mein erster Gedanke, aber das war von Anfang an eingeschaltet.

Gerade war der Fall wieder: Diesmal hat ein an- und abstecken dann zum laden geführt.

 

Nach meinem Verständnis sollte eure CP-Trennung genau das simulieren oder?

 

Kann es ggf. sein, dass der Peugeot diese CP-Trennung länger braucht?

Hier auch ein PR in evcc, mdkeil hat deswegen extra den Charge_now Befehl implementiert. Leider hat das auch nichts gebracht.

bearbeitet November 29, 2023 at 15:11 von wolkenschaufler

[wolkenschaufler]

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.

[wolkenschaufler]

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.

[wolkenschaufler]

Auch heute Nacht wurde an der Mennekes wieder einwandfrei geladen.

Nach dieser Quelle sollte die CP-Trennung für minimum 125 s stattfinden.
 

Am 29.11.2023 um 14:37 schrieb rtrbt:

Der Corsa scheint das Problem nicht zu haben: Wir haben einem davon heute 6 Stunden lang angeschlossen gehabt und erst danach den Strom freigegeben. Er hat sofort angefangen zu laden.

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?

[rtrbt]

Dann ist das auf jeden Fall das Problem: Die Wallbox trennt im Moment für 4 Sekunden, weil die IEC-Spezifikation das so vorgibt. (Fairerweise als Minimum und im Abschnitt "Information on difficulties encountered with some legacy EVs for wake-up after a long period of inactivity (informative)" )

Ich bespreche mal mit meinem Kollegen, wie wir damit umgehen.

[wolkenschaufler]

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.

[rtrbt]

Dafür musst du dir die Firmware nicht bauen, du kannst den CP-Disconnect per API kontrollieren. Den aktuellen Zustand siehst du unter Wallbox -> Ladestatus, Low-Level-Zustand aufklappen, 3. Zeile der GPIO, der letzte in der Zeile (ist links auch beschriftet als CP-Disconnect). Wenn der Pin auf Low steht, ist CP verbunden, wenn er auf High steht, ist CP getrennt.

CP trennen kannst du im einfachsten Fall auf der Kommandozeile mit curl. Zum Trennen:

curl http://warp2-abcd/evse/control_pilot_disconnect -d true

Zum Verbinden:

curl http://warp2-abcd/evse/control_pilot_disconnect -d false

 

Falls du kein curl zur Hand hast, kannst du die Recovery-Seite der Wallbox benutzen: Unter http://warp2-abcd/recovery bei API folgendes zum Trennen eintragen:

{"method": "PUT", "url":"/evse/control_pilot_disconnect", "payload": true}

Zum Verbinden:

{"method": "PUT", "url":"/evse/control_pilot_disconnect", "payload": false}

Und dann auf Call API klicken. Wenn es klappt bekommst du darunter eine 200 angezeigt.

 

Wenn du das testen willst, solltest du davor unter Wallbox -> Ladeeinstellungen den Fahrzeugwegruf deaktivieren damit der Ladecontroller nicht selbst CP-(Dis)connects auslöst während du testest.

[wolkenschaufler]

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

[wolkenschaufler]

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.

bearbeitet December 3, 2023 at 10:24 von wolkenschaufler

[rtrbt]

Das ist sehr interessant. Hast du die aktuelle Wallbox-Firmware laufen? In Firmware 2.1.2 oder älter gab es das Problem, dass das Lastmanagement die CP-Trennung stört.

[wolkenschaufler]

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

 

bearbeitet December 4, 2023 at 14:10 von wolkenschaufler

[wolkenschaufler]

Was kann ich noch tun, um den Fehler zu finden?

Auch heute Nacht wurde ohne den WEM wieder einwandfrei geladen.

[rtrbt]

Damit mein Verständnis richtig ist: Du musst, damit das Auto aufwacht nicht von Hand die API benutzen, sondern auf der Wallbox unter Lastmanagement von "Fremdgesteuert" auf "Deaktiviert" umzustellen reicht?

Erstelle bitte von beiden Varianten (also mit Lastmanagement über den WEM und ohne) jeweils ein Ladeprotokoll: Dafür unter Wallbox->Ladestatus bei Ladeprotokoll auf Start klicken, den Tab auflassen (das Protokoll wird im Browser gesammelt) und dann den Ladevorgang starten, bzw. Strom freigeben. Dann sollte das Auto in der einen Variante ja nach ~ 30 Sekunden aufwachen und in der anderen nicht. D.h. wenn du lange genug gewartet hast, dass das Auto aufgewacht ist, bzw. hätte aufwachen sollen, kannst du auf Stop+Download klicken.

In den Ladeprotokollen sollen wir dann sehen, was genau auf CP passiert.

 

[wolkenschaufler]

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

bearbeitet December 5, 2023 at 15:28 von wolkenschaufler

[rtrbt]

Hm das Timing bei dem Protokoll mit WEM ist sehr interessant. Ich versuche das morgen mal auf meinem Tisch zu erzeugen, und melde mich dann nochmal.

[wolkenschaufler]

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.

bearbeitet December 5, 2023 at 15:59 von wolkenschaufler

[wolkenschaufler]

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

bearbeitet December 5, 2023 at 18:50 von wolkenschaufler

[rtrbt]

Sorry, ich schaffe es heute nicht mehr, dir einen detaillierteren Post zu schreiben. Teste bitte nochmal folgendes:

• Lastmanagement auf der Wallbox deaktivieren
• EVCC bzw. externe Steuerung auf der Wallbox deaktivieren
• Manuelle Ladefreigabe aktivieren
• Auto anstecken (es sollte nicht anfangen zu laden)
• Warten bis das Auto eingeschlafen ist
• Ladeprotokoll starten
• folgendes ausführen:

  curl 'http://warp2-Garage/evse/control_pilot_disconnect' -d 'true' && sleep 5 && curl 'http://warp2-Garage/evse/start_charging' -d 'null' && curl 'http://warp2-Garage/evse/control_pilot_disconnect' -d 'false'

  (Damit wird CP getrennt, 5 Sekunden gewartet, der Ladestrom freigegeben und CP verbunden. Du kannst unter Wallbox ->Ladestatus -> Low Level Zustand auch dabei zusehen, wie CP getrennt und dann wieder verbunden wird)

Das sollte äquivalent zu dem sein, was der Energy Manager tut. Wenn das Auto bei diesem Test auch nicht anfängt zu laden, liegt es am Timing aus CP verbinden und dem PWM mit dem wir den Strom vorgeben.

[wolkenschaufler]

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

bearbeitet December 6, 2023 at 18:17 von wolkenschaufler

[rtrbt]

On 12/6/2023 at 6:48 PM, wolkenschaufler said:

Kann es nicht doch auch an evcc liegen? Ich weiß nicht, was evcc genau alles steuert, aber CP-Trennung ist wohl auch mit dabei.

Würde ich nicht erwarten. Ich habe sicherheitshalber evcc einmal aufgesetzt, testen kann ich das aber erst morgen mit dem Fahrzeug vom Kollegen. Ich melde mich dann nochmal detaillierter.

[rtrbt]

Hier der versprochene detaillierte Post. (Überspring einfach was du schon weißt).

Kommunikation zwischen Wallbox und Auto

Die ganze Kommunikation zwischen Wallbox und Auto funktioniert wie folgt: Es gibt den Kontakt CP (Control Pilot), an den die Wallbox 12V anlegt. Wenn du ein Auto ansteckst, verbindet das Auto CP und Ground mit einem 2,7kΩ Widerstand, woraufhin die Spannung auf 9V fällt. Auto und Wallbox können diese Spannung messen und sehen deshalb beide (du könntest ja eine Wallbox mit Dose haben), dass das Kabel verbunden ist.

Die Wallbox kann auf CP ein 1kHZ-PWM anlegen und anhand des Duty-Cycle (also des Verhältnisses zwischen der Zeit, die 12V und der Zeit die 0V anliegen) kommunizieren, wie viel Strom das Auto maximal ziehen darf. Wenn kein Strom verfügbar ist (weil z.B. EVCC gerade blockiert in deinem Setup), dann liegt die ganze Zeit 12V an.

Wenn Strom verfügbar ist, also das CP-PWM läuft, dann darf das Auto einen weiteren Widerstand zwischen CP und Ground parallel schalten, sodass insgesamt 880Ω anliegen, die Spannung fällt dann auf 6V. Sobald die Wallbox das sieht, schaltet sie das Schütz und das Auto bekommt Strom.

Mehr dazu hier: https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung

tl;dr: Die Wallbox signalisiert also dem Auto, wie viel Strom maximal zur Verfügung steht, das Auto kann dann auf "Ich möchte laden" wechseln und wenn es das tut, schaltet die Wallbox das Schütz.

Jetzt der Interessante Teil: Wenn das Auto nicht 30 Sekunden, nachdem die Wallbox Strom anbietet, den Widerstand anlegt und damit signalisiert, dass es laden möchte, geht die Wallbox davon aus, dass die Ladeelektronik des Autos im Stand-By ist. Wenn jetzt der "Fahrzeugweckruf" aktiviert ist, trennt die Wallbox CP für 4 Sekunden und verbindet CP danach wieder. Aus Sicht des Autos sieht das so aus, als ob das Ladekabel auf Wallboxseite rausgezogen wurde und nach 4 Sekunden wieder eingesteckt. Wenn CP wieder verbunden wurde, läuft sofort das PWM, also ist aus Sicht des Autos sofort Strom verfügbar. Laut IEC-Spezifikation ist das das Vorgehen, um ein Auto aufzuwecken. Das ist aber in der Spezifikation relativ neu, nur informativ und bezieht sich auf "difficulties encountered with some legacy EVs".

Kommunikation zwischen Energy Manager und Wallbox

Der Energy Manager benutzt das Lastmanagementprotokoll um Wallboxen zu steuern. Das ist eigentlich relativ trivial: Der Energy Manager gibt einer Wallbox sekündlich vor, wie viel Strom sie maximal einem Auto anbieten darf, und außerdem ob CP getrennt oder verbunden sein soll. Der Energy Manager muss CP trennen können, da es ein paar Autos (z.B. alte Zoes) gibt, deren Ladeelektronik kaputt geht, wenn die Wallbox von ein- auf dreiphasig wechselt, während das Auto angeschlossen ist.

Das Vorgehen, wenn der Energy Manager einen Phasenwechsel macht ist also:

• Alle Wallboxen auf 0 Ampere runterregeln
• Warten bis alle Schütze abgeschaltet sind
• CP an allen Wallboxen trennen
• Zwischen ein- und dreiphasig wechseln
• CP an allen Wallboxen verbinden und Strom wieder verteilen

Aus Sicht des Autos ist das dann so, als ob du das Kabel an einer einphasigen Wallbox abgezogen hast und in eine dreiphasige eingesteckt, ohne dabei das andere Ende des Kabels aus dem Auto zu ziehen.

EVCC, Energy Manager und Wallbox

EVCC kann WARP-Wallboxen steuern und über den Energy Manager auf die Phasenumschaltung steuern. Aus Sicht von EVCC wird nur die Wallbox gesteuert (indem der maximale Ladestrom vorgegeben wird) und zusätzlich kann EVCC beim Energy Manager einen Phasenwechsel anfordern. Das ist aber auch alles, was EVCC in dem Aufbau tut. Insbesondere steuert EVCC nicht direkt die CP-Trennung.

Problem bei deinem Aufbau

Das hier ist ein Plot aus dem Debug-Log von oben, mit Energy Manager und aktivem Fahrzeugweckruf. Der charger_state ist 1, wenn ein Auto angeschlossen ist, die Wallbox ihm aber keinen Strom zur Verfügung stellt. Er ist 2, wenn die Wallbox Strom zur Verfügung stellt, das Auto aber nicht laden möchte.

Im Plot siehst du, dass CP einmal bei ~ 230 getrennt wird, das ist die Phasenumschaltung des Energy Managers. CP wird dann wieder verbunden und ab dem Moment stehen dem Auto 8 Ampere zur Verfügung. (Auffällig ist hier, dass das Lastmanagement des Energy Managers nur 8 Ampere zur Verfügung stellt, EVCC aber 16 Ampere)

Das Auto reagiert dann nicht auf den verfügbaren Strom, weshalb nach 30 Sekunden (bei Eintrag 890) die Wallbox von sich aus nochmal CP trennt und wieder verbindet.

Wenn das ganze funktionieren würde, sähe es so aus:

Das ist gerade mit einem der Corsas aufgenommen, Aufbau ist der selbe: EVCC steuert WARP2 und Energy Manager. Hier legt das Auto nach der CP-Trennung (für den Phasenwechsel) den zweiten Widerstand an, fordert also Strom an und das Schütz wird geschaltet (Das ist charger_state 3)

In den Reports, bei denen dein Auto anfängt zu laden, sehen die Daten ähnlich aus.

Was jetzt?

Du könntest noch folgendes versuchen: Eventuell ist das Problem wirklich, dass dein Auto manchmal eine längere CP-Trennung braucht und du diesen Fall (warum auch immer) nur erzeugen kannst, wenn die Phasenumschaltung per Energy Manager im Spiel ist. Du kannst aber die CP-Trennung nicht von Hand steuern, wenn der Energy Manager sie steuert.

Folgender Trick sollte aber funktionieren:

• Stelle nochmal den Zustand her, dass dein Auto nicht lädt, obwohl es sollte
• Ziehe dann am Energy Manager das LAN-Kabel raus. Das führt dazu, dass er nicht mehr Pakete an die Wallbox schicken kann, die CP verbinden oder trennen
• Stelle dann auf der Wallbox das Lastmanagement von "fremdgesteuert" auf "deaktiviert", speichere das und starte nicht neu! Das Webinterface behauptet zwar, dass das erst nach einem Neustart wirkt, diese spezifische Einstellung greift aber sofort.
• Du solltest jetzt wieder über die evse/control_pilot_disconnect-API CP trennen und verbinden können.

Damit kannst du testen, ob eine längere CP-Trennung (z.B. 3 Minuten) in dieser spezifischen Situation hilft. Wenn das der Fall ist, müssen wir die Länge der CP-Trennung konfigurierbar machen, bzw. einen Peugeot-Modus einbauen.

Noch ein anderer Gedanke: Hast du das Problem nur mit dem Peugeot an einer Wallbox oder an beiden?