Modul für DWD Open Data

[Ingo298]

Wo wird die Datei vom DWD gespeichert, kann es auch ein Fehler im Download sein ?
im tmp verzeichnis wird eine Datei vom Benutzer FHEM erstellt diese hat aber nur 0 Byte

[DS_Starter]

Die Datei wird nicht gespeichert sondern direkt im RAM verarbeitet. Im tmp Verzeichnis wird der herausgelesene Nutz-Inhalt als File temporär gespeichert. Jens kann da sicher mehr dazu sagen.
An Download Fehler glaube ich nicht. Die sollten vom Modul erkannt werden und soetwas tritt auch nicht ständig auf.

[jensb]

Hallo Heiko,

danke für den Hinweis mit dem Timeout von HttpUtils_BlockingGet. Hier das Attribut downloadTimeout zu verwenden macht Sinn. Allerdings sprengt der Default von 60 s die zuvor aufeinander abgestimmten differenzierten Timeouts mehrere interner Prüfungen, die alle davon ausgehen, dass der Download max. 30 s dauern kann.

Eine einfache Lösung besteht darin, den maximalen Wert für downloadTimeout auf 30 s zu begrenzen, dann kann die aktuelle Logik bleiben.

Grüße,
Jens

[stefanru]

Hi Ingo,
das ist ja sehr seltsam.
Ich habe auch eine RPI4 und bei mir funktioniert es.
Im Moment fehlt mir jegliche Idee was das sein könnte.

Sollen wir etwas vergleichen?
Ich benutze noch:
cat /etc/*release

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Hast du schon auf Bookworm aufgesetzt?

Gruß,
Stefan

[DS_Starter]

Nabend Jens,

bei solchen Abhängigkeiten agiere ich meistens so, dass ich einen einstellbaren Master-Timeout nutze und alle anderen davon abhängigen Timeouts mit einem Teiler davon ableite.
Z.B.

$to  = AttrVal (.... , 60);   
$to1 = $to * 0.75;
$to2 = $to * 0.5;
...

Vllt. ist es auch für diesen Fall eine Variante.

Wie läuft deine aktuelle Entwicklungsversion mit dem neuen Timer? Kann man die schon testen?

LG,
Heiko

[jensb]

Hallo Heiko,

der vorhandene Code ist nicht auf derartige Anpassungen vorbereitet und dadurch dauert der Umbau.

Grüße,
Jens

[jensb]

Es gibt eine weitere Alpha-Version 1.17.1 des DWD_OpenData-Moduls in meinem Contrib-Verzeichnis:

Wesentliche Änderungen:

• Kein Forecast-Download, wenn sich das Dokument auf dem DWD-Server nicht geändert hat. Das spart bei "klassischer" Verwendung (MOSMIX L) mehr als 80 % der Datenmenge, ohne dass die Aktualität darunter leidet. Bei MOSMIX S sind leider keine Einsparungen möglich.
• Besser aufeinander abgestimmte Timeout-Zeiten für Download und Verarbeitung, relevant für MOSMIX S.
• Überarbeitung der Refresh-Timersteuerung.
• Kontextbezogene Anzeige der Beschreibungen von FHEM Kommandos und Attributen in FHEMWEB.
• Erweiterung der Modulhilfetext, insbesondere in Bezug auf MOSMIX S.
• Weitere Detailoptimierungen.

Hinweise:

• Diese Version ist nur eine Zwischenschritt und daher eher etwas für Experimentierfreudige. Sie löst noch nicht das bekannte RAM-Ressourcenproblem bei MOSMIX S.
• Diese Version benötigt das Perl-Modul LWP::UserAgent. Das ist kein Perl Core Modul, sollte aber im Normalfall vorhanden sein.
• Diese Version verwendet 2 unterschiedliche Methoden, um auf den DWD-Server zuzugreifen. Das könnte zu Problemen führen, wenn man einen Proxy verwendet, vor allem einen Proxy mit Authentifizierung. Bitte Testen und Rückmeldung.

[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.

Hallo Heiko,

ich habe mir die Version aus deinem contrib gezogen und den downloadTimeout auf 120 gestellt. Werde das mal testen Ein gezieltes herunterfahren von fhem habe ich definitiv nicht.

Hallo Heiko,

leider hat das Einstellen des Timeouts nicht geholfen. Gestern Abend wieder die gleiche Zeit (zwischen 22:34 und 22:46) 6 Neustarts

Bekomme wieder diese Einträge jetzt aber zusätzlich mit dem timeout.

Code Auswählen Erweitern

2024.02.28 22:41:13 0: Server shutdown
2024.02.28 22:41:13 1: Timeout for DWD_OpenData::GetForecastStart reached, terminated process 3933
2024.02.28 22:41:13 3: DWD_Forecast_Loeningen: GetForecastAbort ERROR: downloading and processing weather forecast data failed (Timeout: process terminated)
Ich werde jetzt erst mal wieder auf die offizielle DWD gehen um zu testen ob das Problem wirklich damit aufhört falls du keine andere Idee hast wonach ich noch schauen könnte?

[Ingo298]

Hi Ingo,
das ist ja sehr seltsam.
Ich habe auch eine RPI4 und bei mir funktioniert es.
Im Moment fehlt mir jegliche Idee was das sein könnte.

Sollen wir etwas vergleichen?
Ich benutze noch:
cat /etc/*release

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Hast du schon auf Bookworm aufgesetzt?

Gruß,
Stefan

PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"


Wie schon geschrieben, ich benutze noch Buster habe die Karte aus dem PI2 in den PI4 gesteckt alles läuft soweit habe dann das DWD Device auf high umgestellt da ich ja jetzt im PI4 8GB Ram habe. Könnten auch irgendwelche Module noch fehlen.   

[DS_Starter]

Moin,

@xerion, deine Fehlermeldungen sind klassische Timeouts die entweder durch lange Downloadzeiten und/oder lange Verarbeitungszeit entstehen. In beiden Fällen könnte! eine weitere Erhöhung des Attributs helfen.

Aber ... folgende Dinge passen nicht zum Bild:

1. der Fehler passiert nur in einem bestimmten Zeitraum, d.h. in den anderen Zeiten funktioniert es offensichtlich? Das spricht gegen die Notwendigkeit das Attr zu erhöhen weil der Prozess im Normalfall io ist.

2. Dieser Timeout Fehler (betrifft den Nebenprozess) ist im Prinzip nichts dramatisches und führt für sich genommen in keinem Fall zu einem regulären Server shutdown. Bei dir liegt kein Absturz vor, sondern ein normaler shutdown, zumal sogar die Reihenfolge vermuten lässt, dass zuerst shutdown ausgelöst wird und die nachfolgenden Meldungen Folgeerscheinungen darstellen.

Ich würde an deiner Stelle versuchen für diese Zusammenhänge eine Erklärung zu finden.

@Jens,
werde deine neue Version in den Test nehmen und melde mich.
Danke dir!

Grüße,
Heiko

[xerion]

@xerion, deine Fehlermeldungen sind klassische Timeouts die entweder durch lange Downloadzeiten und/oder lange Verarbeitungszeit entstehen. In beiden Fällen könnte! eine weitere Erhöhung des Attributs helfen.

Aber ... folgende Dinge passen nicht zum Bild:

1. der Fehler passiert nur in einem bestimmten Zeitraum, d.h. in den anderen Zeiten funktioniert es offensichtlich? Das spricht gegen die Notwendigkeit das Attr zu erhöhen weil der Prozess im Normalfall io ist.

2. Dieser Timeout Fehler (betrifft den Nebenprozess) ist im Prinzip nichts dramatisches und führt für sich genommen in keinem Fall zu einem regulären Server shutdown. Bei dir liegt kein Absturz vor, sondern ein normaler shutdown, zumal sogar die Reihenfolge vermuten lässt, dass zuerst shutdown ausgelöst wird und die nachfolgenden Meldungen Folgeerscheinungen darstellen.

Ich würde an deiner Stelle versuchen für diese Zusammenhänge eine Erklärung zu finden.

ja irgendwie ist das komisch. Ich teste das mal. Ich kann nur sagen das ich das Problem erst seit ein paar tagen habe und ich ziemlich zeitgleich auf das neue DWD Modul umgestiegen bin. Ich schaue mal was sich sonst noch so für Änderungen eingeschlichen haben und werde mal versuchen ein paar Sachen auszuschließen.

[DS_Starter]

Hallo Jens, @all,

bei mir läuft die Version 1.17.1 bereits den ganzen Tag sehr gut, insbesondere der Timer ausgezeichnet.
Ich habe einen kleinen Fehler korrigiert und ein paar kleine Änderungen vorgenommen.
Zum Beispiel wird fc_dwdDocTime jetzt lokaler Zeit im Reading dargestellt. Damit passt:

     fc_time  2024-02-29 15:00:00
     und
     fc_dwdDocTime 2024-02-29 15:21:49

Meine Anpassungen habe ich im Text mit "# Heiko" gekennzeichnet.

EDIT: siehe auch Post #945 mit weiterer Version

Grüße,
Heiko

[DS_Starter]

Hallo Jens,

ich habe eine Möglichkeit gefunden, LWP wieder loszuwerden und den Header mit HttpUtils_BlockingGet zu lesen.
Wenn du damit noch nicht begonnen haben solltest, würde ich einen Vorschlag erstellen.
Den kannst du dann ja wie gehabt optimieren.

Grüße,
Heiko

[Ingo298]

Hallo Leute, neuer Tag neue Meldung. Bring uns das weiter?

Code Auswählen Erweitern

2024.02.29 20:25:00 5: DWD: ProcessForecast: parsing XML document
2024.02.29 20:25:02 4: DWD: ProcessForecast ERROR: domain_29 error : Memory allocation failed : growing buffer


[DS_Starter]

Mir fällt es gerade wie Schuppen von den Augen. Du hast doch ein:

...das OS ist Buster mit 32bit ...

richtig?

32Bit -> adressierbarer Speicher max. ist 4GB!

Mehr als 4GB können nicht verwendet werden egal wieviel RAM drin steckt.
Da wirst du wohl warten müssen bis Jens eine weniger RAM fressende Version erstellt hat oder mal drüber nachdenken auf 64Bit Linux zu wechseln, was ich auf jeden Fall machen würde.