borg

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

Ich hatte in der Firmware die Zeit die wir warten bis das Auto mit uns ISO 15118 spricht zum Testen von 7s auf 50s erhöht. Viel mehr können wir dann da nicht machen. Andere Idee: Kann es sein dass du sowas wie 80% Ladeziel im Auto eingestellt hast und der aktuelle SoC über 80% liegt? das könnte ein guter Grund sein warum das Auto nicht mit uns sprechen möchte.

Da muss rein was du bekommst wenn du an die URL deines WARP-Geräts '/info/name' anhängst und dort unter 'name'. Sollte sowas sein wie "warp4-2i76" sein.

Jo, das steht schon auf meiner TODO-Liste. Wenn du das dringend benötigen solltest bevor es in der Firmware ist kannst du dir aber auch einfach online den QR-Code aus der SKI generieren, hier z.B.: https://www.livinglabcologne.com/qr-code-generator-de/

Bitte einmal ein Debug-Report herunterladen und anhängen. Wenn die Box frisch in Betrieb genommen wurde: Vielleicht auch direkt einmal stromlos machen, den Deckel aufschrauben und schauen ob das NFC Bricklet mit dem ESP verbunden ist. Das NFC ist ganz rechts an die Gehäusewand geklebt und es geht ein Kabel zum Leiterplattenstapel links daneben. Vielleicht ist das bei der Installation rausgerutscht o.ä.?

Probier es bitte noch einmal mit der Firmware im Anhang (der Verbindungsaufbau wird jetzt länger dauern, bitte so ~3 Minuten warten nach dem Einstecken) und zieh dann nochmal den Debug-Report. warp4_firmware_2_13_4_6abcbae6_826ea92e1189257_ota.bin

Ich würde einmal die EEBUS-Verbindung zwischen der WARP4 und EVCC entfernen. EVCC steuert uns über HTTP. EVCC kann keine Daten über EEBUS auslesen oder uns drüber steuern und scheint deswegen alle 5 Minuten eine Neuverbindung zu machen. Das hat aber nichts mit ISO 15118 zu tun, spammt nur das Eventlog zu. Kannst du einmal schauen ob man beim Zeekr 7GT irgendwie "ISO 15118 for AC" oder "Plug&Charge for AC" oder sowas aktivieren kann? Im Debug Protokoll sieht alles gut aus, es gibt keine Fehler o.ä. Das Auto spricht allerdings keinerlei ISO 15118 mit uns.

Bitte einmal den Debug-Report herunterladen und hier anhängen, dann kann ich schauen was das Problem sein könnte.

In dem Debug-Report sieht so aus als hättest du keine NFC-Karte vor die Box gehalten, aber der OCPP-Server erwartet eine Freigabe.

Den Lademodus kann man mit dem Knopf den es gibt auswählen 😅

Ich würde sagen das ist beides eine Design-Entscheidung. Auf den Fotos ist das Aussehen der Box glaube ich oft nicht so richtig zu greifen, aber in echt ist der Formfaktor schon sehr hübsch. Auf das Display vom Zähler schaut man in der Praxis sowieso nicht, das Fenster ist defakto nur da weil wir es für eine eichrechtskonforme Variante rechtlich benötigen.

Laut Debug-Report ist die WARP2 aktuell nicht mit Powerfill verbunden (connected: false, BootNotification wurde nie bestätigt). Soweit ich das sehe ist kein Passwort eingetragen, kann das sein? Wenn da ein PW benötigt wird bitte unter OCPP -> "Autorisierung aktiviert" anklicken und darunter das Passwort eintragen. Stimmt die Charge-Point-ID (warp2-292S) mit der in Powerfill exakt überein (Groß-/Kleinschreibung), stimmt die URL?

@schonOK Dein Smart hat kein CCS, richtig? In dem Fall gibt es dann keine Möglichkeit den SoC auszulesen. Dein Smart ist das erste Auto was ich gesehen hab welches kein CCS hat und trotzdem ISO 15118 spricht. Wusste gar nicht das es das gibt.

2 und 3 sind korrekt, zu 1 kann ich nichts sagen. Wenn eine individuelle Freigabe der WARP4 möglich ist sag auf jeden Fall gerne einmal Bescheid, wäre für uns ja sehr interessant. Aus Sicht der DKV sollten sich WARP3 und WARP4 aber eigentlich nicht unterscheiden. Wenn eine Freigabe der WARP4 möglich ist sollte das auch für WARP3 möglich sein. OCPP funktioniert aktuell mit beiden gleich. Das ändert sich in der Zukunft dann mit OCPP 2.1 und ISO 15118-20 (was nur mit der WARP4 geht), aber dafür hat aktuell noch niemand Unterstützung.

Das funktioniert in der Tat per mDNS. Du musst mDNS auf der WARP4 aktiviert haben und dein Handy muss die WARP4 per mDNS sehen können. Händisch eintragen kann man dort nichts. Wenn du sowieso immer lokal über eine Fixe IP drauf zugreifen kannst weil du immer im VPN bist kannst du auch einfach die WARP4 mit dem Browser öffnen und dann "..." -> "Zum Startbildschirm" hinzufügen.

Ich befürchte die DKV setzt immer Eichrechtskonformität voraus (also sie behandeln das so wie öffentliches Laden). Eichrechtskonformität ist aktuell weder bei der WARP3 noch bei der WARP4 gegeben. Wir planen eine eichrechtskonforme WARP4 zu veröffentlichen, das wird allerdings noch einige Monate dauern, ist ein langwieriger Prozess. Eine eichrechtskonforme Wallbox im privaten Umfeld einzusetzen hat aber auch viele Nachteile. So müssen wir z.B. den Zähler und die Anschlüsse zu den Schützen etc verplomben. So dass z.B. das Austauschen eines defekten Schützes vom Elektriker vor Ort nicht mehr möglich ist. Auch sowas wie ein WARP3->4 Upgrade ist definitiv nicht möglich wenn Eichrechtskonformität notwendig ist.

https://docs.warp-charger.com/de/docs/interfaces/mqtt_http/api_reference/ev/#ev_inject_soc_warp4

Ich befürchte bei dem Citroen können wir nichts machen, da er auf keine der möglichen Optionen reagiert. Also das Auto wechselt einfach nicht (in einer angemessenen Zeit) in eine AC-Ladung nachdem der SoC gelesen wird. Da können wir aktuell nur auf die ISO 15118-20 warten und darauf hoffen dass die Autohersteller Updates anbieten.

Jo, die Einstellung ist in der Tat aktuell noch "flüchtig". Steht schon auf der TODO-Liste dass das auch gespeichert werden muss.

"Warte auf Freigabe" bedeutet das irgendwas noch freigeben muss (vielleicht wegen PV-Überschussladen o.ä.?). Da ist das Auto noch nicht involviert. Wenn es auf "Ladebereit" steht und nicht auf "Lädt" springt ist es das Auto was nicht möchte.

Grundvoraussetzung für AC bidi Laden ist natürlich dass das Auto auch einen entsprechenden DC-AC-Wechselrichter verbaut hat, wie @Steven.Engelhard schon gesagt hat. Allgemein zur Frage: Ja. Soweit wir wissen ist aktuell in der WARP4 alles an Hardware verbaut was für "echtes AC bidi Laden" notwendig ist. Die neue "Amd1" bringt keine neuen Hardwareanforderungen mit sich. Aufgrund dessen wie die Kommunikation bei der "-20" funktioniert ist softwareseitig eine Zertifizierung notwendig, wir sind dort gerade im Zertifizierungsprozess. Wir wissen aktuell noch nicht ob es für die AMD1 eine weitere notwendige Zertifizierung geben wird, ich könnte es mir aber vorstellen. Das hat bei uns auf jeden Fall höchste Priorität, wir haben natürlich ein großes Interesse daran mit als erstes eine funktionierende AC-BiDi-Wallbox anzubieten. Es gibt zusätzlich noch die IEC 61851-1 Edition 4. Diese Norm ist noch nicht veröffentlicht und wir wissen nicht was drin stehen wird. Es wird gemunkelt dass dort neue Anforderungen zum Netz- und Anlagenschutz bzgl bidi Laden veröffentlicht werden könnten🔮.