76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

DS_Starter · 02 Juni 2024, 09:14:20

Moin,

das Modul kann man durchaus schon laufen lassen. Bei solchen Gegebenheiten wie bei dir wird bei sonnigen Tagen eine größere Differenz zwischen Prognose und realer Erzeugung auftreten sofern die Erzeugung gedrosselt/vermieden wird damit keine Einspeisung erfolgt.
Bei meiner Anlage gibt es auch einen Teil der nicht einspeist. Durch gewisse Optimierung bei der Batterieladung kann ich bei mir den Fehler minimieren, ansonsten muß ich damit leben da ich im Vorfeld nicht weiß wann eine Abregelung erfolgt und wieviel. Vllt. fällt mir dazu noch etwas zündendes ein.
Bei dir würde ich raten mit

Code Auswählen

set ... pvCorrectionFactor_Auto noLearning
den Lernmodus auszuschalten solange eine Abregelung möglich ist. Damit würden die (falschen) Erkenntnisse aus dem Lernprozess ausgeschlossen wenn du später den gewünschten Wert für pvCorrectionFactor_Auto einstellst wenn alles normal läuft.
Die Prognose an sich wird dadurch nicht beeinflusst, sie richtet sich nach der gewählten API.

kask · 02 Juni 2024, 09:32:11

@Mr.X

Erstmal "Hallo" und viel Spass mit der neuen Anlage und dem spannenden Vorhersagen.

Ob du limitiert einspeist ist dem Modul völlig egal.
Du brauchst mindestens 2 Messeinrichtungen um das Modul nutzen zu können. Ein Messmittel am Netzeingang und eines für deine PV-Leistung (meist Daten aus dem Wechselrichter).
Und dann kann es losgehen.

Ich denke allerdings anders als der Modulersteller das es auch mit dem limitieren auf Dauer funktionieren sollte da mit pvCorrectionFactor_Auto auch automatisch Verschattungen ausgebügelt werden. Klar ist die Vorhersage nicht so gut wie ohne. Aber brauchbar anpassen sollte sich das schon lassen könnte ich mir Vorstellen.
Zudem kommt bei wechselnden Lasten über den Tag noch eine weitere Unsicherheit rein. Sofern du aber einen einigermassen geregelten Verbrauch hast sollte es auch so einigermassen funktionieren. Dauert halt etwas länger der Lernprozess.

@DS_Starter
Um das Limitieren abfangen zu können müsste man doch einfach die PV-Capacity dynamsich anpassen für die nächste Stunde auf Consumptionforecast + Gridlimit.
Dazu wird in dem Moment des anpassens(PVforecast) falls das Gridlimit überschritten wird das learning deaktiviert. Bei nicht überschreitung der Einspeiseleistung wird gelernt. Könnte doch klappen.

DS_Starter · 02 Juni 2024, 09:56:25

ZitatIch denke allerdings anders als der Modulersteller das es auch mit dem limitieren auf Dauer funktionieren sollte da mit pvCorrectionFactor_Auto auch automatisch Verschattungen ausgebügelt werden.

Doch, der Meinung von kask bin auch

. Nur für den Anfang würde ich es so machen.

Zitat@DS_Starter
Um das Limitieren abfangen zu können müsste man doch einfach die PV-Capacity dynamsich anpassen für die nächste Stunde auf Consumptionforecast + Gridlimit.
Dazu wird in dem Moment des anpassens(PVforecast) falls das Gridlimit überschritten wird das learning deaktiviert. Bei nicht überschreitung der Einspeiseleistung wird gelernt. Könnte doch klappen.

Das liest sich ganz gut. Allerdings fehlt da noch die Batterie(lade)komponente. Sie geht im Moment des Ladens nicht in der Verbrauch und damit Consumptionforecast ein, vermindert/verhindert aber ein Herunterregeln der Anlage.
Aber der Ansatz an sich sieht nicht so schlecht aus.
Wenn ich mit meinen Umstellungen durch bin können wir das ja nochmal genauer betrachten und testen.

kask · 02 Juni 2024, 11:09:02

Ich habe eine andere Ladephilosophie wie du.
Was aber für beide Strategien funktionieren sollte wäre folgendes.

Wie wäre es mit einer weiteren Prognose? Die "BatteryUse" anhand der Vergangenheit (Laden.-Endladen).
Ähnlich wie der Consumptionforecast, die wäre allerdings positiv sowie negativ.
Damit könntest du den Limiter(PV-Capacity) auf Consumptionforecast + Gridlimit + BatterieUseforecast einpegeln. Nur so als Gedankengang.

DS_Starter · 02 Juni 2024, 11:16:55

Behalten wir mal im Hinterkopf. Wenn ich den Kopf wieder frei habe, holen wir die ganzen Ansätze und Gedanken nochmal raus. Kannst bis dahin gerne noch etwas sinnieren.
Dauert noch ein bisschen bis ich die ganzen Changes durch habe. Muß mich dabei ziemlich konzentrieren um alles sauber umzusetzen.

DS_Starter · 02 Juni 2024, 13:05:53

ZitatUm das Limitieren abfangen zu können müsste man doch einfach die PV-Capacity dynamsich anpassen ...

Gut das wir darüber gesprochen haben. Unter diesem Aspekt lasse ich nämlich die Setter modulePeakString, moduleAzimuth und moduleDeclination als Konfigurations-Readings bestehen. moduleAzimuth und moduleDeclination unter dem Gesichtspunkt dass es Nachführanlagen gibt die sich dem Sonnenstand entsprechend ausrichten.

DS_Starter · 02 Juni 2024, 14:52:51

@all,
die Umsetzung von Konfigurations-Setter in Attribute ist weiter fortgeschritten.

Umgesetzt ist jetzt currentBatteryDev in attr setupBatteryDev.
Der ganze Prozess läuft nach einem Restart! automatisch ab.

WICHTIG nach dem Restart mit "save config" die FHEM Konfiguration sichern da ein neues Attribut gesetzt und das alte Reading gelöscht wird.

Wer mag kann die neue V gleich aus meinem contrib ziehen und restarten. Ansonsten morgen früh im Update.

LG,
Heiko

Mr.X · 02 Juni 2024, 18:17:29

Danke für euren Input.

Das Modul lief heute schon mal, und da es zunächst doch ziemlich bewölkt war, ist die Batterie erst jetzt gerade kurz vor voll, d.h. bisher keine Abregelung (für morgen ist die Prognose nicht besser, aber die Batterie wird morgen Früh nicht leer sein, d.h. denke da läuft es in die Abregelung, Dienstag dann spätestens laut Wetterbericht). Die größte Unsicherheit scheinen da tatsächlich die Wetterdaten (Bewölkung) zu sein, während ich am Vormittag der Prognose deutlich hinterher war, hab ich am frühen Nachmittag als die Sonne raus kam deutlich aufgeholt- über den Tag sieht es im Moment gar nicht so schlecht aus. Allerdings sind natürlich die Korrekturfaktoren die er da jetzt für morgen annimmt auch nicht realistisch, wenn da nicht wieder genau die Sonne rauskommt, aber ich denke verstanden zu haben, dass sich das dann mit der Zeit alles nivelliert und dass das System eben lernt...

@kask: Die notwendigen Messdaten hab ich alle die das Modul haben will, auch die optionalen, habe ich alles angelegt und sollte passen.

Ich mag die graphische Darstellung des Moduls - toll gemacht.

Bin mir jetzt noch unschlüssig, ob ich wie von DS_Starter vorgeschlagen soll das Learning deaktivieren soll oder nicht... Mit einem "Reset" könnte ich aber nach dem Wegfall der Einspeisebeschränkung ja ohne Probleme wieder von vorne anfangen das System zu trainieren. ISt vermutlich dann der bessere Weg, als alles was er bis dahin gelernt hat dann nach und nach in Richtung der realistischeren Werte zu bewegen. Beim Nachbarn hat es 3 Monate gedauert bis die Stadtwerke den neuen Zähler eingebaut haben, d.h. da muss man vermutlich lange neue Daten füttern, bis es dann passt (daher wäre im Moment meine Tendenz im Moment laufen lassen und dann einen Reset zu machen...)

Nächstes WE kümmer ich mich dann mal um die "Consumer".

Vielen Dank für das Modul

kask · 02 Juni 2024, 19:21:04

ZitatBin mir jetzt noch unschlüssig, ob ich wie von DS_Starter vorgeschlagen soll das Learning deaktivieren soll oder nicht.

Welche API nimmst du? Je nach API kannst du dir einfach die Rawdefinition des vorhandenen SolarForecast device kopieren und das device umbenennen.
Dazu die korrespondierenden files in /opt/fhem/FHEM/FhemUtils/ mit dem abgeänderten neuen devicenamen kopieren.
Und dann beide Instancen parallel laufen lassen. Einmal ohne einmal mit autocorrection.
Dann kannst du entscheiden was besser passt bei dir.

Mr.X · 02 Juni 2024, 22:05:17

Das mit der API ist noch ein guter Punkt wo man (ich zumindest) als Anfänger nicht so recht weiß, hab ich keine Empfehlung gefunden. Sind die alle gleichwertig? Ich hab einfach mal OpenMeteoDWD genommen- weil es hier bei mir in der Nähe eine Messstation gibt die die Rad1h Werte zur Verfügung stellt...

kask · 03 Juni 2024, 19:09:17

Nunja, alle gleich!? Kann man sehen wie man will. Die einen funktionieren die anderen auch, nur nicht immer und bei jedem.
Das mußt du für dich rausfinden was am besten bei dir funktioniert, sofern du die API überhaupt nutzen kannst.
Die einen sind frei die anderen brauchen einen Account.
Eine brauch auch bestimmte Hardware damit diese geht (VictronVRM).

Ich denke OpenMeteoDWD ist schon ein guter start. Da auch mal die OpenMeteoEnsemble testen.
Für die SolCastAPI brauchst du bekanntlich einen Acccount da bekommst du max 10 Abfrage am Tag jetzt nur noch. Bei mehrerern Strings reduziert sich das ganze naürlich dann.
Die VictronVRM läuft wohl auch mit der SolCastAPI bzw. nutzt diese Angaben. Ich habe da denoch manchmal große Unterschiede.
Die DWD kann auch ganz brauchbar sein. Vermutlich liefert die dir auch Rad1H Werte da OpenMeteoDWD auch darauf abfeuert.
Bei mir bringen diese auch unterschiedliche Vorhersagen. Die Differenz beider zueinander ist nicht so groß. Aber vorhanden.
Die OpenMeteoWorld liefert bei mir 99% das gleiche Wie die OpenMeteoDWD. Vieleicht ist es bei dir anders.
Mit der ForecastSolarAPI bin ich so garnicht zufrieden. Musst du mal testen ob es bei dir vieleicht brauchbar ist.

Das Ranking bei mir/für mich ist:
sehr gut: SolCastAPI (mehrere Strings, Aber 2x50 Abfragen weil alte accounts. Wichtig ist die rooftops bei Solcast selbst richtig zu parametrieren!)
gut: OpenMeteoEnsemble
gut aber etwas schlechter: VictronVRM,DWD & restlichen OpenMeteo's
Reinfall: ForecastSolarAPI

Jetzt ist es auch so das bei unbeständigem Wetter bei mir die DWD-basierten besser treffen.
Das ist alles nicht so einfach

Ich habe alle API's parallel laufen und bastel mir einen Wert aus allen API's dividiert durch die Anzahl.
Dadurch habe ich im ganzen eine genauere Prognose.
Man darf nicht vergessen das diese Prognose auch DWD lastig ist, da 3 (DWD, OpenMeteoDWD, OpenMeteoWorld) der 6 (eigentlich 7 aber die ForecastSolarAPI verwurste ich da nicht mit) API's ziemlich identische Werte liefern. Was bei mir anscheinend sehr gut am Ende passt.

DS_Starter · 03 Juni 2024, 20:50:05

@all,
ein weiterer Schritt ist vorgenommen.

Umgesetzt ist jetzt currentInverterDev in attr setupInverterDev.
Der ganze Prozess läuft nach einem Restart! automatisch ab.

WICHTIG nach dem Restart mit "save config" die FHEM Konfiguration sichern da ein neues Attribut gesetzt und das alte Reading gelöscht wird.
Außerdem wird nach dem Update der Start der Autokorrektur technisch bedingt um 2h verzögert in der Grafik angezeigt. Das ist in dem Fall normal und kein Grund zur Beunruhigung. Nach 2h wird der Prozeß normal fortgesetzt.

Wer mag kann die neue V gleich aus meinem contrib ziehen und restarten. Ansonsten morgen früh im Update.