borg

So, vielen Dank für den Aufwand. Bin endlich dazu gekommen mir das anzusehen. Hab jetzt aus allen Werten für beide Autos den Durchschnitt gebildet für die neue Kalibrierung. Ich hoffe damit klappt es jetzt dann auch mit beiden Autos :). calibration.json

Es sind ein paar Detailverbesserungen drauf: Mehr Schutzbeschaltung, zwei Schütze ansprechbar, verbesserte CP-Trennung, die Schützprüfung kann jetzt zwischen Schützfehler bei Schütz 1 und 2 sowie PE-Fehler unterscheiden (vorher waren Fehler bei der PE-Verkabelung und Schützfehler nicht unterscheidbar), Temperaturüberwachung, geringerer Stromverbrauch und wir können jetzt eine RGB-LED in der Front ansprechen. Die Ethernetbuchse sitzt jetzt auch an einer besseren Stelle, wo sie für den Elektriker besser anschließbar ist. Vieles davon (neben den neuen Features) ist Umsetzung von Feedback das wir von den Elektrikern bekommen haben um die Box einfacher in Betrieb zu nehmen und Fehler besser diagnostizieren zu können. Das steht aktuell noch auf der Kippe, dazu gibt es dann mehr wenn sicher feststeht welchen Zähler wir verbauen.

Ich glaube du hast ein Debug-Report angehängt, das ist nicht das gleiche wie ein Ladeprotokoll 😅. Schau mal unter Wallbox -> Ladestatus -> Ladeprotokoll. Dort gibt es die Möglichkeit ein Ladeprotokoll zu starten und zu stoppen. In dem Ladeprotokoll ist dann der komplette Zustand der Wallbox hochfrequent aufgezeichnet. Da kann man dann sehen wo das Ping-Pong herkommt.

Prinzipiell wird das möglich sein, du brauchst allerdings neben den neuen Schützen auch das EVSE Bricklet und das ESP Brick neu. Die in der V2 verbauten sind auch wenn man sie anders einbaut viel zu groß noch. Das NFC Bricklet, das Gehäuse(*), das Typ2-Kabel, das DC-Schutzmodul und den Zähler(**) kann man aber wieder verwenden. (*) am Gehäuse muss eine kleine Modifikation durchgeführt werden da die Hutschiene bei WARP3 etwas höher ist (**) bei WARP3 werden wir wahrscheinlich einen anderen Zähler verwenden, der Zähler aus WARP2 wird aber natürlich trotzdem weiter Softwareunterstütztung haben.

Bezüglich des Stroms: Rein technisch ist der niedrigste Maximalstrom den eine Wallbox dem Auto mitteilen kann 6A. Etwas geringeres sieht der Standard nicht vor. Das Auto darf aber weniger laden wenn es das von sich aus tut. Zu den Aussetzern: Am besten machst du einmal ein Ladeprotokoll von dem Problem. Dazu unter Wallbox -> Ladestatus -> Ladeprotokoll -> Start ein Ladeprotokoll starten. Dann das Auto anschließen und eine Ladung mit 8A starten und dann auf 7A und dann auf 6A runter gehen (jeweils mit 30 Sekunden Wartezeit o.ä.). Dann Wallbox -> Ladestatus -> Ladeprotokoll -> Stop+Download und mir das Ladeprotokoll schicken. In dem Protokoll sollten wir dann sehen können was genau passiert und warum.

Blog entry Review 2023 / Outlook 2024: https://www.tinkerforge.com/en/blog/review-2023-outlook-2024/

Blogeintrag Rückblick 2023 / Ausblick 2024: https://www.tinkerforge.com/de/blog/review-2023-outlook-2024/

Der Link funktioniert bei mir: https://www.tinkerforge.com/de/shop/warp/warp2-spare-parts/jst-cable-for-sdm630.html

Ganz so einfach ist das leider alles nicht. Bei dem RED Modul fehlt ja noch die Stromversorgung und das Coupling und die Zero-Cross-Detection und der eigentliche Co-Prozessor auf dem der ISO15118-Stack laufen kann etc. Rein von den Hardwarekosten her ist man am Ende eher hier: https://www.codico.com/de/white-beet-eo-1-1-evse-module-sdk-open-no-embedded-firmw Aber die zusätzlichen Hardwarekosten sind gar nicht das Problem. Wenn wir das integrieren und verkaufen wollen muss es auch getestet sein und im Labor mit abgenommen werden etc. Wenn man das machen will hat man die Hälfte der Arbeit einen minimalen ISO15118-Stack zu implementieren schon getan. Solange die gesetzlichen Voraussetzungen noch nicht gegeben sind und es keine Autos gibt die eine Rückspeisung per AC unterstützen ist das aus unserer Sicht den Aufwand nicht Wert. SoC auslesen können wäre cool. Die ID mit der man Fahrzeugerkennung machen könnte wird bei neueren Autos durchrotiert damit man diese nicht dafür nutzen kann (z.B. bei VW ab FW3.5). Für richtiges Plug&Charge braucht man ein Zertifikatsmanagement das bei einer Heimwallbox leider auch nicht so ohne weiteres umzusetzen ist und AFAIK bei einer Offline-Wallbox die nicht mit dem Internet kommuniziert gar nicht möglich. Falls sich "AC-Rückspeisung" durchsetzen wird, werden wir ISO15118 definitiv nachrüsten (müssen). Aktuell ist das aber noch alles zu ungewiss.

Bei dem Modul fehlt die notwendige Software, das ist im Grunde nur ein Phy. Es gibt aktuell noch keinen Open Source embedded ISO15118-Stack und das selber zu implementieren liegt außerhalb unserer Möglichkeiten. Wir müssten wenn dann dieses Modul verwenden: https://www.codico.com/de/white-beet-ei-evse-embedded-iso15118-module Aber wozu? Es gibt aktuell noch kein Auto das AC V2G/V2H unterstützt und die notwendigen gesetzlichen Voraussetzungen sind noch nicht gegeben (was openwb fairerweise aber auch genau so angibt bei der openwb pro).

Bevor wir da jetzt noch ewig rumsuchen: Schick uns einmal eine Email mit der Bestellnummer der Bestellung in der das Bricklet drin war und den Hinweis auf diesen Forenbeitrag, wir schicken dir dann ein neues Bricklet zu.

Mh, also in dem Log ist es definitiv so dass das Auto jedes mal die Ladung von sich aus abbricht und dann wieder anfängt zu laden. Die Frage ist warum es das macht. Wenn das Auto kurz in dem Fehlerzustand ist, sagt es dann warum es im Fehlerzustand ist?

Das ist normal, an der Stelle können wir auch nichts nachjustieren. Die Kalibrierung für WARP1 bezieht sich auf das erkennen des Widerstandes den das Auto anlegt, nicht auf die Pulsweite (welche den Strom vorgibt). Die Pulsweite ist immer genau, da gibt es nichts zu kalibrieren. Da allerdings viele Autos gerne ein bisschen weniger ziehen als ihnen erlaubt wurde, kannst du unter Wallbox -> Lade­ein­stellungen den "Boost-Modus" aktivieren. Dann legen wir immer eine etwas höhere Pulsweite an als eigentlich eingestellt und es sollte bei dir näher an den eingestellten Wert kommen.

Unsere Wallboxen (ohne Kabel) sind immer auf 22kW ausgelegt. D.h. wenn du einen WARP Charger kaufst und da selber ein 11kW-Kabel dran machst hast du eine 11kW-Wallbox und wenn du ein 22kW-Kabel dranmachst hast du eine 22kW-Wallbox. Ich würde das vom verfügbaren Netzanschluss abhängig machen. Wenn bei dir 22kW/32A möglich ist würde ich auch ein 22kW-Kabel nehmen um da zukunftssicher zu sein. Allerdings ist das 22kW-Kabel natürlich auch schwerer und störrischer, was bei einem 10m langen Kabel vielleicht auch nervig sein könnte. Muss jeder selber für sich entscheiden.

Wir haben bisher in solchen Fällen immer die Metron-Kabel verbaut. Die sind von der Qualität her gut. Das offiziell angegebene IP-Rating bei Metron halte ich allerdings für gewagt, ich würde das Kabel nicht langfristig im Regen hängen lassen.

Der Tesla-Button wird nicht benötigt. Man kann damit die Ladeklappe öffnen (aber das geht natürlich auch aus dem Auto heraus oder mit der App).

Ja, der WARP2 Charger ist förderfähig und wird auch direkt wenn diese veröffentlicht wird in der Liste der geförderten Ladestationen stehen.

Hast du dran gedacht dass der eigentliche Wert per uint16_t *ret_value zurückgegeben wird und der Rückgabewert der Funktion einen Fehler-Code zurück gibt (wobei 0 = OK)?

Da ist auch aktive Elektronik und eine Knopfzelle drin, schau mal hier das erste Bild: https://www.evchargeking.com/Media/Uploaded/Tesla Connector Installation Instructions.pdf

Wie meinst du das? Der "Onbordlader" wandelt bis zu 16A bei 230VAC (11kW) in 400VDC und packt es in die Batterie. Die IDs haben keinen DC -> AC Wechselrichter im Auto. An die 230VAC kommst du danach nicht wieder ran.

Die Anforderungen an das bidirektionale Laden sind bei der Förderung aber auch wirklich hoch Ich bin gespannt welche Wallboxen da dann in der Liste stehen die das unterstützten und was die kosten.

Ich glaube das ist nicht vorgesehen da das Kabel verklebt ist.

Hast du ein Beispiel für so einen Stecker?

Ich hab es mal auf die Liste der interessanten Sensoren gepackt 😀.

Anbei die angepasste Kalibrierung. calibration.json