21 Kommentare

1. Hi Jörg,
   bin beim Ausprobieren deines Flows eine Auffälligkeit entdeckt, über die eventuell auch andere stolpern könnten.
   Ausgehend von der Einstellung: ESS Modus im GUI “Optimized with BatteryLife” und dem Akku SoC oberhalb vom Min SoC bei 20%, aber unterhalb vom “Aktiven SoC” (vorgegeben durch Battery Life) von aktuell bei 80%:

   Wie du habe ich folgende Nodes angesteuert:
   – Umstellung auf externe Steuerung (Settings Control Node -> Settings: “Venus Settings”, Measurement: “ESS Mode” = 3 (External Control”)
   – Einstellen eines negativem AC In Feed-In Setpoints von z.b. -500W (ESS Control Node -> ESS: “Multiplus II….”, Measurement “AC Power L1 setpoint (W)”)

   Die Batterie lässt sich dann zwar mit dem Setpoint von z.b. 500 (W) laden, aber sie lässt sich bei -500 (W) nicht entladen (SoC bei ca. 50%, BMS selbst erlaubt Entladen, etc). Dann passiert einfach gar nichts und es fließt 0W.

   Ich hatte ein bisschen rumprobiert und dann erkannt, dass ich: ESS Control Node -> ESS: “Multiplus II….”, Measurement “Disable feed-in” aktiv auf 0 setzen muss.
   Dieser Wert setzte sich allerdings jedes mal auf “1” zurück, wenn ich den ESS Mode wieder auf “1 – ESS with Phase Compensation” setze und über “ESS Control Node -> ESS: “Venus Settings”, Measurement: “ESS State” = “1 – BatteryLife enabled (GUI controlled)” aktiviere, damit das ESS wieder über den intelligenten Algorithmus von Victron gesteuert wird.

   Ich vermute, dass das Entladen der Batterie (was von BatteryLife nicht erlaubt wird, wenn der SoC unterhalb von der aktiven SoC-Grenze ist) hier deaktiviert wird und man muss dies zusätzlich noch freigeben.

   Im Übrigen wird “BatteryLife” durch die Einstellung “Settings Control Node” -> Settings: “Venus Settings”, Measurement: “ESS Mode” = 1 oder 2 – ESS with/without Phase Compensation) nicht aktiviert oder deaktiviert.

   Dies erfolgt über “ESS Control Node -> ESS: “Venus Settings”, Measurement: “ESS State”
   -> “1 – BatteryLife enabled (GUI controlled)” für EIN
   oder
   -> “10 – Optimized mode w/o BatteryLife: self consumption, SoC at or above minimum SoC” für AUS

   wobei der “ESS State” (wenn man ihn abfragt mit dem “ESS Node” -> ESS: “Venus Settings” -> Measurement: “ESS State”) je nach aktuellem SoC und Zustand/Aktivierung des BL-Algorithmus dann automatisch auf einen der andere 12 möglichen Werte wechselt.

   Venus OS Version ist 3.11

   Antworten

2. Hallo Jörg, deine nicht Faulheit, wie Du hat so erzählt hast, aufgreifend, habe ich über die Feiertage angefangen mit Node-RED rumzuprobieren.
   Technisch gesehen, bin ich totaler Anfänger, aber mit ein wenig Geduld und Rücksprache mit Java Profis habe ich es auch geschafft, etwas zum Funktionieren zu bringen. Die Funktion ist wie folgt:
   Eingangsgrößen sind die “Custom Inputs” Wechselrichter und Lade/Entladezustand des Akkus, welcher über ein DalyBMS gesteuert wird. Im Cerbo GX Sytsem ist das GitHub Projekt “dbus serialbattery” mit integriert.
   Welche Zustände des Systems sind möglich:
   1. Akku wird bis 21% entladen, danach wird der Multiplus auf “Nur Ladegerät” gestellt
   2. Akku wird immer bis 99% aufgeladen solange bleibt der Multiplus immer auf “Nur Ladegerät” gesetzt
   3. Ist der Akku auf 99% aufgeladen, wird der Entladezyklus gestartet bis auf minimal 21%. Solange bleibt der Multiplus auf “Ein”
   4. Sollte der Akku nicht komplett auf 99% geladen sein, wird der Multiplus auf “Aus” geschaltet sobald die eingespeiste Wechselrichterleistung unter 50W fällt. Der Multiplus wird wieder eingeschaltet sobald die Wechselrichterleistung über 100W ansteigt.

   Danke fürs anfixen 🙂 Ist halt nur was für die Wintersaison, aber der Sommer kommt ja noch.

   Grüße aus Melsungen

   Antworten

3. Hallo Jörg,
   leider gibt es bei mir “ESS Control – Switch Position”, woran kann das liegen?
   Ich habe unter “ESS Control” MP2 nur 5 Einträge!?
   VenusOS V3.13
   MultiPlus-II 48/5000/70-48 V5.06

   Antworten

   1. Die Antwort habe ich hier gefunden:
      https://github.com/victronenergy/node-red-contrib-victron/wiki/Available-nodes#ess-control

      VE.Bus System Control

4. Tipfehler …
   … “leider gibt es bei mir “ESS Control – Switch Position” NICHT,”

   sollte es heißen.
   Sorry

   Antworten

5. Hi Jörg,
   ich habe mich 2 Jahre mit einer SENEC Lösung (5kWh Akku) rumgeärgert und (auch durch deine tollen Videos ermutigt) nun einen Multiplus II 5000 + Venus OS auf Raspberry + GlobalPower 14,5kWh Batterie als Erweiterung. Leider funktioniert dies nun nicht so “out of the box”:
   Senec liefert Batteriestrom für den Hausbedarf (zB. Herd an). Der Herd geht wieder aus und der Multiplus fängt sofort an die GP-Batterie zu laden. Zieht also die SENEC-Batterie leer. Daher experimentiere ich aktuell in NodeRed mit “setpoint” etc rum.
   Gibt es für solche Fälle bereits eine Lösung bzw wie muss ich den MP (mit ext. Control) steuern, damit beide Batterien sich nicht mehr in die Quere kommen (welche Befehle?).
   Eine Steuerung werde ich wohl auch wegen meiner Wallbox benötigen (EVCC nun mit 2 Batterien funktioniert auch nicht mehr wirklich…).

   Vielen Dank
   Bernd

   Antworten

   1. Hi Bernd,
      habe das Thema bei meinem “Senec”-Kumpel mit Multiplus-Upgrade (wie bei dir) über eigene Steuerungslogik in Loxone gelöst. Läuft 1a – gerne stelle ich die Lösung mal in einem Video vor… Ist halt super skalierbar – auch mit weiteren Steuerungsgeschichten, wie bspw. Wallbox.

   2. Hi Jörg,
      so viel Mühe (Video) musst du dir nicht machen (andererseits natürlich immer willkommen 😉 ). Die Loxone-Logik und (vor allem) die dann abgesetzten Victron-Befehle würden mir vollkommen reichen. Ich setzte zwar ioBroker bzw nun auch HA ein, denke aber, dass man Loxone-Files auch ohne Loxone-Hardware lesen kann?
      Generell würde ich die Steuerung lieber auf dem Raspberry und NodeRed machen um bei meinen dezentralen Ansätzen zu bleiben (ein Ausfall ioBroker darf nicht zu einem Chaos in meinem Haus führen, Stichwort WAF 😉 ). Bin auch aktuell am Überlegen ob auch ein Mode 2 (anstatt 3) ausreichen würde. Lt. Doku behält ESS die Kontrolle und ich könnte trotzdem das “ungewollte Laden” per Code unterbinden. Oder ist dies nicht zutreffend?

6. Wurde u. a. auch von deinem Video mit NodeRed inspiriert .
   Ich bin gerade dabei ein Dashboard zu erstellen . Zum großen Teil geht das ja recht easy mit den Victron Nodes und den UI-Nodes .
   Wo ich momentan scheiter eist, wie kann ich CellMax und CellMin subtrahieren da ich die Differenz anzeigen möchte.
   Muß ich hinter den beiden Victron Nodes (CellMii & CellMax) noch eine Json Node dahinter packen und auch variablen zuweisen ??
   Leider reicht meine Kenntnis dazu nicht aus .
   Kannst du mir helfen

   Antworten

7. Hallo Jörg, kannst du eventuell mal ein Video machen wie man auf einem bestehenden Node-Red-System die Victron Nodes nachinstalliert und dann auf das GX-Devise zugreift? Wenn man eh einen externen Node-Red-Server hat wäre das ja die einfachere Variante als das Large-Image zu verwenden, oder?

   Antworten

   1. Hi Dieter, das wäre hilfreich, wenn es da eine Info zu gibt. Die Nodes zu insatllieren war recht einfch, offen ist für mich der Punkt, was auf dem Cerbo via SSH eingestellt werden muss, damit eine Verbindung zu einem anderen NodeRed funktioniert. Ich nutze NodeRed im ioBroker und wollte das eigentlich auch nicht ändern 🙂
      @Jörg, wenn du eine kleine Anleitung hast, auch ohne Video wäre das schon hilfreich.
      Danke & beste Grüße
      Matthias

8. Hallo Jörg,
   wie ich sehe hat Dein Video doch Viele inspiriert diese Lösung auch zu implementieren, so auch bei mir. Ich habe einen CerboGX und im Flow das Ein- und Ausschalten des MPII implementiert. Dies funktioniert prima.
   Da ich noch am experimentieren bin, wie ich die Einspeiseleistung ansteuern muss, um eine Nulleinspeisung zu optimieren, habe ich bislang nur den Knoten “ESS Control node” mit “ESS=MPII” und “Measurement= AC Power L1 setpoint (W)” benutzt, um einen konstanten Wert (negativ) vorzugeben.

   Du hast in Deinem Flow einen ähnlichen Teil der die drei MPII ansteuert. Diesen Teil habe ich versucht auf meinen Fall umzusetzen (nur ein MPII). Hier hast Du einen “resend every 30s” Knoten (trigger node) benutzt. Woher weißt Du, dass eine Zeitspanne von 30s korrekt ist? Hast Du diesen Wert aus einer der Victron Dokumente entnommen? Durch so einen hohen Wert wird die Regelung sehr träge. Das mag gut oder schlecht sein. Auf der anderen Seite liefert der neue Victron Energiezähler alle 1/10 sec einen Wert. Das würde eher dafür sprechen, dass man eine kleinere Zeitkonstante verwenden könnte. Ich habe bei mir die Zeit auf 2s gesetzt.

   Grund der Frage: Ich bin dabei ein Problem zu klären, warum mein Cerbo nach ein paar Stunden einen Reboot durchführt. Aus den Log-Files konnte ich ersehen, dass ein Fehler “253 load average too high” gemeldet wird. Dieser Fehler deutet auf eine zu hohe Belastung der CPU hin, die ich mir aber nicht erklären kann, da ja nur der oben beschriebene Flow zum Tragen kommt.

   Kannst Du zu meiner Problemlösung etwas beitragen? – Danke.

   Gruß
   Christof

   Antworten

   1. Das Resend bedeutet lediglich, dass der aktuell unveränderte Wert alle 30s erneut gesendet wird, damit die Multis nicht auf 0W runterregeln. Ich glaube das passiert sonst, wenn 60s kein neuer Steuerbefehl mehr kommt.

      “Real” regle ich aktuell alle 5s (oder waren es 10s) nach, was ausreichend ist. Luft nach oben gibt es aber natürlich immer…

   2. Hallo Jörg,
      danke für Deine Antwort. Ich habe erst jetzt gesehen, dass Du mir zeitnah geantwortet hattest. Ich hatte wohl vergessen, eine Benachrichtigung zu aktivieren und nicht mehr hier reingeschaut.
      Das eigentliche Problem, dass mein Cerbo ohne erkennbaren Grund einen Reboot aufgrund des Fehlers „253“ durchführt, besteht weiterhin. Das Refresh-Interval scheint nicht die Ursache zu sein. Ich habe den Verdacht gehabt, dass evtl. mein aktiver USB-Hub der Verursacher sein könnte und ihn durch einen passiven Hub ersetzt. Zunächst schien der Fehler behoben zu sein, da mein Cerbo über einen längeren Zeitraum durchgelaufen ist (zuvor war ein Reboot pro Tag zu beobachten). Jetzt, nach ca. 10 Tagen habe ich wieder einen Reboot gehabt. Das ärgerliche dabei ist, dass der NodeRed-Flow abgebrochen wird. Ich vermute, dass Du diesen Effekt bei Dir nicht beobachten konntest, sonst hättest Du vermutlich ein Tipp dagelassen. – Dass der Cerbo einen defekt hat, würde ich zwar ausschliessen, werde aber zur Verfikation das Ganze mit einem Raspi4 gegentesten.
      VG

   3. Hallo und für alle, die diesen Block verfolgen und vielleicht das gleiche Problem haben.
      Nochmals zu dem Thema Steuerung mit NodeRED und den von mir beobachteten sporadischen Reboots. Ich muss hier erwähnen, dass ich einen CerboGX benutze, der gegenüber einem RPI3/RPI4 etwas schwachbrüstiger ist, was die Rechenleistung betrifft. Es läuft das aktuelle VenusOS 3.31 mit einigen Scripten zur Anbindung von BMS, MPPT und Shunt.
      Die wirkliche Ursache für die beschriebenen Reboots habe ich nicht herausfinden können. Da reicht mein Wissen im Bereich Linux leider nicht aus. Welcher Prozess dann letztendlich „das Faß zum Überlaufen“ bringt, läßt sich aus den Log-Files nicht entnehmen. Was ich beobachtet habe, ist dass ein Watchdog anschlägt, der eine drohende Überlastung der CPU feststellt. Die Ursache dieser Überlast kann ich mir nicht erklären. Schaut man sich die Prozessorauslastung mittels dem Befehl „top“ an, so habe ich festgestellt, dass der Anteil NodeRED relativ klein ist und die CPU mit annähernd 40% im IDLE läuft. So gesehen eigentlich harmlos. Innerhalb NodeRED waren dabei nur ein paar sehr einfache Nodes am Laufen, die Werte mittels Victron-Nodes empfangen und auch über einen Victron-Node an den MPII verschickt haben. Also keine komplexen rechenintensive Aufgaben. Eine GUI bzw. ein Dashboard habe ich nicht implementiert. Dies würde sicher zu höherer Auslastung führen können.
      Tipps und Ratschläge in anderen Foren haben mir geraten NodeRED nicht zu nutzen, da dies die Ursache der Reboots sei. Da sich die wirkliche Ursache schwer finden läßt, habe ich zwei Optionen das Problem zu umgehen. Dies wären zum Einen einen RPI4 einzusetzen, in der Hoffnung, dass dadurch die kritische Schwelle der CPU-Last nicht erreicht wird oder zum Anderen die Steuerung mit NodeRED auf einen extern Rechner (RPI4) auszulagern. Da ich nun eine CerboGX besitze, möchte ich diesen auch nutzen und habe mich für die zweite Alternative entschieden. Da das VenusOS ohnehin alle Daten per MQTT verschickt, ist es nur erforderlich einen oder ein paar Werte an den Cerbo zu schicken. In dieser Weise läuft das System „bislang“ bei mir ohne Probleme.
      Fazit: Mir ist unverständlich warum Victron das NodeRED in der Large-Version zur Verfügung stellt, wenn dies laut Aussagen von Nutzern zur Überlast und den Neustarts führt. Ich kann mir nicht vorstellen, dass dies nur nettes „Schmuckwerk“ darstellen soll. Eine Nutzung sollte also in gewissem Rahmen möglich sein. Wenn also ein Linux-Experte hier weiterhelfen könnte, um die Ursache herauszufinden zu können, wäre das prima!

9. Hallo Jörg, vielen Dank für die ganzen Denkanstöße, ich habe nur eine kurze Grundsatzfrage, bevor ich mich länger mit dem falschen Ansatz beschäftige.

   Die ganze Einbindung von victron (z.B. mit deinem Code) geht so einfach nur, wenn das NodeRED als Bestandteil vom Venus OS läuft, oder? Oder geht es auch mit einem NodeRED auf einer separaten Plattform (ioBroker o. standalone)?

   Ich habe ein laufendes System mit MP und CerboGX, gesteuert durch mein Loxone. Aber man testet ja gern neue Sachen aus 😉

   Danke
   Tim

   Antworten

   1. Hallo Tim,
      ich habe ja weiter oben mein Problem geschildert und meine Lösung sieht wie folgt aus:
      Ich habe VenusOS-Large eliminiert und lasse NodeRED auf einem externen RPI4 laufen. Dort stehen keine Victron-Nodes zur Verfügung, wären da aber auch sinnlos. Das VenusOS schickt alle Daten des Systems per MQTT raus. Dies geschieht zum Beispiel wenn Du Dein VRM-Portal öffnest. Wird das VRM geschlossen, werden für ca. 60 sec weiterhin Daten verschickt. Danach stellt das VenusOS das Senden ein, wenn Du nicht einen „WakeUp“ schickst. Dieses WakeUp schicke ich vom externen RPI4 an den Cerbo. Es besteht aus aus dem Befehl „Serial“ auszulesen. Auf dem externen RPI4 habe ich einen Inject-Node, der periodisch alle 30s etwas von sich gibt. Diese Message triggert einen MQTT-OUT-Node, welcher einen Read-Befehl mit Deiner System-ID sendet: „R//system/0/Serial“
      Zur Steuerung des MPII wertest Du die empfangenen Daten aus und sendest Deine Werte per MQTT an den Cerbo. Wie die jeweiligen Befehle aussehen, kannst Du ganz leicht mittels eines MQTT_Exploerers ermitteln.
      Ich hoffe, diese Lösung hilft Dir weiter.
      VG

   2. Hallo Tim,
      vielleicht ist der Hinweis überflüssig, aber die Blog-Software hat im Lesebefehl einen Teil verschluckt. Der Befehl muss lauten:
      „R/‚ID‘/system/0/Serial“
      Wobei für ‚ID‘ Deine System-ID eingetragen werden muss.
      VG

   3. Hallo Christof,
      ich wusste ja gar nicht, dass ich das “large” Image auch auf dem GX laufen lassen kann. Das werd ich jetzt erstmal auf meinem Testsystem probieren, einfach mal zum rumspielen…
      Aber klar, per MQTT bekomm ich die Daten natürlich nicht nur ins Loxone (das nutze ich ja bereits aktiv) sondern auch in das NodeRED auf meinem iobroker System und zurück zum Victron.
      Vielen Dank für den weiteren Denkanstoß, ich bin dann mal testen 😉

   4. Hallo Tim,
      ich vermute, Du hast meine Beiträge davor nicht gelesen. Meine Versuche mit VenusOS-Large und NodeRed habe ich abgebrochen. Ich konnte ein kleines System zur Steuerung zwar laufen lassen, aber eben nicht stabil über einen längeren Zeitraum. Irgendwann stürzte das VenusOS ab und führte einen Neustart durch. Laut Log-Files wurde der Reboot wegen CPU-Overload initiiert.
      Wenn Du damit leben kannst, dann OK.
      VG

   5. Guten Morgen Christof, doch, danke, hatte ich gelesen und das mit dem Watchdog / Reboot steht auch offiziell in den Infos von Victron.

      Ich will ja erstmal nur testen ob es sich überhaupt lohnt so ein System (produktiv dann später auf nem RP4 oder Multi GX) aufzubauen.

      Ich habe das komplette Haus mit Loxone verwaltet, dann um ioBroker ergänzt, und bin nun einfach neugierig ob NodeRED da ne geeignete Ergänzung ist um manche nervigen Besonderheiten in der Usability zu optimieren. Aber vor dem Aufwand scheu ich mich noch, eigentlich läuft ja alles 😉

      Schönes Wochenende
      Tim