Leistungsprognose für Wechselrichter

Tomk · 21 Januar 2024, 06:20:14

Danke für deine Antwort. Und ja, die Kriterien sind wirklich schwierig festzulegen. Bei mir ist es aktuell eindeutig: anstatt 5-7kw kommen gerade 50-70watt an mit 10-30cm Schnee auf dem Dach. Bis jetzt war der jetzt so das der schnee irgendwann abrutscht und dann schlagartig wieder Leistung ankommt.
Zur Not könnte man auch ein manuelles flag setzen, für Vorübergehenden Produktionsstopp aufgrund von Schnee oder sonstigen defekten.

DS_Starter · 21 Januar 2024, 08:10:07

Guten Morgen,

ja ist bei genauer Betrachtung nicht so simpel.
Deswegen tendiere ich dazu den Setter pvCorrectionFactor_Auto mit einem "noLearning" zu erweitern.
Dann kann man per Automation beliebig in diesen Modus schalten wenn es angebracht erscheint.

LG,
Heiko

Tomk · 21 Januar 2024, 10:44:29

Aber das verhindert nur das verlernen und nicht die "falsche" Prognose, richtig?

DS_Starter · 21 Januar 2024, 10:50:19

ZitatAber das verhindert nur das verlernen und nicht die "falsche" Prognose, richtig?

Ja, das stimmt.
Wenn man wegen bestimmten Ereignissen wie Anlagendefekt oder abnormen Wetterbedingungen quasi das ganze Modul temporär außer Betrieb nehmen möchte sodaß auch keine Verbraucher/Batterie geplant/geschaltet werden, eignet sich eher das Attr disable=1.

Dann käme vermutlich der Wunsch auf, einen Setter active/inactive wie beim at-Modul zu haben um dynamisch per Skript, DOIF etc. umschalten zu können ohne die Konfiguration speichern zu müssen.

kask · 21 Januar 2024, 11:48:54

Ich denke auch das es das beste und sicherste wäre. Wenn einer dann genug Daten gesammelt hat wie es bei Ihm funktioniert, dann könnte man immer noch abwägen das zu implementieren bei bedarf. Aber für mal eben einbasteln gibt es zuviele Unstimmigkeiten für die breite Masse.
Eventuell könnte man schon einmal ein Rollback von 24h einpflegen, denn wenn man feststellt das die Werte unbrauchbar sind, dann ist es schon zu spät. Und es wurden bereits Werte angepasst.
Wäre sicher auch einfach zu lösen in dem das Modul bei z.B. Sunset die Historydaten wegspeichert (kopiert).
Z.B. "PVH_SolarForecast_Forecast" >> "PVH_SolarForecast_Forecast_past1day".
So könnte man ein rollback über mehrere Tage auch einfach realisieren.

Für 3 Tage z.B.:
"PVH_SolarForecast_Forecast_past2day" >> "PVH_SolarForecast_Forecast_past3day"
"PVH_SolarForecast_Forecast_past1day" >> "PVH_SolarForecast_Forecast_past2day"
"PVH_SolarForecast_Forecast" >> "PVH_SolarForecast_Forecast_past1day"

Hätte man halt ein paar Files mehr im Ordner.

Und Reverse, also Rollback laden, halt umgekehrt. Ich würde allerdings dabei die Rollbacks nicht alle überschreiben, sondern nur das was man haben will als aktuelles laden.
Mit einem schicken Dateinamen kann man das dann theoretisch auch ganz einfach eine dynamische Anzahl von "backups" realisieren.

kask · 21 Januar 2024, 11:52:57

Das Modul ist Klasse aber ohne gute Backup Strategie, versemmelt man sich die History ganz schnell.
Habe ich leider schon mehrmals gehabt, gerade wenn man am rumprobieren/testen/optimieren ist.

DS_Starter · 21 Januar 2024, 13:06:14

Eine rollback Funktionalität ist eine gut Idee! Da muß ich aber noch etwas Hirnschmalz versenken weil es nicht nur die pvHistory betrifft, sondern auch die pvCircular. Und es bestehen Beziehungen zueinander.

Ich denke eine schrittweise Vorgehensweise der Implemntierung macht Sinn damit auch alles reibungslos ausgerollt werden kann:

1. ich implementiere eine noLearning Option. Damit kann man die Weiterschreibung von Korrekturfaktoren bzw. das AI-Lerning abschalten.

2. Wenn von euch gewünscht kommt ein Setting active/Inactive dazu als Ergänzung zu disable

3. die Anregung von kask bzgl. einer rollback Funktionalität

Tomk · 21 Januar 2024, 13:22:26

Ich wäre für den Punkt 2 wirklich dankbar

TheTrumpeter · 22 Januar 2024, 08:26:03

Zitat von: DS_Starter am 15 Januar 2024, 22:19:17Die wichtigste Neuerung ist im Consumer Management. Nach der initialen Planung erfolgt ein Review der Planungsdaten jedes Consumers alle 30 Minuten (xx:15, xx:45) sofern der Consumer noch nicht gestarted wurde (also nur planned) bzw. suspended (ausgesetzt wegen zu wenig erwarteten Überschuß).
Es erfolgt in dem Fall eine Neuberechnung mit den dann verfügbaren Vorhersagedaten.

Durch das neue Feature bekommt das Setzen der "notbefore" und "notafter" Attribute bei den Consumern in meinem Anwendungsfall nun plötzlich Bedeutung.

Das Warmwasser lasse ich mit SolarForecast aufheizen, abhängig von der Speichertemperatur, der Verbraucher ist ein "must" Verbraucher. Es ist ausreichend den Speicher 1x täglich auf die Solltemperatur zu bringen. Selbst wenn die Temperatur beim Speicherfühler im Laufe des Tages unter die Schwelle sinkt, ist keine erneute Einplanung nötig. (Falls ausreichend Überschuss vorhanden ist, kann es trotzdem erfolgen.) Mit der alten Verbrauchsplanung war das immer gegeben, weil die automatische Planung um die Mittagszeit war und danach nicht erneut bewertet wurde.
Gestern ist dann die Temperatur offenbar kurz vor 16:15 unter die Schwelle gesunken, sodass SolarForecast dann gleich nochmal nachgeheizt hat, obwohl es nicht erforderlich war und natürlich auch kein PV-Überschuss mehr vorhanden war.

Nun möchte ich mit "notbefore" und "notafter" verhindern, dass ein Start früher/später als 90min nach/vor Sonnenauf-/-untergang passiert.
Allerdings sind da lt. CommandRef nur Stundenwerte zulässig.
Frage 1: Werden da Perl-Ausdrücke akzeptiert? (Habe mal einen Perl-Ausdruck reingeschrieben, der die Stunde 90min nach/vor Sonnenauf-/-untergang liefert, was aber recht ungenau ist.)
Frage 2: Ließe sich das auf die volle Uhrzeit umbauen? Durch die kontinuierliche Planungsüberprüfung 2x pro Stunde gewinnt das meiner Meinung nach etwas an Bedeutung.

Nachtrag:
Frage 1: Offenbar werden keine Perl-Ausdrucke akzeptiert, denn da war immer "Start 00:00" und "Ende 01:00". Mit "normalen" Stunden wird's wieder ordentlich geplant.

fichtennadel · 22 Januar 2024, 09:24:15

Zitat von: DS_Starter am 20 Januar 2024, 19:06:34
ZitatKann man nicht bei Temperaturen dauerhaft unter null und einer Erzeugung kleiner 5% automatisch von Schnee ausgehen und die Prognose entsprechend anpassen sowie den lernalgo stoppen?

... kann ich schon implementieren. Nur was versteht man unter "dauerhaft" und wo zieht man die Grenze zu "vorübergehend"?
Und wie steht es mit der Schneebedeckung wenn es kleiner 8% aber größer 5% sind? Liegt dann kein Schnee?
Die Frage kann man beliebig variieren .... was ist mit Schnee wenn die Erzeugung zwischen 5% und 15%? Nur ein Teil der Module bedeckt oder "dünne" Schneedecke?

Bei mir ist selbst eine geringe Schneebedeckung ein Leistungsverlust von 99% (sehr geringer Aufstellwinkel auf Grund der Dachform).

Ich würde das nicht an externen Faktoren aufhängen und "dauerhaft"/"vorübergehend", sondern am Ergebnis je Stunde: PV Ertrag der Stunde im Vergleich zum Vortag (bzw. letzten Tag mit "gültigem" Wert) und das als konfigurierbaren Faktor.

Ist der Ertrag der vergangenen Stunde kleiner als die des Vortages mal dem Faktor, wird sie nicht berücksichtigt.

DS_Starter · 22 Januar 2024, 18:36:18

ZitatNun möchte ich mit "notbefore" und "notafter" verhindern, dass ein Start früher/später als 90min nach/vor Sonnenauf-/-untergang passiert.
Allerdings sind da lt. CommandRef nur Stundenwerte zulässig.
Frage 1: Werden da Perl-Ausdrücke akzeptiert? (Habe mal einen Perl-Ausdruck reingeschrieben, der die Stunde 90min nach/vor Sonnenauf-/-untergang liefert, was aber recht ungenau ist.)
Frage 2: Ließe sich das auf die volle Uhrzeit umbauen? Durch die kontinuierliche Planungsüberprüfung 2x pro Stunde gewinnt das meiner Meinung nach etwas an Bedeutung.

Zu Frage1: Nein, hattest du dann auch schon angemerkt.
Zu Frage2: Im Prinzip könnte ich den Ausdruck erweitern, also hh:mm statt bisher nur hh. Müßte es natürlich nochmal prüfen wieviel Aufwand es verursacht und ob der gerechtfertigt wäre.

ZitatIch würde das nicht an externen Faktoren aufhängen und "dauerhaft"/"vorübergehend", sondern am Ergebnis je Stunde: PV Ertrag der Stunde im Vergleich zum Vortag (bzw. letzten Tag mit "gültigem" Wert) und das als konfigurierbaren Faktor.

Ist der Ertrag der vergangenen Stunde kleiner als die des Vortages mal dem Faktor, wird sie nicht berücksichtigt.

Werde ich mir durch den Kopf gehen lassen.
Spontan gebe ich aber zu bedenken, dass auch "normale" Bewölkungserscheinungen in Verbindung mit Regen starke Abweichungen der Erzeugung nach unten bewirken können die allerdings durchaus registriert werden sollten da die Bewölkung bei den komplexen Berechnungsfaktoren bzw. KI mit eingeht und gemerkt wird.

TheTrumpeter · 22 Januar 2024, 18:43:19

Zitat von: DS_Starter am 22 Januar 2024, 18:36:18Zu Frage1: Nein, hattest du dann auch schon angemerkt.
Zu Frage2: Im Prinzip könnte ich den Ausdruck erweitern, also hh:mm statt bisher nur hh. Müßte es natürlich nochmal prüfen wieviel Aufwand es verursacht und ob der gerechtfertigt wäre.

Die Kombination hätte Charme.
Das Attribut des/der Verbraucherdefinition jeden Tag (oder 1x pro Woche, aber im Endeffekt egal) mit einem ,,at" nach Mitternacht neu zu setzen, um die Zeit abhängig vom Sonnenaufgang/-Untergang zu setzen ginge natürlich auch, wäre aber nicht so schlank.

DS_Starter · 22 Januar 2024, 21:09:27

Hallo zusammen,

der Punkt 1 aus #3486 ist umgesetzt und morgen früh im Update:

noLearning:
Mit dieser Option wird die erzeugte PV Energie der aktuellen Stunde vom Lernprozess (Korrekturfaktoren sowie KI) ausgeschlossen.
Die zuvor eingestellte Autokorrekturmethode wird weiterhin angewendet.

Code Auswählen

Das Attribut des/der Verbraucherdefinition jeden Tag (oder 1x pro Woche, aber im Endeffekt egal) mit einem ,,at" nach Mitternacht neu zu setzen, um die Zeit abhängig vom Sonnenaufgang/-Untergang zu setzen ginge natürlich auch, wäre aber nicht so schlank.

Das ist wirklich nicht elegant und erzeugt Gänsehaut.

Ich schaue es mir mit an.

kask · 22 Januar 2024, 22:44:03

ZitatIch würde das nicht an externen Faktoren aufhängen und "dauerhaft"/"vorübergehend", sondern am Ergebnis je Stunde: PV Ertrag der Stunde im Vergleich zum Vortag (bzw. letzten Tag mit "gültigem" Wert) und das als konfigurierbaren Faktor.

Ich glaube der Stundenweise ansatz ist schon garnicht so schlecht.

Eine Idee könnte sein das man eine zweite frei definierte Schwelle eintragen kann. Die maximale erlaubte Korrekturfaktor anpassung ist ja schon enthalten.
Jetzt könnte man eine zweite Schwelle angeben, wenn diese überschritten wird (werden würde ohne die schon vorhandene Schwelle), wird der wert nicht verarbeitet bzw. verworfen und der letzt gültige Wert (also keine korrektur) wird übernommen.

Das wäre bei Wolken mit Regen und straffer schwelle ein einstündiger Ausreißerwert. Auf Dauer sollte es weniger beeinflussen wie ein ganzer verworfener Tag.
Und wird sich, so denke ich, "wegkompensieren". Würde auch ein einstündigen System-Shutdown (WR, Speicher etc.) so fast unbemerkt nicht sichtbar machen.

DS_Starter · 22 Januar 2024, 22:53:51

ZitatJetzt könnte man eine zweite Schwelle angeben, wenn diese überschritten wird (werden würde ohne die schon vorhandene Schwelle), wird der wert nicht verarbeitet bzw. verworfen und der letzt gültige Wert (also keine korrektur) wird übernommen.

~~fichtennadel hatte eher eine Schwellenwertunterschreitung im Blick, du wie es sich liest eine Überschreitung. Oder hast du dich verschrieben?~~
Vergiss es .... ZWEITE frei definierte Schwelle ...