Rangliste

Die fehlerhaften Werte in der Vergangenheit können leider nicht korrigiert werden, da die entsprechenden Daten verloren gegangen sind. Mit der neuen Firmware sollten die Daten nicht mehr verloren gehen können. Um die gelegentlich nicht angezeigten Einspeisewerte konnte sich leider noch niemand kümmern. Da die Daten aber da sind und nur nicht angezeigt werden, sollte ein zukünftiger Fix auch die alten Daten wieder anzeigen.

Firmware: WARP1 2.8.0, WARP2 2.8.0, WARP3 2.8.0, WARP Energy Manager 2.4.0, WARP Energy Manager 2.0 1.3.0 Instabile Firmware-Aktualisierungen werden automatisch erkannt und auf die vorherige Firmware zurück gewechselt (Nur WARP2) Verbessertes PV-Überschussladen und dynamisches Lastmanagement für einphasig ladende Fahrzeuge auch ohne Energy Manager zur Phasenumschaltung (durch Update auf Ladecontroller-Firmware 2.2.11) (Nur WARP3) OCPP: Messwerte werden auch während eines Ladevorgangs gemeldet Modbus TCP: Unterstützung für SAX Power Home hinzugefügt Modbus TCP: Unterstützung für E3/DC Hauskraftwerk hinzugefügt Modbus TCP: Unterstützung für Huawei SUN2000 hinzugefügt Modbus TCP: Unterstützung für zweiten GoodWe-Batteriespeicher hinzugefügt Modbus TCP: GoodWe-Batterie-Leistung > 32kW repariert SunSpec: Bei Fehlern während der Gerätesuche wird eine Warnung im Webinterface angezeigt SunSpec: Unterstützung für Geräte mit Basisadresse 50000 und 0 repariert PV-Ertragsprognose: Sommer-/Winterzeit-Behandlung repariert Ein NFC-Tag kann nicht mehreren Benutzern zugeordnet werden (Nur WARP Energy Manager 2.0) Display: Anzeige des Bewölkt-Icons repariert Dynamisches Lastmanagement: Untergrenze für maximalen Strom am Netz­an­schluss von 25A auf 20A reduziert Fernzugriffs-Abschnitt zur Statusseite hinzugefügt Mehr Hilfetexte dem Webinterface hinzugefügt Aktualisierung der Haupt-Software-Bibliotheken (ESP-IDF 5.4 und arduino-esp32 3.2) Download: WARP1 2.8.0 bzw. WARP2 2.8.0 bzw. WARP3 2.8.0 bzw. WARP Energy Manager 2.4.0 bzw. WARP Energy Manager 2.0 1.3.0

Wenn die Felder für einphasig und dreiphasig nicht manuell wählbar sind, zeigen sie beim Laden den aktuellen Zustand an und wenn nicht geladen wird, zeigen sie den Zustand vom letzten Ladevorgang an, wenn ich mich recht erinnere. Wenn das Lastmanagement aktiviert ist, ist auch immer die automatische Phasenumschaltung aktiviert. Im Modus „Schnell“ wird immer dreiphasig geladen (sofern das Auto das kann) und im (Min+)PV-Modus wird je nach verfügbarer Leistung umgeschaltet. Der einstellbare Strom auf der Statusseite wird dabei immer als Maximum genutzt. Den zu reduzieren macht aber eigentlich nur im Schnell-Modus Sinn. Im PV-Modus greift die Begrenzung nämlich auch beim einphasigen Laden, was man meist nicht will.

Das Lastmanagement wird für PV-Überschussladen und die Lademodi benötigt. Wenn du nur PV-Überschussladen aktivierst, wird ein Hinweis eingeblendet, dass du das Lastmanagement aktivieren musst. Ich vermute, dass du das letztes Mal getan und gleich vergessen hast. Wenn das Lastmanagement aus ist, kannst du manuell einen Ladestrom und die Phasenumschaltung einstellen. Beide Einstellungen sind unabhängig voneinander. Du kannst also 1p 6A, 1p 16A, 3p 6A und 3p 16A und alle Stromwerte dazwischen einstellen.

Es gibt noch ein paar weitere Bedingungen. Poste mal einen Debug Report. Ansonsten die obligatorische Frage: Hast du die neueste Firmware installiert? Nicht, dass wir alten Bugs hinterherlaufen. 😉

Als nächstes großes Feature kommt die Batteriespeicher-Steuerung. Im Webinterface unter Energiemanagement > Speichersteuerung zu finden. Der erste Schritt ist dem Batteriespeicher das Entladen zu verbieten, während im Schnelllademodus geladen wird. Vorher hätte sich der Batteriespeicher für die Ladung des Autos entladen. Dies kann jetzt unterbunden werden. Intern wird dies über das Lastmanagement realisiert. Daher muss der Lastmanager aktiviert sein. Dies ist aber vermutlich eh schon der Fall, da die Speichersteuerung hauptsächlich zusammen mit dem PV-Überschussladen verwendet werden wird, für das der Lastmanager auch aktiviert sein muss. Aktuell steht zur Kommunikaton mit dem Batteriespeicher Modbus/TCP zur Verfügung. Es gibt aktuell vier Aktionen die wir für sinnvoll halten: Laden vom Netz erlauben Erlaubnis zum Laden vom Netz zurücknehmen Entladen verbieten Verbot zum Entladen zurücknehmen Davon werden aktuell nur die letzten beiden verwendet. Die ersten beiden werden in einer späteren Version nachgereicht werden. Es reicht also aus die Sequenz an Modbus-Registern für die letzten beiden Aktionen zu konfigurieren. Das ganze funktioniert ähnlich wie die Anbindung Modbus/TCP Stromzähler. Es wird auf Dauer vorgefertigte Presets für verschiedene Speicher geben. Aktuell müssen die Register von Hand eingetragen werden. Wir freunen uns über jegliche Rückmeldung. Gerne auch mit Modbus-Registersätzen die für eure Speicher funktionieren. energy_manager_firmware_2_3_6_67f91981_ae4fa7cca7be157_feature-batteries-4_merged.bin energy_manager_v2_firmware_1_2_6_67f91acc_ae4fa7cca7be157_feature-batteries-4_merged.bin warp2_firmware_2_7_7_67f913cf_ae4fa7cca7be157_feature-batteries-4_merged.bin warp3_firmware_2_7_7_67f91776_ae4fa7cca7be157_feature-batteries-4_merged.bin warp_firmware_2_7_6_67f912a6_ae4fa7cca7be157_feature-batteries-4_merged.bin

Kleiner Zwischenstand: Die Beta läuft bei mir zuverlässig. Wegen wenig Kilometern und meistens ausreichend Sonne musste ich bisher nur einmal sofortladen. Dabei hat die WARP den Batteriewechselrichter zuverlässig auf "nicht entladen" gestellt, nach Ende des Auto-Ladevorgangs wurde die Hausbatterie wieder in den normalen Zustand zurückgestellt. 👍

Die Variante von der Dokuseite ist auch der normale Weg, wenn der Brick noch lebt. Meine Variante ist etwas brutaler und funktioniert manchmal, wenn sich der Brick aus irgendeinem Grund erhängt. Flash-Speicher, wie er auch im Microcontroller auf dem Master Brick verwendet wird, hat nur eine begrenzte „Gedächtnisleistung“, die bei gutem Speicher meist bei 10 oder 20 Jahren liegt. Wenn dein Master Brick von 2015 ist, kann es sein, dass ein paar Bits nicht mehr zuverlässig lesbar sind und seltsame Dinge passieren. Einmal neu flashen erneuert dann die gespeicherten Bits, theoretisch wieder für die nächsten 10 Jahre.

Externet Extension und alle Bricklets vom Master trennen Master Brick von USB trennen ERASE gedrückt halten USB verbinden 2 Sekunden warten ERASE loslassen 10 Sekunden warten USB trennen 5 Sekunden warten USB verbinden Dann sollte ein serieller Port erscheinen oder alternativ ein unbekanntes Gerät, falls Windows den Treiber nicht findet. Die LEDs am Master Brick bleiben aus. Wenn es keinerlei Reaktion von Windows gibt, scheint da was kaputt zu sein.

Es gibt (gab) ein bekanntes Problem mit den Tagessummen, was üblicherweise zu unsinnigen, negativen Werten geführt hat. Auch wenn du jetzt an einer Stelle einen unsinnigen Positiven Wert hast, habe ich die Hoffnung, dass das das selbe Problem ist. Das Problem sollte mit der nächsten Firmware behoben sein, die hoffentlich zeitnah veröffentlicht wird.

Bei einem Reboot über das Webinterface wird der Ladevorgang bereits ordnungsgemäß beendet. Die Wallbox hat zwei Prozessoren: Einer sitzt auf der EVSE-Platine und ist zuständig für die Kommunikation mit dem Fahrzeug, das Schalten vom Schütz und die Überwachung vom DC-Schutz, usw. Der Andere sitzt auf der ESP-Platine und ist für alle höheren Aufgaben zuständig, also Webinterface, Auslesen von Zählern, PV-Überschussregelung, NFC, WLAN, usw. Wenn du einen Neustart über das Webinterface auslöst, wird nur der ESP neugestartet, nicht aber das EVSE. Im Log ist zu erkennen, dass das Fahrzeug nach dem ESP-Neustart auch weiterhin normal am Laden ist. Da nach dem Neustart aber die Logik für das PV-Überschussladen erst die Stromsituation analysieren muss, wird dem EVSE gesagt, es solle den Ladevorgang regulär beenden, was es dann auch macht. Hast du kein PV-Überschussladen oder sonstiges Lastmanagement aktiviert, wird ein Ladevorgang übrigens nicht mal unterbrochen, wenn der ESP neugestartet wird. Warum dein Auto in diesem Fall gemeckert hat, dass der Strom plötzlich weg war, kann ich nicht sagen. Prinzipiell war das aber kein anderes Ladeende als alle anderen, die von der Wallbox ausgelöst wurden.

Das kann ich bei uns weder mit WARP1, noch WARP2 oder WARP3 reproduzieren. Ich baue jetzt aber noch zusätzlich ein, dass zwischen AP aktivieren und HT20 setzen auf das Interface gewartet wird. Vielleicht hilft das. Vielen Dank vor allem an dich für deinen Einsatz zum Testen, Bug melden und dann auch noch aufwändig das Problem einkreisen. Du machst das hier ja schließlich alles freiwillig! 👍

Vielen Dank für die detaillierte Analyse und Rückmeldung, @MatzeTF. Wieder ein kleines „Krabbeltierchen“ eliminiert… 😂

Okay, über WLAN kann ich das Problem bei uns auch reproduzieren. Dass das Zählermodul der Multicastgruppe beitritt, bevor die WLAN-Verbindung steht, ist prinzipiell kein Problem. Im funktionierenden Fall werden die entsprechenden IGMP-Pakete sofort nach Aufbau der Verbindung rausgesendet, auch wenn der entsprechende Aufruf im Zählermodul schon ein paar Sekunden her ist, da sich irgendwas unten drunter anscheinend merkt, welchen Multicastgruppen man beitreten möchte. Das seltsame ist, dass wenn esp_wifi_set_bandwidth nach dem Multicast-Join ausgeführt wird, anscheinend alle Multicast-Mitgliedschaften vergessen werden und nach anschließendem WLAN-Verbindungsaufbau keine IGMP-Pakete rausgeschickt werden. Der aktuelle Master-Stand lässt sich reparieren, indem entweder der Aufruf von esp_wifi_set_bandwidth wieder in die setup-Funktion verschoben wird, wodurch er vor dem Multicast-Join ausgeführt wird, oder der Aufruf bleibt wo er ist und der Multicast-Join wird per Task Scheduler so lange verzögert, dass er wieder hinter dem esp_wifi_set_bandwidth-Aufruf ausgeführt wird. Da ich keine Lust habe, in dem Closed Source WiFi-Blob rumzustochern, werde ich den esp_wifi_set_bandwidth-Aufruf wieder in die setup-Funktion schieben und mit einem entsprechenden Kommentar versehen, damit ihn nicht nochmal jemand verschiebt. Die 58 Byte langen Pakete, die immer durchkommen, sind übrigens Broadcasts vom SHM. Als Broadcasts kommen sie auch ohne Multicast-Join an und aus irgendeinem Grund empfängt der Multicast-Port auch die Broadcasts. Das war schon immer so, ist nur niemandem aufgefallen.

Ok, hab's nun mit den oben angegebenen Daten doch noch auf dem Victron Multiplus-II GX zum Laufen gebracht (ist zu Hause am PC auch leichter zu testen als remote per VPN übers Smartphone 😉). Man muss, bevor man per "Ausführen" die Einstellungen überhaupt testen kann, diese final speichern und die Box neustarten. Erst dann konnte ich per "Ausführen" einen Test machen und die Batterie ist zuverlässig der Ansage der Wallbox gefolgt. IMHO ist das für den Nutzer nicht zu erwarten, denn der "Ausführen" Knopf dient nach meinem Verständnis dem Zweck, die eingetragenen Registerwerte zu testen. Dass man dazu auf "Übernehmen", "Speichern" und "Neu starten" muss, damit man weiß, ob die Eingaben stimmen, war zumindest für mich nicht ersichtlich - zumal das Auslesen auf der Debug-Seite ja auch ohne Reboot geht. Hier nun die Einstellungen, die bei mir (über "Ausführen") funktionieren: Mit "Entladen verbieten" wird die Batterie auf "Charger only" gesetzt, bei "Verbot zurücknehmen" wieder auf "On" Viele Grüße Alex @andyknownasabu: Jetzt kannst Du auch 😜

Großen Dank für das Teilen der Lösung! Ich kann bestätigen, dass genau diese Einstellung bei meinem Skoda ENYAQ 85 (Modelljahr 2024, Software 5.2) dafür sorgt, dass der Phasenwechsel einwandfrei funktioniert. Während in der Vergangenheit das PV-Überschussladen jedes mal beim Umschalten von ein- auf drei-phasig abgebrochen ist, und ich den Stecker erst physisch wieder aus und einstecken musste - ist nach Aktivierung der Einstellung "Kabelschloss - Nach dem Laden immer entriegeln" jeder Phasenwechsel erfolgreich. Noch als kleiner Tipp: Man kann in der VW-Software spezifische Einstellungen für Ladeorte festlegen. So kann man für Zuhause diese Einstellung aktivieren, während beim öffentlichen Laden die Funktion deaktiviert bleibt.

Moin! Wenn ich versuche, die Einstellung für meinen Victron (Geräteadresse 228, Register 33) durch Drücken auf "Ausführen" zu testen, erhalte ich von der WARP die Meldung "Aus­füh­rung fehl­ge­schlagen 404(Not Found) Nothing matches the given URI". Der Modbus-Leser im Debug Menü gibt mir unter diesen Daten den aktuellen Modus (3=On, 1=Charger Only) korrekt zurück. Grüße Alex EDIT: Debug Report angehängtwarp-TH5-Debug-Report-2025-04-12T01-02-06-670.txt

Aktuell ist das in der Tat irrelevant. Ansonsten ist der Unterschied, dass „PV“ für reine PV-Erzeugung steht und „Wechselrichter“ ein nebulöser Leistungswert vom Wechselrichter ist, der bei Hybrid-Wechselrichtern auch Leistung aus dem Batteriespeicher mit einschließen kann. Wenn du weißt, dass das nur PV-Leistung ist, stell es auf PV.

Der ESP32 hat zwei Firmware-Slots. Wenn du per USB flasht, wird immer der Erste geschrieben und der Zweite invalidiert. Hier ist kein Rollback möglich. Du kannst von hier aus aber problemlos in den unten genannten Zustand kommen. Wenn du die Firmware per Webinterface (oder API) hochlädst, wird immer der nicht laufende Slot überschrieben. Falls die Firmware in dem Slot dann crasht, wird wieder der andere gestartet, also der Slot, der lief, als du die neue Firmware hochgeladen hast. Das funktioniert auch mit selbstgebauten Firmwares (vom aktuellen Master-Stand) und es wird immer wiederhergestellt, was auch immer sich im anderen Slot befindet. „Wiederhergestellt“ ist vielleicht auch der falsche Begriff. Die alte Firmware bleibt schließlich einfach da stehen, wird nur standardmäßig nicht mehr gestartet.

Die drei Phasenspannungen fehlen. Du brauchst L1N, L2N und L3N.

Die Wallbox würde das nicht so stören, ein gerade ladendes Auto dagegen schon. Es wäre besser, wenn du über die extern Steuerung der Wallbox den Ladestrom auf Null setzt (wenn du kein EVCC oder sowas verwendest). Dann beendet die Wallbox den Ladevorgang regulär selbst oder gibt gar nicht erst einen frei.

Warp2 hat die Temperatursensoren nicht. Die sind bei Warp3 neu dazu gekommen.

Ich habe es doch hinbekommen! - name: "Wallbox Temperatur (EVSE)" unique_id: sensor.wallbox_temperatur_evse state_topic: "warp3/evse/low_level_state" unit_of_measurement: "°C" value_template: "{{ value_json.temperature | float / 100 }}" device_class: temperature Falls es mal jemand anderes noch benötigt. Vielen vielen Dank!!!

warp3/2345/evse/low_level_state {"led_state":0,"cp_pwm_duty_cycle":1000,"adc_values":[3913,3913,0,0,2103,3728,170],"voltages":[12026,12026,0,0,1694,12016,-12104],"resistances":[4294967295,688],"gpio":[false,false,false,true,false,false,false,false,false,true,false,true,true,true,false,true,false,true,true,false,false,false,false,false],"charging_time":0,"time_since_state_change":23141327,"uptime":23141557,"time_since_dc_fault_check":23140327,"temperature":3443,"phases_current":3,"phases_requested":3,"phases_state":0,"phases_info":0,"dc_fault_pins":0,"dc_fault_sensor_type":1} warp3/2345/esp32/temperature {"temperature":3975} In den beiden MQTT-Topics gibt es jeweils ein "temperature"-Feld, das du in HA auslesen kannst.

Wenn es bei den Automatisierungen nun noch eine 2. Bedingung gäbe, wäre die WARP fast perfekt. Wenn der Front­taster gedrückt wird UND der Lademodus "AUS" ist, wechsle Lademodus auf PV. Wenn der Front­taster gedrückt wird UND der Lademodus "PV" ist, wechsle Lademodus auf Min + PV. Usw. Dann könnte man wenigstens alle Lade-Modis über den Taster steuern, was ich von einer Wallbox mit Taster eigentlich erwarte. Das wäre für mich als Kunde, der nicht den ganzen Tag das Smartphone in der Hand hat, die wichtigste Funktion für den Taster. Dazu noch die passende LED Farbe (z.b. PV=Grün / Min+PV= Grün-Gelb / Schnell=Blau) und die Sache wäre rund ;)

Zweiphasiges Laden zu evaluieren steht auf unserer langen Wunschliste zukünftiger Features… Das Problem ist, dass zweiphasiges Laden im Standard für Wechselspannungswallboxen mit Typ 2-Stecker nicht vorgesehen ist. Da kann also bestenfalls etwas getrickst werden. Das Lastmanagement nimmt übrigens immer eine Phasenspannung von 230 V an. Das einphasige Maximum liegt also bei 3680 W und das dreiphasige Minimum bei 4140 W.

Gutes Argument, aber könnt ihr dann nicht einfach zuschauen, wie alles automatisch funktioniert? 😉 Okay, zugegebenermaßen ist die ganze Logik im Lastmanagement inzwischen so komplex, dass wir ein paar Bugs drin hatten, die von den besagten technikbegeisterten Nutzern entdeckt wurden… Die wirklich faszinierende Technik des Lastmanagements kannst du dir zu Hause übrigens gar nicht ansehen. Stell dir einen Ladepark mit 64 Wallboxen vor, mit einer bunten Mischung aus WARP 1, WARP 2 (mit und ohne Phasenumschaltung per Energy Manager) und WARP 3, manche davon mit bekannter, manche mit unbekannter Phasenrotation, der an einer unterdimensionierten Zuleitung hängt, die dynamisches Lastmanagement benötigt, und der zusätzlich auch noch bei gutem Wetter PV-Überschussladen auf allen Wallboxen machen soll und bei schlechtem Wetter die billigsten Stunden eines dynamischen Stromtarifes nutzen soll, und dann am Ende des Tages, wenn alle Mitarbeiter der Firma nach Hause wollen, jedem ungefähr gleich viel Energie ins Auto geschoben haben. Gleichzeitig soll der Anwendungsfall mit nur einer Wallbox zu Hause damit genauso gut funktionieren. Ja, wir hatten im letzten Jahr echt viel Spaß. 🤪

Welchen Grund sonst könnte es denn geben, die Wallbox von euch zu kaufen, außer faszinierendes Technik Spielzeug zu wollen? Autos aufladen wird völlig überbewertet, die sind nur Mittel zum Zweck, um Phasenumschaltungen und Überschussladen im Detail optimieren zu können... :-)

Zumindest den Teil kann ich dir beantworten: Das ist eine Debug-Ausgabe die langfristig verschwinden wird. Wir haben den Modbus-Server grundlegend überarbeitet, und künftig wird dann auch im Webinterface angezeigt werden, wer gerade verbunden ist bzw. vor kurzem verbunden war und warum die Verbindung weg ist. Das existiert aber noch nicht, deshalb steht die Information erstmal im Ereignislog. Die Victron-Software scheint zum Auslesen der Wallbox aber nicht einfach eine TCP-Verbindung offen zu halten, sondern alle 10 Sekunden eine Verbindung aufzubauen, die Register zu lesen und die Verbindung dann wieder zu trennen. Das führt dann zu maximalem Logspam. Was mir nicht klar ist: Das Script, dass die Victron-Integration hinzufügt, kommuniziert über HTTP mit der Wallbox, nicht mit Modbus TCP. Hast du noch mehr konfiguriert? Irgendwas muss das Victron-Gerät ja dazu bringen, eine Modbus-TCP-Verbindung zur Wallbox aufzubauen. Wie du willst. Hier bekommen es typischerweise mehr Leute mit -> Du bekommst schneller eine Antwort. Das ist so von Victron vorgegeben: https://github.com/victronenergy/venus/wiki/dbus#evcharger Autostart benutzt im Endeffekt die evse/auto_start_charging-API. Das ist also das, was du als "manuelle Ladefreigabe" im Webinterface aktivieren kannst. Enable Charging scheint auf /StartStop zu mappen, und damit auf unsere evse/start_charging und /stop_charging-API. Damit kannst du also den Ladevorgang einmal stoppen oder starten, je nachdem. Wenn du damit sowieso gerade rumspielst, teste bitte mal diese Version, falls du Muße dazu hast: https://github.com/Tinkerforge/dbus-warp-charger/blob/main/dbus-warp-charger.py Der einzige Unterschied sollte sein, dass jetzt /MaxCurrent und /SetCurrent implementiert sind, du solltest also einmal den maximal erlaubten Strom (der auch gespeichert wird) setzen können und per /SetCurrent den Strom beliebig verstellen.