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

[chris1284]

Evtl den support mal kontaktier

[chris1284]

Meine persönliche Meinung:
- es gibt mittlerweile genug Wetter(-vorhersage) Module

um so besser wenn man dann nur noch gds braucht und sich nicht mir mehr modulen befassen muss

- gerade beim GDS-/DWD-Modul habe ich KEINE passende Messstelle in der Nähe (obwohl es laut DWD eine geben soll)

schade für dich

- kleine Module, die nur "eine" Sache, die dafür "richtig" können, finde ich übersichtlicher und stabiler

große module die alles liefern was man braucht und die "sachen richtig"  können sind nicht zwangsläfig unübersichtlich und / oder stabil. der dwd liefert alles was man braucht, warum nicht auch nutzen

[Hollo]

Ich habe ja auch extra geschrieben, dass es meine persöniche Meinung ist.
Für MICH liefert er das nicht, weil die Wetterdaten zu weit entfernt sind.

Außerdem ist das GDS-Modul in der bisherigen Form leider Blocking-Kandidat, der bei mehreren/vielen zu Disconnects des HMLAN führt.
Wenn das gleichzeitig behoben wird und mit den Erfahrungen aus den anderen Wettermodulen (Beispiel: korrekte Wetter-Bildchen-Zuordnung) eine ideale Lösung gefunden wird, habe ich gar nichts dagegen.

[jensb]

• Blocking
  
  

  Außerdem ist das GDS-Modul in der bisherigen Form leider Blocking-Kandidat ...

  
  Das GDS-Modul ist während des FTP-Transfers ein Blocker, da dieser Vorgang meist mehrere Sekunden benötigt und in seiner Dauer auch noch abhängig ist von der Größe der übertragenen Dokumente und der Verbindungsgeschwindigkeit. In diesem Punkt hilft es auch nichts, von Textdokumenten auf XML-Dokumente zu wechseln. Eine mögliche Lösung wäre es, den FTP-Transfer asynchron in einem eigenen Thread auszuführen. Das würde aber dem Styleguide von FHEM widersprechen. Allerdings nutzen einige Module bereits erfolgreich Threads, so dass das im Endeffekt in der Verantwortung des Entwicklers liegt. Eine Alternative wäre es, einen GDS-Transfer-Dienst in Perl zu schreiben, der parallel zu FHEM gestartet wird und z.B. eine TCP-Verbindung zwischen FHEM und dem Dienst für die Steuerung zu verwenden. Dies würde aber das Handling für viele User erschweren. Beide Varianten lösen das Problem, sind aber nicht mal eben gemacht.
  
  Durch die von mir derzeit gewählte Aufteilung der FTP-Transfers wird die Blockdauer nicht verlängert sondern verteilt. In den Übertragungspausen kann FHEM dann andere Module bedienen.
  
  Ich würde für eine Verbesserung die Thread-Variante vorziehen, da der FTP-Transfer nicht auf FHEM-Daten zugreifen muss und damit nicht wirklich Multithreading/Locking-Probleme auftreten können. Eine derartige Verbesserung sollte aber erst in einem zweiten Schritt erfolgen. Da die Funktionserweiterungen optional sind und konfiguriert werden müssen, entsteht kein Problem für User, die die neuen Funktionalität nicht benötigen.
  
  


• Weblink
  
  Was ich in den Rückmeldungen vor allem vermisse, ist eine Kritik an dem HTML-Generator. Er ist vom Aufbau her aus dem Weather-Modul übernommen, aber aufgrund der GDS-Datenlage entsprechend modifiziert. Für mich haben sich bei der Implementierung mehre Fragen gestellt:
  
  
  
  
  
  • Macht es überhaupt Sinn, einen Weblink-Generator in einem Modul zu integrieren oder sollte man das nicht den Users überlassen?
    Es gibt mehrere schöne Beispiele für gelungene Wettervorhersagedarstellungen im Forum. Was trotzdem für eine Integration spricht, ist, dass man so zumindest für den Einstieg sofort eine funktionierende Lösung hat.
  
  
  • Sollte man die Darstellung vielleicht anders gestalten?
    Hier könnte man wahrscheinlich noch etwas verbessern, aber ich habe kein geübtes Händchen für HTML/CSS und beschränke mich daher auf das wesentliche.
  
  
  • Sollte man für den aktuellen Tag statt 2 Elementen (Aktuell/Spät bzw. Aktuell/Nacht) vielleicht 5 oder eine von der Uhrzeit abhängige variable Anzahl zwischen 1 und 5 anzeigen?
    Variable Breiten können bei bestimmten Darstellungen ein Problem sein und 4 Elemente, die abhängig von der Uhrzeit bedeutungslos werden, fand ich auch nicht gut. Allerdings kann man so nicht alle verfügbaren Daten darstellen. Gerade Morgens fehlt so die Anzeige für Früh, Mittag und Nacht.
  
  
  • Welche zusätzlichen Funktionen könnte man in die Darstellung integrieren?
    Als Erweiterung könnte ich mir z.B. auch vorstellen, ein Warnsymbol mit Link auf die Details einzublenden, wenn eine Wetterwarnung vorliegt.
  
  Bitte meldet euch, falls ihr hierzu Ideen, Wünsche oder Lösungen habt.
  
  


• Maintainer
  
  betateilchen hat mir gestern geantwortet und mitgeteilt, dass er momentan keine Zeit hat, sich um die Erweiterung zu kümmern. Werde mich um einen SVN-Account kümmern.
  
  


• Wie geht es weiter
  
  
  
  
  • Umbenennen der Vorhersage-Readings analog zum Proplanta-Modul in "fc?_..." wobei "?" die Nummer des Tages ist und 0 der aktuelle Tag
  
  
  • Zusammenfassen der Readings für einen Tag:
    
    
    
    • fc?_weekday
    • fc?_tMinAir für früh
    • fc0_tAvgAir12 für mittags am aktuellen Tag
    • fc?_tMaxAir für spät
    • fc0_tAvgAir24 für nachts am aktuellen Tag
    • fc0_weather06
    • fc?_weather12
    • fc0_weather18
    • fc?_weather24
    • fc0_windGust06
    • fc?_windGust12
    • fc0_windGust18
    • fc?_windGust24
  
  
  • Fehlersuche, um möglicherweise etwas gegen die in den anderen Threads berichteten Abstürze des unveränderten GDS-Moduls zu tun.
  
  
  • Bereitstellung eines überarbeiteten Patchs zum Testen.
  
  
  • Checkin, wenn der Test bestanden ist.
  
  
  
  

[Deudi]

Anregung: Man könnte noch eine interne PRESENCE Funktion integrieren (auf den DWD Server) und im Falle der Nichterreichbarkeit das Modul auf disabled setzen. Das mache ich derzeit "zu Fuß".

[chris1284]

zum weblink:
die fhem-oberfläche selbst nutzen sicher die wenigsten zur schönen darstellung von inhalten, da gibt es besseres (tablet-ui, smartVisu usw).
die meisten module liefern nur die daten und der user bereitet sie selbst grafisch auf (ein ks300 oder andere Wettersensoren liefert ja per modul auch kein schönes bild des aktuellen wetters ).
-> nettes feature aber nicht essenziell und zu vernachlässigen bis das modul an sich fertig ist würde ich sagen

Umbenennen der Vorhersage-Readings analog zum Proplanta-Modul in "fc? -> top, dann ist es auch einfacher es zb in fertige tui-widgets aufzunehmen, gerade wenn die icon-namen-readings passen

[jensb]

@Deudi

Mit der vorbereiteten erweiterten Fehlerbehandlung ist ein externes enable/disable vielleicht schon nicht mehr nötig. Wenn doch, würde ich anhand der Fehlerbeschreibung versuchen, Abhilfe zu finden. Generell ziehe auch ich es vor, wenn das Modul alle typischen Fehler selbst behandelt und nicht auf externe Hilfe angewiesen ist. Was war für dich der eigentliche Grund für einen PRESENCE-Test des DWD-Servers? Hattest du Blockaden oder Abstürze? Verwendest du WLAN?

@chris1284

Danke für die Rückmeldung. Bin mit den Test des geänderten Patches inzwischen zufrieden und werden ihn wohl heute Abend posten. Da ich selbst noch kein Proplanta-Modul laufen habe, weiß ich nicht, was genau in den "icon-namen-readings" steht. Bitte schau dir die neue Version mal an und melde dich, wenn dir da etwas fehlt.

LG, jensb

[Deudi]

Was war für dich der eigentliche Grund für einen PRESENCE-Test des DWD-Servers? Hattest du Blockaden oder Abstürze?

Hallo jensb,

der Grund war, dass das Modul FHEM länger blockiert, wenn die Verbindung nicht geöffnet werden kann. Daraufhin hat betateilchen auf mein Quengeln hin ein disable Attribut eingebaut, wofür ich ihm sehr dankbar bin. Siehe hier:
http://forum.fhem.de/index.php/topic,27871.0.html

Noch eine Anmerkung:
Ich schätze die Arbeit der Entwickler hier sehr und bin mir bewusst, dass das erzielte Ergebnis gelegentlich auch ein Kompromiss zwischen Perfektionsgrad und Aufwand darstellt.
Aufgrund von solchen Erfahrungen habe ich allerdings eine Gewaltenteilung eingeführt, für die ich im Forum von einigen etwas belächelt wurde. Bei mir läuft auf einem Cubietruck FHEM, welches mit der einzigen Ausnahme des Yamaha-Moduls nur Homematic macht und sonst nix. Seitdem habe ich absolut keine Probleme mehr (keine Hänger, Ausfälle, Disconnects, whatever...).
Auf einem zweiten Cubietruck läuft FHEM mit allem möglichen anderen Gedöns (Yahoo, GDS, InfoPanel, RSS, Hue, ...) und da ist es mir Wurscht, wenn alles mal ein paar Sekunden steht. Für mich ist das DIE Lösung aller erdenklichen Probleme.

Grüße!

[jensb]

@Deudi

Von deiner Beschreibung her gehe ich davon aus, dass der von mir vorbereitete Patch dir bezüglich des Blockierens keinen Vorteil bringen wird.

Das Blockieren, wenn eine Verbindung nicht hergestellt werden kann, ist typisch für TCP/IP. Je nach API kann man ein Timeout vorgeben, aber das setzt man im Normalfall nicht auf einen Wert unter einer Sekunde. Da FHEM andererseits aus guten Grund nur einen Ausführungspfad verwendet, muss alles nacheinander stattfinden, und da stört ein Blockieren und das Warten auf einen Timeout, gerade wenn es um "Echtzeit"-Kommunikation mit externen Geräten geht. Deine Idee mit der "Gewaltenteilung" ist eine mögliche Lösung, da du so das Multiprocessing bekommst, das ein FHEM allein (meist) nicht hat.

Mit dem Blocking-Modul von besteht aber die Möglichkeit, derartige Vorgänge auf nur einem System asynchron auszuführen, vorausgesetzt die CPU hat dafür noch Luft. Hierfür müssten aber alle Module, die manchmal etwas langsam sind, mit mehr oder weniger viel Aufwand umgebaut werden. Einige Entwickler haben das bereits gemacht. Habe auch schon überlegt, ob ich das GDS-Modul entsprechend anpassen sollte.

LG, jensb

[jensb]

Hallo,

anbei ein überarbeitetes GDS-Modul, das u.a. einen Teil der geäußerten Wünsche aufgreift. Wer bereits den Patch aus dem 1. Posting verwendet, sollte mit

Code Auswählen Erweitern

deletereading <GDS-Modulname> f_.*

die "alten" Vorhersage-Readings manuell löschen, da die Vorhersage-Readings nun einen Prefix wie beim Proplanta-Modul haben (siehe dazu auch die Modul-Hilfe).

Aber auch für User, die die Vorhersage-Readings nicht benötigen, könnte das überarbeitet Modul interessant sein:

• 
  FHEM sürzt nicht mehr ab, wenn man "get list capstations" aufruft und die Verbindung fehlschlägt. http://forum.fhem.de/index.php/topic,39048
  
• 
  Es wird nun der Fehlergrund mit Level 4 geloggt, wenn der FTP-Connect fehlschlägt.
  
• 
  Außerdem wird in allen Abläufen die Folgeverarbeitung nicht mehr durchgeführt, wenn ein FTP-Dokument sich nicht öffnen lässt (weil z.B. der FTP-Transfer fehlgeschlagen ist). Damit werden Folgefehler vermieden, die z.B. zu Perl-Warnings führen ("Use of uninitialized value ..."). In jedem Fall wird ein Logging mit Level 4 erzeugt, teilweise werden die Fehlermeldungen auch an das User-Interface weitergegeben. Um Letzteres aber konsequent zu machen, wären weitere Umbauten erforderlich. http://forum.fhem.de/index.php/topic,38899
  

Da Sourceforge immer noch nicht wieder ganz da ist, kann ich keinen SVN-Patch generieren. Auch einen SVN-Account habe ich daher noch nicht und mein Antrag, in die Gruppe der Developer aufgenommen zu werden, ist auch noch nicht genehmigt. Deshalb kann ich den Patch leider nicht selbst einchecken. Vielleicht kann einer der anderen Developer sagen, wie es weiter gehen könnte, da betateilchen momentan keine Zeit dafür hat.

Viel Spaß, jensb

[CoolTux]

Mal eine kurze Frage als einer der Perl lernt.

Code Auswählen Erweitern


no if $] >= 5.017011, warnings => 'experimental';


Ist das $] korrekt? Sieht so seltsam aus in meinen Augen.

[chris1284]

http://perldoc.perl.org/perlvar.html

$]

The revision, version, and subversion of the Perl interpreter, represented as a decimal of the form 5.XXXYYY, where XXX is the version / 1e3 and YYY is the subversion / 1e6. For example, Perl v5.10.1 would be "5.010001".

This variable can be used to determine whether the Perl interpreter executing a script is in the right range of versions:

        warn "No PerlIO!\n" if $] lt '5.008';

When comparing $] , string comparison operators are highly recommended. The inherent limitations of binary floating point representation can sometimes lead to incorrect comparisons for some numbers on some architectures.

See also the documentation of use VERSION and require VERSION for a convenient way to fail if the running Perl interpreter is too old.

See $^V for a representation of the Perl version as a version object, which allows more flexible string comparisons.

The main advantage of $] over $^V is that it works the same on any version of Perl. The disadvantages are that it can't easily be compared to versions in other formats (e.g. literal v-strings, "v1.2.3" or version objects) and numeric comparisons can occasionally fail; it's good for string literal version checks and bad for comparing to a variable that hasn't been sanity-checked.

[CoolTux]

Hallo Chris

Ich Danke Dir herzlich für den Text, hättest aber auch einfach sagen können ist korrekt so, ich hätte mich dann informiert. Wollte keine Arbeit machen   
Ich danke Dir aber für Deine Arbeit. Dann gehe ich mal weiter lernen


Grüße

[chris1284]

muss ich eigentlich die forcast selbst aktualisieren oder macht dass das modul selbst alle xxxx sekunden?
ein readingsupdate wäre super. die aktuelle lösung über at's alles selbst zu holen ist irgendwie bäh.
aktuell

Code Auswählen Erweitern

get gdswetter radarmap Nordwest;
get gdswetter conditionsmap Nordwest;
get gdswetter warningsmap Niedersachsen;
get gdswetter forecastsmap Nordwest_morgen_frueh;
set gdswetter clear alerts;
get gdswetter alerts 103241000;
get gdswetter conditions Hannover-Flh.;

man könnte ja attribute der zu holenden daten einbauen und als wert die location zb (und das am besten schön als multiselect)

Code Auswählen Erweitern

attr gdswetter warningsmap Niedersachsen
attr gdswetter conditionsmap Nordwest
attr gdswetter forecastsmap Nordwest_morgen_frueh
attr gdswetter alerts 103241000
attr gdswetter conditions Hannover-Flh.
den timer sollte man auch per attr setzen können

Code Auswählen Erweitern

attr gdswetter refreshtimer 3600

für mich wäre es toll wenn man die, für mich nutzlosen, bilder abstellen könnte und den damit verbunden HTTPSRV GDS Files. die bilder hole ich mir zb wo anderst her, ich brauch nur die rohdaten.
spart zu dem etwas last ein auch wenn die bilder nicht groß sind

Code Auswählen Erweitern

attr gdswetter httpsrv 0/1

[jensb]

In der Hilfe zum GDS-Modul steht

readings generated by SET will be updated automatically every 20 minutes

Damit werden die Conditions und Forecasts, die wenigstens einmal mit SET abgerufen worden, dauerhaft automatisch aktualisiert. Dieses automatische Aktualisieren macht auch nichts anderes. Den Aktualisierungstakt per Attribut konfigurierbar zu machen, wäre ein weiteres Feature. Ob es sinnvoll ist, habe ich noch nicht geprüft. Hierzu müsste man noch mal in die DWD-Dokumentation schauen, um herauszufinden, wie oft überhaupt neue Daten zur Verfügung stehen.

Wer die Bilder nicht braucht, holt sie sich einfach nicht. Falls der Menüeintrag "GDS Files" stört, einfach beim FHEMWEB im Attribut hiddenroom eintragen.

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

LG, jensb