76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Heatseeker]

Bei einer Wettervorhersage oder einer Strahlungsprognose zwischen zwei (auch benachbarten) Stationen zu mitteln, ist physikalisch (oder meteorologisch, wenn man so will) totaler Unsinn.

LG

pah

Vielen Dank für die ausführliche Begründung dieser Aussage, das hilft sehr beim Verständnis.

Sorry: Ich interpretiere das Ergebnis von Versuchen lieber selbst als einfache Behauptungen aus dem Internet glauben zu schenken, das machen leider schon zu viele...

Bei mir befindet sich Station 1 etwa 8km westlich von mir, Station2 etwa 9km östlich. Hauptwetterrichtung ist von Osten kommend, und z.B. bei Verwendung der Station 2 sehe ich oft eine Zeitverschiebung von einer halben Std, weshalb ich es mal mit einer Mittelung der beiden Stationen versuchen wollte. Ob es funktioniert werde ich dann ja sehen...

[Prof. Dr. Peter Henning]

Bei "Behauptungen im Internet" sollte man einfach ansehen, welchen Hintergrund der Verfasser hat, das klärt schon einiges...

sehe ich oft eine Zeitverschiebung von einer halben Std

. Soso. Oft = immer? Und immer eine halbe Stunde, oder können es auch 20 Minuten sein?

Offenbar hängt es eben von mehreren Faktoren ab, wie das Wetter in der "Mitte" zwischen zwei Stationen ist - unter anderem von der Windrichtung. Der DWD schreibt selbst dazu, so wie unten zitiert

Konsequenz aus der Erstellung individueller Gleichungen für jede einzelne Station

.

Dann braucht man nur noch etwas Wissen über diese Gleichungen und kann mit mathematischer Genauigkeit die Aussage treffen

Bei einer Wettervorhersage oder einer Strahlungsprognose zwischen zwei (auch benachbarten) Stationen zu mitteln, ist physikalisch (oder meteorologisch, wenn man so will) totaler Unsinn.

Aber Unsinn ist nicht verboten. so frei ist dieses Land ja noch. Also: Go ahead, mancher freut sich seines Lebens, wenn seine "Vorhersage" eine Genauigkeit von 50% hat.

LG

pah

[Heatseeker]

Bei "Behauptungen im Internet" sollte man einfach ansehen, welchen Hintergrund der Verfasser hat, das klärt schon einiges...

Naja, ein Forumsname heißt ja nun mal gar nichts solange es keine Verifizierung etc gibt, kann mich hier auch Pumuckel nennen - werde dadurch jedoch auch kein Experte für rote Haare...

Zum Thema:
Mir ist schon bewusst, dass jede Station individuelle Ergebnisse liefern und dass in der Mitte zwischen zwei Stationen nicht immer der Mittelwert des Ergebnisses anliegen muss, aber mein Haus hat halt keine eigene Station und somit treffe ich für meinen Standort immer nur eine bestimmte Annahme und die Annahme, dass hier die Wetterbedingungen herschen wie an der Station 9 km weiter ist genau so falsch für mich wie der, dass hier der Mittelwert von der Station 1 und Station2 herrschen.
Ich wohne in der Nordeutschen Tiefebene, der maximale Höhenunterschied auf der Strecke zwischen Station1 und Station2 liegt bei unter 25 Metern, da habe ich bestimmt weniger toplogische Einflüsse wie im Alpenraum, deshlab lasse ich es gerne auf einen versuch ankommen zumal ich gerne experimentiere...

[stefanru]

Hallo Heiko,

so ich habe den Timeout mal auf 120 sec erhöht und es geht
Ich habe auch beobachtet was dann beim get forecast passiert.

Mein Speicher vorher ist:
Verfügbar
Physisch 2704 MB
Swap     4048 MB

Dann mache ich den get forecast auf meinem Haupt Wetter Device.
Erst dauert es und es tut sich sehr wenig und nach 20 -30 sec nimmt der Speicher dann rapide ab bis ich:
Verfügbar
Physisch 284 MB   
Swap     3566 MB

Verbraucht wurden also 2420 MB physisch + 529 MB Swap.
Wow! 3 GB Speicherverbrauch.
Der Speicher nahm sehr schnell ab. Somit denke ich dass bei mir wirklich die 6MBit Leitung den Timeout reißt.
Den Timeout kann ich dann wieder auf 30 setzen wenn ich Glasfaser habe.

Nun ein paar Fragen
Wie kommt das denn bei den 700 MB Rohdaten zu einem Speicherverbrauch von ungefähr 3 GB?

Ich benutze im Moment 2 Wetterdevices.
Wenn ich das richtig verstanden habe genügt es eigentlich die precision bei meinem Strahlungsdevice hochzusetzen, oder?

Gruß und Danke,
Stefan

[300P]

Hallo Heiko,

wenn mit "deinem" DWD-Modul und den dazu empfohlen zugehörigen zusätzlichen neuen Einstellungen arbeite, erhalte ich irgendwann im laufe der Zeit folgende Meldung: (bislang 3 x - 3 Tage Laufzeit)

PERL WARNING: Use of uninitialized value $cloudCover in multiplication (*) at ./FHEM/98_DWD_OpenData_Weblink.pm line 837.


Gruß
300P

[DS_Starter]

@Stefan,

dachte ich mir. Es macht dann durchaus Sinn den Timeout einstellbar zu gestalten.

Wie kommt das denn bei den 700 MB Rohdaten zu einem Speicherverbrauch von ungefähr 3 GB?

Ich starte mal einen Erklärungsversuch. Zunächst muß man beachten dass bei dem verwendeten BlockingCall der Perl Hauptprozess geforkt, also in einen weiteren Prozess "kopiert" wird. Das stimmt nicht wirklich, Rudolph König hatte es mal im Forum genauer erläutert (suchen..) was in Perl passiert. Für uns nehmen wir erstmal eine Duplizierung des vorhandenen RAM (Perl) an.
In dem neuen Prozess wird das Stationenfile heruntergeladen und mit Perl-Mitteln entpackt. Die 700M gehen schonmal in den RAM.
Nun wird anschließend der gesamten Inhalt nach den relevanten Informationen geparst. Wir können davon ausgehen, dass dabei wieder einiges an Speicher verbraucht wird, möglicherweise wiederum die Größe des Files.
Der gesamte zusätzlich allokierte Speicher wird durch den geforkten Prozess verbraucht. Wenn die Arbeit getan ist, wird der geforkte Prozess beendet und der Speicher wieder freigegeben.

Jensb (im DWD Thread) will sich noch eine Technologie anschauen, um den Parsing Prozess ressourcenschonender zu gestalten. Aber das wird noch etwas dauern vermutlich. Leider stellt DWD die MOSMIX_S Daten mit dem stündlichen Update nur als komplettes File mit allen Stationen zur Verfügung. Da ist eine Menge Datenoverhead enthalten den wir handeln müssen.

Wenn ich das richtig verstanden habe genügt es eigentlich die precision bei meinem Strahlungsdevice hochzusetzen, oder?

Wenn du ein DWD Device hast für die Strahlungsdaten (Rad1h) und ein anderes für die Bewölkung, Regen usw. macht es Sinn beide stündlich updaten zu lassen. Unstetige Witterungslagen können dadurch eher berücksichtigt werden.

@300P,

wenn mit "deinem" DWD-Modul und den dazu empfohlen zugehörigen zusätzlichen neuen Einstellungen arbeite, erhalte ich irgendwann im laufe der Zeit folgende Meldung: (bislang 3 x - 3 Tage Laufzeit)

PERL WARNING: Use of uninitialized value $cloudCover in multiplication (*) at ./FHEM/98_DWD_OpenData_Weblink.pm line 837.

Der DWD aktualisiert die MOSMIX_S Daten 24x täglich, aber nur bis +24h in die Zukunft. Wenn du in deinem DWD_OpenData_Weblink Device das Attr forecastDays > 2 eingestellt hast, können Daten fehlen und dann kommt diese Warnung. Das habe ich nämlich bei mir auch beobachtet. Mit  forecastDays = 2 passt es.

LG,
Heiko

[stefanru]

Ok super,
Danke Heiko macht alles Sinn.

Ich habe 2 ctrlWeatherDev:
ctrlWeatherDev1 DWD_Birkenau
ctrlWeatherDev2 DWD_Weiher

Im currentRadiationAPI ist DWD_Birkenau eingetragen. Da geht ja nur eins.

Wenn ich das richtig verstehe kommen die Strahlungsdaten von DWD_Birkenau.
Bewölkung usw von beiden.

Dein Vorschlag ist beide mit precision high damit die Bewölkung usw auch immer aktuell ist.
Bisher habe ich nur DWD_Birkenau mit high.

Werde denke ich meinen Swap noch etwas erhöhen und dann beide mit high laufen lassen.

Danke und Gruß,
Stefan

[DS_Starter]

Hi Stefan,

ja genau, das Modul holt sich die Rad1h (Strahlungsdaten) von DWD_Birkenau.
Die Wetterdaten wie Bewölkung etc. werden auch aus ctrlWeatherDev1 DWD_Birkenau geholt.
Die Bewölkungsdaten werden mit den Daten aus ctrlWeatherDev2 DWD_Weiher gemerged. Ob das sinnvoll ist mußt du für dich entscheiden. Im einfachsten Fall setzt du nur ctrlWeatherDev1.

Gerade gesehen, dass ich den Mouse-Over bei der DWD Status LED korrigieren muß, statt "Vorhersagezeitpunkt Wetterdaten" ist richtig "Vorhersagezeitpunkt Strahlungsdaten". Eine LED für die Aktualität der Wetterdaten müsste ich noch an geeigneter Stelle noch einfügen.

LG,
Heiko

[stefanru]

Ok, danke.

Ich teste es mal so mit den 2 Devices auf high auf dem Raspberry PI4.
Ist vielleicht ja auch für andere interessant, Raspberry wird ja doch oft benutzt.

Zu erwähnen ist bisher der Timeout, der liegt aber eher an meiner langsamen Internet Verbindung.

Und bei meinem Raspberry mit 4GB Speicher ist es zu knapp mit einem 8GB Raspberry könnte es im Speicher reichen.
Ich würde aber auf jeden fall einen Swap empfehlen mit mind 4098MB.

Vor allem hat sich der Raspberry ohne Swap einfach aufgehängt sobald der Speicher aufgebraucht war.
Also am besten mit dem Swap nicht zu geizig sein.
Ich nutze eine SSD für meinen Raspberry und habe somit nicht viel bedenken mit einem Swap.
Wenn man den Raspberry von SD Karte laufen hat sollte man sich da eher Gedanken machen.


Viele Grüße und Danke,
Stefan

[kask]

edit.: geklärt

[DS_Starter]

Moin,

in meinem contrib befindet sich eine Version des DWD_OpenData Moduls mit einem Attribut "timeout".
Damit kann man sich bei Bedarf (stefanru) diesen Parameter anpassen.

Grüße,
Heiko

[kask]

Bei mir holt sich das Modul die Werte immer zur vollen Stunden (Mosix_S).
Ich meine bei DWD aber gelsen zu haben das es um ca. 25min nach der vollen Stunde aktualisiert wird.
Mal eben gesucht:

Es werden MOSMIX-Vorhersagen mit einem Vorhersageintervall von einer Stunde und einer maximalen Vorhersagezeit von +240 Stunden zur Verfügung gestellt. Sie werden 24x täglich, ca. 25 Minuten nach jeder vollen Stunde zur Verfügung gestellt.
Während die ersten 24 Vorhersagestunden auf Basis der neuesten Beobachtungsdaten stündlich aktualisiert werden, wird der Vorhersagezeitraum +25 bis +240 Stunden 4x täglich (um 4, 10, 16 und 22 UTC) aktualisiert.

Wäre es da nicht besser das man das um xx:30 immer holt? Und wäre es nicht besser wenn jeder Benutzer eine andere Zeit bekommt per Zufall beim Laden des Modules. So zwischen xx:30:00 - xx:49:59 damit nicht alle Zeitgleich pollen? Ist ja auch im Interesse des Hosters & DWD und gibt keine Engpässe abei den usern.
Gut es werden nicht 90802987359 geladene Module die Daten holen. Aber andere benutzen das ja auch für andere Scripte, Applications etc. .Man kann ja auch auf seine Mitmenschen mit soetwas rücksichtnehmen.

Mal so als Anregung.

Edit: Gerade mal ins modul geguckt. Ist ja fast sogar so. Ist bei mir nur doof getimed. Hatte es gestern Abend scharf gemacht.

[DS_Starter]

Hallo kask,

Bei mir holt sich das Modul die Werte immer zur vollen Stunden (Mosix_S).

Da bist du einem Irrtum aufgesessen. Der Timer des DWD Modul schaut regelmäßig nach durchzuführenden Aufgaben (Reading nextcycle). Je nach Aufgabe erfolgt die Datenholung im Viertel 0-3 einer Stunde. Bei Neustart sofort mit zufälliger Verzögerung.
Im Fall von MOSMIX_S ist es immer das Viertel "2", also zwischen xx:30 bis xx:45.
Das zahlt auf die Aktualisierungszeit des DWD ein. Ist mir bekannt und deswegen auch berücksichtigt.

Und die Abholzeit wird auch per Zufallszahl in gewissen Grenzen variiert. 

LG,
Heiko

[stefanru]

Danke Heiko,

habe das neue DWD Modul geladen und Timeout gesetzt.
Ansonsten scheint es gut zu laufen.

Ich beobachte noch wie sich der Swap über eine längere Zeit verhält.

Gruß,
Stefan

[DS_Starter]

Hallo zusammen,

trotz des sonnigen Wetters habe ich eine weitere Implementierung vorgenommen die mir schon lange wichtig war.
Es gibt nun schon einiger Zeit die Anreicherung der KI mit den Sonnenstandsdaten.
Für die diskreten Korrekturfaktoren bei den API's wie DWD ohne KI, SolCast, Forecast.Solar API oder VictronVRM war das bisher nicht der Fall. Das habe ich nun nachgeholt.
D.h. die Faktoren werden nunmehr neben der Bewölkung (die sich dank DWD "high" schneller anpasst) jetzt auch in Abhängigkeit der Sonnenaltitude pro Stunde bestimmt und in der pvCircular gespeichert.

Das Mouse-Over bei der Bewölkung in der Grafik zeigt jetzt auch die Sonnenstandsangaben für die jeweilige Stunde.

Ich bilde mir ein, dass die starke (und korrekte) Anpassung der Prognose von Stunde 12 auf 13 dem DWD MOSMIX_S Daten zu verdanken ist. Wir werden die weitere Entwicklung beobachten.

Wer schon etwas austesten möchte, kann sich die neue Version 1.16.3 aus meinem contrib ziehen. Restart nicht vergessen!
Wahrscheinlich werde ich die V heute Abend noch einchecken falls keine Auffälligkeiten zu Tage treten.

LG