alestrix

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!