76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

DS_Starter

Nein. Ich meinte über die AI. In der Statistik werden ja große Ausreiser auch aussortiert und entweder mit dem Median gearbeitet oder mit der 2. und 3. Quartil.
Ja, nur was ist "groß"? Der Wert für "groß" ist bei einer 800W Peak Balkonanlage sicher ein anderer als bei einer 15 Kw Peak Anlage. Wenn die Anlage neu definiert ist und noch keine Erfahrungswerte vorliegen wird es auch schwierig. Ab einer bestimmten Anzahl von "Days in range", ich werfe mal empirisch 5 Tage in den Ring, könnte man eine Abweichung von größer +- 30% (empirisch) als Ausreißer definieren und vom Lernprozess ausschließen.
Das meinst du doch sicherlich, oder?
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

tupol

In % und konfigurierbar geht auch. Aber besser sind statistische Auswertungen wie 
  • den Median nehmen,
  • den Durchschnitt des 2. und 3. Quartil (= 50 % der Werte) berücksichtigen.
  • Meine Anlage hat im aktiven Zustand noch keinen Schnee gesehen. Ich vermute aber, der PV-Wert geht dann unter 10%. Das könntest Du auch einfach komplett ignorieren. Obere Ausreißer gibt es ja vermutlich nicht.
  • Der Modus geht evtl. auch, wenn nicht zu oft Schnee drauf liegt.

Ich weiß halt nicht, was die KI-Bibliothek hergibt. Eigentlich ist das ja ein normaler Vorfall, dass man Ausreißer hat. Vielleicht gibt es auch ein passendes Statistikmodul in Perl.
Beeinflussen sich benachbarte Werte gegenseitig, also z. B. der Sonnenstand 25° auch den Sonnenstand 30°?


DS_Starter

Statistische Auswertungen wie Median oder Quartile müsste ich selbst berechnen. Die KI hilft hier nicht weiter. Sie wird mit den real gemessenen Werten gelernt und liefert ein Ergebnis wenn sie wiederum mit Prognosen gefüttert wird.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

#738
@all,
ein weiterer Schritt der geplanten Umstellungen ist vorgenommen.

Umgesetzt ist jetzt
- Setter moduleAzimuth in setupStringAzimuth
- Setter moduleDeclination in setupStringDeclination
- Setter moduleRoofTops in Attr setupRoofTops

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.

Update morgen früh.

LG,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

SparcWolf

Moin Heiko,

Im fhem.log sind mir einige Warnungen aufgefallen:
2024.06.17 08:31:13 1: PERL WARNING: Use of uninitialized value $FHEM::SolarForecast::FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 11674.
2024.06.17 08:31:13 1: PERL WARNING: Use of uninitialized value $FHEM::SolarForecast::FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 11674.
2024.06.17 08:31:13 1: PERL WARNING: Use of uninitialized value $FHEM::SolarForecast::FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 11694.
2024.06.17 08:31:13 1: PERL WARNING: Use of uninitialized value $FHEM::SolarForecast::FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 11694.

Grüße,
  Guido.

DS_Starter

Moin Guido,

die Warnings gibt es bei mir zwar nicht, aber ich schaue mir das an.
Danke für die Info.

Grüße,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Henno

Hallo zusammen,

kann mir dieses Modul auch die Autarkie mit anzeigen?
Ich finde nicht dazu.
Klar kann man das mit einem extra Dummy oder sonst was rechnen, aber übersichtlicher wäre es wenn es hier direkt dabei wäre.

seayak

Hi Henno,

Du findest nativ im Modul das Reading "Current_AutarkyRate" und noch vieles andere mehr.

Viele Grüße!

Peter

tupol

Zitat von: DS_Starter am 16 Juni 2024, 23:27:58Statistische Auswertungen wie Median oder Quartile müsste ich selbst berechnen. Die KI hilft hier nicht weiter. Sie wird mit den real gemessenen Werten gelernt und liefert ein Ergebnis wenn sie wiederum mit Prognosen gefüttert wird.
OK. Dann bleibt nur die Variante mit der Aussortierung von zu kleinen Werten bei Minusgraden.

Ich habe noch nicht verstanden, wie die KI genau funktioniert. Bildet sie nur den Mittelwert aller eingespeisten Werte für eine Parametergruppe? Oder ist da auch noch eine Logik drin wie bei statistischen Vorhersagemodellen? Vielleicht kann man auch den Parameter "Schneefall" aus dem Wetterbericht mit aufnehmen? (Wobei es ja Leute gibt, die den Schnee von den Panelen fegen und das Abrutschen oder Schmelzen des Schnees auch nicht erfasst wird. Schwierig...)

DS_Starter

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.

ZitatVielleicht kann man auch den Parameter "Schneefall" aus dem Wetterbericht mit aufnehmen?
:)  Ja, das wäre schön einfach. Aber leider kann in der Realität der schönste Sonnenschein sein (und demzufolge eine hohe Prognose), aber dennoch Schnee für eine Woche auf den Zellen liegen weil es gestern Nacht doll geschneit hat und wegen den Minusgraden keine Schmelze eintritt.
Darum wäre ein "Schneesensor" nicht das schlechteste Mittel.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

@Guido,

ich habe die Warnings hoffentlich beseitigt.
Eine entsprechende Version ist eingecheckt und morgen früh im Update.
Du kannst sie aber auch schon aus meinem Contrib laden, FHEM restarten und schauen ob es geholfen hat.
Wie gesagt, kamen bei mir diesen Warnungen nicht.

Grüße,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

tomcat.x

Hallo Heiko,

Danke noch mal für die Erläuterungen zum CorrectionFactor. Hatte ich zwar schon geschrieben, aber nicht genug. Das hat echt geholfen zu verstehen, warum das bei mir gerade so läuft. Führt aber auch zu einem Verbesserungsvorschlag ;)

Wenn man wie in meinem Fall Probleme mit Verschattung zu bestimmten Zeiten hat, ist zu diesen Zeiten ein Faktor von 1,0 als Ausgangsbasis nicht der beste Wert. Die letzten 2 Tage hatte ich das erste Mal für alle Stunden einen korrigierten Wert und eine viel bessere Vorhersage. Morgen sind aber nach derzeitigem Stand wieder 2 Stunden ohne vorhanden. Bei dem vorhergesagten Wetter (Bewölkung) führt das dann zu Ausreißern mit zu hoher Vorhersage. 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.

Und eine Frage noch: Du hattest weiter oben geschrieben, dass die Strings bei der Berechnung des Faktors nicht (unterschiedlich) berücksichtigt werden (hätte ja z. B. wegen Thema Beschattung so sein können). Da ich das bei der Einrichtung nicht wusste, habe ich trotz gleicher Ausrichtung mehrere Strings definiert und das jetzt so gelassen. Woran ich nicht gedacht habe und was mir jetzt im Debug-Log aufgefallen ist: Die API-Abfrage erfolgt natürlich für jeden Strings einzeln. Das ist dann in meinem Fall unnötig. Kann ich das noch ändern (zu einem String zusammenfassen) oder gibt das irgendwelche Probleme und ich sollte es lieber lassen?

Viele Grüße
Thomas
FHEM: 6.3 auf Raspi 3B+, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.00), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

DS_Starter

Hallo Thomas,

ZitatKann ich das noch ändern (zu einem String zusammenfassen) oder gibt das irgendwelche Probleme und ich sollte es lieber lassen?
Ändern kann man es natürlich. Ob es einen Vorteil bringt hängt etwas von der verwendeten API ab. Welche benutzt du?

ZitatWenn 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.
Da probiere ich mal etwas.

Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

tomcat.x

Zitat von: DS_Starter am 17 Juni 2024, 16:19:03Ändern kann man es natürlich. Ob es einen Vorteil bringt hängt etwas von der verwendeten API ab. Welche benutzt du?

Aktuell nutze ich nur OpenMeteoDWD-API. Aber wo die Geschichte mit der Umwandlung der Einstellungen in Readings abgeschlossen ist und man mit weniger manuellen Nacharbeiten kopieren kann, wollte ich noch mal weitere testen. Bei Vorteil dachte ich nur an weniger Abfragen (auf meiner Seite) und weniger Antworten/Berechnungen für den Server, nicht in Richtung besserer Vorhersage.
FHEM: 6.3 auf Raspi 3B+, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.00), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

DS_Starter

#749
Ok, bei SolCast-API hätte ich einen direkten Vorteil gesehen weil die Rooftop Abfrage so sehr beschränkt ist. Aber bei OpenMeteoDWD-API sehe ich eigentlich keinen Vorteil.
Du hast natürlich Recht was den Rechenaufwand betrifft, aber ob die Einsparung überhaupt spürbar ist bezweifle ich ehrlich gesagt. Du kannst es natürlich umsetzen wenn du magst.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter