borg

In the log it looks like you turned the ISO 15118 off while the EV was connected, it then tried to talk to us, then you turned it on while in the middle of talking to us. We are not handling this well in the firmware, i think i can see why it read the SoC but did not increase it with the charging. I will improve this in the firmware for future versions, so there is no "race condition" any more. Just to be completely sure that there is nothing stuck, please Reboot the box once when no EV is connected (System -> Settings -> Reboot). Does the SoC still get stuck then next time you connect the EV?

👍 Das hat dann auch nichts mit SoC auslesen oder ISO 15118 zu tun, das Verhalten (dass sie ohne Willkommensladung nach einer Weile nicht mehr aufweckbar sind) haben wir schon bei vielen Autos gesehen. Bei uns gibt es immer automatisch eine Willkommensladung wenn man PV-Überschussladen oder Lastmanagement aktiviert. Mich wundert dass das bei EVCC nicht prominenter integriert ist.

"SoC shutdown ignored after 11 retries, sending FAILED" ist das erwartete Verhalten bei dem OBC von Aptiv den dein Auto hat. Den Weckversuch um 06:37 gab es, der taucht nicht im Log auf da er intern vom EVSE gemacht wird. Wenn du EVCC aus machst (oder direkt auf schnell stehen hast) und den SoC ausliest, dann lädt er auch sofort, richtig? In dem Fall würde ich davon ausgehen dass dem Auto die Willkommensladung fehlt. Schau mal ob du bei EVCC Willkommenladung oder "Welcome Charge" aktivieren kannst.

Apps: iOS 2.2.1 iOS: https://apps.apple.com/de/app/warp-by-tinkerforge/id6736695801 Neuladen bei Menüklicks im lokalen Modus unter iOS 27 gefixt

@StarviMarvin Schreibst du uns auch einmal per Email an info@tinkerforge.com an mit Bezug auf diesen Thread? Ich würde bei dir dann auch vorsichtshalber einmal das PLC-Modem tauschen wollen.

Danke fürs Testen. Ich kontaktiere dich per Email bzgl dem Austausch des Upgrade-Kits, ich denke da stimmt etwas mit der Hardware nicht. Entschuldigung für die Probleme!

Auf github versucht gerade jemand das Auslesen de SoC per BLE zu vide-coden: https://github.com/Tinkerforge/esp32-firmware/issues/535 Ich bin mir nicht sicher ob wir genug RAM dafür haben das in die generelle Firmware zu bringen, aber ist auch ein interessanter Ansatz. Ansonsten würde ich aktuell erstmal bis zum Jahresende warten und schauen was mit der ISO 15118-20 passiert. Aufgrund der AFIR-Regeln muss eigentlich auch Tesla zumindest für Neufahrzeuge bald die ISO 15118-20 bieten. Falls Tesla das Software-Update dann auch für die älteren Fahrzeuge ausrollt (was ich eigentlich erwarten würde), können wir den SoC direkt auslesen während des Ladens.

Sieht in der Tat sehr ähnlich aus. Auch da wäre meine erste Frage ob vielleicht 80% SoC-Ziel o.ä. eingestellt ist (ich frage weil wir wissen dass einige Autos dann einfach gar kein ISO 15118 mehr sprechen, wenn das Ziel erreicht ist). Wäre sonst schön wenn einer von euch vielleicht irgendwie mit einem anderen Auto testen könnte. Die Befürchtung wäre dass es sich um defekte Hardware handelt. Hatten wir bisher allerdings noch nie beim PLC-Modem und ich kann in die Test-Reports von beiden sehen dass die Dämpfungswerte vom PLC-Modems bei uns gut waren (einmal reguläre WARP4 und einmal 3->4 Upgrade-Kit). Also PLC-Modems haben beiden definitiv funktioniert ursprünglich. Aber da bleibt ja irgendwann dann keine andere Möglichkeit mehr 🤔.

Solange du ein Passwortmanager hinterlegt hast bei Android funktioniert das Merken des Logins bereits. Direkter Zugriff via IP steht auf der TODO-Liste, hat aber keine Prio. Ist hauptsächlich eine Frage der UI, das ganze ist jetzt schon viel zu kompliziert für Nicht-Nerds und zusätzliche Eingabemasken für IPs auf der my.warp-charger.com Startseite würde da nicht helfen. Langfristig sollten die Apps vermutlich die Startseite von my.warp-charer.com gar nicht nutzen, sondern native Elemente für den lokalen Zugriff und die initiale Registrierung. Dann könnte man die App auch lokal ohne Zugriff zum Internet nutzen.

In der Kombination iOS 27 + lokal per App + Passwortschutz aktiviert kann ich es erzeugen (mit iOS 26 nicht, über Safari nicht, per Fernzugriff nicht, ohne PW nicht). Super komisch. Ich hab damit rumgespielt, sobald einmal ein reload gemacht wurde ist das Problem weg. d.h. eine Lösung ist dass wir beim ersten öffnen vom Webinterface einmal direkt reload aufrufen (hab ich auch schon getestet als Hack in der App, funktioniert). Ich denke das ist ein Bug in dem WebView in iOS 27, aber das ist so spezifisch, das wird vermutlich nicht so schnell gefixt werden. Jetzt muss ich entscheiden ob ich einfach ein Release 2.2.1 mit dem Hack mache oder ob mir noch was besseres einfällt.

🤔 Ich schaue morgen nochmal. Rein technisch ist der Unterschied dort dass über den Fernzugriff die Webseite in in der App in einem iframe auf my.warp-charger.com läuft und lokal direkt in der App.

Dann würde ich erstmal abwarten. Sag Bescheid falls es nochmal auftritt.

Mh, kann das jemand anderes mit einem iphone/ipad reproduzieren? Unser Test-iPad in der Firma macht das nicht, ich hab privat gerade kein ipad/iphone hier zum testen.

Nur um sicher zu gehen das wir uns nicht vom Gegenteil überzeugen: Kannst du einmal die Firmware auf den neusten Stand bringen, dann 15 Minuten warten (damit die Firmware als valide markiert wird in der WARP4), dann die WARP4 vom Strom trennen und wieder verbinden damit das PLC-Modem definitiv in einem guten Zustand ist und dann nochmal das Auto anstecken? (vorher natürlich Autocharge / SoC auslesen aktivieren) Und dann nochmal den Debug-Report herunterladen? edit: Hast du vielleicht irgendwie die Möglichkeit das mit einem anderen Auto zu testen?

Apps: iOS 2.2.0, Android 2.2.0 iOS: https://apps.apple.com/de/app/warp-by-tinkerforge/id6736695801 Links zu öffentlichen Webseiten öffnen sich jetzt im Browser. Das Herunterladen von Debug-Reports über das Webinterface der Wallbox funktioniert wieder. Android: https://play.google.com/store/apps/details?id=com.tinkerforge.warp&hl=de Links zu öffentlichen Webseiten öffnen sich jetzt im Browser. Die Anmeldung bleibt nach dem Schließen der App erhalten.

Aktuell nicht (OCPP sieht soetwas allerdings tatsächlich vor). Im Zuge der ISO 15118-20 müssen wir unseren OCPP-Stack aufbessern. Eventuell müssen wir an der Stelle Caches für OCPP 2.1 hinzufügen und könnten das dann für OCPP 1.6 backporten. Das wird allerdings etwas dauern bis das soweit ist, stand aktuell kann der Nutzer bei einem Ausfall nur OCPP ausschalten und dann einfach lokal laden (und hinterher wieder anschalten).

Deine Übersicht zeigt welche Unterseiten es im Webinterface gibt je Variante. Ich denke die meisten Unterschiede zwischen den Generation sind in der verbauten Hardware und den Einstellungsmöglichkeiten die man auf den Seiten hat. Hier mein Versuch einer Feature-Auflistung: WARP1: WLAN, PV-Überschussladen, Lastmanagement (bis 10 Wallboxen), Batteriesteuerung, externe Zähler, Benutzerverwaltung mit NFC, Ladetracker mit PDF-Export, Automatisierung, MQTT, Modbus/TCP, WireGuard, Fernzugriff, Boost-Modus, Schützüberwachung. Pro-Variante mit Stromzähler nur dreiphasig anschließbar, DC-Fehlerstromüberwachung löst vorgeschalteten FI aus. WARP1 → WARP2: LAN, HTTPS, OCPP, EEBUS, dynamische Strompreise, PV-Prognose, Eco-Modus, §14a, DC-Fehlerstromüberwachung durch die Firmware, CP-Trennung, EV-Wakeup, Abschalteingang, mehr RAM (Ladetracker, Benutzer, Lastmanagement mit mehr Teilnehmern), auch einphasig anschließbar. WARP2 → WARP3: Eingebaute Phasenumschaltung, RGB-LED, PE-Prüfung, Schützüberwachung über Hilfskontakte, Temperatursensor, eingebaute Echtzeituhr. WARP3 → WARP4: Schaufenster in der Pro mit hochwertigerem Zähler, integriertes PLC-Modem für ISO 15118, SoC-Auslesen und SoC-Ladelimit, Fahrzeugprofile, Autocharge, OVE R 37, Secure Boot, Einfuhr von LAN und §14a Kabel gleichzeitig möglich, [Vorbereitungen für Eichrecht¹ und bidi laden²] ¹ Geplante Hardwarevariante ² Per Firmware-Update Über die Generationen hinweg haben wir außerdem viele Details verbessert: Mehr Platz für den Elektriker zum Anschließen, einfachere Fertigung und bessere Prüfbarkeit, umfangreichere Tests zur Temperaturbeständigkeit und Störfestigkeit/Störaussendung sowie zusätzliche Zertifizierungen (z. B. OVE R 37 und ISO 15118-20).

Was zulässig ist bestimmt der Netzbetreiber bei dir vor Ort. Wir haben 850 Netzbetreiber in DE und jeder hat andere Vorgaben. Zum Teil ist denen das egal wie es angeschlossen ist, zum Teil verlangen sie auch ein vom Heimnetz getrenntes Netz für die Steuerung über EEBUS... Das ist im EEBUS LPC usecase schon vorgesehen und implementiert von uns. Gibt (genau dafür) auch noch ein paar bug fixes mit dem nächsten Firmware-Release.

Für WARP1 kannst du den normalen ESP32 Brick nehmen und mit Brick Viewer per USB eine WARP1 firmware drauf flashen: https://shop.tinkerforge.com/de/bricks/esp32-brick.html

OCPP sieht das leider nicht vor. Jetzt wo wir Änderungen an den Schnittstellen ohne neustarten speichern können, könnte ich mir eine Automatisierungsregel vorstellen die beim Vorhalten der privaten NFC OCPP deaktiviert und bei Wechsel in State A (auto abgesteckt) OCPP aktiviert. Die Aktion dafür gibt es noch nicht, aber wäre nicht viel Aufwand das hinzuzufügen. Die Frage ist was Powerfill dann macht. Aus sicht von Powerfill verschwindet die Wallbox (gibt eventuell ein Alert oder so) und taucht irgendwann wieder auf. Beim nächsten Firmenladevorgang über Powerfill ist der Zählerwert dann nicht mehr konsistent (der Startwert entspricht nicht dem letzten Endwert). Ich könnte mir vorstellen dass das auch als Fehler angezeigt wird. Ihr könntet das ja einmal händisch testen: Über Firmen-NFC laden, OCPP ausstellen, über Privat-NFC laden (lokal autorisiert), OCPP wieder einschalten und über Firmen-NFC laden. Erzeugt das Probleme bei Powerfill? Falls ja wird es schwierig da eine Lösung für zu finden, weil den Zähler können wir nicht abschalten, der Läuft immer mit.

Das Protokoll ist OCPP 2.1. Ob da langfristig eine IP ausreicht oder nicht hängt vermutlich davon ab wie viele Wallboxen wir verkaufen in nächster Zeit. Ich hätte ja jetzt gesagt desto mehr desto besser 🙃. Nur um das klarzustellen: ISO 15118-20 ist natürlich optional und, wie auch jetzt schon, wird alles was mit ISO 15118 zu tun hat im Auslieferungszustand deaktiviert sein. D.h. deine bestehende Box wird keine Features verlieren o.ä. wenn sie nicht im Internet hängt.

Oh my sweet summer child... 😅 Es handelt sich dabei nicht um ein Zertifikat welche in der Firmware embedded ist, es ist ein Zertifikat für deine spezifische Wallbox (und es darf diese Wallbox nie verlassen). Erneuert wird es per CSR (Certificate Signing Request), welches von deiner Box getriggert wird: Damit wir das abgenommen bekommen muss die WARP4 zusätzlich auch OCSP mit Stapling unterstützen. Und das Zertifikat was da erneuert wird ist nur eins in einer länglichen Certificate Chain: Wir betreiben dort in der Chain "CPO Sub CA1" und deine Wallbox ist SECC. Das Zertifikat von dem wir geredet habe ist das "SECC certificate". Das Auto (EVCC) wird dann später prüfen ob SECC certificate sowie alle anderen Certs in der Chain von V2G Root CA signiert wurden und maximal drei Monate alt sind. Die Wallbox macht das gleiche mit der Chain vom Auto (mutual authentication). Was wir nicht alles tun um ein Schütz zu schalten.

Ah du meinst den Anmelde-Dialog direkt auf dem Gerät wenn du einem Nutzer ein Passwort hinterlegst. Da würde ich dir recht geben, da könnte in der Tat stehen auf welches Gerät du dich gerade einloggen möchtest 😅.

Welche WARP-Variante es ist steht, egal ob Browser oder App, immer im Menü unten links? Und auf der Statusseite kann man der Box einen Namen geben, damit kann man es auch unterscheiden.

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.