DWD Wettervorhersage

[ak68]

Ich habe beim LBS 19000937 das Problem, dass die Ausgänge 16-18 (Symbol und Texte) leer bleiben, alle anderen Ausgänge bringen korrekte Werte:


2019_06_24_22_57_37_EDOMI_Administration_Opera.png

[MrIcemanLE]

So ohne Weiteres ist das schwer zu interpretieren. Vielleicht stellst du das Log-Level mal auf 8 und triggerst den Baustein. Ein Blick in das Log hilft uns bestimmt weiter. Echt merkwürdig, dass eine der Messgrößen nicht richtig kommen soll. Der Text (lang und kurz) ist nur ne Übersetzung des WPcd1-Codes. Daher sind, wenn dann alle drei Ausgänge leer.

[ak68]

Vielleicht stellst du das Log-Level mal auf 8 und triggerst den Baustein. Ein Blick in das Log hilft uns bestimmt weiter.

Hier das Log eines kompletten Abruf´s:

2019_06_25_14_35_03_10.10.1.35_data_log_CUSTOMLOG_DWD_Tageswerte_v02_LBS19000937.htm_20190625143.png

[MrIcemanLE]

im Temp-Verzeichnis müsste eine Datei namens "EDOMI_LBSLBSID_MOSMIX_L_LATEST_(stationId).km l" liegen. Dort sind alle Rohinformationen drin. Wenn ich das richtig sehe, gibt es für deine Stations-ID keine Vorhersage für das signifikante Wetter:

<dwd:Forecast dwd:elementName="WPcd1">
                    <dwd:value>         -          -          -

Vielleicht findest du eine andere Station in deiner Nähe?

[ak68]

im Temp-Verzeichnis müsste eine Datei namens "EDOMI_LBSLBSID_MOSMIX_L_LATEST_(stationId).km l" liegen. Dort sind alle Rohinformationen drin. Wenn ich das richtig sehe, gibt es für deine Stations-ID keine Vorhersage für das signifikante Wetter:

<dwd:Forecast dwd:elementName="WPcd1">
<dwd:value> - - -

Vielleicht findest du eine andere Station in deiner Nähe?

Du hast Recht: z.B. Alternative 10788 (Straubing) liefert korrekte Werte:

2019_06_25_23_01_17_EDOMI_Administration_Opera.png

[ak68]

Nach tagelangem problemlosen Verlauf habe ich plötzlich beim LBS 19000939 folgende Log-Einträge:

2019_07_26_07_23_46_Window.png
Die Abfrage bringt jedoch offensichtlich korrekte Werte

Wer kann sich diesen Eintrag erklären ?

PS: Ich triggere den LBS stündlich, jedoch taucht der Fehler NICHT stündlich auf sondern alle par Stunden (z.B. 1 und 7 Uhr !)

[MrIcemanLE]

Der erste Fehler kommt aus einer Debug-Ausgabe. Wenn die temporäre Datei nicht existiert, wird trotzdem versucht das Dateidatum auszulesen.
Der zweite Fehler kommt daher, dass anscheinend der Download der Datei fehlerhaft war und die xml-Datei nicht richtig in einen JSON-String umgewandelt werden konnte. Das führt dann wiederum zu der fehlerhaften Array-Variablen.

Ich habe den Baustein jetzt so umgebaut, dass er die Fehler abfängt. Das bewirkt aber nur, dass die Fehler im LBS-Log landen und nicht im EDOMI--Log. Möglicherweise ist der DWD-Server manchmal kurz nicht erreichbar oder deine Internetverbindung gestört. Hier könnte man einen Loop bauen, der sicherstellt, dass die Datei wirklich geladen wurde. Oder man lebt mir dem Logeintrag und "hofft" dass es in der nächsten Stunde klappt.

Die Daten des DWD werden ohnehin nur drei bis vier mal am Tag aktualisiert. Ich meine mich zu erinnern, dass es 6 Uhr 12 Uhr und 18 Uhr passiert. Möglicherweise auch noch 0 Uhr. Das würde zu deinen Zeiten passen. Wenn du mit dem Stundentrigger arbeitest, wird 6 Uhr festgestellt, dass es noch keine neuen Daten gibt und 7 Uhr findet er dann neue Daten und versucht diese zu laden.

Lange Rede, kurzer Sinn: Version 0.3 im Download-Portal.

Wenn du mir Feedback geben würdest, ob die Meldungen jetzt im Log landen, würde ich die Anpassung auch für die anderen DWD-LBS vornehmen.

[ak68]

Wenn du mir Feedback geben würdest, ob die Meldungen jetzt im Log landen, würde ich die Anpassung auch für die anderen DWD-LBS vornehmen.

Leider ist der erste der beiden Fehler noch NICHT behoben- der Fehler landet weiterhin im EDOMI-Log:

2019_07_27_16_08_22_Window.png

[MrIcemanLE]

Wahrscheinlich kann die Datei nicht entpackt werden, die vom DWD-Server geladen wird. Hast du vielleicht mal nich einen Log-Auszug für mich (Level 8). Weiß zwar nicht, ob uns das hier weiterhilft, aber einen Blick könnten wir schon riskieren ;-)

[ak68]

Wahrscheinlich kann die Datei nicht entpackt werden, die vom DWD-Server geladen wird. Hast du vielleicht mal nich einen Log-Auszug für mich (Level 8). Weiß zwar nicht, ob uns das hier weiterhilft, aber einen Blick könnten wir schon riskieren ;-)

Anbei die Log-Datei ( Ich verwende den LBS 5x !) 4x Unzip fehlgeschlagen, 1x korrekt- ist das das Problem ?:

2019_07_29_07_39_36_10.10.1.35_data_log_CUSTOMLOG_DWD_Tageswerte_Einzelabfrage_v03_LBS19000939.png

[MrIcemanLE]

Es kann gut sein, dass bei gleichzeitigem Trigger die Datei blockiert ist und nicht entpackt werden kann. Das könntest du vielleicht mit Verzögerungs-LBS testen. Ich denke, dass hier minimale Werte reichen sollten.

Die Frage wäre, wie ich das von LBS-Seite her umgehen könnte. Man könnte x-Mal versuchen und dann erst aufgeben, aber das kann dann bei vielen LBS mit gleichzeitigem trigger auch dazu führen, dass jeder LBS die Datei lädt und entpackt. Alternativ könnte ein separater LBS sich um download und entpacken kümmern und anschließend die anderen LBS triggern. Das Problem ist also, dass aktuell alle meine DWD-LBS im Fall einer veralteten lokalen Datei bei gleichzeitigem Trigger auch gleichzeitig die neue Datei laden und diese dann mehrfach überschreiben (oder dies zumindest versuchen).

Ein Trigger-Ausgang (oder ein Wertauslöser an einem der Ausgänge) könnte auch eine Lösung sein, da man dann die Einzelabfragen kaskadieren kann und alle Folge-LBS auf die aktuellen Daten zugreifen. Vielleicht so:

2019-07-29 08_10_57-EDOMI · Administration.png

[ak68]

Es kann gut sein, dass bei gleichzeitigem Trigger die Datei blockiert ist und nicht entpackt werden kann. Das könntest du vielleicht mit Verzögerungs-LBS testen. Ich denke, dass hier minimale Werte reichen sollten.

Verzögerung: 3000ms -> KEINE Fehlermeldung mehr !

Ein Trigger-Ausgang (oder ein Wertauslöser an einem der Ausgänge) könnte auch eine Lösung sein, da man dann die Einzelabfragen kaskadieren kann und alle Folge-LBS auf die aktuellen Daten zugreifen. Vielleicht so:

2019-07-29 08_10_57-EDOMI · Administration.png

Auch diese Lösung klappt ohne Fehlermeldungen !

[crewo]

Die Frage wäre, wie ich das von LBS-Seite her umgehen könnte.

Wie wäre ein eigener LBS der nur die Datei abholt und ablegt? Einstellbar wie oft. Alle anderen bleiben, holen aber kein File mehr ab sondern nutzen nur noch das lokale.

[vento66]

Oder der LBS prüft das Alter der heruntergeladenen Daten, und nur wenn älter als z.B 1h dann neu herunterladen. Machen die Darksky LBS auch so.

[MrIcemanLE]

Wie wäre ein eigener LBS der nur die Datei abholt und ablegt? Einstellbar wie oft. Alle anderen bleiben, holen aber kein File mehr ab sondern nutzen nur noch das lokale.

Diese Idee finde ich garnicht schlecht. Sie hat aber den Makel, dass alle Nutzer daran denken müssen auch den Download-Unzip-LBS zu nutzen.

Oder der LBS prüft das Alter der heruntergeladenen Daten, und nur wenn älter als z.B 1h dann neu herunterladen. Machen die Darksky LBS auch so.

Das habe ich auch so drin. Das Problem entsteht aber, wenn mehrere Instanzen des LBS gleichzeitig getriggert werden. Wie ak68 gezeigt hat besteht das Problem nicht, wenn die LBS kaskadiert werden, da der Folge-LBS dann erkennt, dass die Datei aktuell ist. Bei gleichzeitigem Trigger kommt es eben zu Zugriffsproblemen beim Entpacken oder beim Laden der Datei.

Vielleicht wäre auch eine zufällige Verzögerung (0s - 3s) eine Lösung. Einer der LBS ist dann halt der Erste ;-)
Oder könnte man Prüfen ob ein anderer EXEC Teil des gleichen LBS-Typ gerade läuft? Dann könnte man mit einer kleinen while()-Schleife auf die anderen warten. Gibt es einen Instance-Counter o. ä.? ( gaert )

Wenn ich den Abruf aus dem EXEC-Teil raus nehme wäre die Logik-Engine kurz blockiert, wären geladen und entpackt wird und erst dann laufen die anderen LBS ab. Aber das ist möglicherweise Problematisch, wenn der Download mal lange dauert. Im EXEC Teil sind die Sachen schon gut aufgehoben.