Modul für DWD Open Data

[DS_Starter]

Finde ich eine gute Idee. Etwas ähnliches habe ich bei mir im DbRep gemacht -> Attr autoForeward.
Ist nicht das gleiche wie hier, ähnelt sich nur etwas bezüglich des beabsichtigten Ergebnisses.

[DS_Starter]

Bezüglich des Mix aus S und L ist mir der Gedanke gekommen, dass es vllt. ungünstig ist. Wenn zum Beispiel NEFF über MOS S stündlich aktualisiert wird, könnte es durch MOS L mit einem veralteteten Wert überschrieben werden, da das Update-Intervall ja 1h beträgt und der in das Reading geschriebene Wert u.U. 6h alt ist.

Es ist vermutlich besser, dass sich der User entscheiden sollte. Das Ergebnis ist dann eindeutig und auch eine evtl. Fehlersuche leichter.

LG,
Heiko

[Prof. Dr. Peter Henning]

Ich häng mich hier einfach mal rein zum Mitlesen.

LG

pah

[ch.eick]

Moin
ich lese dann auch mit und habe ca. 15 Anwender, die die PV_KI_Prognose für meine Kostal WR Implementierung verwenden. Da gehen ebenfalls die DWD Daten stündlich rein.

VG Christian

[papa]

Wegen der Performance - kennt ihr das Reader Interface der LibXML. Damit kann man recht leicht das gesamte Dokument als Stream parsen - also ohne Aufbau des kompletten DOMs. Soweit wie ich den Code verstanden habe, muss ja nur die richtige Station im XML gefunden werden und deren Daten für die Weiterverarbeitung extraiert werden. Das sollte mit einem Reader recht leicht möglich sein. Hab das aber bisher auch nur mit C/C++ benutzt.

Siehe auch: https://grantm.github.io/perl-libxml-by-example/large-docs.html https://metacpan.org/dist/XML-LibXML/view/lib/XML/LibXML/Reader.pod

Und soweit ich mich erinnere kann LibXML auch gleich den gezippten Input direkt verarbeiten - zumindest in C/C++. Bräuchte man also auch nicht vorher zu entpacken.

[Prof. Dr. Peter Henning]

Ich habe zwar diesen Datensatz noch nicht angesehen, aber kann hier mal einen Tipp aus vielen Jahren Lehre über XML beisteuern.

Wenn es darum geht, aus einem großen XML Datenvolumen nur einen bestimmten Teil herauszufiltern, würde ich FHEM auch bei Verwendung von libXML nicht mit dem gesamten Stream belasten. Sondern eher einen zyklischen Unix/Linux-Prozess bauen, der den gesamten Datensatz durch einen XSLT-Transformer schickt und nur noch den erwünschten Teil an FHEM weiterleitet.

Früher gab es dazu ein fantastisches Projekt der Apache Foundation namens Cocoon, das leider durch Über-Engineering kaputt gemacht worden ist. Das hat übrigens den "Transformer"-Ansatz moderner KI-Systeme vorausgenommen - mit ganz interessanten Konzepten. Beispiel: Eine Datenbank ist eine Funktion, die einen String - die Datenbank-Abfrage - in einen anderen String transformiert.

LG

pah

Edit: Möglicherweise kann man den XSLT-Ansatz auch direkt in einem Modul von FHEM verwenden. Muss ich mal drüber nachdenken.

[DS_Starter]

Moin,

ich habe etwas weitergemacht und das Attr forecastProcess in forecastDataPrecision (low | high) umgesetzt.
Dadurch wird der direkte technische Bezug auf MOSMIX_L/S aufgelöst.
Die engl. Commandref dafür ist auch ergänzt und für den interessierten User mit weiterführenden Links versehen.
Entsprechende Hinweise auf die nötige Leistung sind auch hintelegt.

Weiterhin habe die Formatierung deinem Stil angepasst und dem Modul ein Internal NEXTCYCLE spendiert damit man sieht wann der nächste Refresh geplant ist.
Ich bin bezüglich des Mix aus S und L inzwischen zu einer gefestigten Meinung gekommen dies besser zu lassen.

@papa:

Wegen der Performance - kennt ihr das Reader Interface der LibXML. Damit kann man recht leicht das gesamte Dokument als Stream parsen - also ohne Aufbau des kompletten DOMs.
...

Nein, Jens vielleicht. Ich habe mich gestern mal eben frisch in das Thema XML Parsing eingearbeitet/eingelesen. Bin also völliger Newbie auf diesem Gebiet.
An anderer Stelle habe ich mich schonmal bei pah über die unverhältnismäßige Kürze eines Tages beschwert.  

Soweit wie ich den Code verstanden habe, muss ja nur die richtige Station im XML gefunden werden und deren Daten für die Weiterverarbeitung extraiert werden.

Für MOSMIX_S trifft das m.M. nach auf jeden Fall zu weil dort viel Inhalt obsolet ist. Bei MOSMIX_L wird aber fast der gesamte Inhalt verarbeitet weil bei MOSMIX_L jede Station separat heruntergeladen werden kann.

Ich habe die Modulstudie jetzt als 55_DWD_OpenData_Studie_MOSMIX_S.pm in mein contrib geladen.
Kann sich jeder dort holen.

Edit: Zur Info...läuft bei mir einwandfrei mit MOSMIX_S und auf dem NUC auch innerhalb von ca. 16s im BlockingCall durch.

Code Auswählen Erweitern

2024.02.18 11:00:05.174 5: DWD.Solar.N5872: Timer START
2024.02.18 11:00:05.174 5: DWD.Solar.N5872: GetForecast START (PID 24973)
2024.02.18 11:00:05.219 5: DWD.Solar.N5872: GetForecast END
2024.02.18 11:00:05.221 5: DWD.Solar.N5872: Timer END
2024.02.18 11:00:05.368 5: DWD.Solar.N5872: GetForecastStart START (PID 25573): https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/MOSMIX_S_LATEST_240.kmz
2024.02.18 11:00:08.672 5: DWD.Solar.N5872: ProcessForecast START
2024.02.18 11:00:08.673 5: DWD.Solar.N5872: ProcessForecast: data received, decoding ...
2024.02.18 11:00:10.996 5: DWD.Solar.N5872: ProcessForecast: parsing XML document
2024.02.18 11:00:18.432 5: DWD.Solar.N5872: ProcessForecast: extracting data
2024.02.18 11:00:19.232 5: DWD.Solar.N5872: ProcessForecast: use position >xxxx< of station >xxxx<
2024.02.18 11:00:19.618 5: DWD.Solar.N5872: ProcessForecast temp file /tmp/S1iKlgzGbT forecast 3 size 12734
2024.02.18 11:00:19.621 5: DWD.Solar.N5872: ProcessForecast END
2024.02.18 11:00:19.622 5: DWD.Solar.N5872: GetForecastStart END
2024.02.18 11:00:19.635 5: DWD.Solar.N5872: GetForecastFinish START (PID 24973)
2024.02.18 11:00:19.661 5: DWD.Solar.N5872: GetForecastFinish temp file /tmp/S1iKlgzGbT forecast 3 size 12734
2024.02.18 11:00:19.664 5: DWD.Solar.N5872: UpdateForecast: START
2024.02.18 11:00:19.674 5: DWD.Solar.N5872: RotateForecast: START 2 day(s) exist
2024.02.18 11:00:19.686 5: DWD.Solar.N5872: RotateForecast: shifting forward by 0 day(s) (1708210800 -> 1708210800)
2024.02.18 11:00:19.687 5: DWD.Solar.N5872: RotateForecast: END 2 day(s) remain
2024.02.18 11:00:20.173 5: DWD.Solar.N5872: UpdateForecast: END
2024.02.18 11:00:20.174 5: DWD.Solar.N5872: GetForecastFinish END
2024.02.18 11:00:21.176 5: DWD.Solar.N5872: Timer START
2024.02.18 11:00:21.179 5: DWD.Solar.N5872: Timer END

LG,
Heiko

[jensb]

Wegen der Performance ...

Bzgl. Performance sollte man die Historie des Moduls berücksichtigen. Die Verarbeitung von MOSMIX L erfordert, dass man mehr oder weniger das gesamte XML Dokument ließt. Natürlich geht das auch mit dem Reader/SAX-Parser-Ansatz. Aber so ist es nicht umgesetzt und funktioniert trotzdem prima. Bei einer Dokumentengröße von unter 400 kByte ist die Diskussion fast akademisch ob DOM oder Reader/SAX.

Das MOSMIX S Dokument ist aber anders aufgebaut als MOSMIX L, da hier alle Stationen in einem Dokument stecken, mit einer Dokumentengröße um 700 MByte. Hier würde es helfen RAM zu sparen, wenn man erst mit dem Reader/SAX-Parser die Stationsdaten herausfischt, um dann wie gehabt weiter zu machen. Aber das kann man auch im Nachgang als Optimierung umsetzten.

Jens

[jensb]

Hallo Heiko,

wenn du mit deiner neuen Version des Moduls zufrieden bist, würde ich sie mir noch mal vornehmen. Aber vermutlich komme ich erst nächstes Wochenende dazu.

Wir sollten versuchen den Reader/SAX-Parser für MOSMIX S einzubauen, bevor die Version eingecheckt wird. Würde das übernehmen, es sei denn du hast schon damit angefangen.

Die anderen Features, die wir angesprochen haben, behalten wir aber im Hinterkopf:

• export der Readings in ein anderes Modul
• mehrere Stationen gleichzeitig bei S
• S und L mischen

Des weiteren möchte ich versuchen, den File-Zeitstempel vom DWD-Webserver einzulesen. Dann könnte man etwas häufiger Pollen und dafür seltener Herunterladen, insbesondere bei L.

Grüße,
Jens

[DS_Starter]

Hallo Jens,

ich wollte nur noch das Startverhalten etwas anpassen damit bei mehreren vorhandenen Devices nicht alle versuchen zur gleichen Zeit den Download/Parsing durchzuführen.
Ansonsten bin ich durch und läuft ja auch sehr gut.

Wir sollten versuchen den Reader/SAX-Parser für MOSMIX S einzubauen, bevor die Version eingecheckt wird. Würde das übernehmen, es sei denn du hast schon damit angefangen.

Nein habe noch nicht damit begonnen. Da müsste ich erstmal weiter studieren wo/wie man da ansetzt. Aber lerne gerne von deinem XML Know-How dazu wenn du mir ein paar Tipps gibst. 
Ehrlicherweise hatte ich gehofft wir könnten schon vor dieser Optimierung von dieser Weiterentwicklung offiziell profitieren. Die Nutzer von SolarForecast und Christians Lösung würden sich sicherlich darüber freuen.

- export der Readings in ein anderes Modul
- mehrere Stationen gleichzeitig bei S

Da würde ich auch gerne wieder mit einsteigen.

- S und L mischen

Hier habe ich tatsächlich Bauchschmerzen wie oben geschrieben weil ich die deutliche Gefahr sehe, aktuelle Werte aus S bei einem Refreshlauf des Moduls mit mehrere Stunden alten Werten aus L zu überschreiben.
Das darf auf keinen Fall passieren weil wir uns sonst die Vorteile von S wieder kaputt machen.

Des weiteren möchte ich versuchen, den File-Zeitstempel vom DWD-Webserver einzulesen. Dann könnte man etwas häufiger Pollen und dafür seltener Herunterladen, insbesondere bei L.

Gute Idee. Das wäre ein echter Vorteil.

LG,
Heiko

[jensb]

Hallo Heiko,

Ehrlicherweise hatte ich gehofft wir könnten schon vor dieser Optimierung von dieser Weiterentwicklung offiziell profitieren.

Du hast doch das Modul schon zum Herunterladen zur Verfügung gestellt. Damit kann jeder der will sofort einsteigen. Das habe ich bei anderen größeren Änderungen ähnlich gemacht. Oder geht es um etwas anderes?

Grüße,
Jens

[DS_Starter]

Naja es heißt noch 55_DWD_OpenData_Studie_MOSMIX_S. Wenn du nichts dagegen hast, würde ich die Version als 55_DWD_OpenData in meinem contrib zur Verfügung stellen für die Interessenten.
Dann könnte der Download direkt erfolgen -> Restart ... fertig. DAmit wären wir fein.

LG,
Heiko

[jensb]

Wenn du nichts dagegen hast, würde ich die Version als 55_DWD_OpenData in meinem contrib zur Verfügung stellen für die Interessenten.
Dann könnte der Download direkt erfolgen

Kein Problem.

Was ich übrigens die ganze Zeit schon loswerden wollte: Was ist eigentlich das Ziel bei der Erhöhung der Aktualisierungsrate? Eine aktuellere Prognose (man will möglichst genau wissen was auf einen innerhalb der nächsten Stunde zu kommt) oder Istwerte? Denn für Istwerte gibt es bei OpenData noch andere Möglichkeiten.

Grüße,
Jens

[DS_Starter]

Hallo Jens,

hier geht es um eine möglichst genaue Prognose wie Globalstrahlung und Bewölkung etc.
Davon wird mit verschiedenen Methoden wie Vergleich mit historischen Wertekontexten (wird gespeichert) oder KI Libraries eine möglichst genaue PV Erzeugungsprognose errechnet.
Diese Prognose dient zur optimalen Einplanung von Verbrauchersteuerungen oder auch der prognosegeführten Ladungssteuerung von PV-Batteriesystemen (optimale SoC Steuerung).
Es können auch verschiedene API (Solcast, DWD, VictronVRM) eingebunden werden. Ein Wiki habe ich auch angefangen, ist aber noch rudimentär.

Im Anhang ein paar Impressionen wie das aussieht.

Grüße,
Heiko

[DS_Starter]

Hallo Jens,

nun habe ich noch das Startverhalten angepasst und sofern das Attr forecastDataPrecision auf "high" gesetzt ist, erfolgt der Datenrefresh im Quarter 2, also zwischen xx:30-xx:45. Grund ist, dass der DWD nach meinen Beobachtungen die Daten für MOSMIX_S regelmäßig zwischen 00:15 und xx:30 aktualisiert.

Mit der default Einstellung "low" bleibt die Aktualisierung wie bisher im Quarter 0.

Mit mehreren DWD Devices "high" gibt es ebenfalls kein Problem. Die Timer Einplanung ist um eine rand Zufallssteurung ergänzt die die Wahrscheinlichkeit reduziert dass mehrere Devices gleichzeitig refreshen.
Ich habe mit meinen 4 GB RAM und 4 DWD Devices (3 x high, 1 x low) keine Sorgen.

Die Version liegt als 55_DWD_OpenData.pm in meinem contrib zum Download.
(SolarForecast) Nutzer können das Modul gern schon implementieren und ebenfalls testen.

LG,
Heiko