76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Nun frage ich mich, ob und wie es derzeit schon möglich ist, derartige manuell veranlasste Verbräuche aus der Verbrauchsprognose automatisiert herauszunehmen, wenn diese separat erfasst werden.

Es gibt aktuell zwei Stellschrauben, plantControl->consForecastLastDays und plantControl->consForecastIdentWeekdays.

Will man z.B. eine "Glättung" von unregelmäßig eingeschalteten Verbrauchern erreichen, bietet sich an consForecastLastDays auf einen hohen Wert zu setzen und consForecastIdentWeekdays auf 0 zu belassen. Nachteilig ist, dass regelmäßig und wochentagsabhängige Verbräuche weniger gut berücksichtigt werden und Verbraucher mit exconfc ebenfalls technisch bedingt nicht gut integriert werden können.

Bei meiner Einstellung mit consForecastIdentWeekdays=1 und consForecastLastDays=8 werden die letzten acht gleichen Wochentage, also die letzten 8 Sonntage, Montage etc. miteinander in Beziehung gesetzt. Für mich ergiebt diese Einstellung eine hinreichend gute Berücksichtigung der "Gewohnheiten" an identischen Wochentagen sowie einer Glättung unregelmäßiger Vorkommnisse.

[DS_Starter]

Ich kann nur vor dem Schlüssel "asynchron=1" warnen, ich hatte den bei meinen beiden Inverter-Devices gesetzt

Hier geht es um eine Eventverarbeitung. Wenn die Readings des/der Inverterdevices zu häufig Events werfen (z.B. bei MQTT) dann wird der SF-Zyklus entsprechend angetriggert. Da muss man den Eventmonitor bemühen bzw. ctrlDebug=notifyHandling. Dann sieht man wie stark SF dadurch gefordert wird. Dann mit den bekannten Mitteln die Eventgenerierung eindämmen.
Eigentlich ist es so gedacht, das ein Gerät welches als letztes einer Synchronkette aktualisiert wird, den SF-Zyklus antriggert. Damit kann man ein einigermaßen synchrones auslesen von Meter, Bat und Inverter realisieren.

[DS_Starter]

Ich habe im Wiki einen Abschnitt für Hybridwechselrichter begonnen der noch weitergeführt wird.

[DS_Starter]

Die Version 1.58.4 ist eingecheckt und morgen früh im Update. Sie enthält Überarbeitungen der optmierten Ladeleistung Steuerung.

[Parallix]

Die Version 1.58.4 ist eingecheckt und morgen früh im Update. Sie enthält Überarbeitungen der optmierten Ladeleistung Steuerung.

Was konkret wurde denn verändert? Wenn man das weiß, versteht man besser das, was man anhand des Werteverlaufs am Tag sieht.

[DS_Starter]

Was konkret wurde denn verändert? Wenn man das weiß, versteht man besser das, was man anhand des Werteverlaufs am Tag sieht.

Den Punkt 2 wie in #4106 geschrieben.

[Parallix]

Was konkret wurde denn verändert? Wenn man das weiß, versteht man besser das, was man anhand des Werteverlaufs am Tag sieht.

Den Punkt 2 wie in #4106 geschrieben.

Ahh, OK. Hatte gedacht, die Überhöhung hättest Du bereits zu einem früheren Zeitpunkt herausgenommen. Da lag ich wohl falsch! Danke für die schnelle Aufklärung!

[Parallix]

Viele Hybrid-Wechselrichter verteilen die zur Verfügung stehende PV-Leistung nach folgendem Prioritäten, wenn der (übliche) Modus ,,Eigennutzung" aktiviert ist:

• Nutzung der Leistung zur Deckung des Hausverbrauchs,
• Nutzung der Leistung zur Ladung des bzw. der angeschlossenen Speicher.
• Einspeisung der Leistung in das öffentliche Netz.

Da in aller Regel die Leistung, mit der ein angeschlossener Speicher geladen wird, limitiert werden kann, lassen sich die o.g. Priorität bzgl. des Speichers zugunsten einer Überschusseinspeisung aufgeweichen. Ein entstehender "Überschuss" steht also ggf. nur deshalb zur Verfügung, weil die Ladeleistung des Speichers begrenzt wurde.
Davon ausgehend, dass die in SF bestimmte "optimale Ladeleistung" keine fest eingestellte Ladeleistung ist, sondern nur als oberer Grenze für die Ladeleistung eingestellt ist und der WR im o.g. Moduls "Eigennutzung" betrieben wird, ergibt sich folgendes: Bei der Berechnung der "optimalen Ladeleistung" in SF brauchen prognostizierte Verbräuche nicht berücksichtigt werden.

U.a. vor dem o.g. Hintergrund schlage ich vor, in SF ein Attribut zu definieren, mit denen angegeben werden kann zu welchem prozentualen Anteil SF Verbräuche bei der Bestimmung der "optimalen Ladeleistung" berücksichtigen sollen.

Edit:

Nachdem der gestrige Donnerstag (25.9.25) in meiner Region zu praktisch keiner nennenswerten PV-Leistung geführt hat, liegen bei mir heute (26.9.25) um 10:00 MESZ zwei 7,7 kWh fassende Speicher vor, die nur noch zu 6.6% gefüllt sind. Glücklicherweise werden seit ca. 0,5h ca. 3000 W an PV-Leistung produziert, von denen aber ein Großteil eingespeist wird, weil SF vorschlägt: Battery_ChargeOptTargetPower_0[12] = 250 W, was pinreduced entspricht. Später wird SF sicher Battery_ChargeOptTargetPower_0[12] noch erhöhen, aber ich würde mir wünschen, dass SF dies deutlich früher macht, damit das Ziel (möglichst gleichmäßige Ladung über den Tag im Sinne einer möglichst geringen maximalen Ladeleistung) auch erreicht wird.

Meines Erachtens ist es ungünstig, dass SF für den Fall, dass nicht genügend "Überschuss" vorhanden ist, Battery_ChargeOptTargetPower_XX auf pinreduced setzt, insb. dann, wenn Battery_ChargeOptTargetPower_XX dem WR als maximale Leistung genannt wird, mit dem er einen Speicher laden soll. Da aber Zwangsladungen (auch in Hinblick auf 14a) auf einen möglichst geringen Wert limitiert werden sollten, schlage ich vor, Battery_ChargeOptTargetPower_XX auf pinreduced nur für denn Fall, dass eine Speicher unter lowSoc fällt, zu setzen (also wenn Battery_ChargeRequest_XX == 1).

Edit 2025/10/04:
Seit der Version 1.58.6 bietet SF die Möglichkeit, prognostizierte Verbräuche nicht mehr komplett bei der Bestimmung der "optimalen Ladeleistung" zu berücksichtigen, sondern nur noch zu einem prozentualen Anteil. Hierzu muss im Attribut ctrlBatSocManagementXX der ein Key/Value-Paar weightOwnUse=<Percentage> vorhanden und entsprechend gesetzt werden.
So führt beispielsweise weightOwnUse=100 dazu, dass bei der Bestimmung der optimalen Ladeleistung prognostizierte Verbräuche überhaupt nicht mehr berücksichtigt werden. Eine derartige Einstellung kann z.B. sinnvoll sein, wenn alle ansonsten täglich laufende Verbraucher zugunsten einer Batterieladung ausgeschaltet werden können.
In der weiteren Entwicklung von SF könnten regelmäßig laufende Verbraucher, die fallweise ausgeschaltet werden können, in der Ladeplanung noch spezifischer berücksichtigt werden. Dies setzt aber voraus, dass eine Datenbasis geschaffen wird, in denen jedem Verbraucher ein Verbrauchskontingent im Sinne eine Ressource zugeteilt wird, die er a) selber wieder abgeben kann und b) die für den Fall, dass es sich um eine entziehbare Ressource handelt, auch von einem EMS entzogen werden kann.

[satempfaenger]

Hallo, erst mal dank für SF.
Mit der neusten Version werden alle par Sekunden vom Reading: Battery_ChargeOptTargetPower_01 Events erzeugt.
2025-09-24_10:36:36 2500
2025-09-24_10:36:36 3000
2025-09-24_10:36:39 2500
2025-09-24_10:36:39 3000

Muß ich da noch Einstellungen anpassen?

[DS_Starter]

Mit der neusten Version werden alle par Sekunden vom Reading: Battery_ChargeOptTargetPower_01 Events erzeugt.
Muß ich da noch Einstellungen anpassen?

Nein, das muß ich reparieren bzw. habe es bereits getan.
Du kannst die V 1.58.5 aus meinem contrib laden.

Alternativ/ergänzend kannst du nutzen:

Code Auswählen Erweitern

attr ... event-min-interval Battery_ChargeOptTargetPower_01:300
Das bietet sich hier an und bei mir habe ich es so gesetzt (weswegen ich auch die Events nicht gesehen habe).

LG,
Heiko

[DS_Starter]

Davon ausgehend, dass die in SF bestimmte "optimale Ladeleistung" keine fest eingestellte Ladeleistung ist, sondern nur als oberer Grenze für die Ladeleistung eingestellt ist und der WR im o.g. Moduls "Eigennutzung" betrieben wird, ergibt sich folgendes: Bei der Berechnung der "optimalen Ladeleistung" in SF brauchen prognostizierte Verbräuche nicht berücksichtigt werden.

U.a. vor dem o.g. Hintergrund schlage ich vor, in SF ein Attribut zu definieren, mit denen angegeben werden kann zu welchem prozentualen Anteil SF Verbräuche bei der Bestimmung der "optimalen Ladeleistung" berücksichtigen sollen.

Ich mache erstmal bisschen Urlaub, danach schauen wir uns das mal an.

[satempfaenger]

Mit der neusten Version werden alle par Sekunden vom Reading: Battery_ChargeOptTargetPower_01 Events erzeugt.
Muß ich da noch Einstellungen anpassen?

Nein, das muß ich reparieren bzw. habe es bereits getan.
Du kannst die V 1.58.5 aus meinem contrib laden.

Alternativ/ergänzend kannst du nutzen:

Code Auswählen Erweitern

attr ... event-min-interval Battery_ChargeOptTargetPower_01:300
Das bietet sich hier an und bei mir habe ich es so gesetzt (weswegen ich auch die Events nicht gesehen habe).

LG,
Heiko

Hallo Heiko,meine Einstellungen waren schon entsprechend:
event-min-interval .*:300
event-on-change-reading .*
Mit der Version 1.58.5 ist die Eventerzeugung von Battery_ChargeOptTargetPower_01 nun wie erwartet.
Die Events von Tomorrow_HourXX_PVforecast kommen auch noch sehr oft, trotz der obigen Einstellungen.

Aber erst mal einen erholsamen Urlaub.

VG Wolfgang

[tomcat.x]

event-min-interval .*:300
event-on-change-reading .*

Die sind per oder verknüptft, das heißt bei einer Änderung kommt immer ein Event, nur (auch) ohne Änderung erst nach 5 Minuten.

[celle]

Hallo zusammen,

man kann ja über ctrlNextDayForecastReadings Readings für den nächsten Tag anlegen. Das scheint aber nicht richtig zu funktionieren. Er scheint dort Werte von übermorgen einzutragen. Ich gabe den Code jetzt so gepatcht.

Code Auswählen Erweitern

diff -u 76_SolarForecast.pm 76_SolarForecast.pm.org
--- 76_SolarForecast.pm 2025-09-27 14:58:28.351951115 +0200
+++ 76_SolarForecast.pm.org     2025-09-27 14:58:14.035480104 +0200
@@ -14043,7 +14043,6 @@
       my $pvfc = NexthoursVal ($hash, $idx, 'pvfc', 0);

       storeReading ('Tomorrow_Hour'.$hod.'_PVforecast', $pvfc.' Wh');
-      last if($hods =~ /$hod$/xs)
   }

 return;


Ist das so ok, oder wie geht das besser?

[DS_Starter]

man kann ja über ctrlNextDayForecastReadings Readings für den nächsten Tag anlegen. Das scheint aber nicht richtig zu funktionieren. Er scheint dort Werte von übermorgen einzutragen.

Unlängst habe ich die Vorhersagewerte auf 72h=3d erweitert. Die Anpassung dieser Funktion habe ich wohl übersehen.

Das offizielle CheckIn der V 1.58.6 mache ich erst nach meinem Urlaub. Aber wer es eilig hat und diese Funktion nutzt, kann die gefixte Version aus meinem contrib sofort laden.
Aber daran denken die Version enthält aktuell folgende Änderungen:

- das Reading Battery_ChargeRecommended_XX ist entfernt
- Bugfix ctrlNextDayForecastReadings zur Anzeige der Werte des morgigen Tages anstatt von Übermorgen

@Wolfgang, der Fix sollte auch dein Problem mit den Events von Tomorrow_HourXX_PVforecast lösen.
@celle, dann siehst du auch wie der Fix im Code aussieht.

LG,
Heiko