Hallo,
eigentlich habe ich nur nach einer Möglichkeit gesucht, meine Gartenbewässerung auszusetzten, wenn es regnet, vor kurzem viel geregnet hat oder bald regnen wird, da ich mit direktschaltenden Bodenfeuchtesensoren nicht zufrieden bin. Das GDS-Modul habe ich schon eine ganze Zeit im Einsatz und so konnte ich einige der erforderlichen Daten auch sofort in ein "Wetterfrosch"-DOIF einbauen. Gefehlt hat nur die ortsbezogene Vorhersage von Regen, denn das GDS-Modul unterstützte bisher nur den Abruf von Vorhersagegrafiken (forecastmap).
Ein Blick in das GDS-Modul und die vom DWD verfügbaren Daten hat gezeigt, dass eine ortsbezogene Vorhersage von Niederschlag (und Starkwind) möglich ist, ähnlich wie es das Weather-Modul macht.
Der DWD stellt 4 Vorhersagen für den aktuellen Tag und je 2 für die 3 folgenden Tage in nach Regionen organisierten Textdateien zur Verfügung. Die Dateien für den aktuellen Tag werden abhängig von der Uhrzeit schrittweise durch Leerdateien ersetzt und zum Tageswechsel dauert es fast 1 Stunde, bis Daten für den neuen Tag zur Verfügung stehen. Durch eine Rotation der Vorhersage zum Tageswechsel wird das aber kompensiert.
Heraus gekommen ist der beigefügte Patch mit folgenden Eigenschaften:
- Vorhersage für eine Region als GET-Kommando in Textform (eigentlich nur um zu sehen, welche Daten zur Verfügung stehen)
- Vorhersage für eine Station als SET-Kommando als Readings mit Update alle 20 Minuten
- HTML-Generator für Weblinks, der die 4-Tage-Vorhersage entweder horizontal oder vertikal aufbereitet
Screenshots von den neuen Readings und den beiden Weblinks sind beigefügt, zusammen mit dem Patch.
Wer es ausprobieren möchte, muss vor allem das neue Attribut
gdsSetForecast konfigurieren. Das geht am einfachsten, indem man
set rereadcfg aufruft und anschließend die gewünschte Station aus der Liste von
set forecasts auswählt. Einige Stationen haben beim DWD für die aktuellen Werte und die Vorhersage leicht unterschiedliche Namen (z.B. Münster), und deshalb war das neue Attribut erforderlich. Natürlich kann man sich damit auch einen Spaß machen, indem man für die aktuellen Werte und die Vorhersage wirklich unterschiedlichen Stationen einstellt und jemandem die resultierenden Vorhersage zeigt.
Über Rückmeldungen und Anregungen würde ich mich freuen.
Viel Spaß,
jensb
Hallo,
ich finde den Patch sehr gut. Ist er mittlerweile in das offizielle GDS Modul integriert worden? Wäre doch super, wenn man auch die Forcastmeldungen bekommen kann.
*dafür*
Danke für eure positiven Rüchmeldungen.
Habe noch eine kleine Verbesserung vorbereitet, da es in der geposteten Version unmittelbar beim Neustart von FHEM ein paar hässliche Logs geben kann.
Für die mögliche Übernahme der Erweiterung fehlt mir aber noch der Kontakt zum Maintainer des GDS Moduls. Bin momentan unterwegs und komme nur selten ins Netz. Werde mich ab nächster Woche wieder darum kümmern.
jensb
http://fhem.de/MAINTAINER.txt
FHEM/55_GDS.pm betateilchen http://forum.fhem.de Unterstuetzende Dienste
betateilchen ließt jecoh, wenn überhaupt, nur als gast mit. seinen forum-account hat er gelöscht. ggf muss jemand anderes hier eingreifen und das modul / den patch einchecken
Hallo. Ich wollte das Modul gestern mal testen. Aber nach dem ich nur Abstürze von FHEM beim ziehen der Daten hatte habe ich das erstmal auf Eis gelegt. Ich würde mich sehr freuen wenn hier jemand der Ahnung hat das Modul weiter pflegen und entwickeln würde.
LG
Leon
Selber machen, und nicht nur immer von der Arbeitz anderer profitieren ?
Keine Ahnung ? - hatten wir alle mal.
pah
Zitat von: CoolTux am 08 Juli 2015, 07:46:31
Hallo. Ich wollte das Modul gestern mal testen. Aber nach dem ich nur Abstürze von FHEM beim ziehen der Daten hatte habe ich das erstmal auf Eis gelegt. Ich würde mich sehr freuen wenn hier jemand der Ahnung hat das Modul weiter pflegen und entwickeln würde.
das liegt nicht am modul, ehr an deiner installation. zur hilfe: http://fhem.de/commandref.html#GDS attribut gdsPassiveFtp könnte helfen + ein eigener post + logiles. hier sollte das nicht weiter thematisiert werden.
das modul einzuchecken sollte nicht das problem sein, support schon ehr. ich würde erstmal warten ob der gute betateilchen sich noch meldet
hallo jensb,
ich würde sagen da keine rückmeldung mehr erfolgte solltest du dir einen svn-account anlegen lassen und es einchecken.
dein modul läuft hier bisher stabil
evtl noch ein paar anmrkungen.
warum frueh/spät und nicht den ganzen tag? liefert der dwd dies nicht?
warum die readings nicht einfach halten wie im Weather? die zahlen hinter den readings sind verwirrend (0-12 0-24), warum nicht auch _frueh/_spaet?
die readings der tage bei einander und nicht verstreut wäre auch schöner (fc1_weakday, fc1_minair, fc1_maxair, fc1_... / fc2_weekday usw bzw fc1_weakday, fc1_minair_frueh, fc1_minair_spaet)
warum den forcast nicht per attribut auf 1-4 tage stellen und dann die daten holen anstatt forcast heute, forcat morgen, forcast übermogen, forcast für tag 4?
Attribut gdsSetForecast sollte ein multiselect der verfügbaren stationen bekommen so das dann zb steht attr gds gdsSetForecast Nordwest....
Meine persönliche Meinung:
- es gibt mittlerweile genug Wetter(-vorhersage) Module
- gerade beim GDS-/DWD-Modul habe ich KEINE passende Messstelle in der Nähe (obwohl es laut DWD eine geben soll)
- kleine Module, die nur "eine" Sache, die dafür "richtig" können, finde ich übersichtlicher und stabiler
Dementsprechend hätte ich nichts dagegen, wenn man das GDS-Modul so lassen würde wie es ist.
Abgesehen von evtl. erforderlichen Fehlerbereinigen natürlich.
@chris1284
Bitte sieh dir nochmal mein 1. Posting an. Der DWD liefert für den aktuellen Tag 6-Stunden-Vorhersagen und für die Folgetage 12-Stunden-Vorhersagen. Je nach Vorhersagestunde werden min, mittel oder max-Temperaturen zur Verfügung gestellt. Habe mich deshalb dafür entschieden, als Postfix der Readings die letzte Gültigkeitsstunde zu verwenden. Es ist so zumindest eindeutig. Natürlich könnte man auch morgens, frueh, mittags, spaet und nachts im Namen verwenden, aber das reduziert die Eindeutigkeit wieder.
Im Präfix mit fc zu beginnen, habe ich inzwischen auch schon erwogen, und auch fc1 bis fc4 wären möglich.
Auf die Frage, warum die Forecasts nacheinander geholt werden: Die Modul-Infrastruktur kann derzeit noch kein FTP mget sondern immer nur ein Dokument holen. Holt man die Dokumente alle einzeln unmittelbar hintereinander, wird FHEM zu lange blockiert. Man könnte allerdings über ein Attribut die Tagesanzahl einstellbar machen, die vom DWD abgefragt wird.
Ob man dem Attribut gdsSetForecast eine Auswahlliste der Stationen zur Eingabeunterstützung zur Verfügung stellen kann, werde ich mir ansehen.
Habe gestern versucht, betateilchen, den aktuellen Maintainer des Moduls per Mail zu erreichen, aber noch keine Antwort erhalten. Sollte es dabei bleiben, werde ich die Anpassungen posten und mir einen SVN-Account zum einchecken besorgen.
LG, jensb
@Hollo
Wie du selbst sagst, gibt es bereits viele Wettervorhersagemodule. Die meisten bieten zumindest eine genauere Ortsauswahl und mehr Daten. Ob die Vorhersagequalität dadurch besser ist, sei dahin gestellt.
Das GDS Modul ist aber meines Wissens das Einzige mit Wetter Made in Germany eines nichtkommerziellen öffentlichen Anbieters. Das kann je nach persönlichem Datenschutzbedürfnis für den einen oder anderen auch ein Grund sein, kein weiteres Modul einzusetzen oder dieses Modul nicht einzusetzen.
Der DWD bietet sehr viel mehr Daten an, als das Modul bisher abfragt. Hier ist noch Luft nach oben. Eine Funktionserweiterung sollte die Stabilität natürlich nicht negativ beeinflussen und optional sein. Die Modulgröße allein kann aber kein Kriterium sein (sonst hätten wir heute vielleich immer noch CPM oder MS-DOS ;)).
Die Messstellen des DWD sind leider nicht immer auch Meldestellen. Die nächste Messstelle ist bei mir keine 10 km entfernt und die nächste Meldestelle über 30 km.
LG, jensb
Es ist einfach Käse, diese Daten jeweils als Klartext zu holen. Es gibt vor allem beim DWD sehr viel intelligentere Formate, die Wetterdaten enthalten - und damit wäre FHEM auch nicht "blockiert".
Eine genaue Erklärung, wo welche Daten der Grundversorgung zu finden sind, gibt es auf dem FTP-Server des DWD in der Datei /help/legend_basic_service_level.pdf
LG
pah
Bei der Implementierung der Vorhersage habe ich die vorhandene Funktionsweise des Moduls aufgegriffen, wobei das Parsen der im Verzeichnis gds/specials hinterlegten Textdokumente definitiv in die Kategorie "Käse" fällt.
Die vom DWD zur Verfügung gestellten XML Dokumente sind ein großer Fortschritt, aber es gibt scheinbar nicht für alle Wetterdaten XML-Varianten. Das PDF vom DWD kenne ich und da hatte ich gesucht, bevor ich überhaupt angefangen habe, doch nichts passenderes für Ortsvorhersagen gefunden und mich daher für die Position 25 im PDF entschieden.
Wenn jemand weiß, wo der DWD eine modere Variante der GDS-Ortsvorhersage versteckt hat, wäre ich für einen entsprechenden Tip dankbar.
LG, jensb
Evtl den support mal kontaktier
Zitat von: Hollo am 15 Juli 2015, 12:39:00
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
Zitat von: Hollo am 15 Juli 2015, 12:39:00- 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
Zitat von: Hollo am 15 Juli 2015, 12:39:00- 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
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.
- Blocking
ZitatAuß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.
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ß".
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
@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
Zitat von: jensb am 21 Juli 2015, 15:23:44
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 (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!
@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
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
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 (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 (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
Mal eine kurze Frage als einer der Perl lernt.
no if $] >= 5.017011, warnings => 'experimental';
Ist das $] korrekt? Sieht so seltsam aus in meinen Augen.
http://perldoc.perl.org/perlvar.html
Zitat$]
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.
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 ;D
Ich danke Dir aber für Deine Arbeit. Dann gehe ich mal weiter lernen
Grüße
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
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)
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
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
attr gdswetter httpsrv 0/1
In der Hilfe zum GDS-Modul steht
Zitatreadings 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:
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
Zitat von: jensb am 22 Juli 2015, 20:05:13
Die Abrufe mit GET sind auf einen externen Trigger angewiesen. Wer nur die Alterts benötigt, kommt mit folgendem AT aus:
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.
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.126Ließ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.
@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.
@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
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).
@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 ...
Zitatangedachten Ä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.
@jensb:
Zitat von: jensb am 06 September 2015, 11:48:48
@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.
@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.
Zitat von: jensb am 07 September 2015, 20:16:37
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.
@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.
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 8)
- 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.
@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.
Diesen Thread hattest Du gesehen? 55_GDS.pm - komplett überarbeitet - RC1 (http://forum.fhem.de/index.php/topic,42015.0.html)
Das hat sich wohl gerade ein bisschen überschnitten - du müsstest inzwischen eine PM von mir haben.
*grusel*
Es gibt inzwischen CAP-Meldungen ohne "expire"... das bringt die ganze Anzeigelogik meiner InfoPanels durcheinander :(
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.
Zitat von: jensb am 10 Oktober 2015, 22:56:23
Werde den Generator wahrscheinlich nächste Woche auf das neue GDS-Modul umstellen und nach 99_myUtils verschieben.
in contrib/55_GDS.2015 habe ich bereits eine 99_gdsUtils.pm eingecheckt, die den bisher von Dir beschriebenen Generator komplett enthält. Den kannst Du gerne als Grundlage verwenden und weiterpflegen.
Danke für die Info, das werde ich machen.
Hallo Jens,
noch ein Tipp zu dem Thema: Die sub GDSAsHtmlD($;$) musst Du Dir nochmal genau anschauen.
Hintergrund:
Moduldateien mit 99_ am Anfang werden beim fhem Start vor allen anderen Modulen geladen. Zu diesem Zeitpunkt gibt es noch keine FHEMWEB Instanz, die $FW_ss bereitstellt.
Das Tückische an solchen Punkten in den 99er-Dateien ist, dass das immer erst beim nächsten Systemstart auffällt 8)
Tendenziell würde ich dazu raten, die Datei nicht als 99_ Datei anzulegen, sondern als GDSweblink.pm Die Datei könnte man dann per eval {} in 55_GDS laden.
eval { use GDSweblink; };
Hallo betateilchen,
mit eval könnte man wahrscheinlich auch von 99_myUtils auf GDSweblink zugreifen, ohne dass es Startprobleme gibt und damit die Integration in das GDS-Modul umgehen. Andereseits hätte man mit der indirekten Integration in das GDS-Modul eine funktionsfähige Standardimplementierung zur Hand, ohne dass zusätzlicher Code für die Nutzung nötig ist und die sich jeder bei Bedarf immer noch selbst anpassen kann, ohne das GDS-Modul dabei ändern zu müssen. Die Entscheidung liegt bei dir.
Es juckt mir zwar in den Fingern, es gleich auszuprobieren, aber mein RPi ist für die nächsten 6 Tage mehr als 600 km zu weit weg zum Entwickeln.
Bei mir habe ich das jetzt wie oben beschrieben umgesetzt.
Dein gesamter html Generator - ohne jede Änderung - befindet sich in der Datei GDSweblink.pm
In der 55_GDS.pm steht dann einfach
...
eval { use GDSweblink; };
no if $] >= 5.017011, warnings => 'experimental';
my ($bulaList, $cmapList, %rmapList, $fmapList, %bula2bulaShort, %bulaShort2dwd, %dwd2Dir, %dwd2Name,
$alertsXml, %capCityHash, %capCellHash, $sList, $aList, $fList, $fcmapList, $tempDir, @weekdays);
...
Und das funktioniert hier einwandfrei :)
Die Lösung hat gegenüber der 99_ den Vorteil, dass der Generator nur dann von fhem geladen wird, wenn auch das GDS Modul geladen wird.
Die 99_gdsUtil würde IMMER automatisch geladen, auch wenn der Benutzer beispielsweise alle gds-Devices gelöscht hat und nicht daran denkt, diese 99_Datei wieder aus ./FHEM zu entfernen.
Super, dann lassen wir das so. Ist kein GDSweblink da, stellt das GDS-Modul "nur" seine Backend-Funktionen zur Verfügung, und wenn es geladen werden kann, dann wird es bunt.
Im anstehenden RC2 (kommt vermutlich noch heute) werde ich das so veröffentlichen.
Und in der MAINTAINER.txt werde ich Dich als Supporter für den Weblink eintragen :)
ZitatEs juckt mir zwar in den Fingern, es gleich auszuprobieren, aber mein RPi ist für die nächsten 6 Tage mehr als 600 km zu weit weg zum Entwickeln.
Für solche Fälle habe ich einen Cubietruck mit 60GB SSD und eingebautem Akku als "Unterwegs-Entwicklungssystem" 8)
Vielleicht sollte ich mr auch so einen mobilen Begleiter zulegen, aber ich weiß jetzt schon, dass meine Frau die Augen verdrehen wird, wenn ich den mit einpacke ;D.