76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

DS_Starter · 04 Oktober 2025, 11:16:35

ZitatBei loadStrategy == optPower wird das Ziel verfolgt, einen Speicher schonend zu laden. Wenn nun aber bei unzureichendem PV-Überschuss mit pinmax die maximale Leistung als optimale Ladeleistung empfohlen wird und eine Bewölkung vorliegt, bei der es abwechselnd zu einem niedrigen und sehr hohen Überschuss kommt, wird das Ziel der schonenden Ladung konterkariert.

Die "Gefahr" besteht. Allerdings würde auch, zum Beispiel heute bei mir, OTP für diese Stunden sehr hoch ausfallen was kaum einen nennenswerten Unterschied zu pinmax bedeuten würde.
Generell gibt es das Spannungsfeld die Bat mit möglichst geringer Leistung zu laden und dennoch jedes Fünkchen Überschuß nicht als Einspeisung zu "vergeuden", insbesondere bei sehr volatilen Wetterlagen.

Lass uns zunächst gemeinsam mit weiteren Usern erst noch etwas Erfahrung mit der aktuellen Implementierung sammeln.
Wenn sich dann noch die Notwendigkeit ergeben sollte diesen Prozess anzupassen, gehe ich es an.

ZitatGehe ich denn Recht in der Annahme, dass wenigstens 1 SF-Lauf / h erfolgt?

Das hat der User mit plantControl->cycleInterval in der Hand, per default alle 70 Sekunden.

Ergänzung:

Zitat...es abwechselnd zu einem niedrigen und sehr hohen Überschuss kommt..

Nein dann nicht, hier wird gerechnet. Nur bei kein und unvorhergesehenen (hohen) Überschuß gäbe es den Sachverhalt.

LG,
Heiko

Parallix · 04 Oktober 2025, 11:27:50

Zitat von: DS_Starter am 04 Oktober 2025, 11:16:35...
Lass uns zunächst gemeinsam mit weiteren Usern erst noch etwas Erfahrung mit der aktuellen Implementierung sammeln.
Wenn sich dann noch die Notwendigkeit ergeben sollte diesen Prozess anzupassen, gehe ich es an.
...

Klingt nach einem guten Ansatz! Wollte Dich auch keinesfalls drängen, aber auf die Diskrepanz zwischen Ziel (schonende Ladung) und möglicher Realität (Stress verursachendes "Pulsen" mit hohen Leistungen) hinweisen.

Parallix · 04 Oktober 2025, 11:35:16

Zitat von: DS_Starter am 04 Oktober 2025, 11:16:35...
Ergänzung:
Zitat...es abwechselnd zu einem niedrigen und sehr hohen Überschuss kommt..
Nein dann nicht, hier wird gerechnet. Nur bei kein und unvorhergesehenen (hohen) Überschuß gäbe es den Sachverhalt.

War ein Schreibfehler von mir, den ich gleich in meinem Posting wie folgt korrigieren werde:
... einem niedrigen und sehr hohen Überschuss kommt -> a) ... keinem und b) hohem ggf. auch sehr hohem Überschuss kommt

Edit: Das "unvorhergesehenen" lasse ich weg, da dies bei stark volatilen Wetterlagen häufig der Fall ist.

Parallix · 04 Oktober 2025, 14:00:11

@Heiko: Da ein Teil des gewünschten Textes bereits in meinem Posting #1348429 enthalten ist, habe ich - um Doppelpostings zu vermeiden - das o.g. Posting soeben erweitert. Für das Wiki kannst Du den Teil oberhalb der ersten und unterhalb der zweiten horizontalen Linie verwenden. Nun hoffe ich, dass es für's Wiki ausführlich genug aber nicht zu ausführlich ist. Kannst mir ja kurz ein Feedback geben.

DS_Starter · 04 Oktober 2025, 15:43:09

Danke!
Habe es noch ein bisschen ergänzt und eingefügt.

LG

grappa24 · 04 Oktober 2025, 17:02:56

ha, ich sitz hier im Urlaub (zur Zeit Regen) und schaue zu, wie SF 1.58.6 bei nahezu gleichbleidbendem Verbrauch von 290 Wh dafür sorgt, das mein 7.7 kWh BYD-HVS mit optimierter Ladeleistung sehr schonend bis zum Nachmittag gefüllt wird

DS_Starter · 04 Oktober 2025, 23:01:11

Im Wiki habe ich weitergearbeitet und eure Inputs zur Integration des Fronius Symo eingbaut.

Wer sich wiedererkennt, kann bitte mal gegenchecken was ich niedergeschrieben habe.

LG,
Heiko

Parallix · 05 Oktober 2025, 08:43:40

Bug Report betr. SOC-Prognose bei loadStrategy == optPower:
Aktuell können in SF noch negative Werte für einen prognostizierten SOC entstehen, die es physikalisch natürlich nicht geben kann.

DS_Starter · 05 Oktober 2025, 08:52:51

Moin,

@Max_Meyer, ich habe deinen Input zur Integration eines SMA Hybrid ins Wiki gebracht. Bitte mal gegenchecken und ggf. ergänzen bzw. mir schreiben. Du scheinst neben SMAInverter auch MQTT zu nutzen.

@Parallix,
~~wo genau hast du negative SoCs gesehen? Konnte ich bei mir noch nicht feststellen.~~
Habe das Problem (wahrscheinlich) gefunden, eliminiert und eingecheckt. V 1.58.7 liegt im contrib zum Sofort-Fix.

schwatter · 05 Oktober 2025, 10:10:42

Morgen,

nach den zahlreichen Änderungen im Modul in den letzten Monaten und weil ich mein System neu aufgesetzt habe, richte ich SF ebenfalls neu ein.
Vorrangig nutze ich mein Tablet zur Anzeige. Früher hatte sich die Headerbreite auch nach der Menge der Beams gerichtet.
Welche Möglichkeit(en) habe ich noch um die Breite des Headers zu beeinflussen?

Gruß schwatter

Parallix · 05 Oktober 2025, 10:33:56

Zitat von: DS_Starter am 05 Oktober 2025, 08:52:51...
@Parallix,
Habe das Problem (wahrscheinlich) gefunden, eliminiert und eingecheckt. V 1.58.7 liegt im contrib zum Sofort-Fix.

Wenn ich das richtig sehe, dann nullt Heiko jetzt den für die SOC-Berechnung herangezogenen Überschusswert, wenn dieser < 0 ist. Da dies ja letztlich bedeutet, dass ein Netzbezug prognostiziert wird, frage ich mich, wie dieser oder aber der Verbrauch im SF-Balkendiagramm platzsparend visualisiert werden kann und bin für Tipps dankbar.

DS_Starter · 05 Oktober 2025, 10:53:04

@schwatter,
wenn ich es richtig deute, möchtest du die ganzen Headerbereiche ausblenden, damit nur die Balkengrafik übrig bleibt. Solche Einstellungen kannst du mit dem Attribut graphicSelect festlegen. Die Balkenbreite selbst kannst du mit graphicControl->beamWidth (bedingt) beeinflussen.

DS_Starter · 05 Oktober 2025, 11:00:14

@Parallix,

ZitatWenn ich das richtig sehe, dann nullt Heiko jetzt den für die SOC-Berechnung herangezogenen Überschusswert, wenn dieser < 0 ist. Da dies ja letztlich bedeutet, dass ein Netzbezug prognostiziert wird, frage ich mich, wie dieser oder aber der Verbrauch im SF-Balkendiagramm platzsparend visualisiert werden kann

Ich bin mir unsicher dich richtig verstanden zu haben.
Wenn dieser (Überschusswert) < 0 ist, bedeutet es nicht automatisch Netzbezug, sondern ist nur Verbrauch der auch nur von der Bat befriedigt werden kann.
Der Überschußwert wird bei der SoC Berechnung auch nicht genullt, sondern die Fortschreibung des sich erniedrigenden SoC in diesem Fall auf 0 begrenzt, er kann also nicht tiefer fallen.
Die Darstellungsfrage -> "... wie dieser oder aber der Verbrauch im SF-Balkendiagramm platzsparend visualisiert werden kann." habe ich nicht verstanden was du damit genau meinst.

schwatter · 05 Oktober 2025, 11:02:49

Mh ne, ich wollte es so behalten. Im Header steht ja was so die nächsten Std passiert.
Ich hatte das 2te Bild mit den Beams-Only nur zum zeigen, das wenn ich das so habe die Breite sich verkleinert.
Ich möchte Header und Beams, aber der Header soll schmaler werden. Früher war das wie gesagt möglich,
indem man einfach weniger Beams angezeigt hat.

Gruß schwatter

DS_Starter · 05 Oktober 2025, 11:16:55

Ach so, verstehe.
Früher (ziemlich weit in der Vergangenheit) waren einfach weniger Werte im Headerbereich darzustellen, weswegen die Breite insgesamt weniger war und durch die Balkengrafikbreite dominiert wurde.
Du könntest graphicSelect=forecast setzen und dann mit graphicControl->headerDetail=co,pv nur diesen Bereich des Headers darstellen. Das Bild wird dann wieder schmaler und durch die Balkenbreite dominiert.

Ansonsten sehe ich eigentlich nur die Möglichkeit die Headerbereiche auszublenden um ein schmaleres Bild zu erhalten.