poohnet

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

Die Verbindung zum OCPP-Backend kann über ws oder wss aufgebaut werden (beides getestet mit eCarUp), das Root-Zertifikat kann aber leider (noch) nicht ausgewählt werden. Falls @rtrbt diese Möglichkeit einbauen sollte, so ziehe ich das selbstverständlich nach… 😉 Gruß Thomas

Moin, du hast die externe Steuerung aktiv und darüber drosselt EVCC den Ladestrom aktuell auf 8,4A. Steht EVCC evtl. auf „PV“ oder „Min+PV“? Schalte mal auf „Schnell“, dann sollte die Box mit 16A laden. Alternativ kannst du auch testweise mal den „Freigeben“-Button drücken, dann wird die externe Begrenzung aufgehoben. Gruß Thomas

Alles klar, vielen Dank. Grundsätzlich scheint OCPP mit eCarUp in den meisten Fällen korrekt zu funktionieren, nur hin und wieder halt nicht. Vielleicht hängt das ganze ja auch irgendwie mit EVCC zusammen. Aufgrund des doch eher bescheidenen Wetters in den letzten Wochen gab es immer wieder Ladeunterbrechungen... Gruß Thomas

Pefekt, vielen Dank für die Info... 🙂 Gruß Thomas

Moin, wann wird das LED Strip Bricklet 2.0 wieder verfügbar sein? Vielen Dank und Gruß Thomas

@rtrbt scheint ja wieder da zu sein, daher schiebe ich den Post nochmal etwas nach oben... ;-)

neue Firmware 2.1.2 für WARP on Steroids. Anpassungen s. hier: warp2_firmware_2_1_2_643c25db_59ebea74902b36a_merged.bin

Es müssen immer alle drei Werte (power, energy_rel, energy_abs gesetzt werden, damit meter/values_update verarbeitet wird. Danach wird dann auch das Topic meter/values gesetzt und evcc erhält die notwendigen Daten. energy_rel setze ich übrigens auf evcc/loadpoints/1/chargedEnergy. Somit zeigt der Zähler „seit dem letzten Zurücksetzen“ automatisch den aktuellen bzw. letzten Ladevorgang… Gruß Thomas