poohnet

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"?

Hallo zusammen, bislang war das Thema Phasenumschaltung für mich nicht wirklich relevant, da mein Passat GTE eh nur einphasig mit max. 3.6 kW lädt. Dies wird sich im August aber ändern, dann wird der Passat gegen einen ID.4 getauscht, der ein- oder dreiphasig laden kann. Daher die Frage, ob ich mit dem WARP Energy Manager eine Phasenumschaltung auch bei WARP1 (on Steroids) realisieren kann. Soweit ich das verstanden habe, nehmt ihr vor der Umschaltung bei WARP2 ja eine CP-Trennung vor, was bei WARP1 hardwareseitig nicht funktioniert. Vielen Dank und Gruß Thomas

Nein, das habe ich in der Tat nicht vor. Ich würde an meiner WARP selbst keine weiteren Umbauten vornehmen wollen sondern eher den WARP Energy Manager vorschalten... Gruß Thomas

Super, besten Dank 🙂 Ich hatte gar nicht auf dem Schirm, dass der Coredump jetzt am Debug-Report dranhängt, d. h. ich hatte diesen manuell über die URL /coredump/coredump.elf abgezogen und an das Skript verfüttert (was damit verständlicherweise aber nichts anfangen konnte)... Gruß Thomas

Hallo zusammen, mit Firmwarestand von Anfang Juni stürzt der ESP32-Ethernet-Brick in meiner "WARP-on-Steroids" sporadisch ab: 0,487 **** TINKERFORGE WARP2 CHARGER V2.1.2-6478799b **** 0,488 313K RAM SYSTEM 293032 HEAP BYTES FREE 0,498 READY. 0,498 Last reset reason was: Software reset due to exception/panic. 0,674 Mounted data partition. 86016 of 3538944 bytes (2.4 %) used 0,905 WARP2 Charger config version: 2.1.3 (warp) 0,906 ESP32 Ethernet Brick UID: XSS 5,332 Ethernet started 5,576 Set timezone to Europe/Berlin 5,778 No NFC Bricklet found. Disabling NFC support. 5,799 Found 1 records. First is 1, last is 1 5,821 Last charge record size is 2528 (2528, 0) Ich habe gerade den letzten Coredump abgezogen und würde diesen nun gerne näher analysieren. Wie kann ich den Dump dekodieren und den Stacktrace erhalten? Vielen Dank und Gruß Thomas