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
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).
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
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.
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
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
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 …
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?
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.
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).
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
