76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

...
Gibt es einen konkreten use Case für die Verwendung von Readings oder ist es nur nice to have?

Ja (zur Frage konkreter Anwendungsfall)! Einer war ja bereits im PS beschrieben. Der andere mit "Today_Pvdeviation" nur indirekt. Nun hoffe ich, dass Du nachvollziehen kannst, um was es mir geht, was auch für andere interessant sein dürfte und SF in jedem Fall auch etwas generischer macht. Wenn nicht, so kann ich z.B. beide Anwendungsfälle auch noch näher erläutern.

Edit: Bei den Referenzen könnte man fordern, dass vor der Referenz stets auch ein Rückfallwert angegeben wird, sollte mal ein Reading nicht existieren oder unverdaubare Werte enthalten.

Bsp. für einen Fallbackwert von 0 für den Fall, dass inb Today_Pvdeviation kein sinnvoller Wert abgelegt ist:

Code Auswählen Erweitern

barrierSoC=40:setRelRef:0:Today_Pvdeviation -> Wert mit angegebenen SF-internen Prozentwert multiplizieren

Habe das in meinem ursprünglichem Posting noch ergänzt!

[300P]

Guten Morgen !

Ich will euch mit meinem Beitrag ja nicht bremsen......

Das Modul wird in diesem Bereich inzwischen so umfangreich - wer soll das eigentlich von den normalen Anwendern (ja damit sind auch :innen gemeint ) noch problemlos und sauber bedienen und mit den dabei notwendigen Parametern und Gedanken anfüttern ? 
Ich verfolge dies zwar weiterhin mit etwas Interesse - aber so viel  für dies Thema in dem Modul ist mir inzwischen "zuviel und zu tief detailliert " um mich damit zu beschäftigen.

Wie gesagt - ich möchte nicht eine Riesendiskussion hiermit dazu auslösen, auch nur ansatzweise irgendwie "auf die Füsse treten" oder irgendwelchen Unmut ver - / ausbreiten. 

Das ist halt nur (m)eine Meinung von einem normalen Anwender, mit einer schon nicht ganz normalen PV (∑ = 14.5 kWp mit 3 WR + 7 Strings und 2 HV-BWR (∑ = 25.8 kW).  

[Parallix]

...

Vielleicht sollte man neben SolarForecast (SF), das für Otto-Normal-Erzeugende und -Verbrauchende geeignet ist, ein zweites Modul SolarForecast+ (SF+) haben, in dem dann spannende "Ideen zur Weiterentwicklung" (so der Titel diese Threads) realisiert werden können.

[DS_Starter]

Ich habe die Syntax etwas eingedampft um sie zu simplifizieren:

Code Auswählen Erweitern

barrierSoC=40:set:ReadingA          -> Wert auf SF Reading "ReadingA" setzen
barrierSoC=40:set:1350              -> Wert auf 1350 W setzen
barrierSoC=40:inc:ReadingB          -> Wert um den Wert in Reading "ReadingB" erhöhen
barrierSoC=40:inc:200              -> Wert um 200 W erhöhen
barrierSoC=40:dec:ReadingC          -> Wert um den Wert in Reading "ReadingC" erniedrigen
barrierSoC=40:dec:100              -> Wert um 100 W erniedrigen
barrierSoC=40:prc:ReadingD          -> Wert um Prozentwert in Reading "ReadingD" ändern (+ erhöhen, - erniedrigen)
barrierSoC=40:prc:50                -> Wert um 50% ändern (+ erhöhen, - erniedrigen)

Ist der letzte String numerisch, ergibt sich daraus automatisch ein direkt anzuwendender Wert. Ein alphanumerischer String indiziert ein Reading.
Das ist deutlich einfacher zu handhaben und für mich zu managen.
Inhaltlich sollte alles wie gewünscht abbildbar sein.

@300P, der Einwand ist durchaus berechtigt. SF ist mittlerweile eine recht umfangreiche Anwendung und kein "normales" Modul. Allerdings sind die allermeisten Einstellungsmöglichkeiten optional und nur für die User relevant die einen entsprechenden Case haben. Reichen die Informationen dann nicht, kann das Wiki Handbuch konsumiert werden.

[DS_Starter]

Vielleicht sollte man neben SolarForecast (SF), das für Otto-Normal-Erzeugende und -Verbrauchende geeignet ist, ein zweites Modul SolarForecast+ (SF+) haben ...

Ich habe hier schon einen Fulltime-Job .... das reicht. 

[300P]

@300P, der Einwand ist durchaus berechtigt. SF ist mittlerweile eine recht umfangreiche Anwendung und kein "normales" Modul. Allerdings sind die allermeisten Einstellungsmöglichkeiten optional und nur für die User relevant die einen entsprechenden Case haben. Reichen die Informationen dann nicht, kann das Wiki Handbuch konsumiert werden.

......
Ich habe hier schon einen Fulltime-Job .... das reicht. 

..und genau deshalb : 👌👍👌👍👌👍
Respekt und DANKE für deinen freiwilligen Einsatz !!!!

[Parallix]

Vielleicht sollte man neben SolarForecast (SF), das für Otto-Normal-Erzeugende und -Verbrauchende geeignet ist, ein zweites Modul SolarForecast+ (SF+) haben ...

Ich habe hier schon einen Fulltime-Job .... das reicht. 

@Heiko: Den zwinkenden Emoji in meinem Posting (der leider in o.g. Zitat nicht mehr enthalten ist) hast Du gesehen? Natürlich meine ich nicht, dass es zwei SF-Versionen geben sollte, da damit der Wartungsaufwand ja nochmals ansteigt. Meinerseits glaube ich auch nicht, dass es "normale" User gibt, die FHEM und damit auch SF einsetzen. Aber gerade das macht das, was hier entsteht und sich immer weiter entwickelt ja so unglaublich wertvoll und setzt sich von Lösungen wie z.B. EVCC ab.

[DS_Starter]

Hatte ich tatsächlich nicht gesehen  ... alles gut, kein Stress.

[Hadl]

Hallo zusammen,
heute wie versprochen die Ladekurve mit dem aktuellen Contrib Modul.

Du darfst diesen Dateianhang nicht ansehen.

Was man sieht ist wieder der Einbruch nach der hälfte der Stunde und das Maximum immer beim Stundenwechsel.

Grund scheint zu sein, das in dem Code die Zeitgewichtung innerhalb der Stunde für $mid nicht enthalten ist. Damit wird von der vollen Stundenleistung der aktuellen Stunde ausgegangen, obwohl nur noch weniger als die Hälfte davon übrig ist. Zum Stundenwechsel wirds dann wieder besser, da dann $cap kleiner als $mid ist, und $cap die Zeitgewichtung enthält.

Beispiel um 12:50

Code Auswählen Erweitern

2025.11.04 12:50:14 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2025.11.04 12:50:14 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 2396 Wh -> target likely achievable? yes
2025.11.04 12:50:14 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - current Ratio of surplus / energy requirement to achieve the load target: 350.63 %
2025.11.04 12:50:14 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 04/12 - hod:13/00, lr/lc:1/1, SocS/E:5284/5399 Wh, SurpH/D:4989/4678 Wh, OTP:791/688 W
2025.11.04 12:50:14 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 04/13 - hod:14/01, lr/lc:1/1, SocS/E:5399/6273 Wh, SurpH/D:4124/554 Wh, OTP:1005/874 W
2025.11.04 12:50:14 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 04/14 - hod:15/02, lr/lc:1/1, SocS/E:6273/7081 Wh, SurpH/D:3167/0 Wh, OTP:929/808 W
2025.11.04 12:50:14 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 04/15 - hod:16/03, lr/lc:1/1, SocS/E:7081/7680 Wh, SurpH/D:1534/0 Wh, OTP:790/687 W

Um die 2396 Wh in 3,17h (von 12:50 bis 16:00) in den Akku zu laden brauchen wir
Leistung roh: 756W
Leistung nach Wirkungsgrad 889W
Leistung nach Margin 1067W (keine weiteren Aufschläge da Ratio 350%)

Also sollten wir mit 1067W OTP Laden. Durch die fehlende Zeitgewichtung kommen aber nur 791W OTP raus.
Zum Stundenwechsel gehen wir dann immer wieder auf ca. 1000W

Heiko, kannst du bei $mid bitte auch eine Zeitgewichtung einbauen.

Vielen Dank schonmal für die viele Mühe und die super Arbeit mit dem Modul!

Viele Grüße

Hadl

[DS_Starter]

Kann ich machen, aber vllt. ist es auch eine Wirkung der Einbeziehung der Effizienz (die in deiner Variante nicht enthalten ist):

Code Auswählen Erweitern

          my $cap   = $nhr eq '00' ? int $replacement : $hsurp->{$hod}{surplswh};
          $cap     *= $befficiency;
          $charged += min ($mid, $cap);


Und wenn ich darüber nachdenke ist auch dies nicht ganz richtig und müßte so aussehen:

Code Auswählen Erweitern

          my $cap   = $nhr eq '00' ? int $replacement : $hsurp->{$hod}{surplswh};
          $cap      = min ($mid, $cap);
          $cap     *= $befficiency;
          $charged += $cap;

Ich werden beide Änderungen vornehmen. Vllt. habe ich die nächsten Tage auch mal selbst die Gelegenheit die Characteristik zu testen wenn mal genügend Überschuß vorhanden ist.

[DS_Starter]

Angepasste Version liegt im Contrib.

[Parallix]

Ich habe die Syntax etwas eingedampft um sie zu simplifizieren:

Code Auswählen Erweitern

...
barrierSoC=40:set:ReadingA          -> Wert auf SF Reading "ReadingA" setzen
...
barrierSoC=40:inc:ReadingB          -> Wert um den Wert in Reading "ReadingB" erhöhen
...
barrierSoC=40:dec:ReadingC          -> Wert um den Wert in Reading "ReadingC" erniedrigen
...
barrierSoC=40:prc:ReadingD          -> Wert um Prozentwert in Reading "ReadingD" ändern (+ erhöhen, - erniedrigen)
...

@Heiko: Wäre es nicht sinnvoll, gleich auch die Rückfallwerte in der von mir in #4423 vorgeschlagenen Form mitaufzunehmen?