poohnet

Ein ähnliches Verhalten hatte ich mit meinem ID.4 auch, hier hat die Ladung sogar erst bei 9A stabil begonnen. Evtl. testest du einfach mal meine Kalibrierung aus folgendem Post: Gruß Thomas

Wenn du schon einen SMA Home Manager 2.0 (bzw. SMA Energy Meter) hast, kannst du die Daten auch netzwerktechnisch abgreifen und dem WARP Energy Manager per API zur Verfügung stellen. Ist zwar (noch) ein inoffizielles Feature, funktioniert aber 1a 🙂

Details zur „Kommunikation“ zwischen Wallbox und Fahrzeug sind z. B. hier gut beschrieben: https://ladefragen.de/27/

Ganz einfach, es lädt dann nur ein- oder zweiphasig 🙃 Die Wallbox stellt nur eine oder drei Phasen bereit und teilt dem Auto (über die CP-Leitung) mit, wieviel Strom es maximal ziehen darf. Der Ladecontroller im Auto entscheidet dann selbst, wie viele Phasen verwendet und wie viel Strom tatsächlich gezogen wird. Bei meinem Passat GTE waren in der Ladebuchse beispielsweise L2 und L3 gar nicht verbunden... Gruß Thomas

neue Firmware 2.1.4 für WARP on Steroids Anpassungen s. hier: Zusätzlich kann die Firmware nun ein "Industrial Quad Relay"-Bricklet ansteuern, mit dem ich eine CP-Trennung implementiert und damit die vollständige Kompatibilität mit dem WARP Energy Manager hergestellt habe (Stichwort Phasenumschaltung): Das neue Modul ist zwar eigentlich so gebaut, dass das Standardverhalten erhalten bleibt, wenn das Bricklet nicht gefunden wurde, nichtsdestotrotz wäre es schön, wenn mir z. B. @Little_Company eine kurze Rückmeldung geben könnte, ob die Ladung weiterhin problemlos funktioniert... warp2_firmware_2_1_4_64e60f53_e088a90e321ee92_merged.bin

Hallo Heiko, wenn du in den letzten zwei Jahren einen WARP-Charger gekauft hast, dann ist das mit ziemlicher Sicherheit eine WARP2, d. h. die Tabelle mit den Features sollte passen. Zum Thema "WARP1 on Steroids" kann ich noch ein paar Details beisteuern, da ich (glaube ich) der erste war, der eine WARP1 auf den in WARP2 verwendeten ESP32-Ethernet-Brick aufgerüstet und die Firmware entsprechend angepasst hat: Neben dem Ethernet-Port (den ich selbst nicht verwende) hat dieser Brick aber auch mehr RAM, sodass auch einige der neueren WARP2-Features (z. B. OCPP) funktionieren. Weiterhin habe ich kürzlich die in WARP1 eigentlich nicht vorhandene CP-Trennung nachgebaut, sodass nun auch die 1/3-Phasenumschaltung mittels WARP Energy Manager funktioniert: Aufgrund der modularen und offenen Architektur der Hard- und Software sowie der tollen Unterstützung durch TinkerForge ist meine WARP1 daher noch lange kein "Alteisen"... 🙃 Gruß Thomas

Sieht erstmal gut aus, zweimal neugestartet, kein neuer Peak mehr in der Energiebilanz 😀 Besten Dank für die schnelle Korrektur!

Puh, ich mag mir gerade nicht vorstellen wollen, was ein Wackelkontakt bzw. lose Klemmen bei 11 kW Dauerleistung auslösen können 🫣 Gut, dass das Auto die Ladung abgebrochen hat und es jetzt funktioniert…

Richtig. Beide selbstgebaut mit Repo-Stand von Mitte/Ende letzter Woche. Perfekt, vielen Dank. Dann aktualisiere ich meinen Fork heute Abend mal und baue eine neue Firmware 🙂

Stimmt, kann ich bestätigen 🙃

Ja, er hängt zwischen dem Schütz des WEM und der Wallbox. Ja, ich sende "/meter/state_update" mit state=2 und type=2, sobald die MQTT-Verbindung steht (d. h. nach Empfang des Topics "/mqtt/state"), alle fünf Sekunden "meter/values_update" und "meter/phases_update" und alle 15 Sekunden "meter/all_values_update" (alles an WARP). Jetzt wo ich drüber nachdenke: Könnte das evtl. dadurch verursacht werden, dass das "/meter/state_update" gesendet wird, bevor erstmalig Daten übertragen wurden?

Hallo zusammen, seit ein paar Tagen bin ich ja auch stolzer Besitzer eines Energy Managers und die Steuerung meiner (um die CP-Trennung nachgerüsteten) WARP1 on Steroids funktioniert (fast) perfekt. 🙂 Allerdings ist mir nun aufgefallen, dass ein Reboot der Wallbox in der Energiebilanz reproduzierbar einen Peak von 65.534W (d. h. 64k-1) verursacht, wodurch das Diagramm durch die Skalierung praktisch nutzlos wird: Besonderheit: Der Stromzähler (SDM630) ist in der UV installiert und ich stelle die Werte per MQTT bereit. Hat jemand eine Idee, wodurch der Peak verursacht wird bzw. wie man das verhindern (und evtl. sogar bereinigen) kann? Vielen Dank und Gruß Thomas P. S. Auf der Statusseite ist weiterhin alles in Ordnung, hier ist kein Peak zu sehen...

Am Wochenende habe ich meinen WARP Energy Manager verbaut und die ersten Tests waren erfolgreich 🙂 Standardmäßig lade ich nun weiterhin 1-ohasig, kann auf Wunsch aber jederzeit auch zwischen 1/3-phasig umschalten, was im Ladeprotokoll wie oben schon vermutet aber als separater Ladevorgang aufgezeichnet wird.

Besten Dank, wenn der ID.4 laden soll, dann lädt er auf den ersten Blick jetzt auch im gesamten Bereich von 6A-16A (sowohl ein- als auch dreiphasig) anstandslos 🙂 Allerdings zickt er unter 9A immer noch ein bisschen rum, wenn SOC ist > SOC soll, d. h. keine Ladung stattfindet. Letztendlich ist das aber auch kein Problem, ich werde EVCC einfach standardmäßig auf 75% begrenzen. Damit sollte man dann eigentlich nicht mehr in den Fall reinlaufen. Anbei die beiden neuen Ladeprotokolle... Vielen Dank und Gruß Thomas evse-debug-protocol-2.zip

Moin Erik, anbei die beiden Ladeprotokolle mit Standardkalibrierung. Beim ersten Versuch (2015 Uhr) wurde überhaupt nicht geladen, da SOC ist > SOC soll, beim zweiten (2023 Uhr) habe ich SOC soll entsprechend angepasst und die Ladung hat wie erwartet mit 11 kW begonnen. In beiden Fällen habe ich von 16A bis runter auf 9A keine Auffälligkeiten festgestellt, ab 8A gab's dann aber die oben beschriebenen Probleme. Nur mal so als Idee: Könnte man die Kalibrierung nicht an den User hängen, sodass diese beim Start der Ladung "on-the-fly" geladen wird? Gruß Thomas evse-debug-protocol.zip

Hi Erik, vielen Dank für die schnelle Rückmeldung 🙂 Jepp, hab' ich. (grad zusammenkopiert ;) ) Ok, werde ich so machen. Soll ich den Ladecontroller vorher wieder auf die Standardkalibrierung zurücksetzen oder kann ich die (besser passende) angepasste Kalibrierung beibehalten?

Hallo zusammen, letzten Freitag habe ich meinen Passat GTE gegen einen ID.4 getauscht und die ersten Ladeversuche an meiner WARP1 on Steroids (mit auf Standard zurückgesetzten Kalibrierung des Ladecontrollers) haben leider nicht ganz reibungslos funktioniert. Folgende Probleme sind aufgetreten: SOC 82%, Battery Care aktiv, d. h. Laden bis max. 80%: ein Ladevorgang wird gestartet, das Schütz zieht aber nicht an. Nach wenigen Sekunden wechselt der Status kurz auf "Nicht verbunden" und ein neuer Ladevorgang kann gestartet werden. Lässt man EVCC die Steuerung übernehmen, dann hat man nach kurzer Zeit zwei dutzend Ladevorgänge mit 0,000 kWh und ein bis zwei Sekunden Dauer im Ladeprotokoll. also Battery Care und externe Steuerung durch EVCC deaktiviert und Laden bis 90% erlaubt: Laden mit 6A, 7A oder 8A nicht möglich, Schütz zieht nicht an, Fahrzeug wechselt nach ca. 30 Sekunden auf "Fehler" und der Status springt wieder kurz auf "Nicht verbunden" Laden mit ca. 8,5A: Ladung beginnt, Schütz zieht kurz an, fällt nach ein paar Sekunden aber wieder ab, bevor das Spiel nach ein paar weiteren Sekunden wieder von vorne beginnt ("Tik-Tok") Laden mit >= 9A funktioniert problemlos Bei der Recherche bin ich dann über folgenden Post gestolpert und mit der dort verlinkten Kalibrierung startet die Ladung mit ca. 6,5A 🙂 Ich habe allerdings noch nicht getestet, ob sie stabil durchläuft. Wie muss ich das Ladelog aufzeichnen, damit ihr mir eine passende(re) Kalibrierung erstellen könnt? Soll ich die Standardkalibrierung verwenden (bei der ja erst ab etwa 9A stabil geladen wird) oder schon die angepasste? Vielen Dank & Gruß Thomas P. S. Was ändert die Kalibrierung eigentlich genau in der PWM-Kommunikation zwischen Ladecontroller in der Wallbox und Ladeelektronik im Fahrzeug? Wie sieht die Vorgehensweise aus, wenn zukünftig evtl. ein weiteres Fahrzeug (das ja ggf. eine andere Kalibrierung benötigt) geladen werden soll?

Alles klar, vielen Dank für die Info 👍

Kurzer Zwischenstand: Ich habe tatsächlich noch ein Industrial Quad Relay 2.0 geliefert bekommen und einen ersten Wurf der CP-Trennung in meinem Fork implementiert. Per MQTT "/evse/control_pilot_disconnect_update" kann ich nun das Auto softwareseitig an- und abstöpseln 🙂. Reicht es aus, das API-Feature "cp_disconnect" zu setzen, damit der Energy Manager die Phasenumschaltung triggern kann? Gruß Thomas

Mit einer 3kW-PV werde ich die meiste Zeit eh nur einphasig (nach)laden - außer es muss schnell gehen oder der stündliche Strompreis ist mal wieder extrem niedrig. Eine automatische Umschaltung während einer laufenden Ladung brauche ich somit eigentlich nicht. Ehrlich gesagt finde ich es ganz charmant, wenn mit der CP-Trennung auch eine neue Ladung aufgezeichnet wird. Beim manuellen Neuverbinden wäre das ja auch nicht anders. 🙃 Ich muss mir nur noch überlegen, wo bzw. wie ich die CP-Trennung sicher implementiere. Aktuell tendiere ich dazu, das EVSE-Backendmodul zu erweitern und einen API-Call ans (neue) Relais-Backendmodul zu schicken und hier mittels Monoflop sicherzustellen, dass CP nur dann verbunden bleibt, wenn die Nachricht regelmäßig ankommt.

Hmm, oder vielleicht doch nicht, das Relais-Bricklet ist definitiv zu hoch, d. h. passt nicht so ohne weiteres in den WARP-Charger. In einigen Shops finde ich aber noch die Version 2.0 des „Industrial Quad Relay“-Bricklet, das ja bidirektional arbeitet. Ich hab mal eins bestellt, in der Hoffnung, dass das damit funktioniert… Gruß Thomas

Hallo @ThomKa, kann es sein, dass die fehlende CP-Trennung beim Enyaq ein Problem ist? Vielleicht mag er aber auch kein 2-phasiges Laden? Gruß Thomas

Ok, dann vielleicht doch das normale Relais... 🙃

Super, vielen Dank, dann habe ich ja doch noch ein weiteres Bastelprojekt für den Herbst gewonnen 🙃 An das "Industrial Dual AC Relay"-Bricklet habe ich primär wegen der Bauhöhe gedacht, aber wenn das passt, dann ist das "Industrial Dual Relay"-Bricklet in der o. g. NC-Variante vielleicht sogar einfacher zu implementieren. Wobei: Wäre es nicht grundsätzlich sicherer, das CP-Signal aktiv zuzuschalten, d. h. wenn meine Ansteuerung (warum auch immer) mal nicht funktionieren sollte, dann wird CP definitiv getrennt? Dann sollte doch auch das "Industrial Quad Relay"-Bricklet funktionieren, oder?

Vielen Dank für eure Rückmeldungen. Reicht es nicht eigentlich aus, sicherzustellen, dass das Schütz der WARP nicht angezogen ist (aka nicht geladen wird), bevor die Umschaltung stattfindet? Also z. B. Fahrzeug lädt einphasig Ladevorgang wird beendet, Fahrzeug bleibt aber verbunden Schütz schaltet Phasen 2 und 3 dazu Ladevorgang wird wieder gestartet Oder ist das "dass ein Fahrzeug die zweite und dritte Phase von der Ladebuchse auf unbekannte Art und Weise mit der Ladeelektronik verbunden hat" das Problem? Falls ja, lässt sich die CP-Trennung evtl. auch mit EVSE v1 mit einem Industrial Dual AC Relay "nachbauen"?