borg

Schwer zu sagen was da passiert. Die WARP2 hört von 13:54 bis 15:00 nie auf dem Auto Strom anzubieten. Um 14:01:09 sagt das Auto dann es will kein Strom mehr, woraufhin wir in State 2 wechseln. Dann sagt das Auto es will Strom, woraufhin wir (nach 5s Timeout) das Schütz wieder durchschalten. 8s später will das Auto dann wieder kein Strom mehr, 5s später wird das Schütz wieder geschaltet etc. Das passiert ein paar mal. Nach einer Zeit versuchen wir eine CP-Trennung um das Auto wieder aufzwecken, es macht aber wieder nur den 5s/8s an/aus Tanz. Dann eine Stunde später um 15:07:10 will das Auto wieder laden, wir schalten das Schütz durch und ab da lädt es auch. Wenn du das reproduzieren kannst, könntest du während das Problem auftritt auf der WARP2 unter Wallbox -> Ladestatus -> Ladeprotokoll -> "Start" ein Ladeprotokoll starten. Und einige Zeit laufen lassen und dann "Stop". Dann können wir uns die Widerstände die das Auto anlegt im Chart ansehen (in der Zeit in der das Protokoll aufgenommen wurde). Man kann ca. 10 Minuten aufnehmen.

Das Problem ist nicht unbedingt die schlechte Implementierung in den Autos (da gibt es Probleme, aber nichts katastrophales wo wir keinen fix für finden könnten). Das Problem ist dass die Standards (IEC 61851 und ISO 15118-2) keine Lösung für die Anforderungen/Bedürfnisse von euch haben. Was ihr gerne hättet: PV-Überschussladen und dafür laden unter 6A Plug&Charge / Autocharge Laden zu einem bestimmten SoC und SoC anzeigen Wallbox soll ohne Cloud funktionieren undLaden ohne Internetzugang möglich Probleme bei PV-Überschussladen: Bei einigen Herstellern (bei den meisten sogar) ist es so dass das Auto einschläft wenn es nicht innerhalb der ersten ~10 Minuten nach dem Einstecken Strom bekommt und danach nicht wieder aufwacht (auch nicht mit CP-Trennung) -> Lösung: Eine Willkommensladung beim Einstecken, auch wenn in dem Moment kein PV-überschuss übrig ist Bei einigen Herstellern ist es so, dass diese (auch nach einer Willkommensladung) nicht mehr auf eine Änderung des PWMs reagieren wenn sie lange keinen Strom bekommen haben. Dafür gibt es die CP-Trennung, die greift wenn ein Auto nicht reagiert. Bei der IEC 61851 gibt es tatsächlich ein Appendix für genau diesen Fall der später hinzugefügt wurde. Dieser gibt vor dass die Wallbox den Fehlerzustand E/F erzeugen soll zum Aufwecken. Um dort alle Fahrzeugverhalten die wir kennen abzudecken machen wir vier unterschiedliche Aufweckversuche (CP-Trennung für 4s und für 30s sowie Fehlerzustand E/F für 4s und 30s). Wir machen zuerst die CP-Trennung, da der Fehlerzustand oft dazu führt dass der Nutzer vom Auto eine Notification bekommt das etwas mit der Ladestation nicht stimmt (auch wenn danach alles korrekt weiter läuft). Problem unter 6A laden: Die IEC 61851 sieht das einfach nicht vor. Daher fahren wir den Hack zwischen 1-Phasig und 3-Phasig zu wechseln um geringere Leistungen zu unterstützen. Um das zu bewerkstelligen beenden wir die Ladung, Schalten die Schütze, trennen CP, verbinden CP wieder und starten eine neue Ladung. Sowas sieht der Standard nicht direkt vor, daher gibt es dort auch unterschiedlichstes Verhalten. Wir brauchen da z.B. mindestens 45s CP-Trennung bei BMWs, während bei anderen weniger reicht. Bei Polestar ist es so, dass sie nicht innerhalb der vom Standard vorgeschriebenen 3s die Ladung beenden (wenn wir das PWM auf 100% fahren). Das erkennen wir und wir erhöhen in dem Fall die CP-Trennzeit (das überschreibt dann auch die Nutzerkonfiguration), damit auch ein Polestar die Trennung wirklich mitbekommt. Probleme bei Plug&Charge / Autocharge: Plug&Charge bedingt die Verwendung eines im Auto hinterlegten Zahlungsdienstleisters für eine Ladung, was für private Wallboxen zuhause kein Sinn macht Bei Autocharge liest man einfach die MAC-Adresse aus und nimmt diese zur Authentifizierung -> Problem: Autos in der MEB-Plattform rotieren ihre MAC-Adressen durch. Ob das standardkonform ist oder nicht lässt sich vermutlich drüber streiten, VW argumentiert dort mit Datenschutz (d.h. die wollen explizit das man ein Auto nicht identifizieren kann). Probleme beim SoC auslesen: ISO 15118-2 sieht zwei komplett unterschiedliche Pfade vor, ganz am Anfang der Kommunikation wird ausgehandelt ob die Ladestation AC oder DC kann. Wenn wir dort AC wählen können wir den SoC nicht auslesen. Das sieht der Standard bei einer AC-Ladung einfach gar nicht vor. Also wählen wir DC, lesen den SoC und brechen die Ladung dann ab. Der Standard sieht das Beenden einer Ladung vor, allerdings unterstützen dass die meisten Hersteller nicht. Daher gehen wir dort unterschiedlichste Methoden Stück für Stück durch. Wir probieren da erst StatusCode=EVSE_Shutdown und dann ProcessingType=Finished und dann irgendwann ResponseCode=Failed und wenn das alles nicht hilft hören wir einfach auf dem Auto zu antworten, welches dann in ein Timeout läuft. Letzteres versuchen wir zu verhindern weil das oft dazu führt dass der Nutzer vom Auto eine Notification bekommt das etwas mit der Ladestation nicht stimmt (auch wenn danach alles korrekt weiter läuft). Nachdem die DC-Ladung dann beendet wurde starten wir eine AC-Ladung über IEC 61851. Ab der Stelle ist dann oft eine CP-Trennung notwendig damit das Auto auch darauf reagiert, das passiert dort mit dem gleichen Weckruf wie beim PV-Überschussladen. Neuerdings gibt es die ISO 15118-20, diese löst auf dem Papier alle Probleme: Man kann über die ISO 15118-20 per AC laden und gleichzeitig den SoC auslesen und man kann dem Auto Ströme unter 6A vorgeben. Mit der ISO 15118-20:AMD1 ist sogar AC-bidirektionales Laden möglich. Sie kommt aber mit neuen Problemen. Problem Wallbox soll ohne Cloud/Internet funktionieren: Bei der ISO 15118-20 ist TLS 1.3 mit "mutual authentication" vorgeschrieben. Das funktioniert indem eine verschlüsselte Verbindung aufgebaut wird und die Zertifikate gegenseitig geprüft werden. Damit das Auto das Zertifikat einer WARP4 prüfen kann, muss dieses von einer Instanz ausgestellt werden dem das Auto vertraut (z.B. von Hubject). Dafür müssen wir CPO (Charge Point Operator) werden und einige Auflagen erfüllen und unseren ISO 15118-20 Stack abnehmen lassen. Wenn das alles soweit erfüllt ist müssen diese Zertifikate alle drei Monate erneuert werden, was defakto bedeutet dass eine WARP4 die ISO 15118-20 sprechen möchte zumindest einmal alle drei Monate mit dem Internet verbunden sein muss... Edit: Zur Frage ob sich das auflöst: Ich denke die ISO 15118-20 wird es langfristig tatsächlich lösen und besser/robuster machen. Allerdings werden nicht alle Autos ein Software-Update dafür bekommen und wir werden die ganzen Hacks entsprechend für eine lange Zeit noch mitführen müssen.

Um welche Autos handelt es sich denn? Kannst du einmal ein Debug Report herunterladen und hier anhängen? Edit: Kann es sein dass du unter Wallbox -> Einstellungen den Fahrzeug-Weckruf deaktiviert hast? Das könnte die Symptome gut erklären. Wir müssen bei vielen Autos eine CP-Trennung durchführen damit sie nach der ISO 15118-Kommunikation eine AC-Ladung starten. Wenn der Weckruf ausgestellt ist wird die nicht durchgeführt.

Steht bereits auf der TODO-Liste. Das Ladelog auf ein neues Format zu migrieren ist leider sehr viel Aufwand, daher will das gut geplant sein und sollte direkt im ersten Anlauf alle Erweiterungen beinhalten die wir haben wollen. Dadurch zieht sich das ein bisschen hin.

Oh, in dem Fall sollte sich eigentlich ein externer Browser öffnen. Greifst du lokal oder über den Fernzugriff auf die Box zu?

Hast du das Fahrzeug denn auch angelegt und einem Benutzer zugeordnet? https://docs.warp-charger.com/de/docs/tutorials/soc_autocharge Wenn du Autocharge und Ladefreigabe aktivierst, das Auto aber keine Benutzer zugeordnet ist, dann fängt auch keine Ladung automatisch an.

Tesla verkauft seit 2019 Ladestecker mit CCS in Europa und es gab Model 3/Y nie ohne CCS.

Ja, das steht bereits auf der TODO-Liste.

Ja, das wurde getestet. Nach dem SoC-Auslesen wechselt die Wallbox in den normalen AC-Lademodus. Startet das Fahrzeug dort die Ladung nicht, führt die Wallbox automatisch eine CP-Trennung durch und verbindet anschließend wieder. An der Stelle wird zuerst für 4s CP-Trennung durchgeführt, dann für 30s gewartet, dann eine CP-Trennung für 30s, dann 30s warten, dann probieren wir ein Wecken über Fehlerzustand E/F für 4s, dann 30s Pause und dann Fehlerzustand E/F für 30s. Dann geben wir auf. Zusätzlich hab ich andere mögliche Varianten getestet: 100% PWM E/F-Reset "ISO-15118-Wake-up" (B1->B2) Eine neue SLAC-Kommunikation sowohl mit als und auch ohne Protokollablehnung. Sowie alle Kombinationen die möglich sind (also z.B. zuerst neue SLAC-Kommunikation und dann 100% PWM und dann CP-Trennung etc) Ein Tesla der einmal im "DC-Lademodus" war fängt danach keine AC-Ladung an wenn nicht physikalisch der Stecker einmal getrennt wurde, oder er vollständig eingeschlafen ist und wieder aufgeweckt wird (dauert ca. 30-45 Minuten).

Funktioniert Plug&Charge ist nicht relevant hier.

Der Tesla kann nach dem SoC-Auslesen keine AC-Ladung starten (Autocharge funktioniert). Die anderen vier können Autocharge und nach dem SoC-Auslesen eine AC-Ladung starten.

Sieht jetzt soweit gut aus. Ich hatte in der Zwischenzeit das Backend vom Server einmal neugestartet, das scheint es bei dir gefixt zu haben. Ich gebe deine Logs dem Kollegen der sich bei uns um den Fernzugriff kümmert (der aktuell im Urlaub ist) weiter, vielleicht kann er sehen was genau das Problem war.

Das sieht nach einem komplett anderem Problem aus (womöglich serverseitiges Problem). Kannst du einmal den Debug-Report herunterladen und anhängen?

Ich vermute der SHM integriet selber über den Verbrauchten Strom um die kWh zu berechnen, während die WARP4 die "echten" Daten vom Zähler liest. Da kann SMA aber auch nichts für, die können ja nur mit den Daten arbeiten die EEBUS überträgt.

Ja, das ist aktuell ein bisschen ulkig. Rein technisch hat der Reset über "stromlos + Taster drücken" 3 Stages. Die Information in welcher Stage man sich befindet wird im RAM des EVSE gespeichert. In WARP1/2/3 konnte man auf unterschiedlichste Art und Weise den ESP neustarten ohne den EVSE neuzustarten (bei WARP2 noch mit Taster, bei WARP3 indem man das Kabel ab- und wieder ansteckt). Bei WARP4 sind ESP und EVSE jetzt allerdings so integriert dass man so ohne weiteres den ESP nicht stromlos machen kann ohne den EVSE auch stromlos zu machen... ups 🙈. Die Information in welcher Stage man ist muss bei WARP4 in den Flash des ESP. Bringt dir jetzt allerdings nichts, da es bei deiner Firmware-Version noch nicht so ist.

Jo, definitiv 👍

Da die WARP4 persönliche Informationen speichert/ausliest/anzeigt/verarbeitet (Zählerwerte gehören da zum Beispiel dazu) muss sie leider auf Grund der Anforderungen der RED-Richtlinie eine signierte Firmware mit Secure Boot und verschlüsseltem Flash haben. Wenn du ein Passwort gesetzt hast und jemand die Box klaut darf er nicht an deine Daten kommen. JTAG und Flashen per USB etc ist entsprechend auch deaktiviert. Du hast nicht zufällig den Fernzugriff eingerichtet? Per Fernzugriff kommst du auch direkt drauf wenn du lokal ein Passwort eingerichtet hast.

Ich glaube das bedeutet einfach dass die Email die du eingetragen hast nicht registriert ist. Vom Ablauf her musst du zuerst ein Konto bei https://my.warp-charger.com anlegen und kannst dann mit den gleichen Daten auf dem WARP-Gerät das Gerät hinzufügen.

Was passiert wenn du einfach irgendwas für Nutzername und Passwort einträgst? Ich meine wir hätten in der Firmware dass wir ein Login erlauben falls aus irgendwelchen Gründen das Login aktiv ist aber kein Passwort gesetzt.

Die 2.13.4 hat leider einen Bug der dazu führt dass der automatische Versand des Ladelogs bei einigen Nutzern nicht funktioniert und z.T. zum Absturz führt. Am besten gehst du einmal auf Wallbox -> Ladetracker und nimmst dort den Nutzer aus dem E-Mail-Versand (damit es nicht mehr zu dem Absturz kommt), danach dann das Update auf 2.13.5 und dann kannst du den Nutzer wieder hinzufügen.

Ich würde als erstes schauen ob das Kabel auf beiden Seiten richtig im Stecker sitzt: Das Kabel verläuft grob wie in magenta eingezeichnet: Vom DC-Schutz unter der Hutschiene her und im Leiterplattenstapel rechts an den Stecker der am tiefsten ist (am nächsten an der Gehäuserückseite).

Aktueller Stand: Wir haben die ISO 15118-20 implementiert und müssen unsere Implementierung nun noch zertifizieren lassen (dies ist bei der -20 technisch notwendig um sie überhaupt nutzen zu können). Ich hab dazu diese Woche unsere erste Version des Compliance Report eingereicht. Wenn wir zertifiziert sind, dann können wir über die ISO 15118-20 eine "gegenseitig authentifizierte" Verbindung zu einem Auto aufbauen (wenn dieses auch die ISO 15118-20 unterstützt und auch zertifiziert ist). Das alleine ist schon sehr cool, da wir dann gleichzeitig AC laden und SoC auslesen können. Zusätzlich ist es möglich Ströme unter 6A vorzugeben, was natürlich gut fürs PV-Überschussladen ist. Für das AC-bidirektionale Laden müssen zusätzlich noch Netzparameter übertragen werden, dafür wurde Mitte Juli dieses Jahres die ISO 15118-20:AMD1 veröffentlicht. Bei den Netzparametern geht es um Blindleistungskennlinien, Frequenz-Wirkleistungs-Kennlinien und sowas. Dies zu implementieren ist für uns "nur" Fleißarbeit, der größere Aufwand liegt da im Wechselrichter des Autos der diese Parameter umsetzen muss. Zusätzlich wird gemunkelt dass es zum ~Februar 2027 noch eine aktualisierte Norm geben soll die zusätzliche Regelungen für den Netz- und Anlagenschutz beim AC-bidirektionalen Laden festlegen soll. Wir gehen davon aus dass die WARP4 hardwaretechnisch dafür vorbereitet ist. D.h.: Sobald wir für die -20 zertifiziert sind, die -20:AMD1 implementiert haben, ein Auto auch beides hat, der lokale Netzbetreiber die Netzparameter festgelegt hat und die neue NA-Schutz-Norm eingehalten wird, sind wir technisch in der Lage AC-bidirektionales Laden durchzuführen. Oben drauf kommt dann sowas wie MiSpeL, welches festlegt wann genau entladen werden darf (z.B. Entladung nicht gestattet wenn Strompreise negativ sind und ähnliches). Diese Regeln dann noch zu implementieren ist aber im Vergleich zum Rest kein großes Problem. Könnte natürlich passieren dass sie sich dort auch noch eine Prüfnorm/Zertifizierung o.ä. ausdenken die wir erst angehen müssen.

Jo da war leider ein Bug der bei einigen WARP-Geräten dazu geführt hat dass das Ladelog nicht verschickt wurde. Zum Teil hat es sogar zu einem Crash geführt. Das ist in der 2.13.5 bereits gefixt.

Ja, das wäre ein minimaler standardkonformer EEBUS-QR-Code. PS: Der QR-Code im Webinterface wird im nächsten Firmware-Release schon mit drin sein.

Aber an einer DC-Ladesäule kannst du aktuell laden? Das würde ja bedeuten der Zeekr kann physikalisch zwischen dem Typ2- und CCS-Stecker unterscheiden und verhält sich unterschiedlich. Ist natürlich technisch möglich, aber kann mir gar nicht so richtig vorstellen. 🤔