76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[tupol]

Die KI ist ein Decision Tree (AI::DecisionTree).
Sie kann im Prinzip nur Vorhersagen auf Grund von bereits erlernten Parametern und deren Beziehungen zueinander liefern.

Das ist dann etwas anderes als reine Statistik. Wobei ich mich frage, wo sie besser ist. Wenn ich es richtig verstehe, versucht der Algorithmus für ein Parameterset den Most-Frequent-Wert zu bestimmen, dass wäre dann der Modus.
Es gibt da übrigens auch den Parameter "noise_mode". Der hört sich irgendwie nach "Schneefall" an. Aber prinzipiell kann man auch selber einfach alles weg lassen, was nicht über ein bestimmtes prozentuales Limit kommt. Der "noise_mode" kommt vermutlich besser mit ständigen Abweichungen z.B. durch Verschattung zurecht.

[DS_Starter]

Es gibt da übrigens auch den Parameter "noise_mode". Der hört sich irgendwie nach "Schneefall" an.

Nö ... Ist noise_mode auf fatal (Standardeinstellung) gesetzt, löst die train()-Methode eine Ausnahme (die -> FHEM stirbt) aus. Wenn noise_mode auf pick_best eingestellt ist, wird das häufigste Ergebnis an jedem verrauschten Knoten ausgewählt.
Ich verwende 'pick_best' 

[DS_Starter]

Hallo Thomas,

Wenn man nun für jede Stunde des Tages manuell eine Vorgabe machen könnte, die dann genommen wird, falls noch kein Wert berechnet ist, wäre das aus meiner Sicht eine bessere Ausgangsbasis.

Ich habe die Funktionalität der Setter pvCorrectionFactor_XX aufgewertet:

pvCorrectionFactor_XX <Zahl>

Voreinstellung des Korrekturfaktors für die Stunde XX des Tages.
(default: 1.0)

In Abhängigkeit vom Setting pvCorrectionFactor_Auto ('off' bzw. 'on_.*') erfolgt eine statische oder dynamische Voreinstellung:

    off    Der eingestellte Korrekturfaktor wird durch die Autokorrektur nicht überschrieben.
        Im Reading pvCorrectionFactor_XX wird der Status durch den Zusatz 'manual fix' signalisiert.
       
    on_.*    Der eingestellte Korrekturfaktor wird durch die Autokorrektur bzw. KI überschrieben
        sofern ein berechneter Korrekturwert im System verfügbar ist.
        Im Reading pvCorrectionFactor_XX wird der Status durch den Zusatz 'manual flex' signalisiert.

Dadurch kannst du deinen use Case abbilden. D.h. der voreingestellte Korrekturfaktor für Stunde XX wird solange verwendet bis ein berechneter Faktor (oder KI Wert) vom System bereitgestellt wird sofern man in
pvCorrectionFactor_Auto einen Modus beginnend mit "on_" eingestellt hat.

Im Debugmodus pvCorrectionRead sieht man eine entsprechende Ausschrift:

Code Auswählen Erweitern

...
2024.06.17 22:20:51.086 1: SolTem DEBUG> read parameters - fd: 1, hod: 16, Sun Altitude Bin: 50, Cloud range: 70, corrf: 1.00, quality: -
2024.06.17 22:20:51.090 1: SolTem DEBUG> use 'manual flex' - fd: 1, hod: 17, Sun Altitude Bin: 45, Cloud range: 70, corrf: 0.80, quality: -
2024.06.17 22:20:51.094 1: SolTem DEBUG> read parameters - fd: 1, hod: 18, Sun Altitude Bin: 35, Cloud range: 75, corrf: 1.07, quality: 0.88
2024.06.17 22:20:51.099 1: SolTem DEBUG> read parameters - fd: 1, hod: 19, Sun Altitude Bin: 25, Cloud range: 75, corrf: 0.92, quality: 0.79
2024.06.17 22:20:51.103 1: SolTem DEBUG> use 'manual flex' - fd: 1, hod: 20, Sun Altitude Bin: 15, Cloud range: 75, corrf: 0.90, quality: 0.76
2024.06.17 22:20:51.108 1: SolTem DEBUG> use 'manual flex' - fd: 1, hod: 21, Sun Altitude Bin: 5, Cloud range: 80, corrf: 1.50, quality: -
2024.06.17 22:20:51.112 1: SolTem DEBUG> read parameters - fd: 1, hod: 22, Sun Altitude Bin: 0, Cloud range: 75, corrf: 1.50, quality: 0.27
2024.06.17 22:20:51.116 1: SolTem DEBUG> read parameters - fd: 1, hod: 23, Sun Altitude Bin: 0, Cloud range: 80, corrf: 1.00, quality: -
2024.06.17 22:20:51.120 1: SolTem DEBUG> read parameters - fd: 1, hod: 24, Sun Altitude Bin: 0, Cloud range: 00, corrf: 1.00, quality: -
...

Ich habe die Version 1.29.2 zunächst in meinem contrib zum Download bereitgestellt. Ich möchte mir auch noch den morgigen Tag anschauen wie sich das Ganze verhält.

LG,
Heiko

[yep_DD]

Hallo zusammen,

ich wollte bei mir Open Meteo nutzen und beim Umstellen der setupRadiation-API bekomme ich den Fehler: Please complete command "set PV_Forecast setupStringDeclination". Habe ich eventuell bei einem Update nicht auf "save config" gedrückt? Oder wo ist mein Denkfehler?

Grüße

[DS_Starter]

Ja, ist sehr wahrscheinlich dass du nicht gespeichert hast.
Kein Problem, gebe die Stringdaten in dem Setter neu ein.

LG

[tomcat.x]

Hallo Heiko,

Ich habe die Funktionalität der Setter pvCorrectionFactor_XX aufgewertet:

genial. Nicht nur eingebaut, aus meiner Sicht auch auf optimale Weise, ohne zusätzliche Einstellungen. Man könnte so ohne Automatik mit festen Werten starten und später einfach umstellen und die als Default weiterverwenden.

Ich habe das eben installiert und teste auch. Die beiden Stunden ohne Faktor von heute sind leider (oder zum Glück) verschwunden, weil sich die Wettervorhersage wieder geändert hat. Aber für morgen gibt es zwei, da habe ich schon mal einen Wert eingetragen und schaue mal nach der nächsten Kalkulation. Den Rest trage ich auch noch ein.

Zur Verlässlichkeit der Wettervorhersage: Ich teste gerade neue Apps auf dem Handy. Hat nicht direkt mit der PV-Vorhersage zu tun, aber heute könnte ich mir z. B. als Höchsttemperatur 25, 27 oder 29 Grad aussuchen. Für den Kurzurlaub am kommenden Wochenende schwanke ich noch zwischen Wellness bei Regen oder Radfahren im Sonnenschein 

Viele Grüße
Thomas

[yep_DD]

Ich habe da leider keinen Setter für und wenn ich "set PV_Forecast setupStringDeclination XX" eingebe, dann kommt "The specified inclination angle has an incorrect format"

[DS_Starter]

Das der Setter fehlt, kann an der verwendeten API liegen. Das Attr setupRadiationAPI löschen, den Setter ausführen und das Attr setupRadiationAPI wieder wie gewünscht setzen. Welche API nutzt du?

[yep_DD]

Daran lag es, ich bin von DWD_OpenData umgestiegen auf Open Meteo. Danke dir. Ich habe jetzt ctrlWeatherDev1 auf OpenMeteoDWD-API und die setupRadiationAPI gelöscht und neu gesetzt. Im anschließenden "Guide" hat er dann die Setter auch korrekt definiert. Das Open Meteo device nutze ich über HTTPMOD. Wie kommt SolarForecast an die Daten oder fragt er sie selber ab?

[DS_Starter]

Sehr schön.
Das Modul hat dafür eine eigene Requestverwaltung. Nur bei DWD_OpenData wird auf ein DWD Device gesetzt und von diesem die Daten gezogen.

[yep_DD]

Super, wirklich klasse.

[tomcat.x]

Ich habe das eben installiert und teste auch

Zwei Sachen sind mir auf- bzw eingefallen: Man sieht in pvCorrectionFactor_xx jetzt die Neuberechnung nicht mehr so schön. Und da das Setter und keine Attribute sind, kann man es nicht mit Copy in neue (Test-) Geräte übernehmen. Aber das ist nicht so entscheidend.

Von der Nutzung der Werte her sieht es für mich gut aus. Und in den vorhergesagten Werten sind die Ausreißer bei fehlenden Korrekturfaktoren weg. Leider ist die Vorhersage heute nicht wegen denen völlig daneben. Vorhin hat es mal geregnet, aber nur draußen, in keiner meiner 3 Test-Apps

[bismosa]

Hallo!

Ich versuche mich gerade in das Modul einzuarbeiten. Echt super und man ist unabhängig vom externen Sunny-Portal 
Es sind natürlich ein paar Fragen aufgekommen, die ich mir nicht beantworten konnte...

Ich möchte (wenn es denn doch noch warm wird) meine Poolpumpe mit dem Modul steuern. Dafür habe ich mir erstmal 2 Testverbraucher (dummys) angelegt und 2 consumer erstellt:

Code Auswählen Erweitern

attr SF consumer01 du_Poolpumpe type=other power=1500 \
mode=must mintime=120 | SunPath \
notbefore=09:00 notafter=18:00\
interruptable=1\
locktime=180:180\
on=on off=off
attr SF consumer02 du_Poolpumpe2 type=other power=500 \
mode=must mintime=120 | SunPath \
notbefore=09:00 notafter=18:00\
interruptable=1\
locktime=180:180\
on=on off=off

1.) Ich möchte eigentlich das die Poolpumpe ruhig schon früh startet. Also ab 9:00Uhr, wenn dann genügend Strom da ist.
Bisher ist die Zeitplanung eher Nachmittags, wenn auch der meiste Überschuss zu erwarten ist (aber genug Überschuss ist auch bereits Vormittags vorhanden)
Kann ich das beeinflussen? Auch werden bisher beide Verbraucher immer zur gleichen Zeit eingeplant...obwohl der zu erwartende Verbrauch doch stark voneinander abweicht. Ist das "normal"?

2.) Gibt es auch eine Möglichkeit ein "maxtime" zu setzen? Also
mintime=mindestens(wenn wenig Strom vorhanden)
maxtime=wenn genug Überschuss vorhanden ist, dann gerne so lange laufen lassen...

3.) Die schön übersichtliche Übersichtsseite: Eine Aktualisierung der Werte erfolgt bei mir nur, wenn ich die ganze Seite neu lade. Ist sicherlich so gewollt?

4.) Für FTUI2 gibt es schon eine schöne Vorlage um die Übersicht auch auf dem Tablet anzuzeigen. Gibt es da auch schon was für FTUI3?

Danke für die tolle Arbeit!

Gruß
Bismosa

[DS_Starter]

Hallo Bismosa,

Ich möchte eigentlich das die Poolpumpe ruhig schon früh startet. Also ab 9:00Uhr, wenn dann genügend Strom da ist.
Kann ich das beeinflussen?

Ja. Du würdest dann notafter=09:00 setzen und z.B. mintime=540. Dann würde die Einplanung in der Zeit 09:00 bis 18:00 erfolgen. Die Einplanung ist nicht zwangsläufig gleichzusetzen mit der tatsächlichen Startzeit. Die Einschaltung des Verbrauchers innerhalb der Planungszeit ist noch von mode und anderen Parametern wie swoncond, interruptable, etc. abhängig.

Gibt es auch eine Möglichkeit ein "maxtime" zu setzen? Also
mintime=mindestens(wenn wenig Strom vorhanden)
maxtime=wenn genug Überschuss vorhanden ist, dann gerne so lange laufen lassen...

Der Name "mintime" ist von mir leider etwas unglücklich gewählt. Er beschreibt die Einplanungszeit in Minuten (min=Minuten) wie in der Hilfe angegeben. Wenn du z.B. mintime=SunPath angibst, wird der gesamte Sonnentag als mögliches Schalt/Lauffenster verwendet unter der Prämisse, dass genügend Überschuß vorhanden ist. Durch die Verwendung von interruptable kann man den Verbraucher nach dem Start bei ungenügend PV unterbrechen lassen und wenn wieder genügend Überschuß vorhanden ist, weiterlaufen lassen.

Die schön übersichtliche Übersichtsseite: Eine Aktualisierung der Werte erfolgt bei mir nur, wenn ich die ganze Seite neu lade. Ist sicherlich so gewollt?

Nein. Die aktualisiert bei jedem Update. Allerdings muß "state" einen Event erzeugen, was im Normalfall so ist. In der Detailansicht erfolgt keine Aktualisierung der Ansicht.

Für FTUI2 gibt es schon eine schöne Vorlage um die Übersicht auch auf dem Tablet anzuzeigen. Gibt es da auch schon was für FTUI3?

Dafür habe ich noch keine Template bereitgestellt (nutze kein FTUI). Aber es gibt glaube ich User die FTUI3 nutzen wenn ich mich nicht irre. Vllt. meldet sich jemand mal dazu.
Ich nehem auch gerne einen Prototypen entgegen. Bin mit JavaScript nicht so familiär. 

LG,
Heiko

[DS_Starter]

@Thomas,

Zwei Sachen sind mir auf- bzw eingefallen: Man sieht in pvCorrectionFactor_xx jetzt die Neuberechnung nicht mehr so schön.

Da habe ich nachgebessert.
In meinem Contrib liegt ein Update bereit.
Jetzt wird bei der Berechnung eines auf "manual flex" gesetzten pvCorrectionFactors das Berechnungsergebnis als "flexmatic result" ausgedruckt.

Code Auswählen Erweitern

pvCorrectionFactor_20  1.2 (manual flex) / flexmatic result 0.85 for Sun Alt range: 15, Cloud range: 75, Days in range: 2
Wenn ich es richtig gemacht habe, erfolgt in der Nachtverarbeitung ein Rücksetzen des Readinginhaltes auf:

Code Auswählen Erweitern

pvCorrectionFactor_20  1.2 (manual flex)
damit morgen die Voreinstellung wieder zieht (unter der Bedingung dass kein passendes Berechnungsergebnis im System gespeichert ist).

Und da das Setter und keine Attribute sind, kann man es nicht mit Copy in neue (Test-) Geräte übernehmen.

Aber man kann alle Einstellungen in ein kopiertes Device übernehmen: ->
https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Backup_und_Wiederherstellung_der_Moduldaten

LG,
Heiko