Neues YouTube-Video: Visualisierung im Devices-Adapter

[Sefina]

🔌 Neuer Adapter: ioBroker.victron-gx – Victron GX Geräte nativ in ioBroker

⚠️ Hinweis gemäß Forenregeln: Dieser Adapter wurde mit Unterstützung von KI (Claude von Anthropic) entwickelt. KI war dabei mein Werkzeug – so wie andere einen Linter, ein Framework oder Stack Overflow nutzen. Architektur, Designentscheidungen und Tests lagen bei mir.

---

Ich freue mich, meinen neuen Adapter für Victron GX Geräte (Cerbo GX, Venus GX, Ekrano GX) vorzustellen!

✅ Vollständig lokale Verbindung via MQTT – keine Cloud, kein VRM-Konto nötig
✅ Automatische Device Discovery – Batterie/BMS, MultiPlus, MPPT, Grid Meter, PV-Wechselrichter werden automatisch erkannt
✅ Volle ESS-Steuerung via Modbus TCP – Sollwerte, Min-SoC, Einspeisegrenzen und mehr
✅ Virtuelle Schalter schaltbar
✅ Saubere Datenpunkt-Struktur mit Einheiten und Rollen
✅ Kein manuelles Eintragen von Registern

Der Adapter ist bereits funktionsfähig, auf npm verfügbar und der PR ins offizielle ioBroker-Repository ist gestellt.

👉 GitHub: https://github.com/Sefina-DS/ioBroker.victron-gx

---

Warum KI als Werkzeug?

Die Kombination aus ioBroker Adapter-API, lokalem MQTT-Protokoll von Victron und Modbus TCP ist technisch komplex. KI hat mir geholfen, schneller sauberen TypeScript-Code zu schreiben, Fehler zu finden und Best Practices einzuhalten – ähnlich wie ein erfahrener Pair-Programming-Partner. Das Ergebnis ist ein Adapter, den ich als Einzelperson in dieser Qualität alleine deutlich länger gebraucht hätte.

---

Ich suche:
🔍 Tester mit Victron GX Hardware (egal welches Modell)
💬 Feedback zur Datenpunkt-Struktur
🐛 Bug-Reports aus der Praxis
🌱 Langfristig: eine kleine Community rund um Victron + ioBroker

Fragen, Feedback und Kritik sehr willkommen! 🙏

"Beispiel: Automatisch erkannte Zisterne – kein manuelles Konfigurieren, kein Register-Eintragen."

📋 Status
Der Adapter ist bereits auf npm verfügbar. Die Aufnahme ins offizielle ioBroker-Repository wurde beantragt – PR #6051 ist gestellt. Sobald der Review-Prozess abgeschlossen ist, wird er direkt über den ioBroker Admin installierbar sein.

[Samson71]

@Sefina
Danke für den Adapter. Auf meinem Cerbo läuft Venus OS Large mit aktiviertem MQTT und NodeRed (darüber hole ich mir aktuell die Werte vom Huawei SUN2000 in Venus OS), d.h. ich habe heute praktisch schon alle Werte die ich brauche (und noch einen ganzen Haufen mehr) per MQTT greifbar. Es laufen auch noch zusätzliche Skripte auf dem Cerbo wie z.B. debus-mqtt-ev-charger zur Einbindung, automatischen Steuerung und Darstellung der Wallbox in der Victron GUI oder dbus-mqtt-battery zur Einbindung meiner 5 JK-BMS. Auch diese Werte werden alle mittels MQTT vom Cerbo geliefert.

Wenn ich das richtig verstanden habe, dann speist sich Dein Adapter also aus den vom Cerbo gelieferten MQTT-Werten? Einziger Unterschied auf den ersten Blick scheint dann zu sein, dass der Adapter seine Datenpunkte nativ mit Werten befüllt und diese nicht als String liefert, aus dem ich den Wert erst extrahieren muss. Ist das so in etwa korrekt?

[Sefina]

@Samson71 Ja, genau – der Adapter liest den lokalen MQTT-Broker des Cerbo aus, genau wie du es mit Node-RED machst.

Der Unterschied liegt aber weniger im "was" als im "wie":

Automatische Device Discovery – alle angeschlossenen Geräte (auch deine JK-BMS über dbus-mqtt-battery) werden automatisch erkannt und als strukturierte ioBroker-Objekte angelegt – mit korrekten Datentypen, Einheiten und Rollen. Kein manuelles Mapping, kein String-Parsing.

Vollständige ESS-Steuerung via Modbus TCP – Sollwerte setzen, Min-SoC, Einspeisegrenzen, Betriebsmodi – direkt aus ioBroker heraus, ohne Umweg über Node-RED.

Für Nutzer ohne Node-RED Kenntnisse – der Adapter macht Victron-Daten für jeden ioBroker-Nutzer zugänglich, nicht nur für die die bereits ein funktionierendes MQTT-Setup haben.

Du hast mit deinem Setup natürlich bereits eine mächtige Lösung – der Adapter richtet sich eher an Nutzer die das alles nicht manuell aufbauen wollen oder können. Sozusagen der "plug and play" Weg für Victron + ioBroker. 😊

Spannend übrigens dass du dbus-mqtt-battery für die JK-BMS nutzt – theoretisch sollte der Adapter diese auch automatisch erkennen, da sie sich als reguläre MQTT-Devices am Cerbo anmelden. Wäre interessant das mal zu testen!

[Samson71]

@Sefina sagte:
Du hast mit deinem Setup natürlich bereits eine mächtige Lösung – der Adapter richtet sich eher an Nutzer die das alles nicht manuell aufbauen wollen oder können. Sozusagen der "plug and play" Weg für Victron + ioBroker. 😊

Alles klar, danke für die Bestätigung. Dann habe ich das aber soweit richtig verstanden. Victron ist in der Tat sehr mächtig und bei mir auf dem Weg das führende Element in Sachen Solar zu werden, incl. Steuerung der Wallbox etc. Für ioBroker bleibt am Ende nur die Anzeige bzw. Darstellung am Dashboard.

Spannend übrigens dass du dbus-mqtt-battery für die JK-BMS nutzt – theoretisch sollte der Adapter diese auch automatisch erkennen, da sie sich als reguläre MQTT-Devices am Cerbo anmelden. Wäre interessant das mal zu testen!

Ich bin mir ehrlich gesagt jetzt nicht mehr ganz sicher, ob das (immer) noch so ist. Ich habe vor einiger Zeit meine BMS ausgetauscht (Daly -> JK) und in einem zweiten Schritt die JK dann auf Kabel per Zusatzplatine umgestellt. Ich wollte aus Stabilitätsgründen weg von Funk (wlan).
Ich musste meine ich dabei nur einen Master definieren und die anderen 4 BMS hängen dann mit dran. Kann also gut sein, dass in dem Zuge dbus-mqtt-battery wieder rausgegangen ist. Ich habe das alles mit einem Bekannten zusammen gemacht, der sich auch speziell auf die Konfiguration als Mehrphasen-System versteht.

[dirkhe]

Ich finde ex gut, dass du einen Adapter anbietest, es wird sicherlich für den ein oder anderen sinnvoll sein. Ich victrone seit Ende letzten Jahres und habe auch schon direkt Erweiterungen für das venusos geschrieben.
In iob habe ich es bis jetzt noch nicht integriert, aber da wäre mein weg auch mqtt gewesen. Ich weiss nicht, wie Ressourcen hungrig dein Adapter ist, aber wenn ich sehe, was in mqtt alles an traffic vom venusos ist, weiss ich nicht, ob man da pauschal alles auch in iob haben möchte?
Ich bekomme jetzt bald noch 3 mppt dazu, da werde ich ein bisschen steuern müüssen, damit der "richtige" PV strom bevorzugt in die batterie geht. Da hätte ich dann entweder iob script gesehen ider direkt per python in venusos, mal schauen. NodeRed wäre für mich persönlich raus, weil ich liber scripte als klicke. Soll aber kein schlecht-reden von nodered sein.
Aber vlt. Gibt es ja demnächst noch symbiosen mit anderen iob adaptern.

[Sefina]

@Samson71 Danke Markus für die ausführliche Rückmeldung!

Interessant mit dem Wechsel auf Kabelanbindung – klingt nach einer sehr stabilen Lösung. Falls dbus-mqtt-battery dabei rausgefallen ist, wäre der Adapter für die BMS-Einbindung eh nicht relevant.

Zum Punkt „ioBroker nur für Anzeige“: Das muss nicht so bleiben! 😊 Genau da setzt der Adapter an – über Modbus TCP kannst du ESS-Sollwert, Min-SoC oder Einspeisegrenzen direkt aus ioBroker setzen. Das eröffnet z.B. die Möglichkeit Wallbox-Steuerung, Tibber-Preise oder andere ioBroker-Logik direkt mit dem Victron ESS zu verknüpfen.

---

@dirkhe Danke für das ehrliche Feedback!

Die Ressourcenfrage ist absolut berechtigt. Der Adapter abonniert nicht blind alles, sondern filtert gezielt nach bekannten Device-Typen (battery, vebus, grid, pvinverter, tank, switch etc.). Wer aber wirklich nur 2-3 Werte braucht, fährt mit einem gezielten Script ressourcenschonender – das sage ich ganz offen.

Deine kommende MPPT-Steuerung klingt spannend – genau solche Szenarien (mehrere PV-Quellen, gezielte Priorisierung) sind eigentlich ein starker Anwendungsfall für ioBroker Logik + Modbus TCP. Ob das am Ende ein ioBroker Script oder Python direkt auf dem Cerbo wird, hängt natürlich vom persönlichen Workflow ab.

Und ja – Symbiosen mit anderen Adaptern wären schön! Tibber, Wallbox, Energiemanager – da gibt es definitiv Potenzial.

Viele Grüße,
David

[Samson71]

@Sefina sagte:
Interessant mit dem Wechsel auf Kabelanbindung – klingt nach einer sehr stabilen Lösung. Falls dbus-mqtt-battery dabei rausgefallen ist, wäre der Adapter für die BMS-Einbindung eh nicht relevant.

Ist zwar hier OT aber weil Du es erwähnt hast, habe ich nochmal nachgeschaut. Ich hatte dbus-mqtt-battery tatsächlich für die Dalys im Einsatz, weil da jedes mit einem D1mini versehen war, der die Daten per MQTT geliefert hat. Als ich noch China-Kram im Einsatz hatte war das alles problemlos, aber Victron zickt, geht auf Fehler und stellt den Dienst ein wenn ein BMS "vermisst" wird. Das kam bei den Daly-Wemos ab und an mal vor. Ich habe deswegen dann auf JK-B2A8S20P-HCRPB umgestellt und damit dbus-mqtt-battery überflüssig gemacht, weil die BMS auch CAN/RS485 können und mittels JK-BMS Interface Board per Kabelverbindung direkt am Cerbo hängen.

Das erste BMS mit dem Victron VE.Can Kabel am VE.Can Port des Cerbo und die anderen 4 BMS daran in Reihe als Slave per RS485. Die Verbindung ist so zwar stabil und auch ein WLAN-Ausfall spielt so keine Rolle mehr. Das führt aber auch dazu, dass in Victron z.B. nur jeweils die Min/Max Werte der höchsten bzw. niedrigsten Zellspannung (über alle 5 Packs hinweg) angezeigt werden. Gleiches gilt für die Zelltemperatur. Um wieder alle einzelnen Zellwerte zu bekommen, hängt an jedem BMS noch ein ESP32 Wroom per BT dran und liefert die Einzelwerte incl. aktuellem Charge/Discharge und SoC per MQTT zur Darstellung in ioBroker. Wobei das eben für die reine Funktion des Victron-Systems keine Rolle (mehr) spielt.

[Homoran]

@Samson71 sagte:

Das führt aber auch dazu, dass in Victron z.B. nur jeweils die Min/Max Werte der höchsten bzw. niedrigsten Zellspannung (über alle 5 Packs hinweg) angezeigt werden.

Das sollte aber am BMS liegen.
Bei meinen Pytes via BMS CAN sieht es genauso aus.
Angeblich soll es (bei anderen Batterien??) Über rs232 trotzdem gehen einzelne ZellWerte zu bekommen.
Hab ich mich aber nicht rangetraut

[Samson71]

@Homoran sagte:
Das sollte aber am BMS liegen.

Wohl eher an der Anbindung, bzw. an Victron. Meine BMS liefern ja jedes für sich alle Werte. Über den Weg per ESP32 habe ich ja alle Werte. Aber der "Master" am CAN kontrolliert praktisch die anderen BMS und darüber werden nur Min/Max Werte über alles bzw. alle Zellen geliefert.