poohnet

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

Moin @rtrbt, Nachdem ich nun über eine Woche auch mit aktivierter Zählerüberwachung keine Probleme mehr hatte, war die heutige Ladung wieder blockiert - und zwar nach einem Reboot des Docker-Hosts, auf dem Mosquitto und Node-Red laufen. Nach einem Reboot von WARP hat das aber erstmal wieder funktioniert und ich konnte das Problem nicht mehr reproduzieren. Vielleicht hängt das ja irgendwie mit der Laufzeit zusammen?!? Ich werde das auf jeden Fall weiter im Auge behalten... Gruß Thomas

"relativ groß"? Im Vergleich zum ESP32-Brick wohl eher monströs 😂 Ich habe heute mal etwas gebastelt und testweise die o. g. Variante 2.1 im NFC-Modul implementiert. Softwaretechnisch funktioniert das (für einen ersten Wurf) soweit ganz gut, in der WARP1 untergebracht bekomme ich das Piezo-Bricklet aber nicht so ohne weiteres. Wie das in einer WARP2 aussieht, kann ich leider nicht sagen. Falls das jemand mal testen möchte, so kann ich gerne eine entsprechende Firmware bauen. @rtrbt: Bei der Implementierung ist mir allerdings aufgefallen, dass das NFC-Modul wohl das Users-Modul benötigt, welches seinerzeit dann von EVSE(2) abhängig ist. Ist es geplant, die Module zukünftig weiter zu entkoppeln, sodass NFC bzw. die Userverwaltung auch außerhalb von WARP funktionieren? Einige der hartcodierten Aufrufe habe ich in meinem Fork jetzt erstmal mit einem "#if MODULE_USERS_AVAILABLE()" versehen; evtl. könnt ihr das ja in den Standard übernehmen (Commit b87fc2a)... Gruß Thomas

Besten Dank für die wie immer ausführlichen Erläuterungen 🙂 Nach Deaktivierung der Zählerüberwachung und dem anschließenden Reboot wurde sofort der Start des Ladevorgangs protokolliert, bevor überhaupt eine MQTT-Verbindung bestand (und demzufolge auch noch kein gültiger Zählerstand bekannt war). 0,467 **** TINKERFORGE WARP2 CHARGER V2.1.2-6450d698 **** 0,467 314K RAM SYSTEM 293224 HEAP BYTES FREE 0,477 READY. 0,478 Last reset reason was: Software reset via esp_restart. 0,654 Mounted data partition. 86016 of 3538944 bytes (2.4 %) used 0,947 WARP2 Charger config version: 2.0.0 0,947 ESP32 Ethernet Brick UID: XSS 5,675 Ethernet started 5,685 Set timezone to Europe/Berlin 5,694 No Real Time Clock 2.0 Bricklet found. Disabling Real Time Clock 2.0 support. 5,871 No RS485 Bricklet found. Disabling Modbus Meter support. 5,893 No NFC Bricklet found. Disabling NFC support. 5,910 Found 1 records. First is 1, last is 1 5,933 Last charge record size is 1440 (1440, 0) 6,478 mDNS responder started 6,811 Wifi connecting to HMW-IoT 6,815 This is warp2-XSS (warp2-XSS), a WARP2 Charger Smart 11kW 7,279 Charger state changed from 1 to 2 7,306 Wifi connected to HMW-IoT 7,319 Tracked start of charge. 7,373 Wifi MAC address: A8:03:2A:32:84:78 7,376 Wifi got IP address: 192.168.110.213. Connected to BSSID E4:5F:01:04:D4:08 7,424 MQTT: Connected to broker. 8,380 Charger state changed from 2 to 3 2023-05-04 17:43:05,765 NTP synchronized at 25,108! 2023-05-04 17:43:47,471 This is warp2-XSS (warp2-XSS), a WARP2 Charger Pro 11kW 2023-05-04 17:47:42,341 Wrote last uptime to flash 2023-05-04 18:07:25,852 Charger state changed from 3 to 1 2023-05-04 18:09:39,957 Charger state changed from 1 to 0 2023-05-04 18:09:40,019 Tracked end of charge. 2023-05-04 18:09:47,100 Charger state changed from 0 to 1 2023-05-05 05:38:19,377 Charger state changed from 1 to 2 2023-05-05 05:38:19,421 Tracked start of charge. 2023-05-05 05:38:21,446 Charger state changed from 2 to 3 2023-05-05 06:23:48,593 Charger state changed from 3 to 1 2023-05-05 06:30:16,858 Charger state changed from 1 to 2 2023-05-05 06:30:18,874 Charger state changed from 2 to 3 2023-05-05 06:32:25,392 Charger state changed from 3 to 1 2023-05-05 07:06:12,476 Charger state changed from 1 to 0 2023-05-05 07:06:12,547 Tracked end of charge. Dann werde ich das Feature erstmal wieder aktivieren und versuchen herauszubekommen, warum die Ladung blockiert bleibt. Eventuell bauen wir das bald ein. Perfekt 🙂 Gruß Thomas

Prinzipiell wäre eine einfache Option „ungültige Ladevorgänge ausblenden“ ja ausreichend, sodass derartige Ladevorgänge schlichtweg nicht angezeigt und beim Export übersprungen werden… Gruß Thomas

Hallo Henrik, aktuell werden die Daten des aktuellen Ladevorgangs im Frontend berechnet, d. h. sie stehen leider nicht im MQTT-Topic „charge_tracker/current_charge“ zur Verfügung. Du könntest die Berechnung hilfsweise aber nachbauen, indem du die Topics „evse/low_level_state“ sowie „meter/values“ zusätzlich abonnierst und dort die Werte „uptime“ bzw. „energy_abs“ verwendest. Die verstrichene Ladezeit ist dann beispielsweise „uptime“ minus „evse_uptime_start“ (aus „charge_tracker/current_charge“). Evtl. verschiebt @rtrbt die Berechnung zukünftig aber noch ins Backend, dann wären die Daten direkt verfügbar… Gruß Thomas

Hallo zusammen, ich habe mal etwas mit GitHub Actions „rumgespielt“ und einen CI Build meines Forks der WARP-Firmware eingerichtet. Bei jedem Commit wird die Software nun automatisch kompiliert und - falls erfolgreich - purzelt am Ende dann ein Zip mit der neuen Firmware raus. Falls es jemanden interessiert, hier ist mein erster Wurf… Gruß Thomas name: PlatformIO CI on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/cache@v3 with: path: | ~/.cache/pip ~/.platformio/.cache key: ${{ runner.os }}-pio - uses: actions/setup-python@v4 with: python-version: '3.9' - uses: actions/setup-node@v3 with: node-version: 16 - name: Install PlatformIO Core run: pip install --upgrade platformio - name: Build PlatformIO Project working-directory: ./software run: pio run -e warp2_poohnet - name: Upload Artifacts uses: actions/upload-artifact@v3 with: name: warp-firmware path: ./software/build/

Hallo zusammen, gestern bin ich über ein seltsames Verhalten gestolpert, das zu einem "unbekannten" Ladevorgang geführt hat, den ich nun leider nicht mehr loswerde: Folgende Ausgangssituation: "WARP on Steroids"-Firmware mit Stand Anfang dieser Woche, Auto verbunden, Ladung über EVCC freigegeben, Ladung startet aber nicht. Bei der Analyse habe ich festgestellt, dass es in den Ladeeinstellungen nun einen neuen Punkt "Zählerüberwachung" gibt, der den Ladevorgang blockiert. Da ich keinen Zähler verbaut habe sondern die Zählerstände per MQTT bereitstelle, habe ich die Option deaktiviert, was beim Speichern wie üblich einen Neustart des ESP32-Bricks ausgelöst hat. Nach dem Neustart hat die Ladung sofort begonnen, allerdings wurde im Charge Tracker direkt ein fehlerhafter Ladevorgang protokolliert. Ich habe das jetzt nicht nochmal versucht zu reproduzieren, aber kann es sein, dass der Charge Tracker aus dem Tritt gerät bzw. den Start der Ladung nicht richtig mitbekommt, wenn man den ESP32-Brick neustartet, während das Auto verbunden ist? Zweite Frage: Gibt es eine Möglichkeit bzw. ist es geplant, einzelne Ladevorgänge zu löschen? Vielen Dank & Gruß Thomas

Alles klar, dann warte ich noch ein paar Tage mit der Bestellung... Gruß Thomas

Hallo @batti, gibt es schon Neuigkeiten, wann das LED Strip Bricklet wieder verfügbar ist? Vielen Dank & Gruß Thomas

Hi @MatzeTF, danke für die Info. Ich würde das eh erstmal separat aufbauen wollen (das NFC-Bricklet ist auch noch nicht eingebaut 🙃)... Gruß Thomas

Das Thema klingt auf jeden Fall spannend. Ich werde in meine nächste Bestellung mal ein Piezo Speaker Bricklet reinpacken und mal etwas basteln (aktuell warte ich noch darauf, dass das LED Strip Bricklet wieder im Shop verfügbar ist)... Gruß Thomas

Moin spooner, nein, wenn du auf den „Freigeben“-Button drückst, dann hebst du das von EVCC gesetzte Limit auf und WARP lädt unabhängig vom Überschuss mit max. Leistung. Poste mal einen Screenshot von EVCC wenn der Wagen mit der Einstellung „Min+PV“ bzw. „Schnell“ lädt. Gruß Thomas

Hallo spooner, "PV" bedeutet, dass nur dann geladen wird, wenn ein entsprechender Überschuss vorhanden ist, bei "Min+PV" immer mit mind. 6A pro Phase. Wenn du unabhängig von einem evtl. Überschuss mit max. Leistung laden möchtest, dann musst du "Schnell" auswählen. s. https://docs.evcc.io/docs/guides/charging Am WARP selbst brauchst du eigentlich nichts mehr freizugeben, außer, du möchtest die externe Steuerung durch EVCC (temporär) aufheben... Gruß Thomas