Du kannst den Egolf jetzt mit 7 kW laden und bei einem flexiblen Strompreis die günstigste Stunde in der Nacht nutzen, wenn die 700 Watt Überschuss bei milchiger Sonne nicht bei 1,3 kW Minimum Last des Egolfs abgegrast werden und das stattdessen die Batterie macht.
Ich überschlage so was wie 500 kWh, bei denen man 10 Cent sparen kann. Ist aber schwer da exakt zu sein. Mit 7 kW sind die Ladeverluste beim Egolf geringer Dafür hat man Ladeverluste bei der Marstek Batterie. Wirklich lohnen dürfte sich das vor allem mit dynamischen Tarifen, wenn man mittags 40 Cent hat, abends 50 Cent und nachts 30 Cent (hatten letzten Winter so was häufiger). Da die 5 kWh mittags aus dem Netz und 5 kWh aus der PV schieben (die 5 kWh Netzbezug in die Nacht und die 5 kWh PV Überschuss in den Abend), da kommt eher was zusammen als wenn man eine kWh weniger Ladeverluste beim Egolf gegen 1 kWh Ladeverlust der Marstek tauscht.
Die Rentabilität sieht mit der Rechnung etwa so aus:
Im Sommer muss man 1250 kWh einspeichern für 1000 kWh Ausspeichern. Bei 8 Cent Einspeisevergütung und 30 Cent für Netz-Strom sind das 200 Euro Netto Ertrag (300-100).
Im Winter nehme ich 100 Tage wie oben an. Für die 5 kWh, die der Egolf nachts lädt, sind das 500 kWh * (40 Cent mittags - 30 Cent nachts) = 50 Euro Ertrag
Für die 5 kWh, die Marstek in den Abend schiebt, haben wir 500 kWh * (50 Cent verniederner Bezug abends gegen 40 Cent vermiedener Bezug mittags) = 50 Euro.
Bei 1178 Euro Kosten für den Speicher ist man bei etwas unter vier Jahren und hat die Notstromversorgung als extra umsonst dazu im Paket (ja dafür muss der Speicher auch geladen sein und dann ist der schnell leer, aber besser als ein paar Stunden im Dunkeln sitzen).
Ich habe die Venus E nun seit einigen Monaten in Betrieb, und bin sehr zufrieden soweit. Ungefähr ein Viertel unseres Hausverbrauchs kommt aus dem Akku, und die Autarkie liegt nun bei 97-98%.
ich weiß nicht ob dir das in irgendeiner Weise hilft, aber ich konnte meinen Marstek in eine ähnliche Situation bringen: er hat dann zwar Werte angezeigt, die "Diagnose" ist aber immer fehlgeschlagen. Die Regelung hat dann manchmal funktioniert, aber streckenweise gar nicht mehr.
Und zwar habe ich das Shelly Protokoll auf einem ESP32 selber nachgebaut (siehe mein Beitrag). Interessehalber habe ich dort mal versucht wie sich der Marstek verhält, wenn ich den aktuellen Bezug auf die 3 Phasen gleichmäßig aufteile anstatt die realen Werte durchzugeben.
Ab diesem Zeitpunkt war dann die Diagnose am Marstek nicht mehr möglich, eventuell braucht er unterschiedliche Werte auf den Phasen um zu erkennen "ah, da sind ja wirklich drei Phasen".
Ich kenne mich mit der Tibber Bridge nicht aus, aber vielleicht macht die etwas ähnliches?
Danke, so etwas habe ich mir auch schon überlegt und werde das mal ausprobieren. Die Tibber Bridge liefert nur einen Wert. Dementsprechend verteilt uni-meter sie gleichmäßig auf die drei Phasen. Ich schreib es auch mal in die uni-meter issues. Vielleicht ein Problem mit der neuen Venus E Version? Bei der alten habe ich nie von diesem Problem gelesen.
Das war der entscheidende Tipp. Hab wohl die Doku von uni-meter nicht gut genug gelesen :
# The Marstek storage needs input data on a single phase. This can be controlled by
# the configuration options below
power-phase-mode = "mono-phase"
power-phase = "l1"
Ja sorry, das hätte ich dir auch sagen können, wenn ich dein Post rechtzeitig in Gänze verstanden hätte...
Die Venus versucht die eigene Phase zu ermitteln und schickt dafür ein paar Strompulse über die Leitung. Tibber sieht natürlich nur eine Leistung und uni-meter in falscher Konfiguration teilt das gleichmäßig auf drei Phasen auf. Dann passt der Messwert nicht zum Testpuls und Venus ist unglücklich.
Kein Problem - so lernt man das System kennen
Gibt es von deiner Seite Empfehlungen für den Parameter min-sample-period für den uni-meter output?
Gerade bei hohen Verbräuchen scheint das System noch ziemlich zu überregeln, teilweise schwingt sich das System sogar auf.
Ich kann es natürlich auch einfach ausprobieren, aber wenn es Erfahrungswerte gibt, bau ich gerne darauf auf.
Info: Bei der Tibber bridge habe ich meter_throttle_ms auf 983 gesetzt.
Ich bearbeite den Messwert vom Pulse noch in Home Assistant. Ich habe darin ein Template gebastelt, das vollkommen hoffnungslos dem Feature Creep verfallen ist, weil ich so viel zu berücksichtigen versuche...
Der Teil, der sich ums Schwingen kümmert, schaut einfach auf die Standardabweichung der letzten 2min und reduziert den Wert unso mehr, je größer diese ist. Damit schwingt fast nichts mehr, aber das Regeln zur Null geht etwas langsamer, wenn die Vergangenheit schon "bewegt" war.
Ich kann das Template bei Interesse posten, aber das ist momentan echt würdelos, weil da zu viel passiert. Eigentlich müsste das in echtem Code behandelt werden.
Für mich leider nicht interessant - ich sitze auf OpenHAB außerdem ist das ganze System bei meinem Vater verbaut, weswegen ich da auf die normalen Bordmittel der services setzen möchte. Sonst werd ich zu oft angerufen
Aber vielleicht gibt es hier ja noch andere Nutzer, die auf HA setzen.
Ich probier mal aus, ob ich mit irgendeiner Konfiguration auf ein besseres Verhalten komme und werde berichten.
Hallo ich habe auch seit einer Woche den Venus E und bin weitgehend zufrieden. Weitgehend, da immer noch zwischen ca. 40 und 80 W bezogen werden, trotz stabiler Kommunikation mit einem Shelly Pro 3EM. Ich wäre interessiert, wie ich die Einspeiseleistung vom Speicher erhöhen oder im Shelly einen Offset einstellen, also einen Mehrverbrauch vorgaukeln kann. Geht das irgendwie direkt oder nur über Umwege wie uni-meter o.ä.? Ansonsten ist es ein perfekter Speicher und passt super zu meiner kleinen PV-Anlage. Danke und viele Grüße!
Dann probier mal zum Starten min-sample-period = 2500, bzw. gern eine Primzahl in dem Bereich. Das klappt oft ganz vernünftig.
Relevant ist sicherlich noch, dass der Pulse neue Werte nicht mit konstanter Frequenz sendet. Bei mir kommen neue Werte manchmal nach 1s, meist nach 2s, manchmal nach 3-4s, ab und zu nach 6s und selten auch mal jede Zeit darüber bis ca. 40s. Diese "Aktualität" ist etwas, das ich in meinem Template berücksichtige und dem uni-meter dann eine 0 gebe, weil jede Regelung dann nur kontraproduktiv ist.
Eigentlich schreib ich das nur, damit du beachtest, dass die Werte so gut wie nur möglich ausgelesen werden. Das Abfrageintervall wird länger, wenn der Lesekopf nicht optimal ausgerichtet ist, aber auch wenn die Spannung der Batterien im Pulse nicht mehr total perfekt ist.
einen dynamischen Offset den ich mit HA auf 50 W bzw in der Nacht auf 15 W setze (um das zu erreichen was @klema angesprochen hat)
einen "Lower Cutoff" den ich in der Nacht auf -5W setze. Der bewirkt das alle echten Werte unter diesem Cutoff auf den Cutoff gesetzt werden. Dadurch "schleicht" sich der Marstek langsam "von unten" wieder an den Zielwert. Damit schwingt er gar nicht mehr, braucht nur etwas länger bis er angekommen ist
Jetzt muss ich aber noch Mal blöd fragen: Den dynamischen Offset bekommst du doch nur realisiert, wenn du den tatsächlichen Hausverbrauch oder die Leistung, die dein Speicher gerade abgibt/aufnimmt zusätzlich misst, oder steh ich auf dem Schlauch? Da ich bei meinem Vater eigentlich keine zusätzliche HW verbauen wollte als den eh schon vorhandenen Tibber Pulse, steht mir das nicht zur Verfügung.
Ich hab meine Tibber Bridge mal über ein paar Minuten beobachtet (API requests). Werte über 2500ms kommen schon auch ein paar vor
Ein langsameres Einregeln bei großen Lastsprüngen könnte man theoretisch doch durch eine minimale bzw. maximale Schwelle beim uni-meter umsetzen, oder (z.B. -500W und +500W)?
Das würde dazu führen, dass der Speicher von mal zu mal maximal die Schwelle korrigiert.
Was haltet ihr von der Idee?
Edit: löst natürlich nicht das "kleine" Schwingen in der Nacht.
Zum Offset: Das funktioniert doch ganz einfach: Du nimmst den echten Messwert und addierst da halt einen offset (die Wahlweise 50W oder 15W bei Markus) drauf. Wenn die Summe 0 ist, ist der Speicher zufrieden und du konsumierst halt im Mittel 50W.
Es macht keinen Sinn, den Output bei einem konstanten Wert (z.B. ±500W) zu kappen. Dann limitierst du bestenfalls die Amplitude der Oszillation, aber löst das eigentliche Problem nicht.
Darum habe ich in meinem Template ja stattdessen einen Skalierungsfaktor drin: Dieser ist 1, wenn in den letzten 2min Ruhe herrschte und der echte Messwert sehr aktuell ist. Aber wenn in den letzten 2min schon viel Gezappel war, sollte man nicht den Anspruch haben, in 5s auf echt 0 zu regeln. Da ist dann irgendwas bei den Verbrauchern oder Erzeugern los, dass man langsamere Änderungen machen und erstmal abwarten sollte. Darum wird der Faktor dann verkleinert bis runter zu 0,1. Das löst das Oszillationsproblem vollständig und trotzdem hat man beim Ein- oder Ausschalten von großen Verbrauchern meist eine schnelle Reaktion.
Oszillationen sind ein Zeichen von zu hohem gain oder zu langer Verzögerung oder beidem im Regelkreis.
Solange man die Regelung nicht selbst macht sondern dem Speicher nur den Shelly vorgaukelt, sind die Eingriffsmöglichkeiten da begrenzt. Man kann nur den gain reduzieren, indem man den Messwert z.B. mit 0.9 multipliziert oder einen Totbereich einbauen indem man z.B. alles zwischen 0W und 50W Bezug auf 0 setzt.
Mit Tibber o.ä. cloud-service kann man an der Verzögerung glaube ich wenig machen. Man bräuchte eine Art Y-Kabel für die optische Schnittstelle vom Zähler damit man den Tibber Pulse betreiben und gleichzeitig lokal Echtzeitdaten bekommen kann.
Mit meinem PI-Regler über Modbus mit Messwerten direkt aus dem Smartmeter bin ich jetzt sehr zufrieden, da schwingt nix und der Speicher regelt Leistungssprünge unter 5s aus.
Eigentlich reicht ein I-Regler, da das System an sich keine Trägheit besitzt. Aber da der Zähler immer über die vergangene Sekunde integriert, sieht das wie Trägheit aus und der P- Anteil führt zu etwas schnellerer Antwort bei einem Leistungssprung.
:
