borg

Das reicht, sieht im Log tatsächlich nach einem Fehler auf unserer Seite aus (sehe den "SDP Request" vom Auto, aber kein Response von uns). Muss ich mir wieder im Detail anschauen, könnte ein paar Tage dauern bis ich dazu komme.

Bitte nochmal den Debug-Report nachdem es nicht geklappt hat, Danke!

Da können wir aktuell leider nicht viel machen, ändert sich hoffentlich später mit ISO 15118-20. Und VW würde sagen dass ist genau dafür gut damit man zwei unterschiedliche Autos nicht unterschieden kann ...aus Datenschutzgründen. 🙈

Generell gilt: Wenn eine API nicht dokumentiert ist behalten wir uns vor diese in neuen Versionen noch zu ändern. Oft sind es APIs die bei Features genutzt werden welche noch in der Entwicklung sind und wo wir uns noch nicht sicher sind wie eine langfristige stabile API aussehen kann. Die undokumentierte API ist aber nicht Lava. Du kannst jegliche API nutzen wenn du möchtest. Infos zu den nicht-dokumentierten APIs findet Claude sicher am einfachsten im Source: https://github.com/Tinkerforge/esp32-firmware/tree/master/software Könnte nur sein dass du es nach einem Firmware-Update nochmal anpassen musst.

Kannst du einmal unter Wallbox -> Ladestatus -> Ladeprotokoll -> "Start" klicken, dann das Auto anstecken, dann das Problem erzeugen und dann auf Stop. Das Ladeprotokoll dann hier hochladen. Damit können wir dann schauen was in dem Moment wo er die Ladung wieder beendet passiert.

Die Doku ist ein bisschen zu früh veröffentlicht worden, der Support dafür kommt mit dem nächsten Firmware-Release 😄.

Du kannst unter Benutzer -> Benutzerverwaltung einem Benutzer ein Passwort geben und dann oben über "Anmeldung aktiviert" den Passwortschutz für die Weboberfläche aktivieren. Hinweis: Wenn du dein Passwort vergisst kommst du nur über ein komplettes Factory Reset wieder auf die Box.

Kannst du natürlich gerne verlinken 👍.

Du musst unten "Bei den teuersten" einmal aktivieren und die Zahl dort runter drehen (kannst dann wieder deaktivieren). Er blockiert das weil 4h+20h bereits der ganze Tag ist. Ist natürlich dumm, ein deaktiviertes Feld sollte nicht in die Maximum-Berechnung eingehen 🙈.

Oh in der Tat. Ich hatte ein paar Typos gefixt und Infos zu OVE R 37 hinzugefügt und dabei vergessen die Versionsnummer zu erhöhen und unten einzutragen. Hole ich gleich noch nach (ändert natürlich die aktuelle Printversion nicht).

Das ist soweit OK, es ist die Konfiguration von Iskra im Auslieferungszustand für das Display. Wir haben intern schon API um das Display zu beschreiben, müssen aber noch festlegen was wir dort Anzeigen wollen. Falls ihr Ideen habt: Bitte bedenken dass es ein 7-Segment-Display ist, man kann also nicht alle Buchstaben darstellen leider. Edit: Also wir können in der Mitte 8 Zeichen anzeigen und unten links 4 Zeichen. Oben die gezählten kWh und unten rechts lässt sich nicht steuern von uns. Sowas wie "Cur xxx" (geladene kWh des aktuellen Ladevorgangs) und "End xxx" (geladene kWh des letzten Ladevorgangs) wäre möglich z.B. Und ist von Iskra mit dem Not Set und End 0.00 vermutlich so angedacht.

Rein technisch starten wir eine Ladung um den SoC auszulesen, beenden diese dann um danach die normale AC-Ladung zu starten. Anders können wir nicht an den SoC kommen.

Hat Octopus Energy denn auch Zugriff auf den Skoda über deren API? Dann könnte das vielleicht sein. Eine genauere Aussage könnte ich treffen wenn du es schaffst das Abbrechen der Ladung in einem Ladeprotokoll zu haben. Allerdings können wir nur ~15 Minuten aufnehmen mit dem Ladeprotokoll und so wie ich das verstehe ist das ja nicht so richtig reproduzierbar und daher vermutlich gar nicht einfach das überhaupt aufzuzeichnen 🤔.

Wir warten 90s ob das Auto reagiert, dann 4s CP-Disconnect, dann warten wir 30s ob das Auto reagiert, dann 30s CP-Disconnect, dann 30s ob das Auto reagiert, dann 4s State F, dann 30s ob das Auto reagiert, dann 30s state F und dann geben wir auf. Wenn du nach dem letzten state F nochmal 30s warten willst sind es 278 Sekunden in Summe.

Probier es nochmal mit der angehängten Firmware. warp4_firmware_2_12_2_6a7c2187_ddb367a78040f26_ota.bin

D.h. du machst das PV-Überschussladen über EVCC und hast aktuell keine Willkommensladung aktiviert? Meiner Erfahrung nach ist die Willkommensladung bei MEB-Plattform-Autos notwendig. Mich wundert dass es bisher ohne ging bei der WARP1 🤔.

Ah, ich hatte gedacht es fängt nicht an zu laden nach der ISO-Kommunikation, aber dein Problem ist dass das Auto nicht aufwacht nachdem es eine Zeitlang nicht geladen hat, richtig? Das Wakeup hat in Summe vier Phasen, in dem Log kann man nur die erste CP-Trennung sehen: https://vislog.warp-charger.com/de/Zi2Es8nF5z6P49nCPimqfE#cols=allowed_charging_current%2Ccp_pwm_duty_cycle%2Ciec61851_state%2Cpower%2Cresistance_cp_pe&log=1 Kann es sein dass du nicht geduldig genug warst? Es sind ein paar komplette ISO 15118 Durchläufe inkl. SoC-lesen im Debug-Report, die sehen alle sehr gut aus: https://vislog.warp-charger.com/de/EqyNUUub3bLonFdLufpdNy#tab=trace-iso15118_ll-tab (aber nicht relevant hier) Wie meinst du das, hast du die deaktiviert in deiner Firmware?

Jetzt sieht es schon besser aus: Auch hier hat das Auto für ein paar Sekunden geladen (rote Linie), auch mit mehreren kW. Muss ich mir in Ruhe anschauen, hab auf die Schnelle noch keine Idee woran das liegen könnte. Melde mich dann wieder.

Tut mir leid, aber kannst du einmal unter System -> Einstellungen -> Neu Starten die komplette Box neustarten (am besten vorher Auto abziehen) und das dann nochmal testen? Irgendwas ist da immernoch in einem komischen Zustand (ich kann die Anfragen des Autos sehen, aber keine Antworten von der WARP4).

Ich glaube das sind die gleichen Dateien wie oben auch schon

Mh, um sicher zu gehen das wir den Zustand genau verstehen steck mal das Auto ab, aktiviere Autocharge und SoC auslesen, starte dann das Protokoll, steck den Stecker ins Auto und warte 3 Minuten bevor du das Protokoll runterlädst. Dann haben wir alles drauf was relevant sein könnte. Dann auch den Debug Report nochmal runterladen. Danke!

Kannst du den normalen Debug-Report auch noch einmal runterladen dazu? Wir sollten einbauen dass beim Ladeprotokoll immer der komplette Debug-Report dabei ist...

Ich bin tatsächlich sehr verwirrt von dem Protokoll 😅. In dem Ladeprotokoll sieht es so aus als hätte das Auto nach der ISO 15118 Kommunikation für ~45s 16A gezogen und hätte dann wieder aufgehört? Zeigt das Auto dazu irgendwas im Display an o.ä.? Rein von der Konfiguration her sieht das IMO alles gut aus.

Der DC-Fehlerstromsensor muss an das EVSE: Der Rest ist OK.

Man kann in den Daten in der Tat sehen dass ein Autocharge korrekt durchgelaufen ist (endet mit CM_SLAC_MATCH.REQ). Danach kommen dann auf einmal ganz viele Versuche rein vom Tesla eine neue Verbindung aufzubauen (die der WARP4 aber ignoriert). Sehr komisches verhalten, die Abstände bei den Versuchen sind auch nicht standardkonform. Ich weiß nicht was da passiert ist, hab ich so auch noch nie gesehen. Die Erwartungshaltung wäre auch dass der WARP4 das PLC-Modem ausstellt nachdem das Autocharge durch ist und erst wieder aktiviert wenn der Typ2-Stecker entfernt wird (CP-Widerstand auf >2700 Ohm geht). Würde ich jetzt solange das nicht irgendwie reproduzierbar ist erstmal ignorieren 😅.