# Victron Energy CERBO GX **URL:** \ **Category:** PHP-Module (Diskussion)\ **Created:** [6. März 2021 um 10:56 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858 "2021-03-06T10:56:34Z")\ **Posts on this page:** 20\ **Page:** 4
**Author:** ![Doctor\_Snuggles](https://community.symcon.de/user_avatar/community.symcon.de/doctor_snuggles/32/66_2.png) [@Doctor\_Snuggles](https://community.symcon.de/u/Doctor_Snuggles)\ **Post date:** [5. Januar 2024 um 19:12 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/61 "2024-01-05T19:12:36Z")
Es wirkt halt alles etwas undurchsichtig und jeder ist froh, wenn irgendwie dann doch mal Daten kommen. Der Aufwand sieht auch größer aus, als ein paar Modbus Adressen anzugeben, besonders wenn auch Werte geschrieben werden müssen. Ich werde das aber mal testen, ob das ggf. schneller ist. Viele Grüße, Doc ---
**Author:** ![Thomas](https://community.symcon.de/user_avatar/community.symcon.de/thomas/32/63378_2.png) [@Thomas](https://community.symcon.de/u/Thomas)\ **Post date:** [5. Januar 2024 um 19:57 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/62 "2024-01-05T19:57:47Z")
Nur so als Anmerkung: Das Excel-File von Victron listet für System 41 Modbusadressen, ich habe 185 Topics Ein MPPT hat 51 Modbusadressen, ich habe mehr als 300 Topics pro MPPT. Ja die meisten braucht man nicht, aber Modbusadressen und deren Bedeutung herauszufinden ist schwieriger als einfach das Topic zu nutzen. Aus der Historie heraus habe ich weniger als 5 (ich glaube nur eine) Modbusadresse die kein MQTT-Topic hat (Deswegen ist Modbus noch an, aber ich glaube der Wert ist nicht wirklich wichtig). ---
**Author:** ![ChristianL](https://community.symcon.de/user_avatar/community.symcon.de/christianl/32/29633_2.png) [@ChristianL](https://community.symcon.de/u/ChristianL)\ **Post date:** [6. Januar 2024 um 15:16 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/63 "2024-01-06T15:16:04Z")
Also ich bin jetzt auch glücklich mit der MQTT Lösung. Die Umstellung war natürlich schon ein ganz schöner Aufwand, aber wenn man es von Anfang an darüber macht, hält dieser sich in Grenzen. Gut, ich schreibe jetzt (noch) nicht viele Dinge Richtung Cerbo, aber das funzt ja jetzt dank Thomas Unterstützung auch. Folgende zwei Vorteile sprechen bei mir ganz klar für die MQTT Lösung: Fehlermeldungen. Ich hatte das Log oft voll mit Fehlern aufgrund Unterbrechungen der Netzwerkverbindung. Ich kann die Geräte derzeit nur per Wifi anbinden, da kommt es immer mal wieder zu Unterbrechungen oder man stellt gerade etwas um, etc. Und da es ja einige Variablen sind die dort Daten liefern, hagelt es dann natürlich massig Fehler. Seit der Umstellung ist Ruhe im Log! Und ja, vielleicht braucht mein Monk das einfach 🤣 Das andere ist die Push/Pull Geschichte. Modbus muss ich immer mit festen Zeiten abfragen. Dass kann dann für bestimmte Dinge zu viel des guten oder auch zu wenig sein (z.B. Grid-Meter). MQTT aktualisiert halt direkt, wenn es einen neuen Wert gibt, oder eben auch nicht, wenn sich nix ändert. Somit ggf. sogar weniger traffic. Aber wie Thomas schon sagt, beides funktioniert, wahrscheinlich ist es dann auch irgendwo Geschmacksache 😉 Grüße, Christian ---
**Author:** ![micserver](https://community.symcon.de/letter_avatar_proxy/v4/letter/m/4af34b/32.png) [@micserver](https://community.symcon.de/u/micserver)\ **Post date:** [6. Januar 2024 um 18:59 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/64 "2024-01-06T18:59:44Z")
Das funktioniert ja ausgezeichnet … auch wenn es etwas frickelig erscheint 🙂 @Christian & Thomas: was steuert ihr denn eigentlich so alles außer dem gewünschten SOC des Speichers? Gruß, Michael ---
**Author:** ![Thomas](https://community.symcon.de/user_avatar/community.symcon.de/thomas/32/63378_2.png) [@Thomas](https://community.symcon.de/u/Thomas)\ **Post date:** [6. Januar 2024 um 20:43 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/65 "2024-01-06T20:43:29Z")
Wie erwähnt eigentlich recht wenig. settings/0/Settings/CGwacs/ACPowerSetPoint → Manuell oder auch mit Skript um die Einspeiseleistung über den Tag zu mitteln (Liegt an meiner Konfiguration) settings/0/Settings/CGwacs/BatteryLife/MinimumSocLimit -\>SOC Speicher settings/0/Settings/CGwacs/BatteryLife/State → BatteryLife ein/ausschalten (Hab es nicht so gern, wenn ich sinnloserweise einspeisen muß, nur weil der Akku zu ungünstigen Momenten voll ist) Und dann noch solarcharger/xxx/Mode → Habe einen MPPT der schon mehrmals aufgehört hat die Batterie zu laden (Wohl weil sich die PV-Spannung zu schnell geändert hat …). Da hilft kurz aus/einschalten. ---
**Author:** ![ChristianL](https://community.symcon.de/user_avatar/community.symcon.de/christianl/32/29633_2.png) [@ChristianL](https://community.symcon.de/u/ChristianL)\ **Post date:** [7. Januar 2024 um 09:23 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/66 "2024-01-07T09:23:03Z")
Bisher setze ich auch nur das MinimumSoCLimit. Werde jetzt mal mit den scheduled charge Parametern experimentieren. Das geplante Laden könnte man gut nutzen um auf entsprechende Energiepreise zu reagieren (Tibber). So könnte ich heute ab 13 Uhr berechnen ob es sich lohnt morgen den Speicher zu laden und wenn ja wie lange und zu welcher Zeit. Ebenso könnte ich damit die Ladeuntergrenze anpassen um den Akku zum Ladezeitpunkt entsprechend leer zu haben. So zumindest meine Theorie 😉 Victron ist da ja auch gerade dran mit dem Dynamic ESS, aber solang das noch nicht da ist, bzw. mit Tibber kompatibel, wäre es evtl. eine Möglichkeit… Grüße, Christian ---
**Author:** ![micserver](https://community.symcon.de/letter_avatar_proxy/v4/letter/m/4af34b/32.png) [@micserver](https://community.symcon.de/u/micserver)\ **Post date:** [7. Januar 2024 um 11:22 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/67 "2024-01-07T11:22:34Z")
genau da bin ich auch grad dran … warte zum Einen auf Victron, zum Anderen denke ich ich müsste das selbst mal versuchen … morgen startet mein Tibber Vertrag … Den SOC kann ich schon mal manuell einstellen, jetzt geht’s an die Logik das wenigstens etwas zu automatisieren … bis Victron die optimale Lösung bietet ---
**Author:** ![Doctor\_Snuggles](https://community.symcon.de/user_avatar/community.symcon.de/doctor_snuggles/32/66_2.png) [@Doctor\_Snuggles](https://community.symcon.de/u/Doctor_Snuggles)\ **Post date:** [7. Januar 2024 um 12:41 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/68 "2024-01-07T12:41:59Z")
Aktuell lohnt es sich nicht (die letzten Tage) über Tibber nachzuladen. Die Preise ändern sich kaum über den Tagesverlauf. Da frisst der Wirkungsgrad der MPII die Ersparnis wieder auf. Aber ansonsten mache ich das schon seit einigen Monaten so … … aber noch über Modbus … 😉 ![2024-01-07_13h38_45](https://community.symcon.de/uploads/default/original/3X/2/3/2325ebc4c4051a337d33dc77b8abc04ca2635838.jpeg) ![2024-01-07_13h41_25](https://community.symcon.de/uploads/default/original/3X/f/c/fc480432cdbcb670edc45206be73f622dbece09c.jpeg) ---
**Author:** ![ChristianL](https://community.symcon.de/user_avatar/community.symcon.de/christianl/32/29633_2.png) [@ChristianL](https://community.symcon.de/u/ChristianL)\ **Post date:** [14. Februar 2024 um 07:35 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/69 "2024-02-14T07:35:30Z")
Moin zusammen, moin @Thomas ! Venus OS 3.20 wurde nun offiziell freigegeben. Damit ist auch final die Umstellung von Mosquitto zu FlashMQ ins Image geflossen. Scheinbar gibt es nun einige Dinge die anders laufen, würde das unsere Lösung zur Abfrage über MQTT beeinflussen? > > > We're going to replace Mosquitto + dbus-mqtt by \[FlashMQ\](https://www.flashmq.or…g/) + \[dbus-flashmq\](https://github.com/victronenergy/dbus-flashmq). > > \### The differences in performance: > > \- FlashMQ + dbus-plugin is much faster, publishing all topics (1500) happens in 10ms. In Python this was 3 seconds. > \- FlashMQ + dbus-plugin uses far less TCP packets by maximizing MQTT data per TCP packet. In one sampe for a demo installation with 1500 topics, It was 2900 TCP packets with the old solution, and with FlashMQ it's 179 TCP packets. > \- FlashMQ + dbus-plugin uses far less CPU on the GX device. > > \### Further details: > > Architecture: > \- Mosquitto in Venus OS will be replaced by FlashMQ > \- dbus-mqtt (the python service) will be replaced by dbus-flashmq (plugin to FlashMQ) > \- mqtt-rpc remains in place. This is the other python service, the one that takes care of all remote functionality like the dashboard on VRM; remote firmware updates, and so forth > > Note that there will be a transitionary period, because FlashMQ currently does not support broker to broker connections. During that period we'll use FlashMQ for all local websocket communication (HTML5-App and Gui-v2). And at same time still use dbus-mqtt plus Mosquitto for connection to/via VRM. > > Note that the cluster in the cloud is now also Mosquitto, and will be replaced by FlashMQ as well. > > MQTT spec. details: > \- Support of \[Selective keep-alives\](https://github.com/victronenergy/dbus-mqtt/blob/master/README.md#using-the-keepalive-method-for-selective-keep-alives) will be dropped. While now supported by dbus-mqtt, they will not be implemented in dbus-flashmq. > \- New feature added: \`"keepalive-options" : \["suppress-republish"\]\`. To allow keeping the flow of messages alive without triggering a full (re-)transmission of all topics. See \[dbus-flashmq readme\](https://github.com/victronenergy/dbus-flashmq) for further details; as well as below. > \- Added a publish of \`N/\/full\_publish\_completed\` after full publish. This allows clients to know when they have received all topics, and can > shorten the wait period. > \- Invalid values will be on mqtt as json \`null\` value, just like they were. > \- MQTT messages will no longer be sent with the RETAIN flag. Details \[here\](https://github.com/victronenergy/venus/issues/1027) and \[here\](https://github.com/victronenergy/gui-v2/issues/313). > > \### Changes in apps with regards to keep alive and retain: > > \*This is how UIs (gui-v2, html5-app, VRM) should now work:\* > > 1) subscribe to \`N/\/#\` > > 2) publish once to \`R/\/keepalive\` (lower case k). Empty payload. > > 2) thereafter, every 30 seconds, publish to \`R/\/keepalive\` again, with payload \`{ "keepalive-options" : \["suppress-republish"\] }\` > > There are more details, such has handling disconnects, what to show to the user if the app doesn't get any MQTT updates anymore, reconnecting, and so forth: which is explained in the Google doc called \`Victron - designing a UI\` chapter MQTT. > > \*How about retained messages?\* > > For backward compatibility reasons, especially VRM and VictronConnect need attention. We can do this client-side by interpreting 'retained' messages depending on Venus capability bit, or we can maybe let the server deal with. Pending discussion. > > \* HTML5 App: should have no code that does something special if received topic has retained flag set. > \* guiv2: should have code that ignores retained messages; PR is ready for that \[1\]. This is to have it compatible with existing cloud brokers. Note that it could be that in one or two months we can delete that code; but by then its also harmless - for later. > \* VRM Portal: more complicated story for later, also pending other discussions. > \* VictronConnect: pending other discussions. > > \[1\] https://github.com/victronenergy/veutil/commit/d9d618cd2d6bdafc97e56fb537ecdfaa3819a4d1 > > You're encouraged to read the \[readme for the new FlashMQ plugin\](https://github.com/victronenergy/dbus-flashmq#keep-alive), for more details. > > One extra note: the HTML5 app now uses the selective keep-alives. Which is a bit of a mistake made a long time ago; and this is the moment to correct that. The reason to not use it is that it causes unnecessary CPU load at GX device. > > \### Todos for all local MQTT traffic: > > \- \[x\] ~Add FlashMQ + dbus-plugin into Venus OS~ - done per Venus OS v3.10~1 > \- \[\] Test guiv2 - in progress > \- \[x\] Change guiv2 wrt keep-alive and retain - \[done\](https://github.com/victronenergy/gui-v2/pull/369) > \- \[x\] Test html5 app - in progress, see \`#venus-html5\` channel. > \- \[x\] Change html5 app wrt keep-alive and retain > \- \[x\] Change configs to make FlashMQ handle local MQTT + websocket traffic > \- \[\] Test that \`system/0/Ac/ActiveIn/Source\` and other paths mentioned in #936 behave as per spec (json \`null\`). > \- \[\] Implement authentication against the bcrypt in \`/data/conf/vncpassword.txt\`; \[This is done\](https://github.com/victronenergy/dbus-flashmq/tree/feat-auth-with-vncpassword), but not yet offering for merge because it may surprise/confuse the testers if they have a VNC password. > \- \[\] Make sure the \[venus-influx-data-loader\](https://github.com/victronenergy/venus-influx-loader) project works with flashmq. > > \### Todos for MQTT traffic via VRM > > \- \[x\] Finish broker to broker connection implementation into FlashMQ (action @wiebeytec; mostly ready for testing, pending next point) > \- \[x\] Make Venus Platform support the dbus call to the 'bridge registrator'. See \[this branch\](https://github.com/victronenergy/dbus-flashmq/tree/WIP-register-at-vrm-through-dbus-ipc). > \- \[x\] Change VRM Portal implementation wrt keep-alive and retain > \- \[x\] Test > \- \[x\] Remove Mosquitto + dbus-mqtt completely. > \- \[\] ~Remove all retained message DBs from the servers? What about older clients? Otherwise apps still need to include logic to ignore messages with the 'retain' flag, and that caused a lot of confusion so far, so a one-size fits all solution is preferred.~ > \- \[x\] Decide on a method for backwards compatibility wrt retained messages: based on a new capability bit that shows GX runs without retained messages: have everybody drop them, or run FlashMQ on the cloud servers and port the auth system so we can not relay retained messages. > > \### How to test: > > 1. Install Venus OS v3.10~3, or later > 2. in /etc/mosquitto/mosquitto.conf, change the websockets listener port from 9001 to something else. > 3. in /etc/flashmq/flashmq.conf change the websockets listener port from 9002 to 9001 > 4. restart both (in the right sequence 🙂 ); and wait a bit after stopping Mosquitto, since it waits a while before the port becomes available. ---
**Author:** ![Thomas](https://community.symcon.de/user_avatar/community.symcon.de/thomas/32/63378_2.png) [@Thomas](https://community.symcon.de/u/Thomas)\ **Post date:** [14. Februar 2024 um 17:48 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/70 "2024-02-14T17:48:29Z")
Bin mal kurz über das Changelog gegangen, scheint nicht groß anders zu sein, aber eventuell sind kleinere Anpassungen notwendig. Bin immer noch bei der v3.01, muß also etwas mehr Zeit einplanen wenn ich umstellen will. Eigentlich wollte ich ohne Grund gar kein Update machen und wenn dann auf Large-OS. ---
**Author:** ![Thomas](https://community.symcon.de/user_avatar/community.symcon.de/thomas/32/63378_2.png) [@Thomas](https://community.symcon.de/u/Thomas)\ **Post date:** [10. März 2024 um 18:22 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/71 "2024-03-10T18:22:19Z")
Habe heute (versehentlich) auf die v3.22 upgedatet. Nach einem kurzen Schreckmoment hab ich gewartet bis der Cerbo neu gestartet hat und alle siehe da, alles funktioniert wie bisher. Mir sind auch keinen neuen Topics aufgefallen. Angeblich soll das erste keepalive ohne payload ausgeführt werden, alle weiteren werden wieder mit payload unterstützt. Ich verwende es allerdings sowieso nicht (kein Filter aktiv). Gruß Thomas ---
**Author:** ![ChristianL](https://community.symcon.de/user_avatar/community.symcon.de/christianl/32/29633_2.png) [@ChristianL](https://community.symcon.de/u/ChristianL)\ **Post date:** [11. März 2024 um 07:24 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/72 "2024-03-11T07:24:11Z")
Moin Thomas, danke für die Info, dann kann ich mich bei Gelegenheit ja auch mal ans Update machen 😉 Es gab aber wohl tatsächlich noch hier und da Probleme mit dem MQTT, die in der 3.21 & 3.22 aber gefixt wurden. Ich bin gespannt, DESS ist kurz vor official. Grüße, Christian ---
**Author:** ![Kampfwurst](https://community.symcon.de/letter_avatar_proxy/v4/letter/k/a4c791/32.png) [@Kampfwurst](https://community.symcon.de/u/Kampfwurst)\ **Post date:** [9. Juni 2025 um 11:35 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/73 "2025-06-09T11:35:56Z")
hallo zusammen, folgende Frage, habe gerade ein Projekt am laufen bei dem ein Victron mit dem " Cerbo GX MK2" verbaut ist. Nun macht der Gerbo GX MK2 ja einen MQTT Brocker. Soweit so gut. Das Problem ist das ich nur Daten bekomme wenn ich die Victron Webseite öffne. ([https://vrm.victronenergy.com/](https://vrm.victronenergy.com/)). Wenn ich die Webseite schließe stellt der Victron mit dem Gerbo GX die Komunikation nach ca 1-2 min ein. Wieso das? ---
**Author:** ![Thomas](https://community.symcon.de/user_avatar/community.symcon.de/thomas/32/63378_2.png) [@Thomas](https://community.symcon.de/u/Thomas)\ **Post date:** [9. Juni 2025 um 11:44 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/74 "2025-06-09T11:44:04Z")
Ich vermute da fehlt die Keep alive implementierung auf Symcon Seite. Solange das Portal aktiv ist sendet der Cerbo vermutlich auch intern, sonst hört er nach 2 min auf. ---
**Author:** ![Kampfwurst](https://community.symcon.de/letter_avatar_proxy/v4/letter/k/a4c791/32.png) [@Kampfwurst](https://community.symcon.de/u/Kampfwurst)\ **Post date:** [9. Juni 2025 um 12:53 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/75 "2025-06-09T12:53:07Z")
komisch. Es passiert auch wenn ich per MQTTX mich direkt verbinde. Hier sollte das Keep Alive funktionieren. ![image](https://community.symcon.de/uploads/default/original/3X/5/3/53f4f5095657fe23c4dcd9789c0aaeb6d7504a8f.png) ---
**Author:** ![Thomas](https://community.symcon.de/user_avatar/community.symcon.de/thomas/32/63378_2.png) [@Thomas](https://community.symcon.de/u/Thomas)\ **Post date:** [9. Juni 2025 um 14:53 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/76 "2025-06-09T14:53:33Z")
Kenne jetzt MQTTX und den KeepALive Mechanismus dazu nicht, aber der Cerbo braucht eine spezielle Prozedur, ist weiter oben im Thread beschrieben ---
**Author:** ![rores](https://community.symcon.de/letter_avatar_proxy/v4/letter/r/ebca7d/32.png) [@rores](https://community.symcon.de/u/rores)\ **Post date:** [7. August 2026 um 09:04 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/77 "2026-08-07T09:04:46Z")
Hallo, ich konnte einen MQTT Client auf meine Cerbo einrichten und erhalte auch Daten. Der Client Socket wird aber alle ca. 30 Sekunden rot und die Verbindung wird als fehlerhaft markiert. Ich habe ein keepalive Ereignis (Event 21707) alle 30 Sekunden eingerichtet. Die Verbindung wird nach ein paar Sekunden wieder aufgebaut und bricht dann wieder ab. Hat jemand eine Idee, woran das liegen könnte? ![image](https://community.symcon.de/uploads/default/original/3X/2/3/237414de37e172784cda65176368158ca337c69c.jpeg) ---
**Author:** ![denisweber](https://community.symcon.de/letter_avatar_proxy/v4/letter/d/4da419/32.png) [@denisweber](https://community.symcon.de/u/denisweber)\ **Post date:** [7. August 2026 um 15:13 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/78 "2026-08-07T15:13:30Z")
Bei mir funktionier das seit 2 Jahren einbanfrei Ich halte den MQTT Server auch alle 30s Wach hab mal ein Bild gemacht ![skript](https://community.symcon.de/uploads/default/original/3X/3/4/345cb818879b3f7cb580384713a68db8c914020a.jpeg) ![keep](https://community.symcon.de/uploads/default/original/3X/3/6/3600bdb06d2004c56fae2f3967df9a1e2771d0e3.jpeg) ---
**Author:** ![rores](https://community.symcon.de/letter_avatar_proxy/v4/letter/r/ebca7d/32.png) [@rores](https://community.symcon.de/u/rores)\ **Post date:** [10. August 2026 um 11:43 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/79 "2026-08-10T11:43:35Z")
Ich habe alles noch einmal gelöscht und neu aufgebaut, jetzt tut es, wie soll 🙂 ---
**Author:** ![Bricoleur](https://community.symcon.de/user_avatar/community.symcon.de/bricoleur/32/96029_2.png) [@Bricoleur](https://community.symcon.de/u/Bricoleur)\ **Post date:** [26. Oktober 2026 um 07:55 UTC](https://community.symcon.de/t/victron-energy-cerbo-gx/123858/80 "2026-10-26T07:55:50Z")
Hallo zusammen, hier im Thread geht es seit Jahren um abbrechende MQTT-Verbindungen und das Wachhalten des Cerbo. Für alle, die nur die Werte der Anlage brauchen, gibt es einen zweiten Weg ohne MQTT und ohne Wachhalte-Skript: **Modbus TCP** , das der GX direkt anbietet. Mein Modul **NRG-Stack InverterHub** hat dafür einen eigenen Victron-GX-Treiber. Vorstellung und Diskussion: [[Modul] NRG-Stack InverterHub](https://community.symcon.de/t/144121) **Was es liest** Den zusammengefassten Systemdienst des GX (`com.victronenergy.system`): - PV-Leistung (DC und AC-gekoppelt, auf Wunsch je Solarladeregler) - Netzleistung und Netzquelle - Batterie: Ladestand, Leistung, Spannung, Strom und Zustand - Hausverbrauch **Einrichtung** 1. Am GX unter _Einstellungen → Dienste → Modbus TCP_ einschalten. 2. In Symcon eine InverterHub-Instanz anlegen, als Hersteller Victron GX wählen und die IP des Cerbo eintragen, Port 502. 3. Die Geräte-ID 100 für den Systemdienst setzt das Modul selbst. Was im Formular steht, wird bei Victron nicht verwendet. **Stand** Ich habe selbst keine Victron-Anlage. Den Treiber haben Beta-Tester an echten Anlagen erprobt. Dabei kam auch ein Fehler bei der Hauslast ans Licht, der behoben ist; seitdem stimmt die Anzeige mit der VictronConnect-App überein. Auch Anlagen mit mehreren PV-Wechselrichtern im Victron-System fasst das Modul zu einer Summe zusammen. Falls bei euch das Vorzeichen von Netz oder Batterie verkehrt herum ist: Dafür gibt es im Formular einen Umkehr-Schalter. Jede weitere Anlage hilft mir, gerade mit anderen Geräten am GX. Wer es ausprobiert, schreibt mir bitte im InverterHub-Thread, ob die Werte mit VRM übereinstimmen. Ein Screenshot beider Seiten zur gleichen Zeit genügt schon. **Ausblick: Steuern** Bei GoodWe kann InverterHub schon steuern, also dem Akku Laden und Entladen vorgeben. Das läuft bei mir zusammen mit meinem EMS-Modul im täglichen Betrieb. Gerade arbeite ich an der Steuerung für Solis, das Zwangsladen funktioniert dort bereits. Danach sollen weitere Hersteller folgen, Victron eingeschlossen. Einen Termin nenne ich bewusst nicht, ich baue jede Steuerung erst ein, wenn sie an einer echten Anlage geprüft ist. **Installation** Über den Module Store: In der Verwaltungskonsole nach **NRG-Stack InverterHub** suchen, das Modul steht im Bereich **Beta** , ab Symcon 9.0. Wer über MQTT zusätzlich Einstellungen am GX schreiben will, ist mit der hier beschriebenen Lösung weiter richtig. InverterHub liest bei Victron derzeit nur. Viele Grüße Dietmar [Vorherige Seite](https://community.symcon.de/t/victron-energy-cerbo-gx/123858.md?page=3)