[patch] GDS 4-Tage-Wettervorhersage für einen ausgewählten Ort

[Motivierte linke Hände]

Die Abrufe mit GET sind auf einen externen Trigger angewiesen. Wer nur die Alterts benötigt, kommt mit folgendem AT aus:

Code Auswählen Erweitern


get gdswetter rereadcfg;
get gdswetter alerts <cellid>;

Auch das "set clear alerts" kann entfallen, da es automatisch beim "get alerts" erfolgt. Auf das "get rereadcfg" kann man dagegen nicht verzichten (siehe Modul-Hilfe).

rereadcfg verursacht hier einen Freeze von teilweise mehr als 8 Sekunden.

Code Auswählen Erweitern

2015.09.05 14:00:05 1: at_readGDS: Start
2015.09.05 14:00:13 1: at_readGDS: Stop
2015.09.05 14:00:13 1: Perfmon: possible freeze starting at 14:00:05, delay is 8.126

Ließe sich das ggf. auch noch nonblocking gestalten?

Auch die Abrufe der Bilder per ftp verursachen jeweils einen Freeze, aber das kann man ja auch extern über einen Cronjob erledigen, das muss nicht aus FHEM gestartet werden.

[betateilchen]

@jensb: Du kannst ja mit dem GDS Modul gerne machen und schrauben was Du willst. Aber bitte mach dann ein neues Modul mit eigenem Namen daraus und komme nicht auf die Idee das Modul unter gleichem Namen einzuchecken oder bereitzustellen!

Die von Dir angedachten Änderungen/Erweiterungen sind schlichtweg nicht abwärtskompatibel zu bestehenden Installationen.

Was das Thema nonblocking angeht: Es gab das Modul schon in einer nb-Version. Da traten dann aber noch ganz andere Probleme auf, weshalb diese Änderungen wieder zurückgedreht werden mussten (glücklicherweise bin ich mit dieser Erfahrung als Modulautor nicht alleine).

Eine presence Prüfung auf den DWD Server halte ich für ziemlich sinnlos, da ich noch nie den Fall hatte, dass der DWD Server nicht erreichbar gewesen wäre. Wenn es Verbindungsprobleme gab, lag es bisher immer an anderen Faktoren der Internetverbindung, nicht aber am DWD Server selbst.

[jensb]

@Motivierte linke Hände: Deine Zeiten für get rereadcfg/get alerts decken sich mit meinen eigenen Messungen. Das ist im Wesentlichen die FTP-Übertragungszeit.

Die Stabilität von verschiedenen Parallelisierungsverfahren in unterschiedlichen Szenarien kann ich nur bedingt bewerten. Habe mit dem Blocking-Modul von rudolfkoenig ein eigenes Modul entsprechend optimiert und auf dem RPi 2.0 keine Nebenwirkungen.

@betateilchen: Danke für die Rückmeldung, für mich selbst habe ich natürlich eine eigene Modulvariante und ich habe nicht vor, ein Konkurrenzmodul zu erstellen und einzuchecken. Mein bisheriger Beitrag, also vor allem die Vorhersagefunktion, war ein eigenes Experiment, das ich in diesem Thread vorgestellt haben. Wenn du die Zeit dafür haben solltest, würde ich mich freuen, wenn wir damit noch mal neu anfangen könnten.

LG, jensb

[Motivierte linke Hände]

Mein (sicher nicht sehr elegantes, aber funktionierendes) Skript zum Holen aktueller Karten außerhalb von FHEM habe ich nun mal ins Wiki gestellt. Vielleicht hilft's ja dem einen oder anderen.

@jensb: Wenn Du irgendwo eine Version hast, die rereadcfg non-blocking ausführt, wäre es super, wenn Du sie hier anhängen würdest. Ich habe mir mal Blocking.pm angesehen, aber da ich quasi gar keine Perl-Kenntnisse habe, bräuchte ich wohl mehrere Wochen, um das sub retrieveFile und dann danach initDropdownLists auf non-blocking umzuschreiben (bzw. diese entsprechend aufzurufen).

[jensb]

@Motivierte linke Hände

Habe das GDS-Modul auch in meiner Version bisher nicht auf NB umgestellt, vor allem weil dies eine grundlegende Änderung am Modul ist, die ohne die Beteiligung von betateilchen keinen Sinn macht und ich kein Freund von Forks der Standardmodule bin. Da betateilchen das NB schon ausprobiert hat und nicht zufrieden mit der Stabilität war, stehen die Chancen für eine Integration schlecht, obwohl ich mir sicher bin, dass man das GDS-Modul auch so erweitern könnte, das es abhängig von einem Attributwert NB optional unterstützt, wenn auch nur experimentell.

Das Blocking-Modul kann man meines Wissens nach nicht ohne weiteres in einem at- oder notify-Skript einbinden, um andere Abläufe zu parallelisieren, es eignet sich mehr für die Anwendung innerhalb eines Moduls.

@betateilchen

Du hast geschrieben, dass die von mir ...

angedachten Änderungen/Erweiterungen ... schlichtweg nicht abwärtskompatibel zu bestehenden Installationen

sind. Wenn man die Diskussionen weglässt, die sich nach der Vorstellung des 1. Patches ergeben haben, reden wir eigentlich von der Erweiterung des Moduls um die Vorhersagefunktion. Diese Erweiterung ist ein reines Add-On und ich kann nicht nachvollziehen, warum diese Erweiterung nicht abwärtskompatibel realisiert sein soll. Die neue Funktion wird nicht von selbst aktiv sondern muss genau wie "get conditions" manuell aktiviert werden. Tut man das nicht, bleibt die ursprüngliche Funktion des Moduls unverändert.

[Motivierte linke Hände]

@jensb:

@Motivierte linke Hände
Das Blocking-Modul kann man meines Wissens nach nicht ohne weiteres in einem at- oder notify-Skript einbinden, um andere Abläufe zu parallelisieren, es eignet sich mehr für die Anwendung innerhalb eines Moduls.

So weit ist das klar. Ich hatte daher ja auch schonmal in den Modulcode geschaut. So wie ich den Code verstehe, müsste man...

• das sub retrieveFile auf non-blocking umstellen, um den FTP-Transfers am Blocken zu hindern. In 90% der Fälle muss danach nichts weiter im Modul erfolgen, so dass ich mir das Umstellen auf forken (mit Blocking.pm) an dieser Stelle nicht so schwierig vorstelle.
• rereadcfg braucht wohl zusätzlich noch initDrowdownListe nachdem zwei Transfers durchgeführt wurden. Zum weiteren Ausführen nach Transfers bietet Blocking.pm zwar auch Möglichkeiten, aber da fehlt's mir am Detailwissen.

Bis ich an der Stelle weiterkomme, läuft nun erstmal FTP per Skript und rereadcfg sehr selten.

[jensb]

@Motivierte linke Hände

So weit ich das sehe, blockiert nur sub retrieveFile länger als es wünschenswert wäre. Alle anderen blockierenden Abläufe, also auch set rereadcfg, nutzen aber diese sub, wenn auch z.T. indirekt. Wenn man also retrieveFile asynchron ausführt, ist das Problem gelöst. Aufgrund der Ablaufverkettung von retrieveFile und den unterschiedlichen individuellen Verarbeitungsabläufen sind aber für das Wiederaufnehmen des "äußeren" Ablaufs nach dem asynchronen Aufruf von retrieveFile signifikante Codeumstrukturierungen erforderlich.

betateilchen hatte geschrieben, dass es schon eine NB-Version des GDS-Moduls gab. Laut SVN-Repository wurde dazu ein nicht blockierender FTP-Client (Coro::LWP) verwendet und nicht das Modul umgebaut. Dieser FTP-Client hat aber bekannte Nebenwirkungen, u.a. auf das Perl select, die möglicherweise der Grund waren, warum diese Änderung zurückgezogen wurde.

Ein Umbau des GDS-Moduls auf asynchronen FTP-Transfer ist möglich (z.B. mit dem Blocking-Modul: $blockingFn =  retrieveFile und $finishFn als Wiedereintrittspunkt für die Verzweigung in die vorhandenen Abläufe), auch mit gleichzeitiger Abwärtskompatiblität. Meiner Meinung nach gehört diese Diskussion aber in einen eigenen Thread, da sie nur wenig mit der Vorhersagefunktion zu tun hat und auch auf einige andere Module zutrifft, zu denen interessanterweise auch andere Wettermodule zählen.

[betateilchen]

betateilchen hatte geschrieben, dass es schon eine NB-Version des GDS-Moduls gab. Laut SVN-Repository wurde dazu ein nicht blockierender FTP-Client (Coro::LWP) verwendet und nicht das Modul umgebaut

Falsch.

Die Versuche mit Coro::LWP waren einige Zeit später und haben nichts mit dem Umbau zu tun, den ich meinte.

[betateilchen]

@jensb: ich habe gerade versucht, Deine Vorschläge in die neue Modulversion einzuarbeiten. Das meiste habe ich ja verstanden, einiges davon wird aber letztendlich anders eingebaut werden, da sich in der neuen Modulversion eine Menge interner Abläufe ändern werden. Nein, nonblocking ist derzeit noch kein Thema.

Aber was Du da in GetUpdate() getrieben hast, erschließt sich mir nicht.
Laß uns da mal per email drüber philosophieren.

[betateilchen]

Es geht voran...

An der vorgeschlagenen Aufbereitung der forecasts habe ich einige Anpassungen vorgenommen:

• use FileRead instead of own I/O
• do not set empty readings
• allow temperature readings below zero degrees, too 
• delete all fc_.* readings in case of new station selection
• read forecasts on startup if attr gdsSetForecasts was already defined before

Den Sinn/Nutzen des html-Generators halte ich für sehr begrenzt.
Ob man den wirklich im GDS Modul haben sollte, weiß ich noch nicht genau.

[jensb]

@betateilchen: Sorry, aber hatte die ganze Woche keinen brauchbaren Netzzugang, sonst hätte ich mich eher melden können.

Vom Sinn der Integration des HTML-Generator in das GDS-Modul bin ich auch nicht überzeugt. Habe das nur gemacht, um "mal eben" zu sehen, was geht und weil ich das auch im Weather-Modul so gefunden hatte. Der Generator passt aber bei Bedarf auch gut z.B. ins eigene 99_myUtils.

Der Abruf der Forecasts benötigt mehrere zusätzliche File-Transfers und insgesamt relativ viel Zeit. Um FHEM nicht noch weiter zu belasten und nicht FTP mget nachrüsten zu müssen, habe ich statt dessen das GetUpdate so angepasst, dass es die Conditions wie zuvor als erstes holt und sich anschließend mehrfach selbst aufruft, um jeweils ein Forecast-Häppchen zu verarbeiten. Dadurch ist FHEM nicht die ganze Zeit am Stück blockiert und kann zwischen den einzelnen File-Transfers immer wieder andere Module bedienen. Effektiv werden so die Conditions wie zuvor synchron und die Forecasts kurz hintereinander asynchron geladen. Das kann man z.B. auch an den zeitversetzten Farbumschlägen der Werte sehen, wenn man über FHEMWEB beim Update der Forecasts zusieht, da das Ganze ja insgesamt mehrere Sekunden benötigt.

[betateilchen]

Diesen Thread hattest Du gesehen? 55_GDS.pm - komplett überarbeitet - RC1

[jensb]

Das hat sich wohl gerade ein bisschen überschnitten - du müsstest inzwischen eine PM von mir haben.

[betateilchen]

*grusel*

Es gibt inzwischen CAP-Meldungen ohne "expire"... das bringt die ganze Anzeigelogik meiner InfoPanels durcheinander

[jensb]

Scheinbar hat man beim DWD gemerkt, dass man manche Dinge nicht vorhersagen kann .

Habe meine experimentelle CAP-Erweiterung für den HTML-Generator noch mal diesbezüglich angesehen und da sieht es auch nicht besser aus - Alerts ohne Endezeit werden momentan nicht angezeigt. Werde den Generator wahrscheinlich nächste Woche auf das neue GDS-Modul umstellen und nach 99_myUtils verschieben.