alestrix

Das erklärt aber immer noch nicht, warum die Box auf einmal abschaltet.

Ich hatte Deine Aussage so (falsch) verstanden, dass der Wert nur genutzt wird um die Stromstärke zu berechnen und dass die WARP1 da immer von drei Phasen ausgeht, selbst wenn das Auto (wie in meinem Fall) einphasig lädt. Die WARP hatte sich oben im Debug-Report ja wunderbar an die eingestellten 1380W herangeregelt und hat trotzdem die Ladung abgebrochen.

Die 6A Grenze ist mir durchaus bekannt. Mich verwundert, dass die WARP den eingestellten Wert benutzt um daraus dem Strom zu berechnen, anstatt - wie beim PV Überschussladen - die Ladung an einen bestimmten Leistungswert heranzuregeln. Dann wäre es irrelevant, ob das Auto 1-phasig oder 3-phasig lädt. Wenn der eingestellte Wert aber nur zur Berechnung des Stroms ohne nachfolgende Regelung genutzt wird, dann könnte die Lösung mit 4140W tatsächlich funktionieren. Kann ich testen, sobald das Auto wieder an seinem Platz steht. PS und EDIT: Falls im Debug report nicht ersichtlich: es handelte sich in allen Fällen um eine einphasige Ladung.

Hi @MatzeTF, vielen Dank für die Rückmeldung! Was bedeutet denn, dass die Box 4140W "benötigt"? Das scheint mir weniger eine Notwendigkeit als mehr dem Zuschlagen irgendeines Algorithmus geschuldet zu sein. Und warum wird mir von der GUI selbst in den PV Einstellungen 1380W als Minimum vorgeschlagen? Das Anheben der Mindestleistung auf 4140W, was bei 1p ja dann 18A und somit nur 2A unter der Schieflastgrenze wären, kann keine Lösung sein, das käme ja praktisch einer Sofortladung gleich. Grüße, Alex

Moin! Für mein Setup (WARP1, Victron Multiplus) funktioniert die Steuerung soweit, ich halte es aber für eine bessere Variante, den Victron Lade-/Entlademodus über die entsprechend dafür vorgesehenen Modi zu schalten und nicht über das Setzen von Zahlenwerten für die Lade-/Entladeströme, da diese vom Nutzer ggf. schon aus anderen Gründen auf bestimmte Werte gesetzt wurden und so von der WARP überschrieben werden. Davon abgesehen habe ich aber ein anderes Problem von dem ich jetzt nicht weiß, ob es mit der Beta Firmware (auch schon zu Phase 1 gesehen) zu tun hat: Die WARP beendet die Ladung gelegentlich bei zu wenig PV-Leistung trotz Min+PV Modus. Im Log steht dann "users | Charger state changed from 3 to 1" ohne Hinweis, warum. Die GUI war zu dem Zeitpunkt nicht geöffnet und ein Ladelimit war auch nicht gesetzt bzw nicht erreicht. evcc läuft schon lange nicht mehr, hat also auch nicht reingefunkt. Debug-Report anbei, Ladeabbruch war um 16:10 und nochmal um 16:36. Danke und viele Grüße Alex warp-TH5-Debug-Report-2025-07-18T16-40-42-283.txt

Falls noch aktuell: Ich hatte im Tasmota Script kein `-d` im WebQuery, das funktionierte dann: [...] >S =>WebQuery http://192.168.8.216/meters/1/update POST [Content-Type:application/json] [%sml[3]%] [...] Inzwischen nutze ich eine andere Art des Reportings an die Box. Für den schnellen Anfang reichte es aber so.

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. 👍

TL;DR: Es tut jetzt! ✅ Was ich geändert habe: den Wert/Slot für die Bezugs-Wirkenergie nicht nur auf "seit Herstellung" zurückgeändert, sondern den Wert gelöscht und neu angelegt den Messort per API in `/meters/0/config` (an der GUI geht es nicht) auf "Wallbox" (location=2) geändert (bei `/evse/meter_config` stand in `slot` aber davor auch schon der korrekte Wert 0) Jetzt wird die Energie des aktiven Ladevorgangs korrekt erkannt und vom Limit abgezogen. Welche der beiden Änderungen für den Erfolg zuständig ist kann ich nicht einschätzen. Falls es nur Punkt 1. war, dann lag es wohl daran, dass der API-Zähler anfangs noch einen zu großen Wert (hatte vergessen, die Zahl, die ich an die API sende, durch 1000 zu teilen) erhalten hat. Nach Faktor 1000 Korrektur hätte ich wohl den Wert löschen und neu anlegen müssen. Falls das das Problem war, wäre es ggf. sinnvoll, eine Warnmeldung auszugeben, falls der erhaltene Wert kleiner als der gespeicherte Bezugswert ist. Unabhängig davon, ob Punkt 2. den Ausschlag gemacht haben könnte, fand ich es verwirrend, dass die Auswahl "Wallbox" als Messort an der GUI nicht möglich ist. Bei Wallboxen ohne eingebautem Zähler macht die Auswahl ja schon Sinn und sollte ermöglicht werden. Jetzt funktioniert so weit fast alles, was ich mir von der WARP1 wünschen könnte - Energielimit, Batteriesteuerung, Überlastschutz am Netzanschluss. Wenn da nur nicht das Problem mit dem falschen PV-Ladestart bei 4140W (statt 1380W) Überschuss wäre. Das könnte noch der einzige Grund sein, warum ich dann doch wieder auf EVCC umsteigen muss (Ziel ist eigentlich, die Anzahl der Softwarekomponenten klein zu halten). Viele Grüße Alex PS: Bei "Min + PV: Mindestladeleistung" kann ich auf 1380W gehen, d.h. hier scheint die Box richtig zu erkennen, dass sie nur 1-Phasig angeschlossen ist.

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 😜

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

Das war auch mein erster Versuch. Nachdem das nicht funktionierte, hab ich's dann mit dem rücksetzbaren Zähler probiert. Ich bin derzeit nicht am Ort. In ein paar Tagen kann ich ein neues Protokoll mit dem anderen Zähler ziehen

Ja, das wollte ich im Ursprungspost eigentlich schreiben, wollte dann aber den Post nicht mit ewig vielen Infos überladen. So wird aus dem Gedanken der Sparsamkeit doch wieder ein xy-Problem... 🫤

Was genau heißt "nicht unterstützt"? Ich erinnere mich, dass man in einer recht frühen Version der Firmware der Box noch mitteilen konnte, ob sie 1p oder 3p angeschlossen ist. Gibt es diese Möglichkeit ggf. wenigstens noch via API (hab leider nichts gefunden)? Da wie ich denke für die allermeisten Nutzer die PV-Ladung wohl primär in 1p sinnvoll ist (gerade, da in der Zeit, als die WARP1 raus kam ja noch die Deckelung bei 10kWp existierte), finde ich die Entscheidung etwas unintuitiv, PV Ladung nur in 3p zu ermöglichen. Wäre daher super, wenn man der PV-Ladelogik den Minimalüberschuss (wieder?) irgendwie einkonfigurieren könnte - dass die Umschaltung zwischen 1p und 3p nicht erkannt und für den PV-Ladestart dann auch nicht automatisch genutzt wird ist da nur ein kosmetisches Problem.

@rtrbt Inzwischen habe ich mal die .py komplett durch die Tinkerforge-Version ersetzt (nicht nur verlinkt) und den Multiplus durchgestartet. An der GUI (v2) sehe ich aber nach wie vor keinen Unterschied, egal ob das Auto lädt oder nicht. Außerdem steht im Overview in der EVSE Tile "Waiting for start", obwohl die Ladung schon läuft und auch die Ladeleistung im Tile angegeben wird. Gib einfach Bescheid, wenn ich irgendwas probieren soll (nach meinem Urlaub :) )

Soviel zum ruhig schlafen Heute früh (PV war schon ausreichend) Auto ran gehängt und die Ladung hat im PV Modus wie gewünscht gestartet. Leider hatte meine WARP die Fähigkeit verloren, Energielimits einzustellen. Gut, lag wohl am geänderten API-Stromzähler. Energiezähler hinzugefüht und - nix, immer noch kein Energielimit möglich (der "verbleibend" Wert ändert sich trotz Ladung nicht, in der "Stromzähler" Ansicht der GUI sieht man aber, wie der Energiebezug steigt). Dann aufgrund hohem Hausverbrauch beendete sich die PV Ladung wie gewünscht. Aber später war dann wieder genug Überschuss da und seit dem sind schon 45 Minuten vergangen und trotzdem blockiert das Lastmanagement. Genau dieses Problem hatte ich vorher schon und ging davon aus, dass das 1p3p Thema der Grund ist, leider falsch gedacht. Somit hab ich mein ursprüngliches Problem doch nicht gelöst bekommen und habe es um das Energielimit Problem erweitert. 😭 Über Vorschläge wäre ich hocherfreut...! warp-TH5-Debug-Report-2025-04-06T14-40-42-831.txt

👍 Manchmal kann die Welt so einfach sein... Danke! Wenn es jemanden interessiert: Ich schalte den Schütz über das Relay im Shelly selbst, kann den Schütz-Status also aus demselben JSON bekommen wie die Messungen: METER="$( curl --silent http://shelly-wallbox/status )" curl --silent http://wallbox/meters/0/update -d "$(echo $METER | /bin/jq '[ ( .emeters | map(.power) | add ) , .emeters[0].current, .emeters[1].current, .emeters[2].current, .emeters[0].voltage, if .relays[0].ison == true then .emeters[1].voltage, .emeters[2].voltage else 0, 0 end ]')" Mit diesem API-Zähler: Jetzt kann ich beruhigt schlafen :) Merci & viele Grüße Alex

Moin! Ich hatte hier zunächst viel Text und viel Hintergrundinfo geschrieben, dann aber wieder gelöscht, denn eigentlich lässt sich meine Frage auf einen einfachen Nenner bringen: Was muss an den Wallbox-API-Zähler geschickt werden, damit der WARP signalisiert wird, ob der Strom gerade einphasig oder dreiphasig anliegt? Weder 0 noch null als L2/L3 Strom (bei Leistung mag die API kein null) bringen eine Änderung, es fehlt weiterhin die Phasenangabe. Hier mit L2/L3-Strom = null, L2/L3-Leistung = 0: Danke! Alex

Moin @rtrbt und sorry, dass ich mich jetzt erst melde - irgendwie ging die Antwort an mir vorbei! Vielen Dank, für die Info zu den Bedeutungen von "Enable Charging" und "Autostart" und zu dem Hintergrund bzgl. der Modbus Meldungen. Du hast recht, ich habe tatsächlich irgendwann mal die Wallbox-IP beim Multiplus bei den Modbus Geräten eingetragen, da ich in Erinnerung hatte, dass die Warp Modbus unterstützt - und die Einstellung dann irgendwann wieder vergessen. Der Logspam ist also meine eigene Schuld. Habe das Modbus Ziel im Multiplus gelöscht und der Spam hörte sofort auf. Ich habe die .py ersetzt und den laufenden Prozess gekillt, wodurch der Supervisor das Skript (und somit die neue Version) automatisch neu gestartet hat. In der GUI sehe ich dadurch erst mal keine Änderung. Auch ein erneuten Ausführen des install.sh hat nichts geändert. Liegt das daran, dass derzeit kein Auto angeschlossen ist? Oder daran, dass ich zum Ersetzen mit Softlinks gearbeitet habe? Oder muss ich den ganzen Multiplus nochmal durchstarten? root@victron-multiplus1:/data/dbus-warp-charger# ls -al drwxr-xr-x 3 root root 4096 Apr 5 21:52 . drwxr-xr-x 15 root root 4096 Apr 5 21:51 .. -rw-r--r-- 1 root root 1658 Feb 8 22:56 README.md -rw-r--r-- 1 root root 81 Feb 8 22:58 config.ini -rw-r--r-- 1 root root 8514011 Apr 5 22:09 current.log -rwxr-xr-x 1 root root 15128 Feb 8 22:56 dbus-warp-charger.orig.py lrwxrwxrwx 1 root root 32 Apr 5 21:52 dbus-warp-charger.py -> dbus-warp-charger.tinkerforge.py -rwxr-xr-x 1 root root 15166 Apr 5 21:51 dbus-warp-charger.tinkerforge.py -rwxr-xr-x 1 root root 777 Feb 8 22:56 install.sh -rw-r--r-- 1 root root 7190 Feb 8 22:56 main.zip -rwxr--r-- 1 root root 152 Feb 8 22:56 restart.sh drwxrwxrwx 3 root root 4096 Apr 5 21:59 service -rwxr--r-- 1 root root 250 Feb 8 22:56 uninstall.sh root@victron-multiplus1:/data/dbus-warp-charger# ps | grep warp 1511 root 1608 S supervise dbus-warp-charger 11937 root 34592 S python /data/dbus-warp-charger/dbus-warp-charger.tinkerforge.py 16723 root 2692 S grep warp Viele Grüße Alex

Moin! Vielen Dank für die Victron-Integration, sieht super aus! Ein paar Punkte sind mir beim Testen noch aufgefallen: Es ist nicht klar, was "Enable Charging" und "Autostart" eigentlich tun (wahrscheinlich steht das irgendwo, aber wo?) Unter Devices steht bei EVCS die Firmwareversion der WARP zum Zeitpunkt der Installation von dbus-warp-charger und nicht die aktuelle Firmwareversion Obwohl die Ladeleistung für EVCS angegeben wird, ist sie zusätzlich auch in der Leistung von "AC Loads" enthalten. Logischer wäre, wenn dort die Lasten abzüglich EVCS genannt werden würden: GUI v2 (v1 nicht getestet): Zwischen ESS und EVCS wird grafisch kein Stromfluss dargestellt (wahrscheinlich durch Victron zu lösen?) Im WARP Ereignislog stehen alle 10 Sekunden diese beiden Einträge (die peer_address ist der Victron), ist das beabsichtigt? 2025-02-11 18:04:03,355 | modbus_tcp | client connected: peer_address=3406342336 port=59563 2025-02-11 18:04:03,582 | modbus_tcp | client disconnected: peer_address=3406342336 port=59563 reason=DisconnectedByPeer error_number=-1 Ich habe keine Ahnung, was davon im Upstream Projekt und was hier zu adressieren ist, daher hab ich einfach mal frei ausgespeichert, was mir aufgefallen ist. Nochmal Danke für diese Integration! Ich plane, die Darstellung dauerhaft an einem kleinen Controlpanel im Wohnbereich zur Verfügung zu stellen. VG Alex PS: Falls die Diskussion besser auf GitHub aufgehoben ist, dann kann ich auch gerne dort schreiben. PPS: Gibt es einen Anhaltspunkt, wie viele diese Integration überhaupt nutzen?

Super, das war's! Ich nehme an, dass ich nach der Änderung per API nochmal ein Reboot hätte durchführen müssen. Egal - nach Finden und Ändern in der GUI plus Reboot und erneutem Test wird jetzt nicht mehr falsch begrenzt! Danke!

Moin! Vielen Dank für die Erklärung und das macht erst mal auch Sinn ;). In der GUI finde ich keine Lastmanager-Experteneinstellungen, bin in der API Referenz dann fündig geworden und habe `requested_current_margin` auf 3000 geändert (kann mich nicht erinnern, das jemals geändert zu haben). Jetzt steht's also auf 3A und das Verhalten ist leider nach wie vor das gleiche: Beim Start steht die Begrenzung erst mal wie erwartet auf 12A, dann geht sie kurz auf die konfigurierten 22A und wird dann aber sukzessive immer weiter heruntergeregelt. Ich schicke gleich den Debug Report per PM. Sorry, ich bin blind. Trotz Änderung per API hab ich in der GUI doch noch die 1A gefunden. Werde jetzt nochmal testen. Was die 35A vs 37A angeht: mit dieser Einstellung versucht die WB den Netzübergabepunkt auf maximal ca 35.8A zu regeln (soweit, so gut, da passiert noch nix). Wenn ein 16A Verbraucher unerwartet dazu kommt, geht der Verbrauch auf knapp 52A hoch. Laut der Kennlinie meines 35A SLS wird dieser die 52A **mindestens** 10 Sekunden akzeptieren, bevor er fliegt. In meinen Tests konnte ich reproduzierbar sehen, dass eine Korrektur des Ladestroms wesentlich schneller (2-3 Sekunden) erfolgt. Daher sehe ich da eigentlich derzeit noch kein Problem mit der Einstellung. Ich lasse mich natürlich gerne überzeugen, falls ich was übersehen haben sollte. Und ja, ich hab das auch gemacht in der Hoffnung, dass ich irgendwie trotz Lastmanagement die Ladeleistung höher drücken kann... :)

PM ist raus, inkl. Infos zum WLAN Thema. EDIT: Ich habe hier schon mal beschrieben, wie ich aus dem Core Dump das WLAN Passwort gezogen habe. War eigentlich straightforward.

Moin! Hier nun der Debug Report. Ich habe den Core Dump daraus entfernt, da er das WLAN Passwort enthielt. Zielstrom ist 35A, Phase mit dem stärksten Strom (L2) führt knapp über 17A und Lastmanagement begrenzt trotzdem deutlich über den Zielstrom (22A). Danke & viele Grüße Alex warp-TH5-Debug-Report-2025-02-11T14-13-14-320_no_core_dump.txt

Moin! Ich bräuchte mal ein wenig Nachhilfe mit der Logik hinter dem Lastmanagement. Folgende Angaben habe ich im Lastmanagement meiner WARP 1 eingestellt bzw. werden in den Details angezeigt: Stromzähler: "Netzübergabepunkt" Maximaler Strom am Netzanschluss: 35A Strombedarf des größten Einzelverbrauchers: 16A Marge: 0% Erlaubter Spitzenstrom: 49A (35A * 1.4, soweit OK) Zielstrom: 33A (49A-16A, auch OK) Unter dem Menüpunkt "Stromzähler" sehe ich, dass für den Zähler "Netzübergabepunkt" korrekt die Einzelströme angezeigt werden. An der am stärksten belastete Phase werden um die 20A gezogen, d.h. der Strom liegt deutlich unter dem Zielstrom von 33A: Dennoch steht trotz eines konfigurierten Ladestroms von 25A im Status "Erlaubter Ladestrom: 19,310 A durch Last­manage­ment". Warum wird hier begrenzt? Wo liegt mein Denkfehler? Danke, Alex PS: Die Zoe zieht immer ca. 2A weniger als von der WB vorgegeben werden, d.h. die 17.3A an der Wallbox sind erwartet. PPS: Kurz nachdem ich das geschrieben habe wurde im Haus ein Wasserkocher eingeschaltet und L3 ging auf 27A hoch. Die Begrenzung auf 19.31A blieb in dieser Zeit weiterhin unverändert.

Moin! In der Bedienungsanleitung, der GUI und der API Referenz habe ich keinen Hinweis auf eine Exportfunktion der WARP Konfig gefunden. Zwar finden sich einige Infos im Debug Log, das man an der GUI herunterladen kann oder man kann sich aus http://warp/debug_report viele Infos ziehen, aber da sind auch viele nicht-config Infos enthalten. Und das Problem des Wiedereinspielens ist damit auch nicht gelöst. Das Beste, was ich bisher hinbekommen habe ist ein curl --silent http://warp/debug_report | jq 'to_entries | map(select(.key | test(".*/config$"))) | from_entries' > config.json und aus dem JSON sollte sich auch recht leicht wieder ein oder mehrere API Calls basteln lassen. Aber da fehlen dann - neben wahrscheinlich noch weiteren Daten - die ganzen `evse/.*enabled` Werte. Wie kann ich die Konfig von der Box abziehen? Und wie würde man diesen Export dann z.B. nach einem Werksreset wieder einspielen? Danke! Alex