Integration in Victron VRM?

[andyknownasabu]

Hallo zusammen,

ich habe mir gerade ein Video zu der Charging Station von Victron angesehen und wie diese, nach Verbindung mit dem Cerbo GX, im VRM Webportal von Victron erscheint.

Wäre eine ähnliche Unterstützung bzw. Anbindung des WARP Chargers auch möglich/aus eurer Sicht sinnvoll oder ist vllt. sogar schon angedacht?

Ein vergleichbares Projekt könnte wohl https://github.com/henne49/dbus-opendtu das die Integration von OpenDTU in Victron übernimmt. Das geht allerdings über ein Stück Software auf dem CerboGX, wohingegen die Victron Wallbox offensichtlich per Modbus TCP angebunden wird.

Vielleicht haben ja genug Leute hier Interesse an einer solchen Integration und die Idee könnte auf die TODO Liste wandern (oder vllt. gibt es auch schon ein entsprechendes Projekt?!)

 

bearbeitet June 18, 2024 at 16:07 von andyknownasabu

[photron]

Im Rahmen der Integration des Victron GX als Zählerwertquelle, sind wir auch daran vorbeigekommen, dass man einen WARP Charger in die andere Richtung als Wallbox an Victron GX anbinden könnte. Dazu müsste man den Registersatz einer Victron Wallbox im WARP Charger implementieren. Ich habe das mal als Ticket hinterlegt, damit der Gedanke nicht verloren geht:

https://github.com/Tinkerforge/esp32-firmware/issues/353

[tugsi]

Ich gehe bei mir den Weg über evcc, da mir da die Implementierung mit PV-Laden etc besser gefiel, vor allem aber sperrt der mir mein Batteriespeicher, wenn das Auto lädt, sodass ich nicht meine Batterie leerlutsche...

Auf jeden Fall habe ich da mal ein Beitrag gesehen, ich meine sogar bei evcc selber, wo mein die Wallbox ins Victron integriert.

[andyknownasabu]

Für alle die es interessiert - das ist die von @tugsi genannte Lösung zur Integration von EVCC und Victron:
https://github.com/evcc-io/evcc/discussions/10779

UPDATE: Funktioniert wunderbar - besten Dank @tugsi!

Eine vergleichbare Integration für den Warp2/3 Charger wäre natürlich trotzdem nice ;)

bearbeitet June 25, 2024 at 07:23 von andyknownasabu

[andyknownasabu]

@photron Für den go-eCharger gibt es das schon: https://github.com/vikt0rm/dbus-goecharger

Für den Open_EVSE charger ebenso: https://github.com/JuWorkshop/dbus-evsecharger

Vielleicht ja interessant als "Vorlage"...

bearbeitet June 24, 2024 at 11:32 von andyknownasabu

[batti]

Wir haben mal ein dbus-warp-charger klon entwickelt. Diesen findet ihr auf Github zusammen mit einer kleinen Beschreibung:

https://github.com/Tinkerforge/dbus-warp-charger

Wie die go-e Implementierung nutzen wir auch deren Wallbox (evcharger) Implementierung. Daher ist eine Phasenumschaltung innerhalb der Victron Remote Console damit nicht möglich. Schaut euch gerne das ganze mal an und gebt Feedback oder entwickelt mit.

[andyknownasabu]

Sehr nice - vielen Dank! Werde ich bei Gelegenheit mal ausprobieren.

[TobiSt]

Hallo zusammen,

Ich habe meine Warp 2 laut Anleitung ins VRM Portal gebracht.

Sie ist sichtbar, zeigt aber ohne Anschluss eines Fahrzeuges einen negativen Ladestrom (um die -65 A) und eine Gesamtleistung (um die 250 W) an obwohl die Leistungen der Phasen 0W sind.

[TobiSt]

...und hier noch ein Screenshot aus der Remote Console

[batti]

Hi Tobi,

was für einen Stromzähler hast du bei deiner Wallbox als Stromzähler "0" konfiguriert? Das Skript liest Zähler "0" aus und zeigt diese Werte an.

[TobiSt]

Vielen Dank für die schnelle Antwort!

Als Zähler "0" ist das interne Smartmeter eingerichtet.

Mir ist aufgefallen, dass der angezeigte Ladestrom im VRM einem Phasenwinkel (-67,9) entspricht und die Gesamtleistung ähnelt auch einer Phasenspannung (L-N).

[photron]

@TobiSt Teste bitte die angehängte Version.

dbus-warp-charger.py

[TobiSt]

On 10/14/2024 at 6:29 PM, photron said:

@TobiSt Teste bitte die angehängte Version.

dbus-warp-charger.py 14.77 kB · 2 downloads

Sieht gut aus! Werte alle bei Null. Werde diese Woche noch einen Ladevorgang testen und dann berichten. Besten Dank nochmal!

[alestrix]

Moin!

Vielen Dank für die Victron-Integration, sieht super aus!
Ein paar Punkte sind mir beim Testen noch aufgefallen:

1. Es ist nicht klar, was "Enable Charging" und "Autostart" eigentlich tun (wahrscheinlich steht das irgendwo, aber wo?)
2. Unter Devices steht bei EVCS die Firmwareversion der WARP zum Zeitpunkt der Installation von dbus-warp-charger und nicht die aktuelle Firmwareversion
3. 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:
   
4. GUI v2 (v1 nicht getestet): Zwischen ESS und EVCS wird grafisch kein Stromfluss dargestellt (wahrscheinlich durch Victron zu lösen?)
5. 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?

[rtrbt]

On 2/11/2025 at 7:16 PM, alestrix said:

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

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.

On 2/11/2025 at 7:16 PM, alestrix said:

Falls die Diskussion besser auf GitHub aufgehoben ist, dann kann ich auch gerne dort schreiben.

Wie du willst. Hier bekommen es typischerweise mehr Leute mit -> Du bekommst schneller eine Antwort.

On 2/11/2025 at 7:16 PM, alestrix said:

Es ist nicht klar, was "Enable Charging" und "Autostart" eigentlich tun (wahrscheinlich steht das irgendwo, aber wo?)

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.

[alestrix]

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.

Am 12.2.2025 um 13:06 schrieb rtrbt:

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

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

[alestrix]

Am 6.4.2025 um 00:12 schrieb alestrix:

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?

@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 :) )

[andyknownasabu]

Bei mir hat das Skript heftigen CPU Load generiert. Die VRM hat den Overload des Cerbo angezeigt. Habe das Skript daraufhin wieder deinstalliert.