Hallo zusammen
Ich habe seit Ende 2024 ein Victron-System bestehend aus einem Cerbo GX, drei Multiplus II 5000 und einer DC-gekoppelten 23kWh Batterie von Modual. Zusätzlich war bereits ein Wechselrichter Symo 10.0-3-M von Fronius mit 10kW Leistung und die Fronius Wärmelösung mit einem Ohmpiloten vorhanden. Als Heizstab habe ich zwei 7.5kW Heizstäbe im Warmwasserboiler, wovon derzeit aber lediglich einer in Verwendung ist. Ebenfalls steuere ich über die Überschussproduktion (Regelung im Wechselrichter) bei einer Solarleistung > 6kW meine CTA-Wärmepumpe an. Da diese aber keinen SmartGrid-Eingang sondern lediglich einen Pseudo-SmartGrid hat, kann ich keine genaue Leistung vorgeben. Stattdessen kann ich sie lediglich zum Anlaufen anregen. Ob sie dann tatsächlich einschaltet, entscheidet die Heizung nach ihren eigenen Kriterien.
Mein Ziel war von Anfang an, den Solar-Überschuss sowohl in der erwähnten Heizung, der Batterie als auch gleichzeitig im Warmwasserboiler speichern, anstatt ihn zu lediglich 0.14 Rp./kWh an meinem Energielieferanten zu verkaufen.
Es galt folgende Herausforderungen zu meistern:
- Die Aufhebung der auf Modbus RTU basierten Regelung zwischen Wechselrichter und Ohmpilot
- Die Anzeige des Stromverbrauchs der Heizung
- Das Berechnen des aktuellen Energieüberschusses aus der Solaranlage
- Das Entwickeln einer eigenen Ohmpilot-Ansteuerung
Mir war von Anfang an klar, dass diese Anfoderungen auf eine eigene Regelungstechnik hinauslaufen würde und es derzeit keine fertig verfügbare Lösung gibt. Ich fand nur heraus, dass offenabr einige Leute ebenfalls auf der Suche nach einer Ansteuerbarkeit eines Ohmpiloten mit einem Cergo GX sind. Der Ingenieur in mir war also getriggert und als Hobby-Programmierer war ich herausgefordert 
Während die Einbindung des Wechselrichters im Cerbo GX automatisch erfolgte, war die Anzeige des Energieverbrauchs der Heizung sowie die Ansteuerung des Ohmpiloten eine echte Herausforderung.
Einbindung des Energieverbrauchs der Heizung:
Ich messe den Energieverbrauch der Heizung bereits mit einem entsprechenden Drehstromzähler. Die Daten dazu sind auf einem Emu-Impulslogger mittels einem HTTP_Request im JSON-Format abrufbar. Nur wie kommen diese Daten in den Cerbo GX ? Nach einiger Recherche fand ich das Github-Projekt “GitHub - freakent/dbus-mqtt-devices: A driver for Victron VenusOS GX devices to support use of dbus-mqtt/flashmq-mqtt”. Damit lässt es sich realisieren, dass im Cerbo GX eine (oder in meinem Fall auch mehrere) virtuelle Ladepunkte generiert werden und mittels MQTT mit Daten gefüttert werden. Dank NodeRed auf dem Cerbo geht das gleich alles auf demselben Gerät.
Somit sehe ich nun den Energieverbrauch der Wärmepumpe, als auch diejenige des Ohmpiloten als EVCS, also Elektrofahrzeug-Ladepunkt.
Und übrigens: Ja, das funktioniert auch mit der neuen Cerbo GX Version 3.60. Ich bin mit dem Entwickler Martin Jarvis nicht verbandelt, aber er freut sich bestimmt über eine kleine Zuwendung, wenn ihr sein Projekt ebenfalls so hilfreich findet wie ich es tue
Steuerung des Ohmpiloten via Cerbvo GX
Durch allgemein zugängliche Informationen fand ich heraus, dass sich der Ohmpilot entweder durch Modbus RTU oder auch Modbus TCP ansteuern lässt. Der Plan, die Modbus RTU-Verbindung zu kappen und die Ansteuerung dann via Modbus TCP via Cerbo GX vorzunehmen klingt verlockend einfach. Zu einfach, wie sich alsbald herausstellte. Der Ohmpilot ist erstaunlich hartnäckig und nachhaltig mit dem Wechselrichter bzw. dem Datalogger darin verbunden. Wird die serielle Leitung des Modbus RTU gekappt, reklamiert der Ohmpilot alsbald mit einer fehlenden Verbindung zum Datalogger. ABER einige Zeit später steht die Verbindung wieder, denn es wird nun automatisch Modbus TCP verwendet. Und eine Parallel-Ansteuerung von zwei Modbus TCP-Slaves macht weder Sinn, noch funktioniert es. Hier ist nach wie vor guter Rat teuer, denn selbst Fronius als Hersteller kann mir nicht mitteilen, wie ich die Kopplung zwischen Datalogger und Ohmpilot trennen kann. Das Ticket ist aber noch offen, wer weiss, plötzlich gibt es eine Lösung. 
Mein Plan B ist bisher die Verhinderung der Kommunikation via meiner Firewall. Dazu habe den Ohmpiloten IP-mässig in ein anderes VLAN konfiguriert und blockiere die Kommubikation auf Port 502 von und zum Datalogger. Mir ist dabei natürlich bewusst, dass ich mit Kanonen auf Spatzen schiesse, aber HEY es funktioniert
Um dann den Ohmpiloten via Modbus TCP steuern zu können ist wiederum etwas Zusatzsoftware auf dem Cerbo GX nötig. Dieses Mal aber lediglich in Form einer Zusatzpalette in NodeRed. Diese nennt sich “node-red-contrib-modbus”. Sobald installiert hat man Nodes zur Verfügung, mit welchen man via Modbus TCP kommunizieren kann.
Und dann wird lediglch noch etwas Hirnschmalz verwendet, um die Logik zu basteln. Auch hier gibt es ein paar Hürden zu meistern.
- Es darf unter keinen Umständen Leistung aus der Batterie für den Ohmpiloten verwendet werden
- Es darf unter keinen Umständen Leistung aus dem Netz für den Ohmpiloten verwendet werden
- Sollte die Heizung ebenfalls laufen, kann der Ohmpilot wahlweise abgeschaltet werden
- “Sanfte Regelung” um grössere Lastsprünge zu verhindern
- Berücksichtigung der Leistungen pro Phase und damit “Schonung” der Relaiskontakte des Ohmpiloten
Man kann sich fragen, warum ich nicht ein bereits vorhadenes Energiemanagement-System verwende, welches alle diese Funktionen bereits unterstützt. Die klare Antwort:
Ich möchte GLEICHZEITIG die Batterie, die Heizung und gegebenenfalls den Ohmpiloten ansteuern und nicht nur durch Prioritäten regeln müssen. Und das kann bisher kein anderes Energiemanegement-System !
Nach gut einem halben Jahr kann ich nun stolz eine funktionierende Lösung präsentieren:
Das Dashboard zeigt die entsprechenden Werte und die relevanten Steuerungsparameter lassen sich natürlich zur Laufzeit fein-tunen
In NodeRed gibt es dazu pro “Aufgabe” einen Flow:
-
Daten vom Ohmpiloten abholen
-
Daten von der Heizung abholen
-
Und hier die Logik der Regelung. Viel sieht man nicht, weil die Logik in den FunctionNodes “Überschussregelung”, “Glättungslogik 2.0” und “Schaltlogik 2.0” versteckt" ist
