wolkenschaufler

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.

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.

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.

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ß

Super, wieder mal vielen Dank für den Mega Support hier! Da könnte sich viele Firmen eine gewaltige Scheibe abschneiden ;-) Gruß

Grundsätzlich warte ich noch auf eure Anpassung der API damit EVCC auch den WEM steuern kann. Wenn das der Fall ist, dann können doch auch zwei WEMs eingesetzt werde wo jeder seine "eigene" WB steuert oder? Phasenschieflast wäre ja nur ein Problem, wenn man auf mehr wie 16 A pro Phase geht, was aber bei zwei WB dann wiederum eine Genehmigung vom VNB nach sich ziehen würde. Ist jetzt natürlich ein wenig Glaskugellesen: Wäre es denn möglich, zwei WARP mit einem WEM zu betreiben und EVCC dennoch die Steuerung und Priosierung zu überlassen? Theoretisch doch schon oder?

Hallo Zusammen, wie sähe denn eine sinnvolle Konfiguration mit WEM und zwei WARP Chargern aus? Aktuell habe ich eine WB mit einem WEM. Da in absehbarer Zeit aber ein zweites EAuto angeschafft wird, überlege ich hier, wie da eine sinnvolle Konfiguraiton aussieht. Es sollten beiden Wallboxen Phasenumschaltung können, was nach meinem Verständnis schon dazu führt, dass ein zweiter WEM benötigt wird. Können aber zwei WEM in einen Verbund zum Lastmanagement zusammengeschalten werden, so dass die Leistung beider Wallbox nicht über 11 kW liegt? Danke für eure Einschätzungen. Gruß

@rtrbt Gibts schon updates? Danke! Gruß

Ja, das hat mir Andig auf Slack auch geschrieben. Er gibt zwar keinen zeitlichen Horizont an, sagt aber, dass er darauf wartet, dass TF das implentiert. Heißt für mich: Ich warte erst mal und hoffe dass das schnell passiert.

Ja, die Abfrage des Börsenstrompreises habe ich schon. Ich hatte die Gedanken auch schon, das in HA zu integrieren und damit zu steuern. Aber trotz allem werde ich nicht so schnell die Funktionalität von EVCC vollständig abbilden können. Aber vermutlich hast du recht, Andig wird das nicht so schnell einpflegen.

Was beim WEM aber einfach fehlt, ist das Zielladen mit günstigem Börsenstrompreis. Insofern für mich jetzt nicht so direkt befriedigend. Ich hab seit einiger Zeit beides im Einsatz, was eigentlich schon fast super funktioniert. Also zumindest scheint sich die Regelung von evcc und die vom WEM da nicht in die Quere zukommen, weil evcc aktuell die unterstützte Ladesleistung regelt. Wichtig dafür ist nur, dass der WEM auf min+PV oder darüber gestellt ist, Phasenumschaltung geht damit aber dann leider nicht. Außerdem erkennt evcc dann nicht, dass beim Zielladen mit Börsenstrom 3-phasig geladen werden kann.

Nach Aussage von Andig (evcc Entwickler) wartet er auf Antwort von Tinkerforge. Hat aber dennoch keine hohe Prio, den WEM in evcc einzubinden.