Modul für DWD Open Data

[jensb]

@mumpitzstuff

Danke für den Hinweis, aber ich möchte vermeiden, dass das XML-Dokument überhaupt als Ganzes ins RAM kommt. Das geht vielleicht so ähnlich wie du vorgeschlagen hast mit File-IO. Ansonsten kommt natürlich auch ein XML-Parser in Frage, der kein DOM aufbaut.

[mumpitzstuff]

Mit der von mir vorgeschlagenen Variante baut man 30 Zeilen Code in euren bestehenden Code ein und ist um den Faktor 1000 schneller bei 5x weniger RAM. Die von dir vorgeschlagene Methode ist wesentlich aufwendiger und ob man dort am Ende genauso schnell ist und genauso viel RAM spart ist eher fraglich.

[jensb]

Mir ist nicht klar, wie index() RAM spart. Wenn das entpackte XML 700 MB groß ist, muss es ins RAM, damit man mit index() suchen kann. Das geht sicherlich schnell. Aber soviel RAM hat z.B. mein System nicht übrig.

[mumpitzstuff]

RAM spart man deshalb, weil man libXML nur über einen ganz kleinen Teil der Daten drüber jagen muss, anstatt die gesamten 670MB zu parsen und die geparsten Daten in den RAM zu legen. Ich habe keine Ahnung wieviel libXML verbraucht, wenn man ein 670MB XML File übergibt, aber so 1-2gb würde ich schätzen (ich glaube in deiner Hilfe erwähnst du was von 4gb RAM sollte man haben oder sowas glaube ich)? Wenn man libXML nur die paar KB Stationsdaten gibt, dann braucht libXML nur so viel RAM wie bei der bisherigen kleinen Variante, also fast nix. Aber wie gesagt, das entpacken ins RAM würde man damit nicht sparen, das ist richtig.

[jensb]

@DS_Starter

Hallo Heiko,

meine aktuelle Testversion holt Zeitstempel und Größe ohne Download vom Server und legt dafür Readings an. Beim Forecast verhindert es auch schon, dass noch einmal neu vom Server geladen wird, wenn sich nichts geändert hat. Möchte das erst mal laufen lassen, bevor ich es hochlade. Wenn es stabil läuft wird das bei den Alerts auch so gemacht.

Was mir nicht so gefällt ist der Modulmix. Für die HTML-Header habe ich LWP::UserAgent neu eingebunden, aber der eigentliche Download erfolgt mit HttpUtils. Für User mit Proxy könnte das schwierig werden. LWP verwendet die System-Proxy-Einstellungen, vermutlich ohne Authentifizierung, und HttpUtlils die von FHEM inkl. Authentifizierung. Bitte Info wenn jemand weiß wie man mit HttpUtils nur die Header bekommt.

Bzgl. des Timers habe ich wieder auf meiner Lösung aufgesetzt und versucht das Problem zu beheben. Die Timer-Steuerung ist nicht ganz trivial und ich möchte, dass man den Code auch nach längerer Zeit noch versteht. Außerdem möchte ich nicht den Timer am Anfang schon wieder scharf machen. Falls der Durchlauf wirklich mal sehr lange dauern sollte (sehr unwahrscheinlich), dann sollte der nächste Durchlauf ein bisschen warten.

Aber eigentlich ist es kein Problem sonder eine Frage von Prioritäten. Bisher hatten die Alerts Priorität, deshalb ist wohl in meiner letzten Version die Vorhersage in der 3. Viertelstunde nicht (immer) angelaufen. Habe wahrscheinlich schon die Lösung, die sowohl Alerts als auch MOSMIX S Forecast berücksichtigt.

Grüße,
Jens

[DS_Starter]

Moin Jens,

ja ich hatte auch erkannt, dass die Timersteuerung nicht ganz trivial ist und setze auf deine Innovation den Downlowd mit der DWD Aktualisierung zu synchronisieren. Das ist m.M. nach ein deutlicher Schritt zu mehr Aktualität gepaart mit verringerten Aufwand.
Ich teste die nächste Entwicklung gern wenn du das Signal dazu gibst.
Sag auch Bescheid wenn ich an irgendeiner Stelle Unterstützung geben kann.

Grüße,
Heiko

[jensb]

Hallo Heiko,

bin dran, möchte aber meine aktuelle Version noch eine Nacht laufen lassen.

Der Header-Check für den Forecast ist jetzt robust und vor allem auch die interne Rückgabewert-Auswertung kann jetzt auch mit dem Zustand "geprüft aber es gibt keine Änderungen" umgehen. Der Header-Check für die Alerts steht noch aus.

Anbei ein Screenshot mit den 3 neuen Readings fc_url und fc_kmzDoc*. Der Vergleich der Readings fc_time (Ausgabezeit DWD) und fc_kmzDocTime (Datei-Zeitstempel auf DWD Webserver) ist auch interessant, beide in UTC. Es dauert erwartungsgemäß etwas bis aus einer Prognose eine Datei wird, aber die Datei wird scheinbar vor der "Ausgabezeit" abgelegt.

Die Timersteuerung habe ich noch einmal analysiert, mit dem ursprünglichen Ansatz verglichen und eine neue Zwischenlösung implementiert, die weder Forecasts noch Alerts sporadisch vernachlässigt.

Grüße,
Jens

[xerion]

Hallo zusammen,


ich nutze aktuell auch schon das optimierte Modul für Solarforecast. Seitdem ich das nutze habe ich Nachts diverse Neustarts von fhem.  Heute Nacht ist das ganze 8 mal passiert in einem Abstand von ca. drei Minuten. Habt ihr vielleicht eine Idee was die Ursache sein kann?

Im Log finde ich dann immer diese Einträge.

Code Auswählen Erweitern

2024.02.27 22:32:50 0: Server shutdown
2024.02.27 22:32:50 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 3422
2024.02.27 22:39:28 0: Server shutdown
2024.02.27 22:39:28 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 3428
2024.02.27 22:41:52 0: Server shutdown
2024.02.27 22:41:52 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 3433
2024.02.27 22:43:48 0: Server shutdown
2024.02.27 22:43:48 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 3438
2024.02.27 22:46:29 0: Server shutdown
2024.02.27 22:46:29 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 3444
2024.02.27 22:48:16 0: Server shutdown
2024.02.27 22:48:16 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 3450
2024.02.27 22:49:40 0: Server shutdown
2024.02.27 22:49:40 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 3455

[Ingo298]

Guten Tag zusammen,
ich möchte gern diese Modul benutzen und habe nun vom Pi2 auf Pi4 mit 8GB Ram gewechselt, aber leider kann ich keine Daten von DWD
beziehen. Habe auch schon das TimeOut mal erhöht. Was könnte hier das Problem sei ?
MfG Ingo

Code Auswählen Erweitern

2024.02.28 09:08:56 5: DWD: GetForecast START (PID 783)
2024.02.28 09:08:56 5: DWD: GetForecast END
2024.02.28 09:08:56 5: DWD: GetForecastStart START (PID 870): https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/MOSMIX_S_LATEST_240.kmz
2024.02.28 09:09:00 5: DWD: ProcessForecast START
2024.02.28 09:09:00 5: DWD: ProcessForecast: data received, decoding ...
2024.02.28 09:09:06 5: DWD: ProcessForecast: parsing XML document
2024.02.28 09:11:56 3: DWD: GetForecastAbort ERROR: downloading and processing weather forecast data failed (Process died prematurely)
2024.02.28 09:11:56 5: DWD: RotateForecast: START 0 day(s) exist
2024.02.28 09:11:56 3: DWD: RotateForecast: station has changed, deleting exisiting readings
2024.02.28 09:11:56 5: DWD: RotateForecast: END 0 day(s) remain


[DS_Starter]

Hallo Ingo,

benutzt du das DWD Modul aus meinem contrib? Das habe ich in Betrieb und läuft bei mir mit 4GB RAM.
Hast du genügend SWAP Speicher?
Kannst mit Betriebssystemebene mit "top" schauen ob da irgendwas an die Grenzen läuft.

Grüße,
Heiko

[DS_Starter]

@Jens,

Der Vergleich der Readings fc_time (Ausgabezeit DWD) und fc_kmzDocTime (Datei-Zeitstempel auf DWD Webserver) ist auch interessant, beide in UTC

Sieht gut aus. Frage ... sind im aktuellen Modul nicht alle Zeiten in Localtime umgesetzt oder täsche ich mich?

@xerion,
das sieht nach einem normalen shutdown request aus. Hast du vllt. eine Überwachung auf "terminated process" eingebaut was in der Folge den shutdown triggert?

@Jens, ich denke xerion bekommt einen HttpUtils_BlockingGet Timeout der z.Zt. fest auf 10 eingestellt ist. Hier sollte m.M. auch das Attr downloadTimeout greifen, heißt ja auch so. 

Grüße,
Heiko

[DS_Starter]

@xerion,

in meinem contrib liegt eine Version des DWD Moduls bei der das Attr downloadTimeout auch bei deinem Problem helfen sollte. Kannst du z.B. auf 120 stellen.

@Jens, ich habe zum Test für den HttpUtils_BlockingGet Timeout die Zeile 1669 dahingehend geändert:

Code Auswählen Erweitern

               timeout    => ::AttrVal($name, 'downloadTimeout', 60),

[Ingo298]

Hast du genügend SWAP Speicher?

Da ich nur eine SDCard benutze habe ich SWAP deaktiviert. Im Top läuft im bei benutzer Fhem  der CPU kurz auf 100% und der MEM max 16.2% sonst sind da keine auffälligkeiten zu erkennen

benutzt du das DWD Modul aus meinem contrib?

ja nutze ich

[DS_Starter]

Da ich nur eine SDCard benutze habe ich SWAP deaktiviert.

Könnte ein Problem sein, siehe https://forum.fhem.de/index.php?msg=1304541

[Ingo298]

Hab mal ein SWAP von 2048 gemacht leider ohner erfolgt, wird gemäß Top nicht genutzt