Ich habe das DESS mit Hack seit 3 Tagen am laufen. Aber irgendwie läuft das nicht wie erwartet. Es ist jetzt 20:15, meine Hausbatterie ist zu 95% voll und aktuell ist der Tibber Strom ziemlich teuer: dennoch versucht das DESS aus dem Netz die Batterie zu laden und den Hausverbrauch aus dem Netz zu ziehen. Ich habe das jetzt im ESS erstmal deaktiviert. Um 2,3,4 Uhr Morgens ist der Strom billig, da wäre es sinnvoll, aber jetzt?
Ahhh OK, danke für die Hinweise.
Ja, Ausgleich war aktiviert, aber im VRM stand nichts von “…Ausgleich für diesen Tag …”
OK, ich habe es jetzt deaktiviert, im DESS steht jetzt “SCHEDULED_SELFCONSUME”.
Laut den errechneten Infos, reicht dei Batterie bei jetzigem (gleichbleibenden) Verbrauch noch ca. 7 Stunden. Dann wäre sie leer, wenn Morgen früh die Preise anziehen.
Kann/wird das berücksichtigt, damit die Batterie in der Nacht aus dem Netzstrom geladen werden wird?
Wenn die Batterie nicht reicht um gemeinsam mit der PV-Produktion den Tagesverbrauch abzudecken und ausreichend Preisunterschied vorliegt zw. den günstigen Ladezeiten und jenen Zeiten an denen ansonsten aufgrund leerer Batterie aus dem Netz gezogen wird, dann wird aus dem Netz in die Batterie geladen. Also nur wenn es wirtschaftlich sinnvoll ist. Ansonsten nicht.
Hängt auch stark von den von dir in den DESS Einstellungen angegeben Batteriekosten cent/kWh ab, ob es als wirtschaftlich errechnet wird oder nicht.
Du siehst es ja eh an der DESS Planung, wenn aus dem Netz geladen werden soll.
Kann ich irgendwie dabei behilflich sein, diese Funktion zu implementieren?
Gerne zum Testen oder auch zum Programmieren.
Gerne PN an mich und Kontaktaustausch.
Ich mach das durch temporäres anpassen des Grid-Set-Points. Das is im 5 Watt Schritten aber brutal nervig, wenn ich 12kW ChargeRate will - und wird ignoriert, wenn DESS gerade die batterie idled… Muss man also auch noch temporär DESS abschalten.
Hab mir da auch schon Gedanken gemacht, das bissle komfortabler zu machen, quasi ein “Battery-Charge-Boost”-Button.
Hab das schon mit den 3 Stimmen in meinem Kopf durchgesprochen, wir sind uns aber noch nicht einig, wie das am schönsten machbar wäre
Da fällt mir ein, man müsste mal testen, wie das ist, wenn man nen Battery-Schedule anlegt, während DESS aktiv ist und schauen “wer gewinnt”.
Geht mir genauso. Ich hatte das Minimum Limit auf 15% gehabt, habe es jetzt auf 10% reduziert, brauche jedes KW
Wie angedeutet: Ich stehe gerne für Tests / … zur Verfügung.
Also wenn was programmiert werden könnte dann das Zwangsladen zu geringen Preisen insb. in der Nacht wäre hilfreich.
Man nimmt dazu die zu erwertende Prognose für den nächsten Tag(e) - den erwarteten Verbra/äuch(e und die freie Ladekapazität des Akkus.
Beispiel: Zu aktuellen Zeitpunkt werden erst mal die vorhandene Kapazität bis zu einer Entladegrenze * 0,9 genommen. Dann der Verbrauch berechnet bis endlich mal genug positiver Überschuss vorhanden ist um die Batterie wieder zu laden und das wird zu den erwarteten günstigsten Zeiten bis dahin in den Akku gepumpt.
Wenn man dann hier noch einen fest einstellbaren Grenzwert fest (weil man keinen Strom für über zb. 25 cent/kWh kaufen will) legt wäre schön.
Aber es macht ja keinen Sinn für kleine Unterschiede den Akku zu belasten. Daher wäre es gut das in dem Zeitraum nachts der Akku nur dann in der Prognose Strom zum Zwischenspeichern verwendet wird wenn die Differenz z.B. einen Faktor überschreitet (z.B. ich lade nur bei 30 % differenz) und die Lade- und Entladesteuerung angepasst ist.
Aber fangen wir doch erst mal klein an Z.B. Zwangsladen über Netz jede Nacht auf z.B. 50 % zu den günstigsten Zeiten wäre schon nett. Oder geht das bei DESS auch jetzt schon im ESS menü weil das da höhere Prio hat? Dann aber nur mit festen Zeiten. Schöner wäre anhand der dynamischen Tarife.
Entladen des Netz-geladenen Stroms zum Verbrauch nur wenn der Bezugs-Preis über einen Wert kommt.
Anlage hat 11 kW und kann mit 7 kW laden. Akku hat 100 kWh. um 0 Uhr.
Unterste Grenze 20%.
Ladegrenze 50 % macht 33 kWh notwendige Ladeleistung / 7 kW ~ 4,5 h
Verbrauch 500W Dauerlast (±)
Erwartete PV über 500W zur Deckung der Dauerlast: 10 Uhr
Günstigster Zeitraum für Laden auf 50 %: 0-4 Uhr = 5h. Laden muss also dafür um
0:30 begonnen werden.
Deckung des Verbrauchs von 0:30 - 5 Uhr parallel zum laden.
5-6 Uhr lohnt Verbrauch aus Batterie nicht da hierfür für 20 cent um 0 Uhr vorzeitig geladen werden müsste. Also Durchleitung.
7-10 Uhr Deckung aus Batterie mit 1,5/0,9~1,65 kWh (etweder aus den 50 % oder durch zusätzliches Vorabladen von 0-0:30.
Ab 10 Uhr übernimmt dann die PV die Führung mit Ihrem Überschuss.
Naja nicht so wirklich ideal aber so in der Art stelle ich mir das Ergebnis vor. Das kann man dann über mehrere Tage auch vorprognostizieren um z.B. günstige WEPreise zu nutzen.
In dem Fall sind auch größere Speichersysteme kein Problem mehr wenn man die mit einbindet.
Also erstmal macht das DESS im Prinzip genau das was du beschrieben hast. Leider arbeitet das DESS immer nur für den Zeitraum für den Preise zu Verfügung stehen. Um besonders günstige Preise z.B. an Wochenenden zu nutzen, habe ich vergangenen Winter an solchen günstigen Tagen den Min Soc hochgestuft und dann die nächsten teuren Tage diesen Min Soc Schritt für Schritt wieder reduziert um wirklich alle teuren Zeiten abzudecken. Klappt gut
Das Problem wird nicht durch irgendeinen “Hack” gelöst. Das ist ein systemisches Problem(???) des DESS und damit des VRM und nicht eines Hack im Venus. Das VRM plant nur solange es Preise hat. Es speichert keine Energie für die Zeit über diese Kalkulation hinaus.
Eine Lösung wäre diesen Kalkulationszeitraum zu verlängern. Für diese Kalkulation sind mehrere Faktoren elementar, die wichtigsten Solarprognose, Verbrauchsprognose und die Preise der kommenden Stunden. Genau diese Preise sind das Problem, die stehen nur für den “Dayahead Zeitraum” zur Verfügung.
Der aus meiner Sicht einzige Weg wäre eine “Preisprognose”. Erst dann kann das System Energie speichern für den Bedarf der über den “Dayahead Zeitraum” hinaus geht. Erste Ansätze sind ja regelmäßig zu erkennen. Dabei ist natürlich eine halbwegs genaue Prognose wichtig aber nicht elementar. Es geht darum das das System erkennt, es wird in der Zukunft Zeitpunkte geben mit PV Unterproduktion und teureren Preisen als aktuell. Erst dann wird das System Energie auf “Vorrat” speichern.
ich meine zu verstehen was du meinst aber was hat das mit der Situation zu tun wenn Solarenergie zur Verfügung steht und das Akku noch etwas aufnehmen könnte, dieses aber nicht tut, da der geplante SOC bereits erreicht wurde.
Klar, eine Vorhersage von Verbrauch und Wetter ist schwierig, aber bevor die Energie für lau eingespeist wird kann doch die Planung übersteuert werden.
Weil das System genau soviel Energie speichert, wie es zu dem “dayahead” Zeitraum benötigt. Nur ein Beispiel: wenn es wirtschaftlich sinnvoller ist Strom zu verkaufen und später günstiger wieder zu kaufen wird es auch das tun. Dabei berücksichtigt es nicht nur Kosten und Erlöse sondern auch Verluste und Kosten für Akkudegration. Hierfür auch ein Beispiel….. Bei meiner!!! Konfiguration, 2 cent Akkukosten und ca 15% Wandlungsverluste sind das rund 6 Cent. Entscheident ist dabei wie DEINE Konfiguration aussieht. So jetzt speichert das System nur soviel Energie das es die Zeiten abdecken kann wo es die Kosten erwirtschaftet. Wenn es günstiger ist den Strom zu verkaufen und später OHNE Wandlungsverluste und Akkukosten direkt Strom zu beziehen wird es auch das tun. Und merke…….immer nur für den Planungszeitraum
Ja so sehe ich das auch. Aber wenn ich doch gar keine Vergütung für die Einspeisung bekomme und das auch so hinterlegt habe kann ich mir keine Situation vorstellen wo ein Verschenken und dann auch später ggf. günstig einkaufen ein rechenbarer Fall sein könnte. Negative Ankaufpreise gab es leider schon lange nicht mehr und sicherlich nicht in der Winterzeit. Daher meine ich, ist es immer richtig alles im Akku zu speichern was kostenlos zur Verfügung steht. Aber das macht mein MP2 eben nicht. Und der erwähnte Hack hier im Thread soll den MP2 dazu bringen das zu tun. Es steht dort aber, dass ab V3.55 das Problem von Victron behoben sein soll. Somit noch einmal meine Frage, warum macht mein MP2 mit V3.67 das nicht?