Man könnte vielleicht zeitgesteuert den minSOC über Node-RED anpassen. Z.B. Nachmittags gegen Ende der PV-Produktion den minSOC auf 15% setzen. So wird von DESS auf 15% minimal geplant.
Zu Beginn der üblicherweise teuren Stunden, z.B. kurz vor 06:00, den minSOC dann auf 10% verringern. So hast du dannn für die paar Stunden bis PV-Beginn um 5% mehr zur Verfügung als durch DESS geplant wurde.
Am Nachmittag wird dann wieder auf 15% erhöhen.
Nur mal so eine Idee. Nicht wirklich zu Ende gedacht…
Bei Ladebedarf wird sich der Hack weitgehend an die Vorgabe halten. Die berechneten Soc-Werte (je Stunde) sind von DESS ja so vorberechnet, dass es mit dem erwarteten Solarertrag auf den Wunsch-Soc reicht - und dieser Wunsch-Soc notwendig ist, um später / In der Nacht genug Reserve zu haben.
Daher habe ich da das Laden aus dem Grid nicht unterbunden, weil sich hier einfach nicht abschätzen lässt, um welche “Situation” es sich handelt:
Um hier tatsächlich anders entscheiden zu können, müsste mein “Hack” den Scope des stündlichen Fensters verlassen und tatsächlich nochmal in Eigen-Regie die komplette Roadmap inkl. Forecasts analysieren usw.
Im wesentlichen basiert der Hack darauf, den Plan nur stunden mäßig zu hinterfragen:
Er macht also im Grund nur Optimierungen, die den Plan nicht NEGATIV verändert. In deinem Fall müsste man quasi eine Aktzeptanz einbauen, wieviel man es erlauben will dem Plan hinterher zu hinken - und das wird sehr schwierig, denn alles was versäumt wird, sollte später kompensiert werden und erfordert damit ein Vorrausschauen, ob es überhaupt kostenmäßig sinnvoll ist, ein späteres Aufholen zu akzeptieren.
Auf was hast du denn deine Batteriekosten stehen? Setz die mal höher, je höher die sind, desto konservativer wird DESS beim berechnen einer Laderate sein.
Danke für den Tip.
Ganz ehrlich, für Red-Node fehlt mir die Zeit. Ich habe eine komplette selbstprogrammierte Steuerung parallel laufen, kann ich den Mindest-SOC nicht einfach mit einem ssh-Befehl zu einer bestimmten Uhrzeit absenken? Das würde als Puffer für morgens reichen.
Weiss jemand ob das klappt?
Also wenn du eine selbstprogrammierte Steuerung hast, also programmieren kannst, dann sollte den minSOC zu einer bestimmten Zeit via Node-RED zu ändern wirklich kein Problem darstellen. Viel simpler gehts nicht. Hab mir das auch selbst beigebracht, das geht grundsätzlich recht flott!
Alternative wäre vielleicht noch den minSOC über Modbus zu ändern.
Ja, kannst du, müsste im Prinzip mit folgendem 1 Zeiler gehen:
dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/MinimumSocLimit SetValue XX
Allerdings müsstest du das zeitig tun, DESS plant den Minimum Soc mit ein, und aktualisiert die Planung glaube ich nur stündlich.
Und ob das Minimum überhaupt eine Auswirkung auf die errechnete Laderate hat, ist auch nicht gesagt.
Super, einmal mit Profis arbeiten 
Ich hatte das nicht gefunden, was heisst denn dieses “CGwacs” überhaupt?
Ich werde damit jetzt mal die nächsten Tage rumspielen, vielleicht klappt das ja auch mit der Planung Ziel-SOC dann besser.
Vielen Dank!
Berichte dann bitte mal, obs was bringt!
Du wirst jetzt bestimmt lachen, aber meine Steuerung ist mit Gambas (Basic) auf einem RaspberryPi von 2014 geschrieben, mit neueren Programmiersprachen hab ich nix mehr am Hut
ich würde erwarten, dass das DESS Deine besonderen Verhältnisse über die 28 Tage “Lerndauer” begreift und merkt, dass Du mit der Nordanlage morgens nicht so viel Ertrag bekommst, wie die Solarprognose vielleicht erwartet…hast Du dem DESS schon nen Monat lang Daten gegeben ?
Ja habe ich, es muss ja auch nicht daran liegen, war nur eine Vermutung von vielen. Ich habe blöderweise vor meiner Südanlage ein Haus stehen, so dass ich erst ab 9 Uhr volle Sonneneinstrahlung bekomme, und das ist erst seit 1-2 Wochen der Fall, es wird halt Winter…
Vielleicht muss das System dieses erst noch lernen.
Fakt ist, dass der errechnete SOC am morgen meistens nicht passt und das System dann zu den teuersten Zeiten Strom aus dem Netz bezieht. Es wäre schön, wenn das System nicht Spitz auf Knopf rechnet, sondern in allen Lebenslagen und Situationen einfach mal 5-10% Puffer für aussergewöhnliche Umstände lässt. Ich hoffe ich kann das mit dem mindest-SOC ausgleichen, wenn ich diesen in den Morgenstunden runtersetze, das wäre dann genau der Puffer, den ich bräuchte.
eigentlich mag ich meinen Nachbarn - aber im Winterhalbjahr ist sein Haus auch zu hoch 
Mal schauen wie schnell das DESS das lernt…
2 Wochen wirds dauern - aber dummerweise lernt DESS ein bischen Umständlich:
Ich nutze eine Überschussteuerung und komme so im Sommer immer gut auf 7-8 kW Verbrauch pro Stunde. Nachts hab ich wie eingemeiselt 600 Watt Grundrauschen.
Dess hat 3 Wochen gebraucht um die 7-8 kW Tagsüber langsam zu vergessen - aber justiert hierbei leider scheinbar den Verbrauch jeder Stunde anteilig mit.
Hat bei mir dazu geführt, dass es für die Nacht immer mit ~ 400 Watt gerechnet hat (teils mit 250) und in diesen Nächten der Soc-Plan voll nich aufging.
Dann wäre der von @BuBu angedachte “5-10% Puffer” (einstellbar) schon eine gute Idee. Man müsste halt dem DESS / VRM “mitteilen” wie sich große Verbraucher verhalten (wie BEV oder WP). Dann könnten die besser in die Kalkulation einbezogen werden.
Habe jetzt eine Nacht mein BEV 3 Stunden geladen und dann plant das DESS für die nächste Nacht wieder diesen höheren Grid-Bezug ein…obwohl ich das in der kommenden Nacht gar nicht benötige…ist halt nen komplexes Terrain…
Ich glaube genau das ist das Hauptproblem. Sowohl die Ertrags und Verbrauchsprognose. Damit steht und fällt das gesamte System.
Aus meiner Sicht funktioniert alles andere ganz gut.
Ich hatte auch schon mal angeregt die Relais der MP2 zu integrieren. Das die ein Komando rausgeben PV Überschuss oder günstiger Preis. Dann könnte das DESS evtl den kausalen zusammenhang zwischen erhöhten Verbrauch erkennen. Aber mag sein das das nicht umsetzbar ist oder ich zu kompliziert denke.
Ich denke der Gedanke einer “Verbrauchsreserve” wäre ein Anfang und sollte auch umsetzbar sein
Im Falle eines integrierten EV-Chargers könnte das System diesen Verbrauch ja jetzt schon aus der Prognose “rausrechnen” - tut es aber (noch) nicht.
Habe aber unlängst einen Beitrag gelesen, dass Victron da gerade etwas auf der Roadmap hat, dass man Verbräuche feiner erfassen kann (vermutlich eigene Zähler für WP, etc) wovon der Aussage nach auch Dess profitieren soll.
Schöner wäre natürlich, wenn man direkt von extern dem System irgendwie mitteilen könnte, dass “4kW der aktuellen 5kW” auf “geschaltene Verbraucher entfallen” und in Prognosen nicht eingerechnet werden sollen.
Ich habe jetzt mal mein BEV-Ladetool “evcc” in den Cerbo (und das VRM) eingebunden.
Den Gedanken mit der skalierbaren “Verbrauchsreserve” finde ich trotzdem nice.
Aber sei es drum, ich bin auf jedenfall froh das es momentan, jedenfalls bei mir gut läuft. Ich habe echt viel Umsatz und wenn der Großteil wirtschaftlich gedeckt wird ist mir viel geholfen.
Die letzten paar % Optimierung kommen auch noch. Zwischenzeitlich als die Verbrauchsprognose sprang wie ein Känguru hatte ich Zweifel.
Ich hatte zwischenzeitlich mal ein paar Einblicke bei Mitbewerbern von Victron da sieht das noch traurig aus was ähnliche Entwicklungen angeht
Sehr cool!
Darf ich fragen wie du das integriert hast? Liefert EVCC Daten über Modbus TCP?
Ich habe jetzt mehrmals den mindest-SOC auf unterschiedliche Level gesetzt, das System hat das innerhalb der nächsten Stunde prompt umgesetzt und die Planung angepasst. Das lässt hoffen daraus einen Puffer zu basteln…
cd /tmp
wget https://github.com/SamuelBrucksch/dbus-evcc/archive/refs/heads/main.zip
unzip main.zip "dbus-evcc-main/*" -d /data
mv /data/dbus-evcc-main /data/dbus-evcc
chmod a+x /data/dbus-evcc/install.sh
/data/dbus-evcc/install.sh
rm main.zip
vi /data/dbus-evcc/config.ini
IP-Adresse von EVCC darin eintragen
Gruß Ove