Der Deutsche Wetterdienst stellt im Rahmen seiner Grundversorgung einen unerschöpflichen Vorrat an Daten zur Verfügung, die von jedermann genutzt werden dürfen.
Zitat von: Deutscher WetterdienstDie Leistungen zur Grundversorgung sind eine kleine Teilmenge aus der Gesamtheit der Grundleistungen des DWD. Sie sind Kernaufgaben im Sinne einer gesicherten Bereitstellung von Wettervorhersage- und Beratungsdiensten sowie der Wahrnehmung der Wetterüberwachung und des Warndienstes für die Allgemeinheit. Für diese Informationen liegt ein besonderes öffentliches Interesse vor, das sich in einer Ermäßigung der Vergütung, die auch zu einer Entgeltbefreiung bzw. unentgeltlichen Abgabe führen kann, manifestiert. Hierunter fallen aktuelle Wetterinformationen für jedermann, die unverzichtbare Grundinformationen des nationalen Wetterdienstes für die Öffentlichkeit darstellen.
Quelle: Deutscher Wetterdienst"Warum nicht diesen Datenvorrat in fhem nutzbar machen?" dachte ich mir. Und schwupps... here we go:
get gds bamberg liefert zum Beispiel:
(http://up.picr.de/15381805bn.png)
Das erste proof-of-concept funktioniert und ich kann bereits eine Reihe von Wetterstation direkt vom DWD-Server abfragen Ich stehe natürlich noch komplett am Anfang und muss mich zuerst durch den Berg an Doku wühlen, in dem die bereitgestellten Daten beschrieben sind.
Letztendlich könnte man damit sogar Erdbeben- und Tsunamiwarnungen in fhem darstellen *lach* Viel interessanter finde ich aber allgemeine Wetterwarnungen und ähnliches.
Falls schonmal jemand erste Tests machen möchte - bitteschön :)
1. Schritt: kostenlose Registrierung für den GDS-Dienst beim DWD (//www.dwd.de/grundversorgung)
2. Schritt: prüfen ob das Perl Modul Net::FTP installiert ist, falls nicht: nachinstallieren
3. Schritt: fhem-device definieren mit define gdsName GDS gdsUsername gdsPasswort
Danach kann man schon arbeiten. Z.B. get gdsName list stations Man erhält eine Liste der abrufbaren freiverfügbaren Wetterstationen
Beispiel: get gdsName conditions Cuxhaven generiert folgende Readings:
(http://up.picr.de/15392314aj.png)
Das gleiche funktioniert auch mit set gdsName conditions Cuxhaven was dazu führt, dass die Readings (in diesem Fall mit Präfix c_ anstatt g_) alle 60 Minuten aktualisiert werden. Eine häufigere Aktualisierung macht keinen Sinn, weil die Datenbasis beim DWD auch nur alle 60 Minuten aktualisiert wird.
Für weitere Infos können "get <name> help" und "set <name> help" verwendet werden, um alle verfügbaren Befehle zu sehen.
ToDo:
- Fehler abfangen, falls FTP Verbindung nicht funktioniert
- Doku im Modul implementieren
Geplant:
- Funktion für Vorhersagedaten einbauen
Ich freue mich über jede Rückmeldung.
beim ersten probieren ist mir fhem beim 'list stations' abgeschmiert:
readline() on closed filehandle WXDATA at ./FHEM/55_GDS.pm line 184.
Use of uninitialized value $line in chomp at ./FHEM/55_GDS.pm line 184.
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/55_GDS.pm line 190.
/tmp/wx gab es nicht.
gruss
andre
Solange Du noch keine Daten vom DWD abgerufen hast, kann das nicht funktionieren. Die vom DWD gelesenen Daten werden in /tmp/wx gespeichert. Der List Befehl löst selbst kein Lesen vom DWD Server aus.
Schwierig dürfte das bei fhem-Installationen auf Windows-Rechnern werden, aber wer hat das schon.
dann fehlt etwas in deiner anleitung oben.
ich habe einfach punkte 1-3 nacheinander gemacht...
gruss
andre
Zitatdann fehlt etwas in deiner anleitung oben.
Kann schonmal passieren bei Software im absoluten Beta-Stadium. Deshalb hatte ich ja um Rückmeldung gebeten.
Fehlen tut da oben übrigens nix. Schritte 1-3 waren ja korrekt, aber danach habe ich einfach die Reihenfolge vertauscht. Ich hätte erst das Beispiel Cuxhaven bringen müssen und dann die Liste *g*
Ich werde ein initiales Lesen einbauen, dann paßt auch die obige Anleitung wieder.
Find ich super. Gerade solche Wetterwarnungen wie Sturm/Hagel könnte man damit super alarmieren und eventuelle Vorkehrungen treffen wie Markise rein, Jalousien runter usw.
Werd ich demnächst mal ausprobieren.
Viele Grüße
Markus
Naja, bis dahin ist es noch ein recht weiter Weg. Die Datenfülle ist einfach gigantisch und ich muss erst ein System finden, wie man das regional auswerten kann. Es nützt ja in München niemandem was wenn für Hamburg eine Sturmwarnung besteht.
Ich muss auch noch rausfinden, ob es die Daten nicht in XML oder JSON gibt, das Auswerten der Textdateien ist doch recht mühsam.
-------------------
edit: das initiale Lesen direkt nach dem define ist jetzt eingebaut.
sehr viel besser. vor allem wenn man nicht weiss wo die nächst gelegene station ist.
ein ganz anderes problem fällt mir aber in dem zusammenhang noch auf: alles was umlaute hat kann man sich per telnet nicht richtig anzeigen und auch nicht eingeben.
das problem gibt es für die av clients und titel auch. vielleicht wären zwei generelle funktionen um das encoding von strings zu ändern ganz praktisch. wobei das Encode z.b. auf den fritz boxen scheinbar nicht funktioniert und fhem komplet aussteigen lässt weil perl teile fehlen.
gruss
andre
hast Du mal ein Beispiel, WAS Du nicht sehen kannst?
In meinem Modul werden alle Strings ohnehin schon nach UTF8 konvertiert, weil der DWD die Daten in latin1 liefert.
Die untenstehende Anzeige bekomme ich auch bei einem Telnet-Zugriff:
fhem> set gds warn Nordrhein-Westfalen
VHDL30 DWEH 041800
WARNLAGEBERICHT für
Nordrhein-Westfalen
ausgegeben vom Deutschen Wetterdienst
am Sonntag, 04.08.13, 20:28 Uhr
In der Nacht gering bewölkt, weiterhin trocken. Am Montag heiter bis
wolkig, trocken, dabei sehr warm bis heiß. Zum Abend im Bergland
einzelne Schauer oder Gewitter möglich.
Entwicklung der WETTER- und WARNLAGE für die nächsten 24 Stunden
bis Montag, 05.08.13, 20:30 Uhr:
Schwacher Zwischenhocheinfluss sorgt für angenehm sommerliches Wetter
in Nordrhein-Westfalen.
Bis Montagabend werden keine warnrelevanten Wetterereignisse
erwartet.
Nächste Aktualisierung: spätestens Montag, 05.08.13, 04:30 Uhr
Deutscher Wetterdienst, RWB Essen, A.Würtz
fhem>
Lediglich die Eingabe von Umlauten funktioniert nicht richtig. Zum Glück gibts nur zwei Bundesländer mit einem Umlaut - da könnte ich auch jeweils ue eintragen.
Im Moment gibt es auch schon eine erste Abfrage von Warnmeldungen
set gds warn Nordrhein-Westfalen
liefert:
(http://up.picr.de/15397129ku.png)
Ich habe noch keinen blassen Schimmer, wie ich daraus etwas automatisch verwertbares machen soll. Ich kann derzeit lediglich ein Reading setzen, ob es eine Warnung für das gewählte Bundesland gibt oder nicht.
das harte convertieren nach utf8 ist aber falsch wenn das consolen/telnet encoding nicht utf8 ist.
was ich damit dann nicht richtig sehen (und setzen) kann sind dann etwa 15-20 der städte namen weil meine shell nicht auf utf8 sondern auf latin1 eingestellt ist.
für die web seiten gilt im prinzip das gleiche da fhem die html seiten ohne hinweis auf ein encoding ausliefert. utf8 funktioniert hier auch nur zufällig.
im quelltext utf8 zu verwenden ist ist auch nicht wirklich ok wenn es keinen marker gibt der utf8 anzeigt.
es ist klasse das du an das encoding gedacht hast aber es müssen halt alle teilchen der kette zusammen passen damit es am ende auch funktioniert.
die beiden latin1_2_utf8 und utf8_to_latin1 sind aber gut. die werde ich mir ausborgen. die sollten auch für die fritzbox user funktionieren.
gruss
andre
Wenn Du Dir eine ~/.telnetrc anlegst und dort
localhost
set binary true
(localhost muss durch den Hostname ersetzt werden, auf dem fhem läuft)
reinschreibst, kannst Du auch Umleite in der Telnet-Konsole eingeben.
Da fhem offenbar nix anderes kann als UTF8 habe ich nicht weiter darüber nachgedacht, mir war wichtig, dass die Daten korrekt angezegt werden. Was der DWD da ausliefert, ist gelinde gesagt, eine Katastrophe, ich hatte gar keine andere Wahl.
Die Konvertierungsroutinen sind übrigens nicht von mir, sondern von hier: http://perldoc.perl.org/perluniintro.html (//perldoc.perl.org/perluniintro.html) (ganz unten auf der Seite: UNICODE IN OLDER PERLS)
Inzwischen werden die Warnlageberichte auch aus den richtigen Verzeichnissen gelesen *g*
Zitat von: justme1968 schrieb am So, 04 August 2013 20:10sehr viel besser. vor allem wenn man nicht weiss wo die nächst gelegene station ist.
kein Problem... hier ein Ausblick was bei mir schon geht:
(http://up.picr.de/15398939ai.png)
Um so wichtige wäre mir, im Frontend auch den "get"-Button auswählen zu können - so wie
hier angefragtFeierabend. Gute Nacht.
> das harte convertieren nach utf8 ist aber falsch wenn das consolen/telnet encoding nicht utf8 ist.
Ich werde nicht mit konvertieren der Zeichensaetze anfangen, damit habe ich mit perl viele und hauptsaechlich negative Erfahrungen gesammelt.
> für die web seiten gilt im prinzip das gleiche da fhem die html seiten ohne hinweis auf ein
> encoding ausliefert. utf8 funktioniert hier auch nur zufällig.
Das ist nicht richtig, im HTTP-Header der FHEMWEB Daten steht
Content-Type: XXXXX; charset=$FW_encoding
FW_encoding steht seit gefuehlt einem Jahr auf utf-8.
Wenn das irgendwo noch fehlen sollte, bitte melden.
Zitat von: justme1968 schrieb am So, 04 August 2013 22:09die beiden latin1_2_utf8 und utf8_to_latin1 sind aber gut. die werde ich mir ausborgen. die sollten auch für die fritzbox user funktionieren.
Du kannst ja mal Rudi fragen, ob er sie in den 99_Utils verewigt :)
ich habe mal hier http://forum.fhem.de/index.php?t=msg&goto=88814&rid=430#msg_88814 (//forum.fhem.de/index.php?t=msg&goto=88814&rid=430#msg_88814) einen thread dafür aufgemacht.
gruss
andre
Ein neuer Zwischenstand zum Testen.
neu hinzugekommen:
set <name> warnlage <bundesland>
=> wird im Frontend mit Dropdown-Liste der Bundesländer angezeigt
geändert:
set <name> conditions <stationName>
=> wird im Frontend jetzt mit Dropdown-Liste der aktuell verfügbaren Stationen angezeigt
weggefallen:
get <name> list info
=> redundant, da die Daten auch in "list data" angezeigt werden
jetzt auch mit Wetterwarnungen :)
set gds alerts Baden-Württemberg
liefert:
(http://up.picr.de/15406253rq.jpg)
a_effective ist "gültig ab"
a_expires ist "gültig bis"
a_valid ist 1|0 und ergibt sich aus der aktuellen Zeit, es wird festgestellt, ob diese noch innerhalb der Gültigkeit der Wetterwarnung liegt
a_eventKey ist der verschlüsselte Meldungstyp, daraus kann man weitere Infos ableiten
Ich bin noch nicht ganz zufrieden, aber das ist erstmal besser als nichts. Mit "a_event" und "a_valid" sollten sich schon die ersten notifies bauen lassen.
Hallo betateilchen,
bin grade auf diesen Post gestoßen und ich finde die Idee super auf die Daten des DWD zurückzugreifen.
Leider bekomme ich das Modul nicht zum laufen, mir fehlt wohl MoreUtils.pm bzw. es liegt nicht am richtigen Ort.
Das Net::FTP Modul habe ich installiert, das müsste auch geklappt haben.
Der fhem Log sagt:
Can't locate List/MoreUtils.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/55_GDS.pm line 10, <$fh> line 146.
BEGIN failed--compilation aborted at ./FHEM/55_GDS.pm line 10, <$fh> line 146.
fhem läuft auf einem raspberry pi unter debian wheezy.
Weisst du wo ich dieses MoreUtils.pm her bekomme?
Vielen Dank
Nico
EDIT: Uups da war ich etwas voreilig. Über CPAN installiert und siehe da: funktioniert
EDIT: Uups da war ich etwas voreilig. Über CPAN installiert und siehe da: funktioniert
na super :)
Das Modul heißt List::MoreUtils (falls nochmal jemand darüber stolpert)
Im Moment gibt es Bundesweit 261 aktuell gültige Wetterwarnungen (die meisten wegen Hitze)... ich überlege grade, wie ich die sinnvoll einbaue.
edit: und jedes dritte XML File hat Fehler, die zum Abbruch der Auswertung führen *grummel*
Die nächste Version...
neu hinzugekommen:
Abfrage von Wetterwarnungen mit der allgemeinen Syntax:
set <name> alerts <area>
Vor der ersten Nutzung muss ein
set <name> rereadcfg
durchgeführt werden, um die Daten bereitzustellen.
Im Webfrontend steht danach eine Dropdownliste mit ALLEN Regionen bereit, für die in Deutschland derzeit gültige Wetterwarnungen bestehen.
Nach Auswahl der gewünschten Station in der Dropdownliste, wird die Meldung interpretiert und in die Readings übertragen.
set gds alerts Ortenaukreis
liefert bei mir aktuell folgende Ausgabe:
(http://up.picr.de/15410717mk.png)
Das Reading a_countAlerts enthält die Anzahl derzeit bestehender Wetterwarnungen.
Dem aufmerksamen Tester wird auffallen, dass in der Dropdownliste immer weniger Regionen stehen als im Meldungszähler. Das hängt damit zusammen, dass es einfach zu viele Fehler in der XML Datei gibt, die bei der Auswertung übersprungen werden. Interessanterweise sind es fast immer die gleichen Regionen, die aus dem Raster fallen. Ich denke noch über eine Lösung nach.
Die beschriebene Differenz beruhte nicht auf Fehlern in der XML Datei, sondern auf einem falschen Parsing in meinem Modul. Ich hatte schlicht den Fall nicht berücksichtigt, dass es innerhalb einer ausgegebenen Warnmeldung mehrere Regionen geben kann, für die diese eine Meldung gültig ist.
Und wenn man weiß, wo es klemmt, kann man das Problem auch beheben :)
So. Das XML-Parsing wurde jetzt komplett neu gebaut, es werden nun alle Regionsdaten geparst und beim Abruf einer bestimmten Region wird der gesamte Datensatz decodiert. Welche Readings dann allerdings gespeichert werden, läßt sich über Attribute steuern. Wer mal sehen möchte, WAS da alles decodiert wird, kann das Attribut gdsAll testweise auf 1 setzen - aber dann nicht erschrecken. Im normalen Gebrauch wird man dieses Attribut eher nicht brauchen.
Standardmäßig reichen die Readings in der Default-Einstellung
(http://up.picr.de/15420707ae.jpg)
völlig aus, um daraus ein notify zu bauen, um bei Unwetterwarnung z.B. die Markise einzufahren. Die hierfür wichtigsten Readings aus obigen Beispiel sind:
a_eventCode_GROUP = THUNDERSTORM HAIL WIND RAIN
a_expires = 2013-08-07T00:00:00+02:00
a_onset = 2013-08-06T22:01:00+02:00
a_valid = 1
a_eventCode_GROUP enthält die Unwettertypen, für die diese Warnung klassifiziert ist, in diesem Fall Gewitter, Hagel, Wind und Regen. In diesem Reading können eine oder mehrere Angaben stehen, die durch Leerzeichen getrennt sind.
a_onset ist der Zeitpunkt, ab dem die Warnung gilt
a_expires ist der Zeitpunkt, an dem die Warnung abläuft
a_valid kennzeichnet, ob diese Warnung bereits abgelaufen ist (=0) oder noch gültig ist(=1) Dieses Reading stammt nicht aus der Meldung selbst, sondern wird vom Modul selbst errechnet und eingefügt.
Ein ganz wichtiges Reading ist auch a_geoCode_WARNCELLID, aber darauf komme ich in einer späteren Version zurück.
----------------------------------------
WICHTIG:
1. Das Modul verwendet die aktuelle fhem.pl die Rudi heute eingecheckt hat!
2. Das Modul braucht das Perl Modul XML::Simple
Viel Spaß beim Testen :o)
----------------------------------------
Als nächstes würde ich ja ganz gerne ein paar bunte Bildchen (Wetterkarten) anzeigen lassen, aber die Sache mit weblink & co ist mir noch ein totales Buch mit sieben Siegeln. Kann mir mal jemand einen einfachen Tipp geben, wie ich eine Bilddatei aus dem lokalen Dateisystem im fhem-Frontend anzeigen lassen kann?
{*grübel*}Wieso kreist hier mitten in der Nacht eigentlich ein Suchhubschrauber über dem Stadtteil?{/*grübel*}
define weblink_Name weblink htmlCode <img src="/fhem/images/default/Bild.png">
klappt bei mir
lg Nico
bild liegt in www/images/default/Bild.png ;)
danke, das funktioniert erstmal auch hier, ist aber noch nicht ganz das, was ich mir vorstelle. Mein Ziel ist eigentlich ein "get gds map" und dann soll ein entsprechendes Wetterbild angezeigt werden. Aber damit kann ich weiterforschen.
Jetzt noch einen guten Whiskey und eine ordentliche Feierabendzigarre auf dem Balkon, und dann => Gute Nacht.
es gibt im prinzip zwei möglichkeiten für die icons:
- so wie im weather modul über einen weblink der mit einer 2html funktion oder einem get das html code liefert befühlt wird
- mit der 'neuen' summaryFn/detailFn um direkt das icon des device aus dem modul zu setzen
als dritte variante geht im prinzip auch devStateIcon in der {} variante aus dem modul heraus zu setzen, das ist aber eigentlich nicht mehr nötig und durch summaryFn ersetzt.
zu summaryFn/detailFn findest du mehr im wiki und im remote modul.
gruss
andre
Guten Morgen!
Mit dem neuen Version von GDS.pm bekomme ich diese Fehlermeldung:
2013.08.07 06:28:33 1: reload: Error:Modul 55_GDS deactivated:
Undefined subroutine &main::latin1ToUtf8 called at /opt/fhem/FHEM/55_GDS.pm line 673, <WXDATA> line 1.
2013.08.07 06:28:33 0: Undefined subroutine &main::latin1ToUtf8 called at /opt/fhem/FHEM/55_GDS.pm line 673, <WXDATA> line 1.
mit der Version vorher hatte ich keine Probleme.
Fhem up-to-date
Mfg Steffen
Zitat von: Steffen schrieb am Mi, 07 August 2013 06:32Fhem up-to-date
Mfg Steffen
Nein, Dein fhem ist NICHT up to date. Ich hatte oben nämlich extra dazugeschrieben:
ZitatWICHTIG:
1. Das Modul verwendet die aktuelle fhem.pl die Rudi heute eingecheckt hat!
Diese Datei musst Du also entweder aus SVN ausgecheckt haben oder Du musst das HEUTIGE Update in fhem durchführen. Die Update-Dateien werden m.W. morgens um 07:45 Uhr generiert. Also heute morgen um 06:32 als Du hier gepostet hast, kannst Du diese Datei per Update noch nicht erhalten haben ;)
Zitat von: justme1968 schrieb am Di, 06 August 2013 23:53es gibt im prinzip zwei möglichkeiten für die icons:
[...]
zu summaryFn/detailFn findest du mehr im wiki und im remote modul.
Hallo Andre,
ich muss erstmal versuchen zu verstehen, wie das Frontend eigentlich "funktioniert". Dann weiß ich auch, was ich im return() meiner Funktion liefern muss, damit das Ergebnis so aussieht, wie ich mir das vorstelle.
Viele Grüße
Udo
Zitat von: Markus Bloch schrieb am So, 04 August 2013 19:23Gerade solche Wetterwarnungen wie Sturm/Hagel könnte man damit super alarmieren und eventuelle Vorkehrungen treffen
[...]
Markus
Hallo Markus,
das kannst Du mit der aktuellen Version nun schon machen :) So kompliziert wie zuerst befürchtet, war es dann doch gar nicht.
Viele Grüße
Udo
Zitat von: betateilchen schrieb am Mi, 07 August 2013 08:58Zitat von: Steffen schrieb am Mi, 07 August 2013 06:32Fhem up-to-date
Mfg Steffen
Nein, Dein fhem ist NICHT up to date. Ich hatte oben nämlich extra dazugeschrieben:
ZitatWICHTIG:
1. Das Modul verwendet die aktuelle fhem.pl die Rudi heute eingecheckt hat!
Diese Datei musst Du also entweder aus SVN ausgecheckt haben oder Du musst das HEUTIGE Update in fhem durchführen. Die Update-Dateien werden m.W. morgens um 07:45 Uhr generiert. Also heute morgen um 06:32 als Du hier gepostet hast, kannst Du diese Datei per Update noch nicht erhalten haben ;)
Oh je entschuldige, da waren meine Finger auf der Tastatur wieder schneller als mein Gehirn;-),
habe aber trotzdem leider mit der neuen Version ein Problem, wenn ich "set GDSRagow update" eingebe stürzt mein Fhem komplett ab.
set GDSRagow alerts...usw. klappt aber nur bei "Update".
Hier mal verbose 5 log:
2013.08.07 19:58:08 4: Connection accepted from FHEMWEB:24.134.76.21:52007
2013.08.07 19:58:08 4: HTTP FHEMWEB:24.134.76.21:52007 GET /fhem?XHR=1&cmd=xmllist
2013.08.07 19:58:08 5: Cmd: >xmllist<
2013.08.07 19:58:08 5: Loading /opt/fhem/FHEM/98_XmlList.pm
2013.08.07 19:58:09 5: SET: Unknown argument ?, choose one of clear getConfig getRegRaw inhibit off on on-for-timer on-till peerBulk press regBulk regSet sign statusRequest toggle
Unknown argument ?, choose one of clear getConfig getRegRaw inhibit off on on-for-timer on-till peerBulk press regBulk regSet sign statusRequest toggle
Unknown argument ?, choose one of clear getConfig getRegRaw inhibit off on on-for-timer on-till peerBulk press regBulk regSet sign statusRequest toggle
Unknown argument ?, choose one of clear down getConfig getRegRaw getSerial inhibit off on on-for-timer on-till pair pct:slider,0,1,100 peerBulk press raw regBulk regSet reset sign statusRequest stop toggle unpair up
Unknown argument ?, choose one of clear getConfig getRegRaw getSerial inhibit off on on-for-timer on-till pair peerBulk press raw regBulk regSet reset sign statusRequest toggle unpair
2013.08.07 19:58:09 4: /fhem?XHR=1&cmd=xmllist / RL: 278297 / text/plain; charset=UTF-8 / /
2013.08.07 19:58:10 4: HTTP FHEMWEB:192.168.178.78:40612 GET /fhem?cmd=jsonlist+KinderZimmer&XHR=1
2013.08.07 19:58:10 5: Cmd: >jsonlist KinderZimmer<
2013.08.07 19:58:10 4: /fhem?cmd=jsonlist+KinderZimmer&XHR=1 / RL: 824 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2013.08.07 19:58:10 4: HTTP FHEMWEB:192.168.178.78:40615 GET /fhem?cmd=jsonlist+meinPopupDevice&XHR=1
2013.08.07 19:58:10 5: Cmd: >jsonlist meinPopupDevice<
2013.08.07 19:58:10 4: /fhem?cmd=jsonlist+meinPopupDevice&XHR=1 / RL: 195 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2013.08.07 19:58:10 4: Connection accepted from FHEMWEB:24.134.76.21:56116
2013.08.07 19:58:10 4: HTTP FHEMWEB:192.168.178.78:40619 GET /fhem?cmd=jsonlist+Terrassen_Eingang&XHR=1
2013.08.07 19:58:10 5: Cmd: >jsonlist Terrassen_Eingang<
2013.08.07 19:58:10 4: /fhem?cmd=jsonlist+Terrassen_Eingang&XHR=1 / RL: 502 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2013.08.07 19:58:10 4: HTTP FHEMWEB:24.134.76.21:56116 GET /fhem&detail=GDSRagow&detail=GDSRagow&dev.setGDSRagow=GDSRagow&cmd.setGDSRagow=set&arg.setGDSRagow=update&val.setGDSRagow=
2013.08.07 19:58:10 5: Cmd: >set GDSRagow update<
2013.08.07 19:59:28 1: Including fhem.cfg
2013.08.07 19:59:28 5: Cmd: >attr global autoload_undefined_devices 1<
2013.08.07 19:59:28 5: Cmd: >attr global backup_before_update 0<
2013.08.07 19:59:28 5: Cmd: >attr global holiday2we Lindenhof<
2013.08.07 19:59:28 5: Cmd: >attr global logfile ./log/fhem-%Y-%m.log<
2013.08.07 19:59:28 5: Cmd: >attr global modpath /opt/fhem<
2013.08.07 19:59:28 5: Loading /opt/fhem/FHEM/99_SUNRISE_EL.pm
2013.08.07 19:59:29 5: Loading /opt/fhem/FHEM/99_Utils.pm
2013.08.07 19:59:29 5: Loading /opt/fhem/FHEM/99_andnotify.pm
2013.08.07 19:59:31 5: Loading /opt/fhem/FHEM/99_email.pmHoffe kannst da was erkennen und mir bitte Helfen?
Mfg Steffen
Zitat von: Steffen schrieb am Mi, 07 August 2013 20:23[code]
2013.08.07 19:58:10 5: Cmd: >set GDSRagow update<
2013.08.07 19:59:28 1: Including fhem.cfg
/code]
Hoffe kannst da was erkennen und mir bitte Helfen?
Hallo Steffen,
ich erkenne, dass Du irgendwann zwischen 19:58:10 und 19:59:28 Dein fhem neu gestartet hast, mehr nicht.
Logging ist in meinem Modul noch nicht eingebaut. Für mich reichen die auftretenden Fehlermeldungen, die ich auf der Systemconsole sehe, in der ich fhem starte.
Ich weiß auch nicht, was Du mit dem update Befehl bewirken wolltest? Ich kann mich nicht daran erinnern, diesen Befehl hier im Thread schon beschrieben zu haben.
Nichtsdestotrotz funktioniert der Befehl bei mir problemlos:
(http://up.picr.de/15429197je.png)
Die beiden readings mit c_ am Anfang sind das Ergebnis des Updatebefehls.
Die Fehlerursache für Deinen Absturz vermute ich eher in Deiner Systemumgebung oder in Deiner Handhabung des Moduls.
Mach doch mal bitte ein "list GDSRagow" und poste die Ausgabe hier. Den Username und das Passwort kannst Du weglassen.
Viele Grüße
Udo
Hier kommt das tägliche Update :o)
Da FHEMWEB jetzt (reguläres Update kommt morgen früh!) auch GET grafisch unterstützt,
(http://up.picr.de/15427052lr.png)
sind einige Befehle aus "set" zum sehr viel logischeren "get" umgezogen.
SET Befehle:
"set <name> clear"
"set <name> help"
"set <name> conditions <stationName>"
"set <name> rereadcfg"
"set <name> update"
clear: löscht alle a_ c_ und g_ Readings
conditions <stationName>: definiert eine Station, deren Wetterdaten regelmäßig (alle 60 Minuten) aktualisiert werden
rereadcfg: liest alle benötigten Wetterdaten neu vom DWD Server
update: aktualisiert die Wetterdaten der mit "conditions <stationName>" festgelegten Wetterstation und startet den Aktualisierungtimer neu
help: gibt eine Hilfeliste aus
GET Befehle:
"get <name> alerts <region>".
"get <name> conditions <stationName>".
"get <name> help".
"get <name> list stations|data".
"get <name> rereadcfg".
"get <name> warnings <region>
alerts: liefert aktuelle Wetterwarnung für die aus der Dropdownliste angegebene Region
conditions <stationName>: definiert eine Station, deren Wetterdaten NICHT automatisch aktualisiert werden
help: gibt eine Hilfeliste aus
list stations: listet alle verfügbaren Wetterstationen mit aktuellen conditions auf
list data: listet alle Wetterdaten aller verfügbaren Wetterstationen in einer Tabelle auf
rereadcfg: liest alle benötigten Wetterdaten neu vom DWD Server
warnings <region>: liefert die aktuelle Warnlage für das gewählte Bundesland
Die Regionsangabe bei "alerts <region>" kann sowohl über den Region-Namen wie in der Dropdownliste angezeigt (!) oder über die WARNCELLID der Region angegeben werden.
get gds alerts Insel_Helgoland
und
get gds alerts 901056002
liefert also die gleichen Daten. Wichtig: Man beachte den Unterstrich in der Stationsangabe zwischen "Insel" und "Helgoland" - der ist wichtig und muss bei allen Regionsangaben mit Leerzeichen verwendet werden.
Wenn man eine WARNCELLID einmal kennt, kann man diese immer wieder für die Abfrage verwenden, diese IDs sind eindeutig und fest einer bestimmten Region zugeordnet. Das macht die Abfrage übersichtlicher, wenn man in notify oder at arbeitet.
Das Modul wird seit heute nur noch auf dem regulären Update-Weg von fhem ausgeliefert. Die heutige update-Version entspricht der gestern hier im Thread angehängten Version.
Bitte die (auch in commandref) dokumentierten Voraussetzungen für eine erfolgreiche Inbetriebnahme beachten, das Modul braucht die Perl-Module Net::FTP, List::MoreUtils, XML::Simple die ggf. nachinstalliert werden müssen.
ich bekomme mit der aktuellen version den fehler No value specified for 'KeyAttr' option in call to XMLin() at ./FHEM/55_GDS.pm line 456 und die alerts gehen nicht.
wenn man beim XMLin noch ein KeyAttr => {} mit übergibt geht alles.
das mit der aktuellen XML::Simple version 2.20. die gleiche verwende ich auch für die hue module. da ist das gleiche nötig.
gruss
andre
ps: die encoding geschichte sollte jetzt gelöst sein. rudi hat vorhin die ausgabe als ersten teil eingecheckt und ich hab dann noch die eingabe gepostet.
Zitat von: justme1968 schrieb am Do, 08 August 2013 16:34das mit der aktuellen XML::Simple version 2.20. die gleiche verwende ich auch für die hue module. da ist das gleiche nötig.
Hallo Andre,
danke für den Hinweis, ich habe die vorgeschlagene Änderung gerade eingecheckt.
Kannst Du bitte nochmal testen? Bei mir tritt die Fehlermeldung nicht auf.
Viele Grüße
Udo
schaut gut aus.
gruss
andre
Hallo,
wollte es gerade auch testen, leider schaffe ich es aber nicht das ganze in Funktion zu bringen.
Mir ist aufgefallen, dass zumindest bei Installationen auf der FBF, fhem.pl bei einem define abstürzt, wenn das Verzeichnis /tmp/conditions nicht vorhanden ist.
/tmp/conditions, /tmp/alerts und /tmp/warnings habe ich manuell angelegt und die Rechte erst einmal zum testen auf 777 gesetzt. Jetzt stürzt fhem bei einem define nicht mehr ab, das Modul wird aber nicht geladen, Verbose 5:
2013.08.09 11:25:20 0: Modification of non-creatable array value attempted, subscript -1 at ./FHEM/55_GDS.pm line 796.
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/55_GDS.pm line 796.
2013.08.09 11:25:20 1: reload: Error:Modul 55_GDS deactivated:
2013.08.09 11:25:19 5: Loading ./FHEM/55_GDS.pm
2013.08.09 11:25:19 5: Cmd: >define myGds gds <user> <passwd><
Habe mal /tmp/conditions/Höhe angelegt, aber auch ohne Erfolg. Jemand eine Idee? Ich weis nicht mehr weiter
Grüße, Tobias
1. /tmp/conditions ist kein Verzeichnis, sondern eine Datei
2. /tmp/conditions wird vom Modul automatisch angelegt.
Voraussetzung: Es müssen die in der commandref beschriebenen zusätzlichen perl-Module vorhanden sein!
Zitat/tmp/conditions/Höhe
was soll das sein?
Die Module sollten installiert sein. Gibt es einen Weg um das noch einmal zu prüfen?
Habe u.a. folgende Module auf der FBF und gehe davon aus, dass diese damit auch installiert sind:
\\192.168.178.1\fritz.nas\fhem\lib\perl5\site_perl\5.12.2\mips-linux\Net\FTP.pm
\\192.168.178.1\fritz.nas\fhem\lib\perl5\site_perl\5.12.2\mips-linux\List\MoreUtils.pm
\\192.168.178.1\fritz.nas\fhem\lib\perl5\site_perl\5.12.2\mips-linux\XML\Simple.pm
Ich dachte, dass ggf. irgendwelche Verzeichnisse oder Dateien nicht angelegt werden können und habe diese deshalb per Hand erstellt. Da habe ich dann Verzeichnis und Datei verwechselt. Ist aber alles wieder rückgänmgig gemacht. Lege ich die datei /tmp/conditions nicht per Hand an, bekomme ich eine andere Fehlermeldung:
2013.08.09 12:46:18 0: Document requires an element [Ln: 1, Col: 0]
Document requires an element [Ln: 1, Col: 0]
2013.08.09 12:46:18 1: reload: Error:Modul 55_GDS deactivated:
Die Datei /tmp/conditions wird dabei auch nicht angelegt. Vielleicht liegt das Problem am FTP Modul? Der FTP Zugang selber funktioniert, mit dem total commander komme ich drauf.
Zitat von: TeeVau schrieb am Fr, 09 August 2013 12:47Gibt es einen Weg um das noch einmal zu prüfen?
Aus dem fhem Frontend ein "reload 55_GDS" machen - sollten dann irgendwelche Module fehlen, gibt es eine entsprechende Fehlermeldung. Welche Version von 55_GDS hast Du installiert?
aktuell ist: # $Id: 55_GDS.pm 3634 2013-08-08 21:52:21Z betateilchen $
Hast Du mal in das fhem-Logfile geschaut, ob da irgendwelche Meldungen auftauchen?
Zitat von: betateilchen schriebAus dem fhem Frontend ein "reload 55_GDS" machen
2013.08.09 13:14:19 4: HTTP FHEMWEB:192.168.178.22:2608 GET /fhem?room=hidden
2013.08.09 13:14:18 5: Loading ./FHEM/55_GDS.pm
2013.08.09 13:14:18 5: Cmd: >reload 55_GDS<
Zitat von: betateilchen schriebWelche Version von 55_GDS hast Du installiert?
Direkt aus dem fhem update, keine Version aus dem Forum hier.
Zitat von: betateilchen schriebaktuell ist: # $Id: 55_GDS.pm 3634 2013-08-08 21:52:21Z betateilchen $
Genau die habe ich auch.
Zitat von: betateilchen schriebHast Du mal in das fhem-Logfile geschaut, ob da irgendwelche Meldungen auftauchen?
Habe gerade noch mal getestet:
Nach diesem define ist fhem abgestürzt, obwohl keine Fehlermeldung zu sehen ist im fhem log:
2013.08.09 13:17:24 4: et: GDS myGds _copyright: Quelle: Deutscher Wetterdienst -> _copyright: Quelle: Deutscher Wetterdienst
2013.08.09 13:17:24 5: Notify loop for myGds _copyright: Quelle: Deutscher Wetterdienst
2013.08.09 13:17:24 5: Triggering myGds (1 changes)
2013.08.09 13:17:23 3: GDS myGds: retrieving gds/specials/warnings/xml/PVW/Z_CAP* from DWD server
2013.08.09 13:17:23 4: et: GDS myGds _copyright: Quelle: Deutscher Wetterdienst -> _copyright: Quelle: Deutscher Wetterdienst
2013.08.09 13:17:23 5: Notify loop for myGds _copyright: Quelle: Deutscher Wetterdienst
2013.08.09 13:17:23 5: Triggering myGds (1 changes)
2013.08.09 13:17:22 3: GDS myGds: retrieving gds/specials/observations/tables/germany/* from DWD server
2013.08.09 13:17:22 5: Cmd: >define myGds gds user passw<
auf der linux console gab es zu dem diesen Fehler (da werde ich erst mal weiter ansetzen)
could not find ParserDetails.ini in /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2/XML/SAX
Can't locate unicore/Heavy.pl in @INC (@INC contains: /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2 /var/InternerSpeicher/fhem/lib/perl5/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/5.12.2 /opt/lib/perl5/site_perl/5.12.2/mips-linux /opt/lib/perl5/site_perl/5.12.2 /opt/lib/perl5/5.12.2/mips-linux /opt/lib/perl5/5.12.2 . ./FHEM) at /var/InternerSpeicher/fhem/lib/perl5/5.12.2/utf8_heavy.pl line 96.
Ich glaube, wir haben mehrere Fehler.
Nach Deinem Log sollten in /tmp die beiden Dateien "alerts" und "conditions" vorhanden sein.
2013.08.09 13:17:23 3: GDS myGds: retrieving gds/specials/warnings/xml/PVW/Z_CAP* from DWD server
2013.08.09 13:17:22 3: GDS myGds: retrieving gds/specials/observations/tables/germany/* from DWD server
Wenn nicht => Dein Net::FTP funktioniert nicht.
Sollten diese Dateien in /tmp vorhanden sein, scheitert das Decodieren, weil Dein XML::Simple nicht funktioniert, da scheint irgendein Baustein aus SAX zu fehlen.
Teste bitte die hier angehängte Version und schau nach dem Define nochmal ins Log.
-----
could not find ParserDetails.ini in /usr/local/share/perl/5.14.2/XML/SAX
Diese Meldung kommt bei mir übrigens auch - aber das scheint nichts dramatisches zu sein.
Hallo,
habe es zum laufen bekommen. Das Problem betraf auch einmal jemanden, der das HUE Modul verwendet hat. utf8_heavy.pl versucht auf .\unicore\Heavy.pl zuzugreifen, die war nicht vorhanden. Habe mir die Datei runtergaladen und auf die fbf gepackt, nun geht das gds auch.
Die /tmp/conditions wurde beim vorherigen Versuch angelegt und hatte Inhalt --> Net::FTP geht
Am XML::Simple habe ich nichts geändert, von daher gehe ich davon aus, dass alles ok ist.
Soll ich die Heavy.pl noch mal löschen, um den Fehler zu provozieren und deine geänderte Version testen?
klasse. endlich hat jemand das unicode problem auf der fritzbox gelöst.
es scheint so zu sein das die perl version auf den fritzboxen unvollständig ist das aber nur auffällt sobald Encode oder Decode auf daten trifft die wirklich unicode bzw utf8 sind. das schlägt natürlich auch dann zu wenn ein modul das Encode/Decode nicht direkt verwendet sondern nur indirekt wie z.b. bei hue über JSON, beim ituns modul über DAAP::DMAP und bei dem swap modul und scheinbar bei gds über XML::Simple.
magst du das vielleicht noch im wiki auf dokumentieren ?
gruss
andre
nein, wenn es jetzt läuft, brauchst Du nicht zu testen. Die Version hat einfach ein paar zusätzlich Logmeldungen, keine neue Funktionalotät.
Die utf8_heavy.pl hängt mit XML::Simple zusammen. Von daher scheint das Decodieren jetzt zu laufen. Wenn Du bei get "conditions" und get "alerts" jetzt gefüllte Dropdownlisten hast, sollte alles ok sein.
Gds funktioniert jetzt wunderbar, ich teste es die Tage mal und vergleiche die gelieferten Werte mit owo, yahoo und den eigenen Messwerten.
Was mir noch aufgefallen ist, ich habe bei mir keine Auswahl für die get Befehle, trotzt aktuellem fhem. In den anderen Modulen sind die get-Befehle, soweit unterstützt, vorhanden.
ein get myGsd ? liefert aber korrekt:
Unknown argument ?, choose one of help:noArg rereadcfg:noArg list:stations,data alerts:Kreis_Altötting,Kreis_Bad_Tölz-Wolfratshausen,Kreis_Berchtesgadener_Land,Kreis_Cham,Kreis_Dachau,Kreis_Deggendorf,Kreis_Dingolfing-Landau,Kreis_Ebersberg,Kreis_Eichstätt,Kreis_Erding,Kreis_Freyung-Grafenau,Kreis_Garmisch-Partenkirchen,Kreis_Miesbach,Kreis_Mühldorf_a._Inn,Kreis_Neuburg-Schrobenhausen,Kreis_Pfaffenhofen_a.d._Ilm,Kreis_Regen,Kreis_Rottal-Inn,Kreis_Straubing-Bogen_und_Stadt_Straubing,Kreis_Traunstein,Kreis_Weilheim-Schongau,Kreis_und_Stadt_Landshut,Kreis_und_Stadt_Passau,Kreis_und_Stadt_Regensburg,Kreis_und_Stadt_Rosenheim,Stadt_Ingolstadt conditions:Aachen,Angermünde,Arkona,Augsburg,Bad_Lippspringe,Bamberg,Berlin-Dahlem,Berlin-Tegel,Berlin-Tempelhof,Bremen-Flh.,Brocken,Cottbus,Cuxhaven,Dresden-Flh.,Düsseldorf-Flh.,Emden,Erfurt,Fehmarn,Feldberg/Schw.,Fichtelberg,Frankfurt/M-Flh.,Freudenstadt,Fritzlar,Fürstenzell,Gera,Gießen/Wettenberg,Greifswald,Grosser_Arber,Görlitz,Hahn-Flh.,Hamburg-Flh.,Hannover-Flh.,Helgoland,Hof,Hohenpeissenberg,Kahler_Asten,Karlsruhe-Rheinst.,Kassel,Kempten,Kiel,Konstanz,Köln/Bonn-Flh.,Lahr,Leipzig-Flh.,Leuchtt._Alte_Weser,Leuchtturm_Kiel,Lindenberg,List/Sylt,Magdeburg,Mannheim,Marnitz,Meiningen,München-Flh.,Münster/Osnabr.-Fl,Neuruppin,Norderney,Nürburg,Nürnberg-Flh.,OF-Wetterpark,Oberstdorf,Potsdam,Regensburg,Rostock,Saarbrücken-Flh.,Schleswig,Schwerin,Straubing,Stuttgart-Flh.,Stötten,Trier,Wasserkuppe,Weiden,Würzburg,Zugspitze,Öhringen warnings:Baden-Württemberg,Bayern,Berlin,Brandenburg,Bremen,Hamburg,Hessen,Mecklenburg-Vorpommern,Niedersachsen,Nordrhein-Westfalen,Rheinland-Pfalz,Saarland,Sachsen,Sachsen-Anhalt,Schleswig-Holstein,Thüringen
@justme
Ja, ich kann mich mal versuchen. Wird aber eine kurze Dokumentation. Den kompletten Hergang des Problems habe ich nicht verstanden, kann aber die Punkte beschreiben, die zur Lösung des Problems geführt haben. Das wird vermutlich für die meisten ausreichen, denke ich.
@betateilchen
Danke für die Unterstützung!
Zitat von: TeeVau schrieb am Fr, 09 August 2013 14:34Was mir noch aufgefallen ist, ich habe bei mir keine Auswahl für die get Befehle, trotzt aktuellem fhem. In den anderen Modulen sind die get-Befehle, soweit unterstützt, vorhanden.
ein get myGsd ? liefert aber korrekt:
in GDS funktioniert das aber auch:
(http://up.picr.de/15444484ks.png)
Hast Du eventuell noch nicht alle zu den Styles gehörenden Dateien aktualisiert, die von Rudi gestern noch überarbeitet wurden?
Das du es in deinem Modul implementiert hast glaube ich dir. Habe es ja in dem Posting gelesen und auch den Screenshot gesehen. Darum verwundert es mich um so mehr, dass es bei mir mit GDS nicht funktioniert.
"update" sagt, dass alles aktuell ist. Habe gerade für die get-Befehle etwas im VIERA Modul angepasst, dort habe ich die get möglichkeiten mit FHEMWEB. Komisch.... Habe auch mal mit dem dark Style getestet, macht aber keinen Unterschied.
(siehe Anhang / see attachement)
(siehe Anhang / see attachement)
Hallo!
Mit der neuen Version habe ich jetzt keine Abstürze mehr und Conditions und Update klappen, leider scheint bei "Alerts" noch nicht ganz alles so bei mir zu stimmen,
denn ich habe da nur eine sehr kleine Liste von Regionen und bei der letzte Version waren viel mehr dabei z.B.:"dahme-spreewald" noch mit dabei und jetzt nicht mehr.
Ein get GDSRagow alerts 112061000 ergibt:
Kreis Görlitz - Bergland sollte aber laut Liste "Kreis Dahme-Spreewald PD LDS Dahme-Spreewald Dahme-Spreewald 12061 112061000" ergeben oder verstehe ich das noch Falsch?
Habe schon diese Versionen neu installiert: "Net::FTP, List::MoreUtils, XML::Simple",
aber ein rereadcfg bringt keine änderung.
Mfg Steffen
Keine Sorge, es ist grundsätzlich alles in Ordnung.
Zitat von: Steffen schrieb am Fr, 09 August 2013 15:55Ein get GDSRagow alerts 112061000 ergibt:
...
sollte aber laut Liste "Kreis Dahme-Spreewald PD LDS Dahme-Spreewald Dahme-Spreewald 12061 112061000" ergeben oder verstehe ich das noch Falsch?
Ich weiß zwar nicht, welche Liste Du meinst, aber grundsätzlich hast Du schon recht. Was Du aber offenbar noch nicht verstanden hast: Alarmmeldungen können nur angezeigt werden, wenn es welche für die gesuchte Region gibt.
Zitatdenn ich habe da nur eine sehr kleine Liste von Regionen und bei der letzte Version waren viel mehr dabei z.B.:"dahme-spreewald" noch mit dabei und jetzt nicht mehr.
Dann gibt es aktuell für die gesuchte Region "dahme-spreewald" keine Warnmeldung. Als ich das Modul neulich begonnen habe, waren zeitweise über 300 Meldungen ausgegeben, aktuell sind es immer etwa 20.
Ich habe in meinem Modul noch nicht abgefangen, dass jemand eine Region über die WARNCELLID sucht, für die es keine Meldung gibt. Erkennen kannst Du das derzeit nur im Frontend daran, dass die Anzeige komplett verlassen wird und nicht nur eine Aktualisierung stattfindet. Ich habe die Abfrage auf die ToDo-Liste gesetzt.
Ok, Problem ist lokalisiert und behoben. Es wird jetzt eine entsprechende Meldung ausgegeben, wenn Warnmeldungen für eine Region gesucht werden, für die es keine gibt. Das wird auch geprüft, wenn die Suche mit der Text-ID einer nicht gewarnten Region ausgeführt wird.
Verfügbar ab #3644
Der Abruf von bundeslandbezogenen Warnlageberichten kann jetzt auch durch Eingabe der offiziellen Länderkürzel (//www.bmelv-statistik.de/de/daten-tabellen-suche/abkuerzungen-der-bundeslaender/) erfolgen, zum Beispiel liefert
get gds warnings nw
die vorhandenen Warnlageberichte für Nordrhein-Westfalen.
Außerdem ist die Texteingabe der Zielregion für den Abruf jetzt nicht mehr case-sensitive. Somit sind folgende Eingaben völlig gleichbedeutend:
get gds warnings Nordrhein-Westfalen
get gds warnings nordrhein-westfalen
get gds warnings NW
get gds warnings nw
-----
Vorschau in die laufende Entwicklung:
get gds map Deutschland
liefert:
(http://up.picr.de/15454659xt.jpg)
Hallo betateilchen,
habe heute noch mal etwas nachgeforscht, wieso ich bei mir die Steuerelemente für get im FHEMWEB nicht sehe.
Es scheint an den "alerts" zu liegen. Nach dem heutigen update habe ich die Zeile 312 auskommentiert, damit sehe ich das get Steuerelement.
Per Log habe ich mir mal $aList ausgeben lassen, vielleicht findest du eine ungereimtheit?
Log 2, "DEBUG GDS: " . $aList;
2013.08.10 18:16:22 2: DEBUG GDS: Erzgebirgskreis,Erzgebirgskreis,Kreis_Altenburger_Land,Kreis_Amberg-Sulzbach,Kreis_Barnim,Kreis_Bautzen_-_Bergland,Kreis_Bautzen_-_Tiefland,Kreis_Cham,Kreis_Cuxhaven_-_Küste,Kreis_Dithmarschen_-_Küste,Kreis_Elbe-Elster,Kreis_Friesland_-_Küste,Kreis_Greiz,Kreis_Görlitz_-_Bergland,Kreis_Ludwigslust-Parchim_-_Ost,Kreis_Mecklenburgische_Seenplatte_-_West,Kreis_Meißen,Kreis_Meißen,Kreis_Mittelsachsen_-_Bergland,Kreis_Mittelsachsen_-_Tiefland,Kreis_Märkisch-Oderland,Kreis_Neumarkt_i.d._OPf.,Kreis_Neustadt_a.d._Waldnaab,Kreis_Nordfriesland_-_Küste,Kreis_Oberhavel,Kreis_Oberspreewald-Lausitz,Kreis_Oder-Spree,Kreis_Potsdam-Mittelmark,Kreis_Schwandorf,Kreis_Sächsische_Schweiz-Osterzgebirge_-_Tiefland,Kreis_Sächsische_Schweiz-Osterzgebirge_-_ostelbisches_Bergland,Kreis_Sächsische_Schweiz-Osterzgebirge_-_westelbisches_Bergland,Kreis_Tirschenreuth,Kreis_Uckermark,Kreis_Vorpommern-Greifswald_-_Binnenland_Nord,Kreis_Vorpommern-Greifswald_-_Binnenland_Süd,Kreis_Vorpommern-Greifswald_-_Küste_Nord,Kreis_Vorpommern-Greifswald_-_Küste_Süd,Kreis_Vorpommern-Rügen_-_Insel_Rügen,Kreis_Wittenberg,Kreis_Wittenberg,Kreis_Wittmund_-_Küste,Kreis_Zwickau_-_Bergland,Kreis_Zwickau_-_Tiefland,Land_Berlin,Stadt_Amberg,Stadt_Dessau-Roßlau,Stadt_Dresden,Stadt_Frankfurt_(Oder),Stadt_Weiden_in_der_Oberpfalz,Vogtlandkreis_-_Bergland,Vogtlandkreis_-_Tiefland
Verwendete Version ist # $Id: 55_GDS.pm 3656 2013-08-09 23:59:12Z betateilchen $
Ich habe mir jetzt Deine aList in mein fhem kopiert, und damit kommt die Dropdownliste problemlos. Es ist schwierig, einen Fehler zu beheben, den man nicht reproduzieren kann. Kannst Du mir bitte eine /tmp/alerts schicken, mit der bei Dir das Problem auftritt?
Mach mal bitte ein "get <name> rereadcfg" das sollte im Logfile eine Ausgabe nach folgendem Muster erzeugen:
2013.08.10 21:55:28 1: I: 0 A: 14 City: Kreis_Friesland_-_Küste Cell: 903455002
2013.08.10 21:55:28 1: I: 1 A: 0 City: Kreis_Mittelsachsen_-_Tiefland Cell: 914522001
2013.08.10 21:55:28 1: I: 1 A: 1 City: Kreis_Nordsachsen_-_Süd Cell: 914730002
2013.08.10 21:55:28 1: I: 2 A: 0 City: Kreis_Meißen Cell: 114627000
und poste die Logausgabe hier.
ui ui ui... die nächste Änderung wird etwas umfangreicher als erwartet. Mit Net::FTP bekomme ich keine vernünftige Übertragung von jpg Dateien bewerkstelligt - keine Ahnung wieso. Sämtliche möglichen Objektattribute habe ich durch - ohne Erfolg.
Testweise habe ich den Abruf von Radarbildern auf http umgebaut und siehe da: alle Bilder sind schick. Also werde ich wohl die gesamte Kommunikation auf LWP umstellen.
Neue Funktionen:
get <name> conditionsmap <region>
get <name> forecastsmap <region>
get <name> radarmap <region>
get <name> warningsmap <region>
Diese Funktionen liefern Wetterkarten vom DWD Server. Links in der Frontendnavigation sollte es einen neuen Menüpunkt "GDS Files" geben
(http://up.picr.de/15459728rf.png)
Dahinter verbirgt sich die Liste der anzeigbaren Bilddateien
(http://up.picr.de/15459729nj.png)
Achtung: Diese Liste existiert auch, wenn noch keine Wetterkarten abgerufen wurden! Eine Anzeige der Bilddatei ist dann natürlich noch nicht möglich!
Guten Morgen!
Bekomme nach neustart Fhem mit der neuen Version diese Fehlermeldung:
2013.08.11 09:26:35 1: reload: Error:Modul 55_GDS deactivated:
Bareword "initDropdownLists" not allowed while "strict subs" in use at /opt/fhem/FHEM/55_GDS.pm line 105, <$fh> line 852.
2013.08.11 09:26:35 0: Bareword "initDropdownLists" not allowed while "strict subs" in use at /opt/fhem/FHEM/55_GDS.pm line 105, <$fh> line 852.
Mfg Steffen
gefixed in #3667
Entweder aus svn auschecken oder warten bis zum morgigen Update oder Zeile 105 ändern in: initDropdownLists();
Prüfe bitte vor dem Starten der neuen Version, ob in Deinem System das Modul Text::CSV installiert ist, das wird von der neuen Version benötigt.
Hallo Gemeinde,
ich habe es jetzt auch endlich geschafft, alles ans Laufen zu bekommen, nachdem ich per CPAN die fehlenden Dateien installiert bekommen habe. Jedoch gibt es seit dem GDS Modul folgende Fehlermeldung:
2013.08.13 05:34:27 3: GDS DW: Retrieving conditions data
2013.08.13 05:34:27 3: GDS DW: searching gds/specials/observations/tables/germany/* on DWD server
2013.08.13 05:34:27 3: GDS DW: retrieving SXDL99_DWAV_20130813_0314
Use of uninitialized value $s in substitution (s///) at fhem.pl line 3508.
Use of uninitialized value $s in substitution (s///) at fhem.pl line 3508.
Use of uninitialized value $s in substitution (s///) at fhem.pl line 3508.
Use of uninitialized value $s in substitution (s///) at fhem.pl line 3508.
Wollte dies nur mal berichten, vielleicht gibt es ja ein bugfix....
(GDS Version war gestern up-to-date)
VG
mcfly
moin,
die Meldungen sind keine "echten" Fehler, sondern Warnungen und stammen auch nicht primär aus dem 55_GDS, sondern aus fhem.pl (ja ich weiß, letztendlich werden sie durch irgendwas unschönes im Modul verursacht).
Funktionieren sollte das Modul aber trotzdem. Und Du kannst auch gerne die heute mit dem Update verteilte Version testen, da sind noch ein paar kleine Änderungen drin, vielleicht beseitigen die schon die Warnungen.
Ansonsten bitte nochmal Logmeldungen aus der aktuellen Version posten, dann kann ich mich auf die Suche machen.
Viele Grüße
Udo
Zitat von: mcfly71 schrieb am Di, 13 August 2013 07:26Jedoch gibt es seit dem GDS Modul folgende Fehlermeldung:
Use of uninitialized value $s in substitution (s///) at fhem.pl line 3508.
Sollte ab dem morgen verfügbaren Update nicht mehr auftreten.
Ursache gefunden und behoben.
55_GDS funktioniert dann ab morgen auch auf fhem-Installationen, die auf Windows-Rechnern laufen *örks*
Anstatt "/tmp/" (wie in ordentlichen Betriebssystem üblich) wird automatisch "c:\temp\" verwendet, wenn MSWin erkannt wird.
-----
Benutzer einer FritzBox müssen seit einem Update vor ein paar Tagen zusätzlich das Modul Text::CSV installieren.
Das Modul unter http://search.cpan.org/CPAN/authors/id/M/MA/MAKAMAKA/Text-CSV-1.32.tar.gz (//search.cpan.org/CPAN/authors/id/M/MA/MAKAMAKA/Text-CSV-1.32.tar.gz) downloaden und den Inhalt von "lib" entsprechend installieren.
Habe jetzt gds wieder laufen. Das Problem, dass bei mir die get-Befehle im FHEMWEB nicht angezeigt werden, besteht immer noch.
Habe mal die /tmp/alerts angehangen, wie gewünscht.
Echt komisch, dass das Problem augenscheinlich nur bei mir auftritt oder nur mir auffällt.
Das Problem existiert offenbar nur bei Dir. Welche Zeichensatzcodierung verwendet Dein Browser?
Und die Sache mit Text::CSV betrifft nicht nur die Fritzbox-Benutzer. Das ist seit Sonntag so, als das neue Kommando "get <name> list capstations" dazukam, und ist auch in der commandref so dokumentiert.
Zitat von: TeeVau schrieb am Di, 13 August 2013 20:55Habe mal die /tmp/alerts angehangen, wie gewünscht.
Echt komisch, dass das Problem augenscheinlich nur bei mir auftritt oder nur mir auffällt.
Deine alerts läßt sich hier problemlos verarbeiten.
Zitat von: betateilchen schrieb am Di, 13 August 2013 21:54Das Problem existiert offenbar nur bei Dir. Welche Zeichensatzcodierung verwendet Dein Browser?
Mozilla und Opera sagen es wird UTF-8 verwendet. Bei dem Safari auf iOS Geräten weiß ich nicht wo man das sehen kann.
Habe es auf 3 PCs getestet mit Opera und Mozilla sowie auf 2 iOS Geräten mit Safari, bei allen das selbe Problem.
Sonst noch eine Idee woran es liegen könnte?
Zitat von: TeeVau schrieb am Mi, 14 August 2013 08:20Sonst noch eine Idee woran es liegen könnte?
leider nein.
Poste doch Deine Frage im Frontend-Thread zu den Set/Get Buttons (http://forum.fhem.de/index.php?topic=14125.0), vielleicht hat Rudi noch eine Idee.
Hab einen neuen Thread gemacht, sonst wird der Thread mit der Ankündigung von dem Feature zu unübersichtlich.
Das Problem mit dem Unicode auf der Fritzbox ist im Wiki dokumentiert: http://www.fhemwiki.de/wiki/Unicode_FritzBox (//www.fhemwiki.de/wiki/Unicode_FritzBox) (Falls jemand mal auf das selbe Problem stößt und per Suche auf diesen Thread stößt)
Danke für deine Unterstützung betateilchen! GDS ist ein tolles Modul, vorallem die Radarkarte gefällt mir sehr.
Hallo Betateilchen,
ich habe jetzt wieder einen Fehler:
Use of uninitialized value $align in string eq at ./FHEM/55_GDS.pm line 835.
Use of uninitialized value $align in string eq at ./FHEM/55_GDS.pm line 839.
Vielleicht kannst du den bei nächster Gelegenheit entfernen ?!
VG
mcfly
Das ist kein wirklicher Fehler, das ist nur Optik. Diese Meldung habe ich übrigens noch auf keinem meiner drei Entwicklungssysteme gesehen.
edit: ich kann diese Meldungen nicht reproduzieren. Die können eigentlich nur auftreten, wenn das File mit den Wetterbedingungen nicht vom DWD Server geholt werden konnte. Gibt es in Deinem tmp-Verzeichnis eine Datei *_conditions* ?
-----
Füge mal bitte in Zeile 834 folgendes ein:
Log 3, "$line - extracting: ".$item;
und poste die Ausgabe im Logfile, vielleicht hast Du ja ein neues reading entdeckt *g*
Hmm das habe ich gemacht, jetzt kommt der "Fehler" nicht mehr....
Hat sich wohl erledigt
Wann kommt denn diese Meldung im Log-File ?
configfile: gds_web_DW already defined, delete it first
In der cfg steht das ganze nur 1 mal ???
Zitat von: mcfly71 schrieb am Do, 15 August 2013 14:58Wann kommt denn diese Meldung im Log-File ?
Wenn Du z.B. ein get <name> conditions <region> aufrufst.
Zitat von: mcfly71 schrieb am Do, 15 August 2013 14:58configfile: gds_web_DW already defined, delete it first
In der cfg steht das ganze nur 1 mal ???
Ja, Und genau das "in der cfg stehen" ist das Problem :o) Stör Dich nicht dran, die Meldung stellt kein Problem dar.
Hallo,
wie wäre denn der Ablauf um etwas zu automatisieren, wenn alerts für die eigene Region vorliegen?!
Bei mir ist es so, dass sich die alerts nicht automatisch update, das muss ich selber anstoßen per rereadcfg. Zudem müsste ich dann selber auch die alerts für die gesuchte Region pollen.
Gibt es einen Weg das mit dem Modul automatisch zu machen, oder muss man die Daten zyklisch per at abholen und dann entsprechend auswerten?
Bevor ich es umständlich mache, frage ich lieber mal nach einem einfachen Weg :-)
Eine automatische Aktualisierung ist derzeit nicht vorgesehen, dazu werden die Warnungen von seiten des DWD einfach zu häufig aktualisiert (alle 5 Minuten). Ein rereadcfg würde ich Dir auch nicht empfehlen, das aktualisiert und parst ja immer auch die kompletten conditions.
Meine Vorgehensweise:
1. "get gds alerts 105116000" (sucht Warnmeldungen für Mönchengladbach und füllt die readings entsprechend, sofern etwas gefunden wurde)
2. danach prüfen, ob das reading a_valid = 1 (wenn ja, gibt es eine aktuell gültige Wetterwarnung)
Bei mir läuft (1.) als at Definition alle 30 Minuten. Eine eventuell vorhandene Wetterwarnung wird in fhem per RSS bereitgestellt, der automatisch aktualisiert wird.
da hat sich heute ein Fehler eingeschlichen (kommt davon, wenn man sowas schreibt, während man keinen Zugriff auf die eigene Konfiguration hat)
Man muss natürlich tatsächlich erst ein "get gds rereadcfg" machen, bevor die Warnmeldung für eine bestimmte Region extrahiert werden kann.
Danke! Dann mach ich mich dran :-)
Die automatische Aktualisierung der alerts wurde übrigens aus Performancegründen absichtlich nicht eingebaut. So ein alerts-File kann durchaus einmal mehrere MB groß sein. Das verursacht massive Netzwerklast und das Parsen einer solch großen Datei dauert auch etwas. Ich fand (und finde nach wie vor) die flexible Lösung per at einfach sinnvoller.
Ist ja kein Problem, man muss es nur wissen.
Was mir aufgefallen ist, dass manchmal gds nicht mehr aktualisiert, obwohl per set conditions xyz eine Wetterstation gesetzt wurde.
Ein set rereadcfg behebt das Problem wieder. Kannst du vielleicht temporär dein at mal deaktivieren, damit nicht alle 30 Minuten ein rereadcfg gemacht wird?! Das sollte zum nachstellen reichen. Ich glaube das Problem tritt u.a. auf, wenn FHEM ein restart macht.
2013.08.26 19:25:08 1: configfile: gds_web_myGds already defined, delete it first
2013.08.26 19:24:54 3: GDS myGds: using HTTP for retrieval
2013.08.26 19:24:54 3: GDS myGds: retrieving Z_CAP_C_EDZW_20130826172001_PVW_STATUS.xml
2013.08.26 19:24:53 3: GDS myGds: searching for gds/specials/warnings/xml/PVW/Z_CAP* on DWD server
2013.08.26 19:24:53 3: GDS myGds: using FTP for retrieval
2013.08.26 19:24:53 3: GDS myGds: retrieving SXDL99_DWAV_20130826_1714
2013.08.26 19:24:52 3: GDS myGds: searching for gds/specials/observations/tables/germany/* on DWD server
2013.08.26 19:24:37 3: Registering HTTPSRV gds_web_myGds for URL /myGds...
2013.08.26 19:24:37 3: GDS myGds: tempDir=/tmp/
2013.08.26 19:24:37 3: GDS myGds: created
2013.08.26 19:24:36 3: owo myOwo: created
2013.08.26 19:24:32 2: VIERA: defined with host: 192.168.178.31 and interval: 30
2013.08.26 19:24:32 2: FB_CALLMONITOR: FBF read 193 contacts from FritzBox phonebook
2013.08.26 19:24:32 2: FB_CALLMONITOR: FBF found FritzBox phonebook /var/flash/phonebook
2013.08.26 19:24:32 3: FBF device opened
2013.08.26 19:24:32 3: Opening FBF device 192.168.178.1:1012
2013.08.26 19:24:30 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2013.08.26 19:24:30 3: CUL_0 device opened
2013.08.26 19:24:30 3: Setting CUL_0 baudrate to 9600
2013.08.26 19:24:29 3: Opening CUL_0 device /dev/ttyACM0
2013.08.26 19:24:28 3: WEBtablet: port 8085 opened
2013.08.26 19:24:28 3: WEBphone: port 8084 opened
2013.08.26 19:24:28 3: WEB: port 8083 opened
2013.08.26 19:24:27 3: telnetPort: port 7072 opened
2013.08.26 19:24:26 1: Including fhem.cfg
2013.08.26 19:24:22 0: Server shutdown
Es gab danach aber keine aktualisierung mehr. Erst ein rereadcfg hat geholfen:
2013.08.27 11:26:41 3: GDS myGds: using FTP for retrieval
2013.08.27 11:26:41 3: GDS myGds: retrieving SXDL99_DWAV_20130827_0914
2013.08.27 11:26:40 3: GDS myGds: searching for gds/specials/observations/tables/germany/* on DWD server
2013.08.27 11:26:40 3: GDS myGds: Retrieving conditions data
2013.08.27 10:26:40 3: GDS myGds: using FTP for retrieval
2013.08.27 10:26:40 3: GDS myGds: retrieving SXDL99_DWAV_20130827_0814
2013.08.27 10:26:39 3: GDS myGds: searching for gds/specials/observations/tables/germany/* on DWD server
2013.08.27 10:26:39 3: GDS myGds: Retrieving conditions data
Edit:
Hab mich vertan, es reicht kein rereadcfg, es muss ein neues set conditions sein.
c_nextUpdate bleibt bei dem Fehler auch auf dem alten Update stehen (Heute stand es z.B. auf dem 27. Aug, 12 Uhr irgendwas)
hast Du mal das set conditions direkt in die fhem.cfg geschrieben?
edit: probier das nicht[/b] *grummel*
du kannst aber in die fhem.cfg folgende at-Definition aufnehmen:
define gdsDummy at +00:00:30 set gds conditions Helgoland
Damit wird 30 Sekunden nach dem FHEM-Start das set automatisch durchgeführt.
Und das hat bei mir auch ein "shutdown restart" überlebt.
du kannst ein notify an global INITIALIZED hängen. das wird getriggert wenn fhem gestartet hat. das ist besser als die zeit zu schätzen.
das kannst du übrigens auch im modul code direkt per NotifyFn und dann dinge tun die du nach dem fhem start ein mal tun möchtest.
ach ja. noch etwas: hast du dir mal BlockingCall angeschaut? das wäre vielleicht etwas um zumindest das ftp im hintergrund zu machen. ein beispiel findest du z.b. im speedtest modul.
gruss
andre
Hallo Andre,
Zitat von: justme1968 schrieb am Do, 29 August 2013 00:34das kannst du übrigens auch im modul code direkt per NotifyFn und dann dinge tun die du nach dem fhem start ein mal tun möchtest.
Das Problem dabei ist, dass das Modul selbst ja gar nicht weiss, was es tun soll ;) Die Sache mit dem notify auf INITIALIZED wäre eine Option, aber ich bin grundsätzlich kein Freund von notify, die nur ein einziges Mal ausgeführt werden.
Zur Sache mit dem FTP im Hintergrund: Normalerweise stellt die Dauer der FTP Übertragung kein Problem dar. Die DWD Server sind ausreichend schnell und die Dateigrößen halten sich in Grenzen.
Die conditions-Datei ist generell unter 10kB groß, die alerts-Datei im Durchschnitt unter 500kB. Aktuell ist sie 502 Byte groß, weil es derzeit keine Unwetterwarnungen im Bundesgebiet gibt.
Ausnahmesituationen wie eine bundesweite Unwetterlage mit über 300 gleichzeitig gültigen Meldungen kommen ja nicht jeden Tag vor.
> ich bin grundsätzlich kein Freund von notify, die nur ein einziges Mal ausgeführt werden.
Man kann NotifyFn nach der Benutzung :) auch entfernen, damit sollte sie keine zusaetzliche Last verursachen, das macht auch Telnet so.
Natürlich.
Das ändert aber immer noch nichts daran, dass mir das im vorliegenden Fall überhaupt nichts nützen würde, weil die einmalig auszuführende Aufgabe nicht vom Modul selbst festgelegt ist, sondern vom Anwender bestimmt wird.
Hallo,
ich habe mit bereits mit einem notify abhilfe geschaffen, dennoch danke für den Hinweis.
Wollte von dem Verhalten berichten, denn in meinen Augen ist es ein Bug im Modul.
Wenn man ein set conditions macht sollte diese Station gespeichert werden (reading oder helper) und einen restart überleben, ohne dass der Nutzer nach einem restart erneut ein set conditions machen muss.
Zitat von: TeeVau schrieb am Fr, 30 August 2013 10:32denn in meinen Augen ist es ein Bug im Modul.
In meinen Augen nicht wirklich. Ich hatte das "Überleben" nämlich ursprünglich im Modul eingebaut und damit teilweise fhem während des Startens oder während eines rereadcfg völlig lahmgelegt.
In der nächsten Version kannst Du mit "attr <gds> gdsSetCond <region>" eine Region festlegen, die nach einem Neustart von fhem automatisch an ein "set <gds> conditions <region>" übergeben wird. Die Funktionsweise entspricht intern dem oben beschrieben at mit 30 Sekunden Verzögerung. Fehlt dieses Attribut, verhält sich das Modul exakt wie bisher.
Danke!
Das ist zwar noch nicht die endgültige Lösung, aber sie hilft schonmal ein ganzes Stück weiter.
Letzte Woche Donnerstag gegen 12:40 Uhr muss von GDS ein alerts-File mit fehlerhafter XML Struktur gekommen sein. Das hat dazu geführt, dass mein fhem komplett abgestürzt ist, weil das Parsen des Inhaltes nicht möglich war. Natürlich war ich seit Mittwoch letzter Woche bis gestern abend nicht zu Hause, um irgendwas unternehmen zu können - bemerkt habe ich das nur daran, dass fhem keine RSS mehr bereitgestellt hatte.
Nunja, gestern habe ich mich auf die Suche gemacht. Nachdem ich relativ schnell auf GDS als Verursacher kam (fhem liess sich auch gestern abend noch nicht neu starten) habe ich in /tmp die beiden abgelegten Dateien für alerts und conditions gelöscht und siehe da, alles lief wieder.
Inzwischen habe ich eine kleine Änderung im Modul eingebaut, um bei einem solchen Fehler den Komplettabsturz von fhem zu unterbinden. Testen konnte ich das noch nicht, weil es im Moment keine fehlerhaften Daten gibt 8) Die Änderung sollte seit heute im regulären fhem-update enthalten sein.
Sollte also jemand irgendwann selbst vor dem Problem stehen: einfach die XML Datei mit den alerts im temporären Verzeichnis löschen. Sie wird dann automatisch vom GDS Server neu gelesen.
Hallo zusammen,
ich habe das Problem das wenn ich define gdsName GDS gdsUsername gdsPasswort(Habe schon meine Daten eingesetzt) in meine fhem.cfg eintrage komtm die Fehlermeldunf Cannot Load the GSD Module
Das Modul habe ich im fhem/FHEM Order abgelegt bzw.es war schon vorhanden
Ich benutze Fhem auf ein Raspberry Pi
Hat vielleicht jemand eine Lösung für mich finde dieses Module ne gute Lösung??
Mfg
Makkoo
Schau mal bitte ins Logfile von fhem, dort sollte eine Fehlermeldung zu finden sein, warum das Modul nicht geladen werden kann.
Spontan würde ich mal vermuten, Du hast nicht alle für den Betrieb notwendigen Perl-Zusatzmodule (siehe commandref!) installiert.
Hallo!
Ich blicke hier noch nicht ganz durch: Wie muss ich das Modul in FHEM installieren? Welche Datei muss ich herunterladen? Oder ist das Modul bereits im FHEM drin? Danke für die Aufklärung!
Hallo,
Zitat von: Joesky am 26 Dezember 2013, 12:33:25
Ich blicke hier noch nicht ganz durch: Wie muss ich das Modul in FHEM installieren? Welche Datei muss ich herunterladen? Oder ist das Modul bereits im FHEM drin? Danke für die Aufklärung!
in der aktuellen Version von FHEM ist das Modul enthalten. Alles weitere kannst Du der CommandRef entnehmen unter GDS.
Ob Perl-Module auf Deinem Rechner nachinstallieren mußt und wie Du dies bewerkstelligst, können wir Dir leider derzeit bei der von Dir gegebenen Informationslage nicht beantworten.
Viele Grüße
Boris
Alle Module aus Commandref habe bereits installiert, aber GDS war im FHEM nicht drin. Ich mache fast jeden Tag "update" um immer die aktuellste Version zu haben. Ich habe die letzte hier angehängte Datei 55_GDS.pm installiert und jetzt geht es. Ist das Modul weiterhin in einer eigenen Datei? Oder inzwischen irgendwo anders?
55_GDS.pm ist definitiv Bestandteil von fhem in der aktuellen Version.
# $Id: 55_GDS.pm 4145 2013-11-03 19:23:15Z betateilchen $
Hallo,
ich experimentiere mit dem Modul GDS seit Weihnachten herum. Mir ist nun folgendes aufgefallen:
Die Webseite des DWD für Main-Kinzig-Kreis http://www.dwd.de/dyn/app/ws/html/reports/HUX_warning_de.html (http://www.dwd.de/dyn/app/ws/html/reports/HUX_warning_de.html) zeigt eine Warnung vor Glätte. GDS zeigt mir aber auch nach "get e.ext.GDS alerts Main-Kinzig-Kreis_und_Stadt_Hanau" nur den abgelaufenen Alert vom 22.12. (Windböen).
Ich habe mal ein Update gemacht, aber es kam keine neue Version vom Modul nach. Allerdings hängt jetzt FHEM beim Start, weil ein FTP-Transfer in GDS hängt. Aus dem globalen fhem.log die letzten Einträge (reproduzierbar):
2013.12.29 22:42:33 3: GDS e.ext.GDS: created
2013.12.29 22:42:33 3: GDS e.ext.GDS: tempDir=/tmp/
2013.12.29 22:42:33 3: Registering HTTPSRV gds_web_e.ext.GDS for URL /e.ext.GDS...
2013.12.29 22:42:47 3: GDS e.ext.GDS: searching for gds/specials/observations/tables/germany/* on DWD server
2013.12.29 22:42:47 3: GDS e.ext.GDS: retrieving SXDL99_DWAV_20131229_2114
2013.12.29 22:42:47 3: GDS e.ext.GDS: using FTP for retrieval
2013.12.29 22:42:48 3: GDS e.ext.GDS: searching for gds/specials/warnings/xml/PVW/Z_CAP* on DWD server
2013.12.29 22:42:48 3: GDS e.ext.GDS: retrieving Z_CAP_C_EDZW_20131229214000_PVW_STATUS.xml
2013.12.29 22:42:48 3: GDS e.ext.GDS: using HTTP for retrieval
2013.12.29 22:43:05 3: GDS e.ext.GDS: Retrieving conditions data
2013.12.29 22:43:05 3: GDS e.ext.GDS: searching for gds/specials/observations/tables/germany/* on DWD server
2013.12.29 22:43:06 3: GDS e.ext.GDS: retrieving SXDL99_DWAV_20131229_2114
2013.12.29 22:43:06 3: GDS e.ext.GDS: using FTP for retrieval
Ich habe jetzt, nach etwas über 7 Minuten, FHEM abgeschossen und die Definition auskommentiert, damit FHEM wieder arbeitet.
Hier noch der relevante Teil der Konfiguration:
define e.ext.GDS GDS <username> <password>
attr e.ext.GDS alias DWD
attr e.ext.GDS room 1/Garten
attr e.ext.GDS group Wetter
attr e.ext.GDS stateFormat currentMsg
set e.ext.GDS conditions Frankfurt/M-Flh
attr e.ext.GDS userReadings currentMsg:(a_event|a_valid) { ReadingsVal("e.ext.GDS","a_valid",0) ? ReadingsVal("e.ext.GDS","a_event","") : "" }
Was nun?
Viele Grüße
Boris
Hallo Boris,
grundsätzlich funktioniert das GDS Modul (auch heute) problemlos, das kann ich an den Statusseiten meiner fhem-Installation zu Hause erkennen. Bin zur Zeit noch in Urlaub und kann hier keine großen technischen Tests fahren.
Kannst Du mal bitte in /tmp/ die bereits heruntergeladenen Dateien löschen und dann nochmal testen?
Viele Grüße
Udo
Ich habe eben ein aktuelles fhem auf meinem MBA installiert - da funktioniert GDS problemlos. Für den Main-Kinzig-Kreis gibt es aktuell keine Warnung.
2013.12.30 14:01:09 3: GDS gds: created
2013.12.30 14:01:09 3: GDS gds: tempDir=/tmp/
2013.12.30 14:01:09 3: Registering HTTPSRV gds_web_gds for URL /gds...
2013.12.30 14:01:09 3: GDS gds: no datafile (conditions) found
2013.12.30 14:01:09 3: GDS gds: no datafile (alerts) found
2013.12.30 14:01:09 3: GDS gds: searching for gds/specials/observations/tables/germany/* on DWD server
2013.12.30 14:01:09 3: GDS gds: retrieving SXDL99_DWAV_20131230_1214
2013.12.30 14:01:09 3: GDS gds: using FTP for retrieval
2013.12.30 14:01:10 3: GDS gds: searching for gds/specials/warnings/xml/PVW/Z_CAP* on DWD server
2013.12.30 14:01:10 3: GDS gds: retrieving Z_CAP_C_EDZW_20131230125400_PVW_STATUS.xml
2013.12.30 14:01:10 3: GDS gds: using HTTP for retrieval
2013.12.30 14:01:27 3: GDS gds: Decoding CAP record #807
Installationshölle auf dem RasPi:
cpan NET::FTP => stressfrei
cpan List::MoreUtils => stressfrei
cpan XML::Simple => und los gehts :(
Installation wg. fehlendem Modul nicht geklappt
Nach diversen Versuchen ist die Lösung:
apt-get update
apt-get install expat
apt-get install libexpat1-dev
dann klappts auch mit XML::Simple
Vielleicht hilft es ja wem?
Auf dem Raspi ist es noch viel einfacher, wenn man einfach die zur Distribution gehörigen .deb Pakete installiert. Das Rumhampeln mit cpan ist nicht jedermanns Sache und bei der .deb Installation werden die Abhängigkeiten automatisch aufgelöst.
apt-get install libnet-lite-ftp-perl liblist-moreutils-perl libxml-simple-perl libtext-csv-perl
Hallo Udo,
Zitat von: betateilchen am 30 Dezember 2013, 14:03:08
Ich habe eben ein aktuelles fhem auf meinem MBA installiert - da funktioniert GDS problemlos. Für den Main-Kinzig-Kreis gibt es aktuell keine Warnung.
ich habe die Definitionen wieder aktiviert und siehe da: alles läuft wie gehabt. Vermutlich gab es gestern Abend mit dem DWD-Server ein Problem beim FTP.
Komisch nur, daß die Timeouts von 10 bzw. 360 Sekunden in retrieveFile() nicht zugeschlagen haben. Problem erstmal zurückgestellt.
Die scheinbar fehlenden Warnungen im Kreis behalte ich im Auge und melde mich wieder, wenn ich wieder eine Diskrepanz zwischen der DWD-Webseite und dem Ergebnis von GDS sehe.
Viele Grüße
Boris
na dann :)
Es gab auch schonmal Probleme mit fehlerhaften XML-Files vom DWD-Server, das hatte ich hier im Thread Anfang November beschrieben.
Mein /temp/ ist ne RAMDisk.
(Seit meinen Texterkennungsspielereien)
Das hat den Vorteil die Schreibzugriffe auf die SD Karte zu verringern, und fehlerhafte Dateien sind spätestens beim Reboot wieder weg.
Hat das Verfahren irgendwelche Nachteile, die ich grade übersehe?
Zitat von: betateilchen am 30 Dezember 2013, 17:23:17
na dann :)
So, jetzt ist es wieder soweit. FHEM hängt beim Start, weil GDS im FTP-Retrieval hängt:
2014.01.19 11:10:42 3: GDS e.ext.GDS: created
2014.01.19 11:10:42 3: GDS e.ext.GDS: tempDir=/tmp/
2014.01.19 11:10:42 3: Registering HTTPSRV gds_web_e.ext.GDS for URL /e.ext.GDS...
2014.01.19 11:10:51 3: GDS e.ext.GDS: searching for gds/specials/observations/tables/germany/* on DWD server
2014.01.19 11:10:52 3: GDS e.ext.GDS: retrieving SXDL99_DWAV_20140119_0914
2014.01.19 11:10:52 3: GDS e.ext.GDS: using FTP for retrieval
2014.01.19 11:10:52 3: GDS e.ext.GDS: searching for gds/specials/warnings/xml/PVW/Z_CAP* on DWD server
2014.01.19 11:10:52 3: GDS e.ext.GDS: retrieving Z_CAP_C_EDZW_20140119101000_PVW_STATUS.xml
2014.01.19 11:10:52 3: GDS e.ext.GDS: using HTTP for retrieval
2014.01.19 11:11:08 3: GDS e.ext.GDS: Retrieving conditions data
2014.01.19 11:11:08 3: GDS e.ext.GDS: searching for gds/specials/observations/tables/germany/* on DWD server
2014.01.19 11:11:09 3: GDS e.ext.GDS: retrieving SXDL99_DWAV_20140119_0914
2014.01.19 11:11:09 3: GDS e.ext.GDS: using FTP for retrieval
Wie kann ich das debuggen? Die Durchsicht des Codes ergibt ja, daß der Timeout den Transfer schon hätte abbrechen müssen.
Viele Grüße
Boris
ich mach Dir nen Vorschlag:
Du kümmerst Dich um das von mir gestern hier im Forum beschriebene Calandar-Problem und ich lass mir zu GDS was einfallen 8)
Hallo Boris,
teste mal bitte mit der angehängten Modulversion. Ich bin mir noch nicht ganz sicher, wann das Hängenbleiben wirklich passiert. Setze bitte das Attribut gdsDebug auf 1.
Mich intereressiert, wann die _dF_ Readings aktualisiert werden.
Ausserdem habe ich den Timeout von 360 Sekunden auf 10 umgestellt.
Viele Grüße
Udo
Hallo,
hier das Resultat mit Verbosity 5 und "attr ... gdsDebug 1" bis zum Hänger. Das Problem tritt bei "set ... conditions ..." auf.
Viele Grüße
Boris
2014.01.19 21:40:25 5: Cmd: >define e.ext.GDS GDS gds10123 foobar<
2014.01.19 21:40:25 5: Loading /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm
given is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 159, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 160, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 165, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 170, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 182, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 188, <$fh> line 12.
given is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 223, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 225, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 231, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 237, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 243, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 250, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 255, <$fh> line 12.
given is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 256, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 257, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 258, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 259, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 265, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 280, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 285, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 292, <$fh> line 12.
given is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 317, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 318, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 322, <$fh> line 12.
given is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 704, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 706, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 713, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 720, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 727, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 737, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 744, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 751, <$fh> line 12.
when is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/55_GDS.pm line 759, <$fh> line 12.
2014.01.19 21:40:25 3: GDS e.ext.GDS: created
2014.01.19 21:40:25 3: GDS e.ext.GDS: tempDir=/tmp/
2014.01.19 21:40:25 5: Loading /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/02_HTTPSRV.pm
2014.01.19 21:40:25 3: Registering HTTPSRV gds_web_e.ext.GDS for URL /e.ext.GDS...
2014.01.19 21:40:26 3: GDS e.ext.GDS: searching for gds/specials/observations/tables/germany/* on DWD server
2014.01.19 21:40:27 3: GDS e.ext.GDS: retrieving SXDL99_DWAV_20140119_2014
2014.01.19 21:40:27 3: GDS e.ext.GDS: using FTP for retrieval
2014.01.19 21:40:27 3: GDS e.ext.GDS: searching for gds/specials/warnings/xml/PVW/Z_CAP* on DWD server
2014.01.19 21:40:27 3: GDS e.ext.GDS: retrieving Z_CAP_C_EDZW_20140119203413_PVW_STATUS.xml
2014.01.19 21:40:27 3: GDS e.ext.GDS: using HTTP for retrieval
2014.01.19 21:40:39 5: Cmd: >attr e.ext.GDS gdsDebug 1<
2014.01.19 21:40:39 5: Cmd: >attr e.ext.GDS alias DWD<
2014.01.19 21:40:39 5: Cmd: >attr e.ext.GDS room 1/Garten<
2014.01.19 21:40:39 5: Cmd: >attr e.ext.GDS group Wetter<
2014.01.19 21:40:39 5: Cmd: >attr e.ext.GDS stateFormat currentMsg<
2014.01.19 21:40:39 5: Cmd: >set e.ext.GDS conditions Frankfurt/M-Flh<
2014.01.19 21:40:39 3: GDS e.ext.GDS: Retrieving conditions data
2014.01.19 21:40:39 3: GDS e.ext.GDS: searching for gds/specials/observations/tables/germany/* on DWD server
2014.01.19 21:40:39 3: GDS e.ext.GDS: retrieving SXDL99_DWAV_20140119_2014
2014.01.19 21:40:39 3: GDS e.ext.GDS: using FTP for retrieval
2014.01.19 21:40:39 1: DEBUG> GDS e.ext.GDS ftp-message: Net::FTP=GLOB(0x3cfa850)->message
Zitat von: Dr. Boris Neubert am 19 Januar 2014, 21:45:05hier das Resultat mit Verbosity 5 und "attr ... gdsDebug 1" bis zum Hänger. Das Problem tritt bei "set ... conditions ..." auf.
Dass es mit den set conditions zusammehängt, war schon klar. Immerhin scheint aber der FTP-Abruf selbst nicht das Problem zu sein, denn die letzte Debug-Meldung in Deiner Ausgabe entsteht erst nach der FTP Übertragung.
Das mit Deinem GDS Problem ist so ähnlich mein aktuelles Calendar-Problem bei Dir: bei mir funktioniert GDS problemlos, zumal das conditions-File ja für alle Stationen das gleiche ist... *g*
Ich werde der Sache weiter nachgehen - ich muss die Debug-Ausgaben weiter präzisieren.
Zitat von: betateilchen am 30 Dezember 2013, 17:11:38
Auf dem Raspi ist es noch viel einfacher, wenn man einfach die zur Distribution gehörigen .deb Pakete installiert. Das Rumhampeln mit cpan ist nicht jedermanns Sache und bei der .deb Installation werden die Abhängigkeiten automatisch aufgelöst.
apt-get install libnet-lite-ftp-perl liblist-moreutils-perl libxml-simple-perl libtext-csv-perl
Leider bekomme ich dabei eine Fehlermeldung. Die anderen Module werden geladen, nur das erste nicht ;-)
xxxx@RaspiFHEM:/opt/fhem/FHEM# apt-get install libnet-lite-ftp-perl
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
E: Paket libnet-lite-ftp-perl kann nicht gefunden werden.
xxxx@RaspiFHEM:/opt/fhem/FHEM#
Probier mal das Paket libwww-perl und teste, ob das GDS dann funktioniert.
Zitat von: betateilchen am 20 Januar 2014, 19:50:30
Probier mal das Paket libwww-perl und teste, ob das GDS dann funktioniert.
jepp, hat funktioniert .....
Zitat von: betateilchen am 20 Januar 2014, 08:32:00Dass es mit den set conditions zusammehängt, war schon klar. Immerhin scheint aber der FTP-Abruf selbst nicht das Problem zu sein, denn die letzte Debug-Meldung in Deiner Ausgabe entsteht erst nach der FTP Übertragung.
Hallo Boris,
Ich habe jetzt sehr viele Versuche gemacht, aber bisher konnte ich das Fehlverhalten nicht ein einziges Mal reproduzieren.
Die Änderung des ftp-Timeouts von 360 auf 10 Sekunden wurde inzwischen als Update generell in das Modul übernommen.
Sollte der Fehler wieder einmal bei Dir auftreten, versuche doch bitte mal, die empfangene conditions-Datei (der FTP Transfer an sich scheint ja generell zu funktionieren) hier zu posten oder mir per email zu schicken.
Viele Grüße
Udo
Hallo,
irgendwie habe ich Probleme Daten mit dem Modul zubekommen.
2014.02.18 23:00:35 3: GDS dwd: searching for gds/specials/observations/tables/germany/* on DWD server
2014.02.18 23:00:36 3: GDS dwd: searching for gds/specials/warnings/xml/PVW/Z_CAP* on DWD server
2014.02.18 23:00:36 3: GDS dwd: no datafile (conditions) found
2014.02.18 23:00:36 3: GDS dwd: no datafile (alerts) found
Wenn ich direkt auf den Server gehe, dann ist der Pfad anders /gds/gds/[ab hier gleich]
Kann es sein, das da ein Fehler im Modul ist oder der DWD die Struktur geändert hat?
Nico
2014.02.18 23:59:32 3: GDS gds: Retrieving conditions data
2014.02.18 23:59:32 3: GDS gds: searching for gds/specials/observations/tables/germany/* on DWD server
2014.02.18 23:59:32 3: GDS gds: retrieving SXDL99_DWAV_20140218_2214
2014.02.18 23:59:32 3: GDS gds: using FTP for retrieval
funktioniert hier problemlos.
@santalaus
Konntest Du Dein Problem inzwischen lösen?
Leider nicht. FTP Verbindung wird laut tcpdump aufgebaut. Den Inhalt der Verbindung hab ich noch nicht analysiert.
Ich hab z.Z. andere Baustellen.
Nico
melde Dich, wenn Du Zeit für die Fehlersuche hast. Im Moment tippe ich auf irgendeine Art Anwenderfehler.
Dein Log-Ausschnitt ist auch einfach zu kurz, um daraus wirklich genügend Informationen ziehen zu können.
Hi Udo,
Geben deine Wetter Daten auch den sonneneinfallswinkel und die sonnenposition an? Nur deshalb müsste ich sonst noch die anderen wettermodule aktiv halten.
Hallo Tobias,
das müsste ich mal beim DWD recherchieren, ob es dafür entsprechende Daten gibt. Im Moment gibt es diese Daten aus meinem Modul nicht.
Viele Grüße
Udo
Hallo,
also ich habe nochmal getestet. Irgendwie kommt nichts rein.
Folgendes ist alles was im Log bzgl gds steht:
2014.02.24 23:00:42 3: GDS dwd: created
2014.02.24 23:00:42 3: GDS dwd: tempDir=/tmp/
2014.02.24 23:00:42 3: Registering HTTPSRV gds_web_dwd for URL /dwd...
2014.02.24 23:00:42 3: GDS dwd: no datafile (conditions) found
2014.02.24 23:00:42 3: GDS dwd: no datafile (alerts) found
2014.02.24 23:00:42 3: GDS dwd: searching for gds/specials/observations/tables/germany/* on DWD server
2014.02.24 23:00:43 2: GDS dwd: No datafile (conditions) found
2014.02.24 23:00:43 3: GDS dwd: searching for gds/specials/warnings/xml/PVW/Z_CAP* on DWD server
2014.02.24 23:00:43 3: GDS dwd: No datafile (alerts) found
2014.02.24 23:00:43 1: configfile: gds_web_dwd already defined, delete it first
2014.02.25 11:08:34 3: GDS dwd: searching for gds/specials/observations/tables/germany/* on DWD server
2014.02.25 11:08:34 3: GDS dwd: searching for gds/specials/warnings/xml/PVW/Z_CAP* on DWD server
2014.02.25 11:08:35 3: GDS dwd: no datafile (conditions) found
2014.02.25 11:08:35 3: GDS dwd: no datafile (alerts) found
2014.02.25 11:08:41 3: GDS dwd: searching for gds/specials/observations/tables/germany/* on DWD server
2014.02.25 11:08:41 3: GDS dwd: searching for gds/specials/warnings/xml/PVW/Z_CAP* on DWD server
2014.02.25 11:08:50 3: GDS dwd: searching for gds/specials/radar/west/Webradar_West* on DWD server
2014.02.25 11:08:59 3: GDS dwd: searching for gds/specials/radar/Webradar_Deutschland* on DWD server
Kann ich irgendwo Verbose erhöhen? Macht das Sinn?
Wenn ich das richtig sehe sollte er wenn mehr loggen.
BTW: die /tmp/dwd.html wird angelegt.
Nico
Irgendwas scheint mit der Internetkommunikation zwischen Deinem fhem und dem DWD Server nicht zu funktionieren.
Sitzt Du hinter einer Firewall oder hinter einem Proxy?
Verbose erhöhen bringt nichts, es ist kein weiteres Logging vorgesehen. Du kannst aber das Attribut gdsDebug auf 1 setzen und dann nach einem Verbindungsversuch mal die Readings hier posten.
Hallo,
es ändert nix: Die readings bleiben bei:
_dataSource
Quelle: Deutscher Wetterdienst
2014-02-25 14:32:07
state
active
2014-02-25 12:17:53
Da ganze hängt hinter einen Router mit openwrt. Dort ist nix gesperrt. Von meinem Arbeitsplatz aus komme ich mittels Filezilla problemlos auf den Server. Der tcpdump auf dem FHEM System sah auch nach erfolgreichem login aus. Muss ich heute Abend mal direkt mit ftp client probieren.
Nico
Kannst Du bitte künftig code-Tags verwenden, um Deinen Text etwas leichter lesbar zu gestalten? Danke.
Ich behaupte, bei Dir schlägt der Verbindungsaufbau zum DWD Server per ftp aus dem Modul heraus fehl. Darauf deutet das Fehlen eines weiteren Readings im Debug Modus hin, das nur angelegt wird, wenn die FTP Verbindung funktioniert und zumindest Inhaltsverzeichnisse auf dem Server gelesen werden können.
Welchen FTP Server hat DWD Dir benannt?
Bisher war das immer ftp-outgoing2.dwd.de
Ich habe gerade eine neue Modulversion eingecheckt, die etwas mehr Logging zum Verbindungsaufbau liefert, das Logging taucht in verbose=4 auf.
Kleine Frage am Rande,
sind die Pollenflugdaten vom DWD in diesem Modul verfügbar oder könnte man sie verfügbar machen?
Zitat von: HolyMoly am 25 Februar 2014, 17:06:45
Kleine Frage am Rande,
sind die Pollenflugdaten vom DWD in diesem Modul verfügbar oder könnte man sie verfügbar machen?
Da will ich mich gleich anhängen:
Wie ist es mit Vorhersagen der Sonennscheindauer?
Zu finden z.B. hier:
http://www.wetter24.de/wetter/hanau/49X3007.html
Inhalt:
<p class="one" title="Sonnenscheindauer: 3h">
<a title="Sonnenscheindauer: 3h" href="wetter/hanau/49X3007/heute.html"></a>
<p class="one" title="Sonnenscheindauer: 0h">
<a title="Sonnenscheindauer: 0h" href="wetter/hanau/49X3007/morgen.html"></a>
Joachim
@jjf: völlig falscher Thread für Deine Frage.
@HolyMoly: Darüber habe ich schon nachgedacht, aber die Bereitstellung der Pollendaten durch den GDS des DWD ist derartig komplex, dass es sich in dem Modul nicht so einfach abbilden lässt. Aber sobald mir eine einigermaßen sinnvolle Lösung dafür einfällt, wird es auch die Nies-und Schnupf-Vorsagen geben.
Ich denke ich habe das Problem.
Mal sehen wie ich das umgehen kann.
Das Modul macht aktives FTP richtig? Das scheint in meiner Konfig Probleme zu machen.
Passives FTP geht.
Nico
Zitat von: santalaus am 26 Februar 2014, 09:40:03Mal sehen wie ich das umgehen kann.
Setze in Deiner Systemumgebung die Umgebungsvariable FTP_PASSIVE auf 1 und teste nochmal.
Ich habe gerade eine Modulversion eingecheckt, in der man das neue Attribut gdsPassiveFtp auf 1 setzen kann, um explizit passiven FTP Transfer zu benutzen.
Ab sofort in SVN verfügbar, morgen früh auch per update.
Hallo,
ich habe versucht GDS auf meiner 7240 zum laufen zu bringen. Ist diese eventuell dafür unterdimensioniert, denn FHEM ist abgestürzt.
Zitat2014.02.26 20:16:30 3: GDS MeinGDS: created
2014.02.26 20:16:30 3: GDS MeinGDS: tempDir=/tmp/
2014.02.26 20:16:31 3: Registering HTTPSRV gds_web_MeinGDS for URL /MeinGDS...
2014.02.26 20:16:31 3: GDS MeinGDS: no datafile (conditions) found
2014.02.26 20:16:31 3: GDS MeinGDS: no datafile (alerts) found
Die fehlenden Module List..., XML..., Text... habe ich bei CPAN heruntergeladen, entpackt und via FTP verschoben. Net... war schon vorhanden.
Gruß rabbe
Zur Fritzkotz kann ich nicht viel sagen, ich würde nie auf die Idee kommen, mit sowas zu arbeiten.
Spontan fällt mir nur die Frage ein, ob Du auch LWP::ua installiert hast?
Nein, das ist nicht vorhanden/fehlt.
Dann kann es nicht funktionieren. Das Modul ist deshalb nicht extra erwähnt, weil ich das normalerweise als vorhanden voraussetze.
Erst einmal recht vielen Dank. Werde berichten, ob es daran lag/liegt.
Das Fehlen des LWP ist die einzige Fehlermöglichkeit, die an der von Dir genannten Stelle (laut Logfile) zum Absturz führen kann.
Mal schauen, bei der nächsten Änderung werde ich auch diese Möglichkeit noch abfangen und eine entsprechende Meldung ausgeben.
Zitat von: betateilchen am 26 Februar 2014, 21:23:35
Mal schauen, bei der nächsten Änderung werde ich auch diese Möglichkeit noch abfangen und eine entsprechende Meldung ausgeben.
Erledigt. Ab sofort in SVN und morgen früh als Update.
Mit gdsPassiveFtp funktioniert es. Als Umgebungsvariable wollte er auch nicht.
Danke
Nico
Na immerhin ist Dein Problem ja nun gelöst :)
Das mit der Umgebungsvariablen ist nur eine Möglichkeit, an der man das vorgeben kann, wobei es dann eine Rangfolge gibt, welche Vorgabe zieht (perl verhält sich da recht eigensinnig) Deshalb ist die Vorgabe direkt beim Verbindungsaufbau, wie jetzt eingebaut, die zuverlässigste Variante.
Danke für Deine Rückmeldung.
Hallo,
wahrscheinlich mache ich irgendetwas falsch. FHEM ist wiederum angestürzt, obwohl ich LWP... kopiert habe. Die Fehlermeldung ist identisch. Naja, vielleicht wird es ja am Wochenende etwas.
Danke und Gruß rabbe
Mit der heute per Update bereitgestellten Modulversion sollte fhem aber nicht mehr abstürzen, sondern eine Fehlermeldung generieren und das GDS Device trotzdem anlegen.
DANKE!
Mir als linux newbie hat es sehr geholfen!! ;D
LG Wolfgang
Hallo zusammen,
seit mehreren Tagen versuch eich nun Das GDS Modul zum Laufen bekommen.
Starte ich mit diesen Settings:
Zitat# Deutscher-Wetter-Dienst für Karlsruhe-Rheinst.
define gdseisy GDS USER PW
erscheint meine FHEM Weboberfläche einwandfrei und ich kann mit
Zitat
get gdseisy conditions Karlsruhe-Rheinst.
die Wetterdaten abrufen.
Füge ich allerdings die Zeile
Zitat
set gdseisy conditions Karlsruhe-Rheinst.
hinzu und speichere die fhem.cfg, dann ist die Weboberfläche nicht mehr erreichbar und selbt mit /etc/init.d/fhem stop bzw stop (via SSH) lässt sich FHEM nicht mehr wiederbeleben. Selbst ein Reboot löst das Problem nicht. Erst ein auskommentieren der obigen "set conditions" Zeile mittels SSH-Login belebt meinen FHEM wieder.
Die Module
Zitatapt-get install libnet-lite-ftp-perl liblist-moreutils-perl libxml-simple-perl libtext-csv-perl
sind installiert, wobei "libnet-lite-ftp-perl" nicht gefunden wurde, stattdessen habe ich "libwww-perl" installiert.
Passives FTP löst das Problem auch nicht.
Weiß nicht, was ich jetzt noch probieren könnte.
Was könnte ich nun noch probieren?
Gruß
duffy6
Hier noch ein log bis zum Absturz:
Zitat
2014.04.20 11:06:41 5: Cmd: >define gdseisy GDS XXX YYY<
2014.04.20 11:06:41 5: Loading ./FHEM/55_GDS.pm
2014.04.20 11:06:44 3: GDS gdseisy: created
2014.04.20 11:06:44 3: GDS gdseisy: tempDir=/tmp/
2014.04.20 11:06:44 5: Loading ./FHEM/02_HTTPSRV.pm
2014.04.20 11:06:44 3: Registering HTTPSRV gds_web_gdseisy for URL /gdseisy...
2014.04.20 11:06:44 3: GDS gdseisy: no datafile (conditions) found
2014.04.20 11:06:44 3: GDS gdseisy: no datafile (alerts) found
2014.04.20 11:06:45 3: GDS gdseisy: searching for gds/specials/observations/tables/germany/* on DWD server
2014.04.20 11:06:45 4: GDS gdseisy: ftp connection established.
2014.04.20 11:06:46 4: GDS gdseisy: filelist found.
2014.04.20 11:06:46 3: GDS gdseisy: retrieving SXDL99_DWAV_20140420_0814
2014.04.20 11:06:46 3: GDS gdseisy: using FTP for retrieval
2014.04.20 11:06:46 4: GDS gdseisy: updating readings.
2014.04.20 11:06:47 3: GDS gdseisy: searching for gds/specials/warnings/xml/PVW/Z_CAP* on DWD server
2014.04.20 11:06:47 4: GDS gdseisy: ftp connection established.
2014.04.20 11:06:47 4: GDS gdseisy: filelist found.
2014.04.20 11:06:47 3: GDS gdseisy: retrieving Z_CAP_C_EDZW_20140420090000_PVW_STATUS.xml
2014.04.20 11:06:47 3: GDS gdseisy: using HTTP for retrieval
2014.04.20 11:06:53 4: GDS gdseisy: updating readings.
2014.04.20 11:06:57 5: Cmd: >attr gdseisy gdsDebug 1<
2014.04.20 11:06:57 5: Cmd: >attr gdseisy gdsPassiveFtp 1<
2014.04.20 11:06:57 5: Cmd: >set gdseisy conditions Karlsruhe-Rheinst.<
2014.04.20 11:06:57 3: GDS gdseisy: Retrieving conditions data
2014.04.20 11:06:57 3: GDS gdseisy: searching for gds/specials/observations/tables/germany/* on DWD server
2014.04.20 11:06:57 4: GDS gdseisy: ftp connection established.
2014.04.20 11:06:57 4: GDS gdseisy: filelist found.
2014.04.20 11:06:57 3: GDS gdseisy: retrieving SXDL99_DWAV_20140420_0814
2014.04.20 11:06:57 3: GDS gdseisy: using FTP for retrieval
2014.04.20 11:06:58 4: GDS gdseisy: updating readings.
Hallo,
bin gerade dabei für ein Tablet eine Wetterwarnung zu bauen und versuche mich gerade in die Bedingungen einzuarbeiten.
Das klappt soweit auch schon recht gut, nur leider nimmt er bei mir "a_valid" immer mit 0 an, da ich anscheinend nicht auf Sommerzeit stehe. Die Werte in der Warnung werden ja in Zulu angegeben und es erfolgt keine Zeitkorrektur.
a_expires 2014-04-23T12:30:00+00:00
a_geoCode_WARNCELLID 107131000
a_headline Amtliche WARNUNG vor GEWITTER
a_onset 2014-04-23T10:40:00+00:00
a_sent 2014-04-23T10:40:00+00:00
a_status Actual
a_valid 0
2014-04-23 13:02:43
Wie bekomme ich denn die Zeitdifferenz eingestellt ??
gruß Marc
@duffy6 - sorry, ich habe Deine Frage erst heute gesehen - muss ich mir mal in Ruhe anschauen.
@yogiflop - vermutlich, indem Du Deine Hardwareplattform auf die richtige Zeitzone einstellst.
Zitat von: betateilchen am 23 April 2014, 13:26:36
@yogiflop - vermutlich, indem Du Deine Hardwareplattform auf die richtige Zeitzone einstellst.
gerade geprüft, das ist es nicht, die Einstellungen stehen korrekt auf Europa Berlin +2h.
Die Zeit des System und überall wo ich geguckt habe, sind die Zeiten korrekt.
Sowohl die Zeitzone als auch die Zeitdifferenz.
In FHEM wird die Zeit ebenfalls korrekt angezeigt. Das einzige, was er nicht macht, ist die Zeitdifferenz in den Alerts zu korrigieren.
Die wird dort auch nirgends korrigiert. Ich schau mir das bei Gelegenheit in Ruhe an.
Der DWD schickt normalerweise die alerts immer mit der korrekten Zeitzone (+02:00) und nicht mit (+00:00)
So... jetzt hab ich nochmal in aller Ruhe nachgesehen.
Zitat von: yogiflop am 23 April 2014, 13:17:14
Die Werte in der Warnung werden ja in Zulu angegeben und es erfolgt keine Zeitkorrektur.
Falsch. Die Zeitangaben in der Warnung sind immer Lokalzeit, deshalb steht da +00:00 dahinter.
a_expires 2014-04-23T12:30:00+00:00
a_onset 2014-04-23T10:40:00+00:00
a_valid 0
2014-04-23 13:02:43
Die Warnmeldung war gültig von 10:40:00 - 12:30:00 Uhr. Um 13:02:43 war die Meldung also bereits abgelaufen, deshalb steht a_valid auf 0.
Der DWD verbreitet durchaus auch noch eine gewisse Zeitlang abgelaufene Warnmeldungen, wie in Deinem Beispiel.
Deshalb wird a_valid vom Modul 55_GDS ermittelt und als reading geschrieben. Das a_valid kommt nicht vom DWD!
Mach Dir also keine Sorgen, der Wert für a_valid wird auch bei Dir auf 1 stehen, sobald Du Dich im Gültigkeitszeitraum der Warnmeldung befindest.
Die Warnmeldungen, die jetzt grade per GDS verbreitet werden, sind bereits alle abgelaufen, so wie ich das eben in einer großen Stichprobe getestet habe.
Zitat von: duffy6 am 20 April 2014, 11:02:47
Füge ich allerdings die Zeile set gdseisy conditions Karlsruhe-Rheinst. hinzu und speichere die fhem.cfg, dann ist die Weboberfläche nicht mehr erreichbar und selbt mit /etc/init.d/fhem stop bzw stop (via SSH) lässt sich FHEM nicht mehr wiederbeleben. Selbst ein Reboot löst das Problem nicht. Erst ein auskommentieren der obigen "set conditions" Zeile mittels SSH-Login belebt meinen FHEM wieder.
Auch Dein Problem hat eine völlig logische Erklärung:
Ein "set <gdsName> irgendwas..." gehört niemals (!!!) in die fhem.cfg.In der fhem.cfg (und in eventuell eingebundenen include Dateien) dürfen sich
ausschließlich 5 mögliche Elemente befinden:
- Zeilen, die mit define beginnen
- Zeilen, die mit attr beginnen
- Zeilen, die mit include beginnen
- Zeilen, die mit # beginnen (Kommentare)
- Leerzeilen
MEHR NICHT!Manche lernen es nie 8)
Das habe ich auch erst gedacht und habe die Daten aus fhem dann mit denen von der dwd Homepage verglichen und da war dann die 2 stunden Differenz wieder. Die Meldung oben wurde erst um 12:30 Uhr gesendet
Gesendet von meinem iPhone
hm... *grübel* Ich denk nochmal drüber nach. Vermutlich aber erst am Wochenende.
Problem gelöst. Kommt morgen per update, ab jetzt schon in SVN.
Falls hier jemand was von einer temporären Lösung mit einem dummy gelesen haben sollte: Einfach ganz schnell wieder vergessen 8)
ZitatAuch Dein Problem hat eine völlig logische Erklärung: Ein "set <gdsName> irgendwas..." gehört niemals (!!!) in die fhem.cfg.
In der fhem.cfg (und in eventuell eingebundenen include Dateien) dürfen sich ausschließlich 5 mögliche Elemente befinden
Und wo muss ich es dann eintragen?
Habe es per Telnet versucht, aber dann werden die Werte (nun nach über 2,5 Std.) nicht im Stundenrythmus abgerufen.
Muss das noch zusätzlich irgendwo aktiviert werden?
Gruß
duffy6
Das musst Du nicht aktivieren. Es wird aktiviert, wenn das set erfolgt.
Am einfachsten baust Du Dir ein notify, das auf global:INITIALIZED|REREADCFG triggert und dann das set ausführt.
define startGDS notify global:(INITIALIZED|REREADCFG) set mygds conditions irgendwo
Zitatdefine startGDS notify global:(INITIALIZED|REREADCFG) set mygds conditions irgendwo
Und das schreibe ich so in die fhem.cfg?
Wenn ich das nämlich tue, schmiert mir FHEM wieder ab!
Ich hatte (vor deinem obigen Tipp) ja auch
Zitatset gdseisy conditions Karlsruhe-Rheinst.
via Telnet ausgeführt und trotzdem bekam ich keine stündliche Aktualisierung. Laut deinem letzten Beitrag hätte das ja funktionieren müssen, oder?
Gruß
duffy6
- Man schreibt überhaupt nichts manuell in die fhem.cfg.
- Ich weiss nicht, was Du falschmachst.
- Bei mir werden die gesetzten conditionsdaten problemlos aktualisiert.
- Du bist offenbar der Einzige mit einem solchen Problem.
Was steht denn aktuell im Log vor dem Abbruch? In Deinem ersten Log lief das Modul ja zumindest soweit, dass es versucht hat, readings zu aktualisieren.
Ich probiere momentan (angesteckt durch den RSS-Workshop) ebenfalls mit der DWD/GDS-Geschichte rum.
Dabei bin ich gestern auch über die genannten Punkte gestolpert; wenn auch etwas differenziert.
Vielleicht habe ich die Vorgehensweise aber auch noch nicht richtig verstanden!?
1. (Warum) muss man das "set conditions" wiederholen?
Wird das nach einmaliger Eingabe nicht gespeichert, ich will ja schliesslich immer die Daten meines Heimatortes bzw. der nächstgelegenen Messstelle.
2. Für die Aktualisierung der Warnung muss ich eine at-Definition mit "get alerts xxx" manuell anlegen (wenn ich möchte).
Dazu merke ich mir Namen oder Warncellid meines Wunsch-Bereiches, da nicht immer für alle Bereiche eine Warnung vorliegt und diese dann auch nicht im Pull-Down verfügbar sind.
Gibt es keine aktuelle Warnung wird das auch bei maueller Eingabe als Hinweis angezeigt.
Dann verschwinden auch die bisherigen Readings, wodurch man kein "a_valid" mehr zur Verfügung hat (eine Abfrage auf a_valid eq 0 geht dann nicht, man muss also a_valid ne 1 nehmen).
Reicht diese Abfrage mit dem get aus ???
Gestern war eine Warnung seit 1 Stunde und noch 1 Stunde aktuell, beim get alerts wurde aber immer "keine Warnung" ausgegeben !?
Zitat von: Hollo am 25 April 2014, 09:17:16
Ich probiere momentan (angesteckt durch den RSS-Workshop) ebenfalls mit der DWD/GDS-Geschichte rum.
Dabei bin ich gestern auch über die genannten Punkte gestolpert; wenn auch etwas differenziert.
Vielleicht habe ich die Vorgehensweise aber auch noch nicht richtig verstanden!?
1. (Warum) muss man das "set conditions" wiederholen?
Wird das nach einmaliger Eingabe nicht gespeichert, ich will ja schliesslich immer die Daten meines Heimatortes bzw. der nächstgelegenen Messstelle.
2. Für die Aktualisierung der Warnung muss ich eine at-Definition mit "get alerts xxx" manuell anlegen (wenn ich möchte).
Dazu merke ich mir Namen oder Warncellid meines Wunsch-Bereiches, da nicht immer für alle Bereiche eine Warnung vorliegt und diese dann auch nicht im Pull-Down verfügbar sind.
Gibt es keine aktuelle Warnung wird das auch bei maueller Eingabe als Hinweis angezeigt.
Dann verschwinden auch die bisherigen Readings, wodurch man kein "a_valid" mehr zur Verfügung hat (eine Abfrage auf a_valid eq 0 geht dann nicht, man muss also a_valid ne 1 nehmen).
Reicht diese Abfrage mit dem get aus ???
Gestern war eine Warnung seit 1 Stunde und noch 1 Stunde aktuell, beim get alerts wurde aber immer "keine Warnung" ausgegeben !?
Das scheint das Zeitproblem zu sein, das ich auch hatte, sollte mit dem heutigen Update ja behoben sein.
Zitat von: Hollo am 25 April 2014, 09:17:16
(Warum) muss man das "set conditions" wiederholen?
Weil ich als Entwickler des GDS Moduls entschieden habe, dass das der einzige (technisch) richtige Weg ist.
Zitat von: Hollo am 25 April 2014, 09:17:16
Wird das nach einmaliger Eingabe nicht gespeichert, i
Es wird solange benutzt, bis Du fhem neustartest die fhem-Konfiguration neu geladen oder ein neues set conditions durchgeführt wird
Zitat von: Hollo am 25 April 2014, 09:17:16
ich will ja schliesslich immer die Daten meines Heimatortes bzw. der nächstgelegenen Messstelle.
Das "immer" ist nicht die ganze Wahrheit. Es gibt durchaus Leute (wie z.B. mich) die viel unterwegs sind und dann immer die Daten des aktuellen Aufenthaltsortes haben wollen.
Zitat von: Hollo am 25 April 2014, 09:17:16
Für die Aktualisierung der Warnung muss ich eine at-Definition mit "get alerts xxx" manuell anlegen (wenn ich möchte).
Jepp. Das ist die richtige Vorgehensweise. Dabei ist der Hintergrund, dass man ggf. die Warnmeldungen für mehrere Orte (z.B. Wohnwagen auf dem Campingplatz, Ferienwohnung irgendwo, Zuhause) verarbeiten möchte.
Und das bereits genannte Zeitproblem in den Warnmeldungen sollte seit dem heutigen Update gelöst sein.
Bestimmt eine sehr dumme Frage.
Ich wollte heute mal das Modul laden. Da ich den Fehler bekomme dass das Modul nicht Laden kann, gehe ich davon aus das ein perl Modul fehlt.
Gemäß commands Net::FTP, List::MoreUtils, XML::Simple, Text::CSV
Wie bekomme ich beim CT heraus welches der Module fehlt?
Installiere einfach alle vier, apt-get erkennt das automatisch, und wird bereits vorhandene Pakete nicht noch einmal installieren.
Ausserdem steht in Deinem fhem-Logfile in einer Fehlermeldung, welches Modul fehlt. Oder Du machst einfach mal ein "reload 55_GDS" in der fhem-Befehlszeile, dann erscheint die Fehlermeldung sogar im Frontend.
Danke bei mir fehlt Text::CSV
Aber mit apt-get Text::CSV oder auch apt-get libtext-csv-xs-Perl passiert leider nichts.
Sorry bin Noch ein doofer Windows Nutzer
apt-get install libtext-csv-perl
Danke, wie ich danach festgestellt habe haben noch 2 andere Module gefehlt aber mit deiner Hilfe klappt es jetzt
Zitat von: Hollo am 25 April 2014, 09:17:16
1. (Warum) muss man das "set conditions" wiederholen?
Wird das nach einmaliger Eingabe nicht gespeichert, ich will ja schliesslich immer die Daten meines Heimatortes bzw. der nächstgelegenen Messstelle.
Nur mal so nebenbei zu dieser immer wieder auftauchenden Frage angemerkt:Seit 30. August 2013 gibt es im Modul GDS die Möglichkeit, eine Station per Attribut gdsSetCond zu definieren, die nach dem Starten automatisch gesetzt wird.
http://forum.fhem.de/index.php/topic,14106.msg92581.html#msg92581
Das ist übrigens der gleiche Thread, in dem wir uns auch jetzt hier befinden.
Zitat von: betateilchen am 25 April 2014, 10:00:09
Jepp. Das ist die richtige Vorgehensweise. Dabei ist der Hintergrund, dass man ggf. die Warnmeldungen für mehrere Orte (z.B. Wohnwagen auf dem Campingplatz, Ferienwohnung irgendwo, Zuhause) verarbeiten möchte.
Und das bereits genannte Zeitproblem in den Warnmeldungen sollte seit dem heutigen Update gelöst sein.
Das habe ich verstanden und ein entsprechendes at definiert.
+*00:30:00 { fhem ("get gds alerts 105766000") }Heute morgen fhem update auf aktuellsten Stand und shutdown restart.
Trotzdem bleibt der Effekt identisch...
beim DWD liegt die Warnung seit 15:49 Uhr vor und ich habe trotz halbstündigem Update um 17:28 Uhr noch nix (letzter Abruf durch at war um 17:19 Uhr).
Wo liegt mein Fehler?
P.S.:
1. Wenn ich denn die Meldung "Amtliche WARNUNG vor STARKEM GEWITTER" in den Readings hätte, wird dann auch der Text irgendwo abgelegt?
2. Gibt es auch eine Möglichkeit, die aktuell gültigen Icons zur Warnsituation einzubinden?
Nein, Du hast die Funktionsweise des Moduls immer noch nicht verstanden.
Zitat von: Hollo am 26 April 2014, 17:21:13
Wo liegt mein Fehler?
Du aktualisierst nirgends Deine Datenfiles. Das "get gds alerts ..." wertet immer das auf Deinem Rechner bereits vorhandene Datenfile aus.
Solange Du diese Datei nicht aktualisierst, wirst Du auch keinen anderen Meldungsstatus ermitteln können.
Du brauchst also
zwei at-Definitionen: Die erste, die das Datenfile aktualisiert und die zweite, die das Datenfile auswertet. Bei mir erfolgen die beiden Schritte immer mit fünf Minuten Abstand zueinander.
Ich schlage vor, Du beschäftigst Dich noch einmal intensiv mit diesem Thread (da wurde das nämlich schon genau beschrieben) und/oder der commandref.
Zitat von: Hollo am 26 April 2014, 17:21:13
1. Wenn ich denn die Meldung "Amtliche WARNUNG vor STARKEM GEWITTER" in den Readings hätte, wird dann auch der Text irgendwo abgelegt?
Ja, im reading a_headline
Zitat von: Hollo am 26 April 2014, 17:21:13
2. Gibt es auch eine Möglichkeit, die aktuell gültigen Icons zur Warnsituation einzubinden?
Nein.
Zitat von: betateilchen am 26 April 2014, 17:58:49
Du brauchst also zwei at-Definitionen: Die erste, die das Datenfile aktualisiert und die zweite, die das Datenfile auswertet. Bei mir erfolgen die beiden Schritte immer mit fünf Minuten Abstand zueinander.
Wie kann ich das am elegantesten definieren ??? das sie in Abhängigkeit zu einander arbeiten ?
*grmpf* das sind doch absolute fhem-Basics...
define readGDS at +*00:10:00 get gds rereadcfg
attr readGDS alignTime 22:30:05
define checkGDS at +*00:10:00 get gds alerts 105116000
attr checkGDS alignTime 22:35:05
Was Du bei alignTime einträgst, ist eigentlich egal, wichtig ist nur, dass die beiden alignTime genau 5 Minuten (genauer: die Hälfte der bei beiden at identischen Wiederholungszeit) auseinanderliegen.
Zitat von: betateilchen am 26 April 2014, 23:06:01
*grmpf* das sind doch absolute fhem-Basics...
define readGDS at +*00:10:00 get gds rereadcfg
attr readGDS alignTime 22:30:05
define checkGDS at +*00:10:00 get gds alerts 105116000
attr checkGDS alignTime 22:35:05
Was Du bei alignTime einträgst, ist eigentlich egal, wichtig ist nur, dass die beiden alignTime genau 5 Minuten (genauer: die Hälfte der bei beiden at identischen Wiederholungszeit) auseinanderliegen.
autsch .....
??? wo tuts weh?
Zitat von: betateilchen am 26 April 2014, 23:06:01
*grmpf* das sind doch absolute fhem-Basics...
define readGDS at +*00:10:00 get gds rereadcfg
attr readGDS alignTime 22:30:05
define checkGDS at +*00:10:00 get gds alerts 105116000
attr checkGDS alignTime 22:35:05
Was Du bei alignTime einträgst, ist eigentlich egal, wichtig ist nur, dass die beiden alignTime genau 5 Minuten (genauer: die Hälfte der bei beiden at identischen Wiederholungszeit) auseinanderliegen.
Recht vielen Dank für die Hilfe/Begleitung. :)
Hallo,
bei mir läuft das Modul seit ca. 1 Woche völlig fehlerfrei....
..vielen Dank für die geleistet Arbeit......
gruß aus Berlin,
Joachim
Zitat von: betateilchen am 26 April 2014, 17:58:49
Nein, Du hast die Funktionsweise des Moduls immer noch nicht verstanden.
Du aktualisierst nirgends Deine Datenfiles. Das "get gds alerts ..." wertet immer das auf Deinem Rechner bereits vorhandene Datenfile aus.
Solange Du diese Datei nicht aktualisierst, wirst Du auch keinen anderen Meldungsstatus ermitteln können.
Du brauchst also zwei at-Definitionen: Die erste, die das Datenfile aktualisiert und die zweite, die das Datenfile auswertet. Bei mir erfolgen die beiden Schritte immer mit fünf Minuten Abstand zueinander.
Ich schlage vor, Du beschäftigst Dich noch einmal intensiv mit diesem Thread (da wurde das nämlich schon genau beschrieben) und/oder der commandref.
Ja, im reading a_headline
Nein.
Bin halt Anfänger und lerne noch dazu. :-X
Laut commandref hatte ich das anders verstanden; nix mit "ich lese immer wieder das lokale File"...
Zitatget <name> alerts <region>
Retrieve alert message for selected region from DWD server
Das reading a_headline ist logischerweise die Überschrift, ich meine den Textkörper, also den Inhalt der Warnung.
Im File ist das dann die description bzw. auch noch der Absatz mit den Hinweisen.
Bitte nicht falsch verstehen, aberwäre es nicht einfacher, wenn die Aktualisierungen nach Eingabe von condition, warncellid und update-intervall automatisch gehen würden. Ohne den Threat ist das erstmal nicht soo ersichtlich.
Trotzdem Danke für das Modul und Deine geduldigen Hilfestellungen; ich weiss wie anstrengend das manchmal ist.
Zitat von: Hollo am 28 April 2014, 08:11:52
Das reading a_headline ist logischerweise die Überschrift, ich meine den Textkörper, also den Inhalt der Warnung.
Im File ist das dann die description bzw. auch noch der Absatz mit den Hinweisen.
Die description steht im reading a_description (wer hätte das gedacht...) sobald Du eines der beiden Attribute gdsAll oder gdsLong gesetzt hast.
Zitat von: Hollo am 28 April 2014, 08:11:52
wäre es nicht einfacher, wenn die Aktualisierungen nach Eingabe von condition, warncellid und update-intervall automatisch gehen würden.
Nein, denn das würde meiner Intention bei der Entwicklung des Moduls komplett zuwiderlaufen. Die conditions
werden übrigens automatisch aktualisiert, wenn sie mit set gesetzt sind.
Vielen Dank, das hat mir ordentlich weitergeholfen.
Ich muss mich doch noch mehr mit den ganzen Möglichkeiten und der Syntax von FHEM befassen.
Bzgl. der Icons der Warntabelle habe ich eine kleine Krücke eingebaut... http://forum.fhem.de/index.php/topic,22630.msg164669.html#msg164669 (http://forum.fhem.de/index.php/topic,22630.msg164669.html#msg164669) .
Über das Reading a_eventCode_Group sind die Namen der aktuell gültigen Icons vorhanden, so dass man die als lokale Bilddateien abspeichern und dann anzeigen lassen kann (wobei ich nicht alle will und die korrekte Farbe erstmal zweitrangig ist.
Zitat von: Hollo am 02 Mai 2014, 17:00:25
Über das Reading a_eventCode_Group sind die Namen der aktuell gültigen Icons vorhanden
deshalb wird das reading ja mit ausgegeben ;)
Guten Morgen,
ich habe in letzter Zeit sehr oft den Fehler "500 Can't connect to api.openweathermap.org:80 (timeout)", ist das ein allgemeines Problem, oder liegt es mal wieder bei mir ??
gruß Marc
nö, das liegt erfahrungsgemäß am openweathermap Server.
Aber mit dieser Frage bist Du hier im völlig falschen Thread!
Wieso ?
In der Überschrift steht doch Openweathermap.
duck und weg
Du solltest die Überschrift genau lesen. Hier geht es um die GDS Daten des Deutschen Wetterdienstes und nicht um openweathermap.
Ich hatte es verstanden
Zitat von: yogiflop am 23 April 2014, 13:17:14
bin gerade dabei für ein Tablet eine Wetterwarnung zu bauen und versuche mich gerade in die Bedingungen einzuarbeiten.
Das klappt soweit auch schon recht gut, nur leider nimmt er bei mir "a_valid" immer mit 0 an, da ich anscheinend nicht auf Sommerzeit stehe. Die Werte in der Warnung werden ja in Zulu angegeben und es erfolgt keine Zeitkorrektur.
Ab dem morgigen Update liefert das Modul zwei zusätzliche readings "a_onset_local" und "a_expires_local" in denen die korrekten Zeitwerte, basierend auf der lokalen Zeitzone, stehen sollten. Damit sollte die Verarbeitung der Gültigkeitsdaten erheblich einfacher sein.
Zitat von: betateilchen am 07 Mai 2014, 19:22:34
nö, das liegt erfahrungsgemäß am openweathermap Server.
Aber mit dieser Frage bist Du hier im völlig falschen Thread!
danke ....
mea culpa, mea maxima culpa
Ich habe auch hierzu mal ein Frage.
Ich möchte gerne über dein Modul die Alarmmeldungen bzw. Wetterwarnungen nutzen.
Ich habe soweit verstanden das Alarmmeldungen nur angezeigt werden, wenn es auch welche für die gesuchte Region gibt.
Aber wie kann ich denn die Region setzen, das leuchtet mir nicht so ganz ein.
In der Drop-Down-Liste für die "alerts" ist meine Region nicht mit dabei, muss ich warten bis eine Meldung dafür vorliegt, oder mache ich was falsch?
Region ist: GLX (Rheinisch-Bergischer-Kreis) 105378000
Der Rest funktioniert so wie er soll.
Zitat von: flocki am 13 Mai 2014, 21:41:09
In der Drop-Down-Liste für die "alerts" ist meine Region nicht mit dabei,
dann gibt es für Deine Region keine aktuelle Alarmmeldung.
Zitat von: flocki am 13 Mai 2014, 21:41:09
Region ist: GLX (Rheinisch-Bergischer-Kreis) 105378000
Grundsätzlich:
get <gdsName> alerts 105378000und falls es aktuelle Warnmeldungen gibt, werden die entsprechenden Readings angelegt.
Die genaue Vorgehensweise habe ich vor einigen Tagen hier im Thread schonmal ausführlich erklärte. Blättere einfach ein paar Beiträge zurück.
Danke, dachte ich mir.
Ich fuchse mich mal durch. 8)
Ich habe mal eine Frage zu der Darstellung der Unwetterwarnung als Text.
Ich bekomme es nicht hin das der Text in mehrere Zeilen aufgeteilt wird.
wenn ich Textbox benutze wird gar nichts angezeigt.
Als "Text" steht alles in einer Zeile bis über den Bildschirm hinaus.
Definition in meiner rss.layout sieht so aus:
# Warntext
pt 12
text 20 80 {utf8ToLatin1(ReadingsVal("gds","a_description","")) }
# textbox 20 80 500 {utf8ToLatin1(ReadingsVal("gds","a_description","")) }
das ist doch keine Frage zu 55_GDS sondern eher für den RSS-Workshop.
Grundsätzlich kann ich bei Deinem textbox Eintrag keinen Fehler erkennen.
Hast Du mal in das Logfile von fhem geschaut, wenn Du versuchst, den textbox Befehl zu verwenden?
Hast Du die in der commandref aufgeführten, für die erweiterte Textdarstellung zusätzlich benötigten perl Module installiert?
Bin gerade mehr aus Zufall auf GDS gestossen. Ist genau was ich für meine "Overview" Seite suche.
Jetzt habe ich zwei Fragen/Probleme:
1. ist det Pfad z.B. Zur Map falsch (/temp//...)
Wie bekomme ich den zweiten / weg?
2. wie kann ich warnungen automatisch auf der Weboberfläche anzeigen? Am liebsten in einem bestimmten Raum?
Raum vermutlich mit attr room.
Danke im voraus.
Sent from my iPhone using Tapatalk 2
Gruss
Markus
- Der Pfad kann nicht falsch sein. Ausserdem ist auf Linux-Systemen der Pfad /tmp/ und nicht /temp/
- Mit dem GDS Modul gar nicht. Die Warnmeldungen stehen in readings. Die Darstellung musst Du Dir schon selber bauen
Danke beta.
Mit dem TEMP hatte ich mich vertippt, es ist tmp//
und da sind wie gesagt, zwei mal // im Pfad und er findet nichts?
Leider kann ich nciht weiter testen, weil mir das Modul GDS gerade meinen Rechner abschmieren hat lassen und ich nicht Vorort bin :-\
Zu 2. habe ich mir fast gedacht, muss ich mir etwas basteln.
Zitat von: Mitch am 22 Mai 2014, 16:48:52
Danke beta.
Hast Du heute einen Clown gefrühstückt?
Zitat von: Mitch am 22 Mai 2014, 16:48:52
Mit dem TEMP hatte ich mich vertippt, es ist tmp//
Bei mir tauchen nirgends zwei slashes auf. Ausserdem ist das Verzeichnis für den Anwender völlig irrelevant.
Das mit dem Clow muss ich jetzt nicht verstehen?
Wollte nur höflich sein.
Pfad kann ich nachliefern, wenn ich Zuhause bin und die Kiste wieder läuft.
Sent from my iPhone using Tapatalk 2
Gruss
Markus
Zitat von: Mitch am 22 Mai 2014, 16:54:42
Das mit dem Clow muss ich jetzt nicht verstehen?
Wollte nur höflich sein.
Einen Nutzernamen durch sinnloses Verkürzen zu verunstalten ist nicht höflich.
Zitat von: Mitch am 22 Mai 2014, 16:54:42
Pfad kann ich nachliefern, wenn ich Zuhause bin und die Kiste wieder läuft.
Es gibt in dem Modul nirgends einen Pfad, der vom Anwender zu nutzen wäre.
ich hab gerade nach das gds modul wieder raus gekramt dabei sind mir ein paar dinge aufgefallen.
in der doku ist ein tippfehler bei 'get <name> list' -> capstationlist statt capstatio. im get help taucht das gar nicht auf.
in der doku ist bei capstation von 'warning regions' und WARNCELLID die rede. es geht aber um das was dann mit get alerts geholt wird und nicht mit get warnings.
ein get warnings im browser und aus der detail ansicht geht: VHDL30 = current | VHDL31 = weekend or holiday
VHDL32 = preliminary | VHDL33 = cancel VHDL32
-------------------------------+--------------------------------------
VHDL30 DWSG 221800
WARNLAGEBERICHT
für Baden-Württemberg
ausgegeben vom Deutschen Wetterdienst
am Donnerstag, 22.05.2014, 20:30 Uhr
Abends zunächst noch zum Teil unwetterartige Gewitter möglich. Nachts
schauerartiger und zum Teil gewittriger Regen. Am Freitag
nachlassende Niederschläge.
Entwicklung der Wetter- und Warnlage für die nächsten 24 Stunden bis
Freitag, 23.05.2014, 20:30 Uhr:
Ausgehend von einem umfangreichen Tiefdrucksystem über Westeuropa
erfasst eine Kaltfront Baden-Württemberg. Zuvor strömt warme und
zunehmend feuchte Luft heran, die am Freitag durch kühlere
Atlantikluft ersetzt wird.
Heute Abend sind anfangs noch kräftige, örtlich auch unwetterartige
Gewitter möglich. Die Gewitter können lokal mit heftigem Starkregen
von mehr als 30 Liter pro Quadratmeter in kurzer Zeit, Hagel mit
Korngrößen von mehr als 2 cm sowie mit Sturmböen um 85 km/h,
vereinzelt auch mit schweren Sturmböen bis 100 km/h einhergehen. In
der zweiten Nachthälfte ziehen die Gewitter nordostwärts ab. Im
nachfolgenden schauerartigen Regen sind nur noch einzelne Gewitter
eingelagert.
Am Freitag besteht im Tagesverlauf lediglich ein geringes
Gewitterrisiko.
Nächste Aktualisierung: spätestens Freitag, 23.05.2014, 04:30 Uhr
Deutscher Wetterdienst, Regionale Wetterberatung Stuttgart, Clemens
Steiner
----------------------------------------------------------------------
aber nicht per telnet:get gds warnings Baden-Württemberg
VHDL30 = current | VHDL31 = weekend or holiday
VHDL32 = preliminary | VHDL33 = cancel VHDL32
Steiner r Wetterdienst, Regionale Wetterberatung Stuttgart, Clemens -
---------------------------------------------------------------------- da fehlt alles zwischen legende und Fußteile und die fußzeile ist verstümmelt. kann es sein das da mit den newlines was nicht stimmt und alles in die gleiche zeile immer wieder übereinander ausgegeben wird? das passiert auf einem mac.
im get alerts drop down habe ich sehr viele doppelte einträge. wenn das tatsächlich unterschiedliche alarme sind nützt es nichts wenn man sie nicht unterscheiden kann. wenn es gleiche sind sollte man die doppelten ausblenden.
wie wäre es wenn es eine möglichkeit gäbe (automatisch) abgelaufene alarme (also nur die a_) readings zu löschen?
ich fände es wäre praktisch beim 'get alerts' direkt die WARNCELLID angeben zu können. nicht nur den klar namen.
gruss
andre
Zitat von: justme1968 am 22 Mai 2014, 23:12:39
aber nicht per telnet:
telnet geht mir ziemlich am Allerwertesten vorbei. Die telnet-Schnittstelle in fhem ist so krank, dass ich da nicht eine Minute Entwicklungsarbeit reinstecke.
Zitat von: justme1968 am 22 Mai 2014, 23:12:39
im get alerts drop down habe ich sehr viele doppelte einträge. wenn das tatsächlich unterschiedliche alarme sind nützt es nichts wenn man sie nicht unterscheiden kann. wenn es gleiche sind sollte man die doppelten ausblenden.
Es sind unterschiedliche, aber der Fall kommt recht selten vor. Heute zum Beispiel, wo es fast für die gesamte Bundesrepublik Warnmeldungen UND Vorwarnungen gleichzeitig gibt.
Zitat von: justme1968 am 22 Mai 2014, 23:12:39
wie wäre es wenn es eine möglichkeit gäbe (automatisch) abgelaufene alarme (also nur die a_) readings zu löschen?
Mach doch. Du musst Dir nur ein at definieren, das regelmäßig die alerts für die gewünschte Region abruft. Wenn es dabei keine neuen alerts mehr gibt, verschwinden auch die abgelaufenen a_ readings. Bei mir werden die alerts alle 10 Minuten geprüft, also sind spätestens 10 Minuten nach dem Ablauf einer Warnung auch die readings verschwunden.
Zitat von: justme1968 am 22 Mai 2014, 23:12:39
ich fände es wäre praktisch beim 'get alerts' direkt die WARNCELLID angeben zu können. nicht nur den klar namen.
Mach doch, das gds Modul ist intelligenter als Du denkst.
get gds alerts 105116000funktioniert jedenfalls problemlos.
Zitat von: justme1968 am 22 Mai 2014, 23:12:39
in der doku ist bei capstation von 'warning regions' und WARNCELLID die rede. es geht aber um das was dann mit get alerts geholt wird und nicht mit get warnings.
Ja. Und das ist kein Fehler, das sind unterschiedliche Datenbestände, wie Dir ja auch an den unterschiedlichen Meldungen aufgefallen sein könnte.
Die Terminologie der GDS Beschreibung habe ich nicht zu verantworten (da sind sogar "echte" Fehler drin)
Übrigens - irgendjemand hat Dir heute abend sowohl beim Satzbau als auch bei der Rechtschreibung mal wieder gewaltig in die Suppe gespuckt, weswegen ich Deinen Beitrag mindestens fünfmal lesen musste, um rauszufinden, was Du eigentlich willst.
Zitat von: betateilchen am 22 Mai 2014, 15:29:26
das ist doch keine Frage zu 55_GDS sondern eher für den RSS-Workshop.
Sorry habe mich im Post vertan.
Zitat von: betateilchen am 22 Mai 2014, 15:29:26
Grundsätzlich kann ich bei Deinem textbox Eintrag keinen Fehler erkennen.
Hast Du mal in das Logfile von fhem geschaut, wenn Du versuchst, den textbox Befehl zu verwenden?
Hast Du die in der commandref aufgeführten, für die erweiterte Textdarstellung zusätzlich benötigten perl Module installiert?
Ja alle perl Module sind installiert, funktioniert bei einer anderen RSS.layout Problemlos.
Im Log steht leider nichts
Zitat von: betateilchen am 22 Mai 2014, 16:58:27
Es gibt in dem Modul nirgends einen Pfad, der vom Anwender zu nutzen wäre.
So, hier die Fehlermeldung:
File not found: /tmp//DWD_conditionsmap.jpgKommt, wenn ich einen der Links aus GDS DWD Files, z.B. Aktuelle Wetterkarte: Wetterlage klicke
Bei mir auch der gleiche Fehler...
die anzahl der / ist nicht relevant. das file ist schlicht und einfach nicht da.
habt ihr die map mit 'get <device> conditionsmap' geholt? das macht das gds modul nicht automatisch sondern mit dem expliziten get.
diese dinge musst du mit einem at selber automatisieren.
gruss
andre
Das muss man nicht zwingend über ein at machen. Man kann die Karten auch einfach dann per get abrufen, wenn man sie wirklich braucht.
Bei mir im RSS Layout sieht das beispielsweise so aus:
img .5 240 h380 jpeg file { fhem("get gds conditionsmap West"); "/tmp/gds_conditionsmap.jpg" }
Mit get conditionsmap gehts, danke!
tja, Doku lesen wäre manchmal nicht die schlechteste Idee.
Hallo zusammen,
ich verfolge das Thema nun seit ein paar Tagen, steh aber aufm Schlauch.
Wenn ich das jetzt hier alles so richtig mitbekommen habe muss ich als FritzBox Nutzer ein paar Module nachinstallieren.
Meine Fehler Meldung nach dem ich reload 55_GDS eingegeben habe lautet:
Can't locate Text/CSV.pm in @INC (@INC contains: /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2 /var/InternerSpeicher/fhem/lib/perl5/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/5.12.2 /opt/lib/perl5/site_perl/5.12.2/mips-linux /opt/lib/perl5/site_perl/5.12.2 /opt/lib/perl5/5.12.2/mips-linux /opt/lib/perl5/5.12.2 . ./FHEM) at ./FHEM/55_GDS.pm line 34.
BEGIN failed--compilation aborted at ./FHEM/55_GDS.pm line 34.Zitat von rabbe:
ZitatDie fehlenden Module List..., XML..., Text... habe ich bei CPAN heruntergeladen, entpackt und via FTP verschoben. Net... war schon vorhanden.
Ich habe mir jetzt auf der Seite:http://search.cpan.org/~makamaka/Text-CSV-1.32/lib/Text/CSV.pm (http://search.cpan.org/~makamaka/Text-CSV-1.32/lib/Text/CSV.pm)
die CSV.pm runtergeladen.
Jetzt zu meiner Frage:
Nach ich die runtergeladene Datei entpackt habe, habe ich einen Ordner der zu der CSV.pm Datei noch einige andere Dateien "beherbergt"
Wo muss der Ordner bzw. die CSV.pm hin verschoben werden damit sie geladen werden kann? Ist das so überhaupt der richtige Weg?
Was ist damit: LWP::ua
Ich denke mal die fehlt bei mir auch :(
Wär schön wenn ich sich rabbe nochmal dazu melden würde, schein wohl bei ihm zu funktionieren.
Grüße Alex
Ich denke, das solltest Du besser im Fritzkotz-Bereich dieses Forums fragen, denn das hat mit GDS nicht direkt etwas zu tun.
Oder Du nimmst einfach mal 30 Euro in die Hand, kaufst Dir davon einen RaspberryPi und entledigst Dich schlagartig all dieser Installationsprobleme.
Fritzkotz ;D der war gut
Hat sich kürzlich jemand dort angemeldet? Ich bekomme seit Freitag immer
Es ist leider ein Fehler aufgetreten. Bitte versuchen Sie sich zu einem späteren Zeitpunkt erneut zu registrieren
wann bekommst Du die Fehlermeldung? Die Anmeldeseite an sich funktioniert, ich kann das Formular ausfüllen. Vermutlich könnte ich es auch abschicken, das habe ich jetzt aber nicht probiert (ich hab ja schon einen Zugang)
Beim abschicken. Email Adresse eintragen, Bedingungen akzeptiert, absenden,Fehler.
Email an admin (ist im Fuß der Seite angegeben) bisher auch ohne Reaktion.
So - GDS läuft jetzt hier auch. Ich hab aber noch ein paar Verständnis Fragen:
Wozu gibt es set und get readcfg? Lt. comandref tun beide das gleiche?
Wenn die Gültigkeitsdauer der Alerts abgelaufen ist bleiben die a_ Readings erhalten und ich muss manuell auf a_valid prüfen?
Noch ein Verbesserungsvorschlag: Die Links in GDS.html funktionieren nicht bei geändertem webname da sie auf /fhem/... codiert sind. Besser wäre ./...
Zitat von: Mx112 am 21 Juli 2014, 23:21:28
Wozu gibt es set und get readcfg? Lt. comandref tun beide das gleiche?
Das ist halt so. Historisch gewachsen.
Zitat von: Mx112 am 21 Juli 2014, 23:21:28
Wenn die Gültigkeitsdauer der Alerts abgelaufen ist bleiben die a_ Readings erhalten und ich muss manuell auf a_valid prüfen?
Das kann man so pauschal nicht sagen. Die alerts müssen ja in fhem irgendwie periodisch geprüft werden, sonst kriegst Du ja gar nicht mit, dass es einen Alert gibt. Und bei dieser Prüfung werden abgelaufene a_ Readings auch automatisch gelöscht. Das Ganze habe ich schon x-Mal hier im Forum erklärt und eine mögliche Vorgehensweise dazu vorgeschlagen.
Zitat von: Mx112 am 21 Juli 2014, 23:21:28
Noch ein Verbesserungsvorschlag: Die Links in GDS.html funktionieren nicht bei geändertem webname da sie auf /fhem/... codiert sind. Besser wäre ./...
Das werde ich prüfen und ggf. in einer der nächsten Versionen ändern.
Zitat von: betateilchen am 22 Juli 2014, 11:02:39
Das kann man so pauschal nicht sagen. Die alerts müssen ja in fhem irgendwie periodisch geprüft werden, sonst kriegst Du ja gar nicht mit, dass es einen Alert gibt. Und bei dieser Prüfung werden abgelaufene a_ Readings auch automatisch gelöscht. Das Ganze habe ich schon x-Mal hier im Forum erklärt und eine mögliche Vorgehensweise dazu vorgeschlagen.
Ich denke ich hab alle verstreuten Infos zu dem Thema gefunden - kann aber nicht ausschließen das ich bei 15 Seiten was übersehen habe oder noch irgendwo einen Denkfehler habe.
Die beiden at funktionieren abwechseld - das File GDS_alerts wird aktualisiert, die die Readings dann ebenfalls. Nur gelöscht werden sie halt nicht. Die alte Warnung (a_expires_local 20.07.2014 19:00:00) ist immer noch vorhanden.
Update: Ich hab jetzt alle alert Readings gelöscht, sowie die GDS files. Wenn ich manuell für eine beliebige Region alerts Abfrage und danach für eine Region, für die keine Meldung vorliegt werden die Readings jetzt gelöscht. Ich hoffe mal das es dann jetzt auch automatisch funktioniert - muss halt warten bis wieder ein alert kommt ...
Zitat von: juppzupp am 21 Juli 2014, 22:26:20
Beim abschicken. Email Adresse eintragen, Bedingungen akzeptiert, absenden,Fehler.
Email an admin (ist im Fuß der Seite angegeben) bisher auch ohne Reaktion.
Fehler wurde heute vom DWD behoben.
bug oder feature ?
{ ReadingsVal("DWD","a_eventCode_II","") . ".png" }
erzeugt ein freizeichen zuviel , ergebnis als beispiel "38 .png"
während
{ ReadingsVal("MyWetter","fc4_code","") . ".png" }
als beispiel ein "38.png" ohne freizeichen vor dem punkt erzeugt.
grüße
und noch eine Frage....
Wann bzw wie wird die Datei gds_alerts refreshed ?
ich lasse via at einmal pro stunde
+*01:00:00 get DWD alerts 105158000
laufen, aber der zeitstempel der datei steht noch immer auf gestern ?
danke
Kennst Du eigentlich den Unterschied zwischen "jemanden um Hilfe bitten" und "jemandes Gutmütigkeit ausnutzen"?
{ trim(ReadingsVal("DWD","a_eventCode_II","")) . ".png" } Ausserdem heißt es Leerzeichen und nicht Freizeichen (Freizeichen gibts beim Telefon).
Zitat von: juppzupp am 28 Juli 2014, 19:04:53
Wann bzw wie wird die Datei gds_alerts refreshed ?
...
laufen, aber der zeitstempel der datei steht noch immer auf gestern ?
Das Verhalten ist logisch und logischerweise "falsch" im Sinne dessen, was Du eigentlich tun willst. Die Aktualisierung von Alarmmeldungen habe ich hier im Forum schon unzählige Male erklärt und beschrieben. Lies einfach nach. Tipp: Nach dem, was Du hier schreibst, ist eindeutig erkennbar, dass Du die Alarmdatei
überhaupt nicht vom Server abholst.
Vielleicht hilft auch einfach nochmaliges Lesen der commandref.
liebes betateilchen.
ich bin nicht faul. und bequemlichkeit kann ich mir auch nicht vorwerfen. ausserdem steht dir ein solches urteil gar nicht zu.
aber vielleicht verwechselst du mich ja. soll ja vorkommen.
im Beitrag vom 27 Juli 2014, 15:05:37 habe ich lediglich auf ein unterschiedliches verhalten verschiedener module hingewiesen, und nicht gefragt wie man es beheben kann. das hatte ich zu dem zeitpunkt schon lange getan.
es wäre nur wünschenswert, wenn sich unterschiedliche module gleich verhalten. dem anwender zuliebe.
im heutigen beirag von 19:04:53 habe ich dann doch tatsächlich mal eine frage gestellt, die ich auch nach 2 mal lesen dieses threads nicht beantworten kann. vielleicht steht hier einfach zuviel.
in der commandref steht, dasget <name> alerts <region>
Retrieve alert message for selected region from DWD server
der get es vom server abholt. tut er aber dann anscheinend nicht.
denn : fhem> get DWD alerts 105158000
fhem> GDS DWD _dataSource: Quelle: Deutscher Wetterdienst
GDS DWD a_eventCode_AREA_COLOR: 255 153 0
GDS DWD a_expires: 2014-07-28T16:00:00+00:00
GDS DWD a_category: Met
GDS DWD a_geoCode_STATE: NRW
GDS DWD a_responseType: Prepare
GDS DWD a_identifier: 2.49.0.1.276.DWD.PVW.1406559945518.0
GDS DWD a_areaDesc: Kreis Mettmann
GDS DWD a_sent_local: 28.07.2014 17:05:00
GDS DWD a_valid: 0
GDS DWD a_eventCode_II: 38
GDS DWD a_expires_local: 28.07.2014 18:00:00
GDS DWD a_headline: Amtliche WARNUNG vor STARKEM GEWITTER
GDS DWD a_geoCode_WARNCELLID: 105158000
GDS DWD a_onset: 2014-07-28T13:59:00+00:00
GDS DWD a_eventCode_LICENSE: Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013
GDS DWD a_status: Actual
GDS DWD a_onset_local: 28.07.2014 15:59:00
GDS DWD a_msgType: Alert
GDS DWD a_eventCode_PROFILE_VERSION: 2.1
GDS DWD a_sent: 2014-07-28T15:05:00+00:00
GDS DWD a_eventCode_GROUP: THUNDERSTORM WIND RAIN HAIL
GDS DWD a_event: STARKES GEWITTER
GDS DWD _tzOffset: 7200
GDS DWD _tzOffset: 7200
GDS DWD _tzOffset: 7200
und :root@cubie:/tmp# tcpdump port 80 or 21
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
bleibt leer.
der Zeitstempel hat sich auch nicht geändert :
root@cubie:/tmp# ls -lisah DWD_alerts
727998 1.4M -rw-r--r-- 1 fhem dialout 1.4M Jul 28 17:06 DWD_alerts
root@cubie:/tmp#
da komme ich dann nicht mehr weiter.
get <name> alerts <region>
holt jedenfalls nicht die Alarmdatei vom Server, sondern wertet die bereits vom Server geholte und bereits auf dem fhem-Rechner vorhandene Datei nach der angegebenen Region aus. Das Abholen der aktuellen Daten vom Server erfolgt mit rereadcfg.
Und das steht durchaus alles schon hier im Forum.
Man sollte auch versuchen zu verstehen, wie etwas funktioniert. Copy & Paste war noch nie der bestmögliche Lösungsweg.
@betateilchen:
Kannst du mir einen Tipp geben? Beim "get gds list" stürzt fhem sang- und klanglos ab!
Meldungen auf der Konsole:
root@trinity:(0)/data/netbackup/Todo//readline() on closed filehandle WXDATA at ./FHEM/55_GDS.pm line 397.
Use of uninitialized value $line in chomp at ./FHEM/55_GDS.pm line 397.
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/55_GDS.pm line 403.
fhem log
2014.07.28 20:31:50.730 4: HTTP FHEMWEB:192.168.1.33:37874 GET /fhem/images/default/fhemicon_dark.png
2014.07.28 20:31:50.857 4: HTTP FHEMWEB:192.168.1.33:37912 GET /fhem?XHR=1&inform=type=status;filter=gdsName×tamp=1406572311237
2014.07.28 20:31:56.103 4: Connection closed for FHEMWEB:192.168.1.33:37912
2014.07.28 20:31:56.131 4: HTTP FHEMWEB:192.168.1.33:37916 GET /fhem&detail=gdsName&dev.getgdsName=gdsName&cmd.getgdsName=get&arg.getgdsName=list&val.getgdsName=stations
2014.07.28 20:31:56.151 5: Cmd: >get gdsName list stations<
Danke im Voraus!
gruß
Patrick
"get gds list" ist kein gültiger Befehl.
Was hat copy&paste (im englischen nicht mit großen Buchstaben ;-)
mit einer falschen Dokumentation zu tun? Da steht 'get' holt es vom Server.
Und bei einem rereadCFG erwarte ich (oder vielleicht sogar man) das die Konfiguration neu gelesen wird. Und nicht die Nutzdaten.
Da kann ich hier und in der Referenz Hundert mal lesen, ohne das es klarer wird.
Immer nur rumpointen hier lesen,da lesen, war noch nie der beste Lösungsweg. Denn zumindest in diesem Fall hier, ist das nicht die Wurzel des Problems.
Danke, das du mir geholfen hast.
extra wegen Dir habe ich grade eine neue Modulversion mit geänderter commandref eingecheckt.
Vielen lieben dank, und ich hoffe das auch noch viele andere was davon haben.
Und vielleicht bekommst Du ja dann auch mal weniger nervige, faule, bequeme fragen.
P.S.: s/wegen\ Dir/deinetwegen/g
Zitat von: juppzupp am 28 Juli 2014, 21:30:19
P.S.: s/wegen\ Dir/deinetwegen/g
da wo ich herkomme, heißt es "wegen Dir"
http://www.spiegel.de/kultur/zwiebelfisch/0,1518,267725,00.html
Zitat von: betateilchen am 28 Juli 2014, 20:40:37
"get gds list" ist kein gültiger Befehl.
OMG ich frage mich immer wieder womit wir armen FHEMler dich verdient haben! :-)
get gdsName list stations Besser?
Zitat von: P.A.Trick am 28 Juli 2014, 22:32:10
get gdsName list stations Besser?
Zumindest ist das mal eine konkrete Frage, mit der man was anfangen kann. Gute Nacht.
Achja: ein paar Logs vom gds Modul selbst wären hilfreich.
Guten Morgen,
irgendwie habe ich mal wieder ein Verständnisproblem.
ich refreshe stündlich via at:
+*01:00:00 get DWD rereadcfg;get DWD alerts Kreis_Mettmann
ich bilde mir ein, das das funktioniert, die Datei hat einen aktuellen Zeitstempel:
root@cubie:/tmp# ls -lisah DWD_alerts
770778 156K -rw-r--r-- 1 fhem dialout 156K Aug 5 08:34 DWD_alerts
auch sind Daten in der Datei vorhanden :
root@cubie:/tmp# grep '<value>[0-9]\{9\}' DWD_alerts
<value>103154000</value>
<value>103241000</value>
<value>103157000</value>
<value>103351000</value>
<value>103102000</value>
<value>103151000</value>
<value>103360000</value>
<value>103158000</value>
<value>103103000</value>
<value>103101000</value>
<value>103153000</value>
<value>103254000</value>
<value>103152000</value>
<value>103251000</value>
<value>103156000</value>
<value>103155000</value>
<value>103257000</value>
<value>103256000</value>
<value>103252000</value>
<value>103255000</value>
<value>115087000</value>
<value>116065000</value>
<value>103358000</value>
<value>109272000</value>
<value>109276000</value>
root@cubie:/tmp#
Das module zeigt aber keine Alarme an :
fhem> get DWD alerts 103154000
Keine Warnmeldung für die gesuchte Region vorhanden.
fhem> get DWD alerts 103241000
Keine Warnmeldung für die gesuchte Region vorhanden.
fhem>
Drauf gekommen war ich, weil ich WEBIF das erste mal
No_alerts_published! gesehen hatte.
Im Anhang die DWD_alerts.
Liegts an mir ? Wo steckt der Fehler ?
Danke im voraus für eure Hilfe.
Starte mal FHEM neu. Hab ein ähnliches Problem. Die Alerts werden bei mir nur nach einem Neustart eingelesen oder gelöscht. Danach tut sich bis zum nächsten Neustart nichts mehr obwohl die _alerts Datei regelmäßig aktualisiert wird.
Zitat von: juppzupp am 05 August 2014, 09:14:34
ich refreshe stündlich via at:
+*01:00:00 get DWD rereadcfg;get DWD alerts Kreis_Mettmann
Du solltest die zwei Schritte nicht gleichzeitig tun. Die Aufbereitung der vom Server gelesenen Datei dauert eine gewisse Zeit.
Mach einfach zwei at draus, die mit einem Zeitversatz von mindestens einer Minute aufgerufen werden - so wie ich das schon x-Mal in Beispielkonfigurationen beschrieben habe.
Hallo betateilchen,
habe den get DWD alerts Kreis_Mettmann
aus dem at entfernt.
dann manuell nochmal
get DWD rereadcfg
und sicherheitshalber für mich
sleep 120
abgewartet.
Es bleibt leider so, das ich im WEBIF "No_alerts_published!" sehe, und auch ein "get DWD alerts 115081000" nichts zurück liefert, obwohl in der datei eine Meldung dazu vorhanden ist.
hm, das kann ja nicht die lösung sein.
Zitat von: Mx112 am 05 August 2014, 09:31:54
Starte mal FHEM neu. Hab ein ähnliches Problem. Die Alerts werden bei mir nur nach einem Neustart eingelesen oder gelöscht. Danach tut sich bis zum nächsten Neustart nichts mehr obwohl die _alerts Datei regelmäßig aktualisiert wird.
Zitat von: juppzupp am 05 August 2014, 10:54:28
hm, das kann ja nicht die lösung sein.
Sicherlich nicht. Aber wenn das bei Dir auch so ist das das Modul dann einmalig funktioniert haben wir beide das gleiche Problem.
mal schauen was betateilchen sagt. ich will jetzt den Zustand nicht ändern, falls es noch eine idee zum troubleshooten gibt.
in der eingangs angehängten alerts-Datei finde ich weder einen Eintrag für Mettmann noch einen für 115081000
richtig. das mettmann nix liefert ist klar, aber mich hatte das "No_alerts_published!" stutzig gemacht, und deswegen genauer geschaut.
danach hatte ich ja nochmal manuell refreshed, deswegen ist der für 115081000 auch verschwunden.
im moment habe ich 52 alerts :
root@cubie:/tmp# grep '<value>[0-9]\{9\}' DWD_alerts -c
52
root@cubie:/tmp#
root@cubie:/tmp# for each in `grep '<value>[0-9]\{9\}' DWD_alerts | cut -b8-16` ; do echo list DWD $each | nc -vt localhost 7072 -q2 ; done
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
localhost [127.0.0.1] 7072 (?) open
root@cubie:/tmp#
ohne Ergebnisse. probe ob nc richtig funktioniert :
root@cubie:/tmp# echo list DWD | nc -vt localhost 7072 -q2
localhost [127.0.0.1] 7072 (?) open
Internals:
DEF xyv xyv
LOCAL 1
NAME DWD
NR 327
STATE active
TYPE GDS
CHANGETIME:
Helper:
Dblog:
C_pressure-nn:
Mydblog:
TIME 1407237529.226
VALUE 1019.6
C_temperature:
Mydblog:
TIME 1407237529.226
VALUE 20.5
Readings:
2014-08-05 13:18:49 _dataSource Quelle: Deutscher Wetterdienst
2014-08-05 13:34:45 _tzOffset 7200
2014-08-05 13:18:49 c_altitude 150
2014-08-05 13:18:49 c_nextUpdate Tue Aug 5 13:38:49 2014
2014-08-05 13:18:49 c_pressure-nn 1019.6
2014-08-05 08:38:40 c_rain12h 1
2014-08-05 13:18:49 c_rain1h 0.0
2014-08-05 08:58:40 c_rain24h 0.5
2014-08-05 08:38:40 c_snow ---
2014-08-05 08:58:40 c_solar ----
2014-08-05 13:18:49 c_stationName Essen
2014-08-05 08:58:40 c_sunshine 4.8
2014-08-05 08:58:40 c_tAvgAir24 19.2
2014-08-05 08:38:40 c_tMaxAir12 21.3
2014-08-05 08:58:40 c_tMaxAir24 23.6
2014-08-05 08:38:40 c_tMinAir12 15.5
2014-08-05 08:58:40 c_tMinAir24 15.3
2014-08-05 08:58:40 c_tMinGrnd24 15.0
2014-08-05 13:18:49 c_temperature 20.5
2014-08-05 13:18:49 c_weather ---
2014-08-05 13:18:49 c_windDir NW
2014-08-05 13:18:49 c_windGust ---
2014-08-05 13:18:49 c_windPeak ---
2014-08-05 13:18:49 c_windSpeed 7
2014-07-28 16:05:03 g_altitude 150
2014-07-28 16:05:03 g_pressure-nn 1009.5
2014-07-28 16:05:03 g_rain1h 0.0
2014-07-28 16:05:03 g_stationName Essen
2014-07-28 16:05:03 g_temperature 25.4
2014-07-28 16:05:03 g_weather ---
2014-07-28 16:05:03 g_windDir O
2014-07-28 16:05:03 g_windGust ---
2014-07-28 16:05:03 g_windPeak ---
2014-07-28 16:05:03 g_windSpeed 11
2014-07-31 23:35:14 state active
Helper:
INTERVAL 1200
PASS xyv
URL ftp-outgoing2.dwd.de
USER xcyc
Attributes:
gdsDebug 0
gdsSetCond Essen
room Wetter
verbose 0
root@cubie:/tmp#
Hallo betateilchen,
Ich glaube ich habe ein Problem?
Zitat
# $Id: 55_GDS.pm 6326 2014-07-28 18:14:54Z betateilchen $
Wenn ich diesen Code laufen lasse, bekomme ich keine Alerts Meldung.
#############################################
# DeutscherWetterDienst Information
#
# - 1. DWD Device
# - 2. DWD Device neu einlesen
# - 3. Unwettermeldugen
#
#1.
define DWD GDS xxxxxxx yyyyyyy
attr DWD gdsSetCond 103151000
attr DWD group 08 DWD
attr DWD room Umwelt
#2.
define readDWD at +*00:10:00 get DWD rereadcfg
attr readDWD alignTime 22:35:05
attr readDWD group 08 DWD
attr readDWD room Umwelt
#3.
define alertsDWD at +*00:10:00 get DWD alerts 103151000
attr alertsDWD alignTime 22:40:05
attr alertsDWD group 08 DWD
attr alertsDWD room Umwelt
Wenn ich jetzt aber beim DWD nach sehe, bekomme ich einen
Warnhinweiss.
Mach ich was falsch?
Während meiner Testphase im Rahmen des RSS-Aufbaus hatte ich auch mehrfach "Unstimmigkeiten" zwischen der DWD-Grafik und den GDS-Ausgaben. Musste allerdings auch feststellen, dass teilweise Unterschiede in der Datei vorlagen.
Z.B. sind die Vorwarnungen auf der Seite und in den FTP-Daten nicht immer identisch vorhanden.
Hab ein Problem mit GDS und den get list Befehlen.
In meiner Konfig steht nur :
define DWD GDS **** ****
Benutzername und Passwort mehrmals überprüft.
Wenn ich get list stations über das Web Interface rufe stirbt FHEM mit diesen Meldungen:
readline() on closed filehandle WXDATA at ./FHEM/55_GDS.pm line 1036.
Use of uninitialized value $line in chomp at ./FHEM/55_GDS.pm line 1036.
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/55_GDS.pm line 1042.
readline() on closed filehandle WXDATA at ./FHEM/55_GDS.pm line 397.
Use of uninitialized value $line in chomp at ./FHEM/55_GDS.pm line 397.
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/55_GDS.pm line 403.
Eigenartig ist seit dem ich GDS benutze meckert er immer mit dieser Meldung:
2014.08.07 19:27:35 3: telnetForBlockingFn: port 47643 opened
2014.08.07 19:27:36 2: SecurityCheck: telnetForBlockingFn has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
Ich habe schon überprüft das alle benötigten Perl Module für GDS installiert sind.
Edit: Ich nutze die neuste verfügbare GDS Version.
Auf welcher Hardwareplattform betreibst Du fhem? Mir scheint, Du hast ein Kommunikationsproblem das darin liegt, dass Deine fhem Installation den DWD Server nicht erreichen kann, um dort Daten abzurufen.
Wie Du die Hinweismeldung wegen des fehlenden Passwortes unterdrücken kannst, steht in der Meldung. Du musst sie nur komplett lesen.
FHEM läuft auf einem Raspberry PI.
Eigentlich wollte ich das Problem lieber lösen und es nicht unterdrücken. Ich verstehe nur nicht was telnetForBlockingFn ist.
Ein Passwort werde ich bestimmt genau wie für meinen standard telnetPort geben können.
Edit: Hab mich eben vom rapsberry pi mit Hilfe von ncftp auf dem gds Server eingewählt, das funktionierte problemlos.
Zitat von: Filly am 07 August 2014, 20:01:40
Eigentlich wollte ich das Problem lieber lösen und es nicht unterdrücken.
Die Meldung ist kein Problem, sie ist noch nicht einmal eine Fehlermeldung, sondern, wie schon geschrieben, nur ein Hinweis. Deshalb kann und darf man sie auch einfach abschalten.
Setze doch mal verbose auf 5 und poste dann die komplette Ausgabe. Im Moment habe ich keine Idee, was da bei Dir schiefläuft.
Zitat von: Filly am 07 August 2014, 20:01:40
Edit: Hab mich eben vom rapsberry pi mit Hilfe von ncftp auf dem gds Server eingewählt, das funktionierte problemlos.
Das besagt nicht viel - eigentlich sogar gar nix.
Habe jetzt Fhem mit folgenden Kommandos gestartet:
define DWD GDS *** ***
set DWD conditions Gera
Hier der Verbose 5 Log dazu:
2014.08.07 22:43:54 5: Cmd: >define DWD GDS **** ****<
2014.08.07 22:43:54 5: Loading ./FHEM/55_GDS.pm
2014.08.07 22:44:18 3: GDS DWD: created
2014.08.07 22:44:18 3: GDS DWD: tempDir=/tmp/
2014.08.07 22:44:18 5: Loading ./FHEM/02_HTTPSRV.pm
2014.08.07 22:44:18 3: Registering HTTPSRV gds_web_DWD for URL /DWD...
2014.08.07 22:44:18 3: GDS DWD: no datafile (conditions) found
2014.08.07 22:44:18 3: GDS DWD: no datafile (alerts) found
2014.08.07 22:44:18 3: telnetForBlockingFn: port 60168 opened
2014.08.07 22:44:18 5: Cmd: >set DWD conditions Gera<
2014.08.07 22:44:18 4: GDS DWD: nb_defRead started
2014.08.07 22:44:18 4: GDS DWD: nb_retrievFile started
2014.08.07 22:44:18 4: GDS DWD: Retrieving conditions data
2014.08.07 22:44:18 4: GDS DWD: nb_retrievFile started
2014.08.07 22:44:18 4: GDS DWD: searching for gds/specials/observations/tables/germany/* on DWD server
2014.08.07 22:44:18 4: GDS DWD: searching for gds/specials/observations/tables/germany/* on DWD server
2014.08.07 22:44:18 4: GDS DWD: ftp connection established.
2014.08.07 22:44:18 4: GDS DWD: ftp connection established.
2014.08.07 22:44:19 4: GDS DWD: filelist found.
2014.08.07 22:44:19 4: GDS DWD: retrieving SXDL99_DWAV_20140807_2014
2014.08.07 22:44:19 4: GDS DWD: using FTP for retrieval
2014.08.07 22:44:19 4: GDS DWD: filelist found.
2014.08.07 22:44:19 4: GDS DWD: retrieving SXDL99_DWAV_20140807_2014
2014.08.07 22:44:19 4: GDS DWD: using FTP for retrieval
2014.08.07 22:44:19 4: GDS DWD: updating readings.
2014.08.07 22:44:19 4: GDS DWD: updating readings.
2014.08.07 22:44:19 4: conditions item: Station
2014.08.07 22:44:19 4: conditions item: Höhe
2014.08.07 22:44:19 4: conditions item: Luftd.
2014.08.07 22:44:19 4: conditions item: TT
2014.08.07 22:44:19 4: conditions item: RR1
2014.08.07 22:44:19 4: conditions item: DD
2014.08.07 22:44:19 4: conditions item: FF
2014.08.07 22:44:19 4: conditions item: FX
2014.08.07 22:44:19 4: conditions item: Wetter/Wolken
2014.08.07 22:44:19 4: conditions item: Böen
2014.08.07 22:44:19 4: GDS DWD: nb_retrievFile started
2014.08.07 22:44:19 4: GDS DWD: searching for gds/specials/warnings/xml/PVW/Z_CAP* on DWD server
2014.08.07 22:44:19 4: GDS DWD: ftp connection established.
2014.08.07 22:44:19 4: GDS DWD: filelist found.
2014.08.07 22:44:19 4: GDS DWD: retrieving Z_CAP_C_EDZW_20140807203630_PVW_STATUS.xml
2014.08.07 22:44:19 4: GDS DWD: using HTTP for retrieval
2014.08.07 22:44:21 4: GDS DWD: updating readings.
2014.08.07 22:44:23 4: GDS DWD: nb_defRead finished
Will ich darauf hin aber den FHEM Webserver starten antwortet der Server nicht (es bleibt beim Verbindungsversuch).
Nach etwas rumprobieren habe ich festgestellt das wenn ich nur mit dem Kommando
define DWD GDS ***
starte, antwortet der Server und ich kann im Webinterface erfolgreich die Kommandos
get DWD list stations
und
set DWD conditions Gera
ausführen.
Leider fehlt mir das Hintergrundwissen um zu verstehen wieso die Kommandos im Webinterface aber nicht in meiner fhem.cfg funktionieren.
Danke schonmal für deine Hilfe.
Zitat von: Filly am 07 August 2014, 22:57:18
Habe jetzt Fhem mit folgenden Kommandos gestartet:
define DWD GDS *** ***
set DWD conditions Gera
...
In die config gehört kein set (ausser in Funktionen); da müsste es attr heissen.
Für den DWD-Dienst könnte der Abschnitt z.B. so aussehen (die xxxx durch Benutzer / Kennwort ersetzen)...
define gds GDS xxxxxxxx xxxxxxxx
attr gds gdsLong 1
attr gds gdsSetCond Bad_Lippspringe
attr gds group Wetter
attr gds room Umwelt
define readGDS at +*00:10:00 get gds rereadcfg
attr readGDS alignTime 09:30
attr readGDS disabledForIntervals 00:30-05:30
define checkGDS at +*00:10:00 get gds alerts 105766000
attr checkGDS alignTime 09:35
attr checkGDS disabledForIntervals 00:30-05:30
Gruß,
Hollo
Danke für die Hilfe, ich werde es testen sobald ich zuhause bin.
Zitat von: Hollo am 08 August 2014, 11:56:24
In die config gehört kein set (ausser in Funktionen);
Exakt das ist das Ursache.
In die fhem.cfg (Teufelszeug) gehören nur:
- Zeilen, die mit define anfangen
- Zeilen, die mit attr anfangen
- Zeilen, die mit # anfangen (Kommentare)
- Leerzeilen
Danke für eure Hilfe, war dann wohl ein klassischer Bedienfehler :D. Mich wundert nur das FHEM komplett ohne aussagekräftige Fehlermeldung abstürzt, aber vielleicht ist es auch nicht ab gestürzt sondern hängt in einer Dead Loop oder ähnliches.
Ist übrigens eine tolle Erweiterung für FHEM, vielen Dank an den Entwickler betateilchen.
@betateilchen : Kannst Du bitte nochmal schauen, wo ich den Fehler suchen kann, ich komme nicht weiter. Obwohl ich eine gefüllte dwd_alerts Datei habe, bleibt im webif die Anzeige "please_use_rereadcfg_first" (und ich habe sowohl get als auch set rereadcfg probiert)
danke.
also es hat mir keine ruhe gelassen. deswegen habe ich jetzt mal ne VM aufgesetzt.
debian-7.6.0-i386-netinst.iso runtergeladen, und installiert.
nach dem booten :
apt-get install perl libdevice-serialport-perl
cpan -i List::MoreUtils
cpan -i XML::Simple
cpan -i Text::CSV
wget fhem.de/fhem-5.5.deb
dpkg -i fhem-5.5.deb
dann auf fhem :telnet localhost 7072
notice confirm update-20130127-001
update
shutdown restart
dann GDS angelegt : telnet localhost 7072
define dwd GDS xxx yyy
get dwd rereadcfg
exit
damit mich meine eigene hektik nicht überrumpelt :
sleep 120 && ls -lisah /tmp
dwd_alerts wird angelegt, zurück im webif steht immer noch "please_use_rereadcfg"
wer kann mir bitte die richtung weisen ?
Du benutzt das DWD Modul in Deinem Beispiel abseits seiner Spezifikation.
Dein Denkfehler liegt darin, davon auszugehen, das angelegte DWD-device sei sofort nach einem define betriebsbereit.
Das ist einfach nicht der Fall. Deshalb macht ein get <irgendwas> direkt nach dem Define definitiv keinen Sinn.
Dann erkläre mir doch bitte deine Spezifikation.
Auf dem produktiv system steht es seit tagen auf 'Please run rereadcfg'
Auch auf die Gefahr hin, daß es jetzt Haue gibt meine Frage:
Nach Eingabe von
define DWD GDS gdsxxx yyyy
bekomme ich die Meldung
Cannot load module GDS
Ich habe im Verzeichnis : /opt/fhem/FHEM die Datei 55_GDS.pm vom 30.07.2014
Ist das die richtige Datei?
Zitat von: betateilchen am 04 August 2013, 17:12:04
2. Schritt: prüfen ob das Perl Modul Net::FTP installiert ist, falls nicht: nachinstallieren
Hast du das Modul?
Scheinbar nicht und bekomme es auch mit
sudo apt-get install Net::FTP
nicht hin.
Paket Net: kann nicht gefunden werden
cpan -i Net::FTP
Das habe ich gemacht und bekomme:
Net::FTP is up to date (2.79).
Auch shutdown restart, es bleibt bei der Meldung
Cannot load module GDS
Du brauchst auch das Modul List::MoreUtils
Ja, danke, hab ich gemerkt. Und auch Text::CSV. Jetzt rennt es.
Oder auch nicht! Die Pfade sind wohl nicht richtig. Ich habe in der root vom raspi ein Verzeichnis tmp mit DWD Dateien.
Wenn ich in fhem auf GDS DWG Files klicke erscheint ein Browserfenster mit links zu Aktuelle Wetterkarte: Wetterlage usw.
Ein Klick darauf führt zu
File not found: /tmp//DWD_conditionsmap.jpg
Allerdings im Linkpfad
http://192.168.xxx.yyy:8083/fhem/DWD/DWD_conditionsmap.jpg
Wo liegt da noch der Fehler?
Hast du ein at definiert, wo du die files lädst?
define Karten at +*00:30:00 get DWD radarmap Nordost; get DWD conditionsmap Nordost; get DWD warningsmap Berlin
Betateilchen, was muss ich tun um das Please_use_rereadcfg weg zu bekommen?
Ich habe get und set rereadcfg probiert, es geht nicht weg, auch nach tagen nicht.
Danke.
Ich hab grad keine Lust mehr auf fhem.
Das ist schade betateilchen.
Glaub mir, ich nerve nur ungern.
Nur wenn das Modul sagt "please_use_rereadcfg_first" und ein "rereadcfg" hilft nicht, kann ich mir nicht mehr selber helfen.
c_ readings funktionieren,
g_ readings funktionieren, sofern ich von hand z.b. "get conditions Essen" eingebe, denn auch hier steht im webif "please_use_rereadcfg_first"
a_ readings bekomme ich gar nicht
Grüße
jupp
Ich habe das immer wenn Fhem komplett neu startet, bei mir hilft ein shutdown restart und dann funktioniert das wieder - die alerts kommen nur wenn es auch ein alert gibt
Zitat von: juppzupp am 12 August 2014, 10:24:23
Glaub mir, ich nerve nur ungern.
glaub mir, bei mir funktioniert das Modul seit Monaten problemlos.
Zitat von: betateilchen am 12 August 2014, 13:34:44
glaub mir, bei mir funktioniert das Modul seit Monaten problemlos.
Glaube ich dir!
Hilft nur leider nicht.
Und das ist das Problem, wäre eine deiner letzten antworten konstruktiv (aka Lösungsorentiert) gewesen, hätten wir beide weniger Zeit damit verbracht, und hätten beide bessere Laune.
Vielleicht liegt es sogar daran _das_ es bei dir seit mehreren Monaten läuft. Vielleicht erbarmst du dich ja für die (mehreren!) user und setzt ein frisches fhem auf, und spielst es mal durch. Ich kann dir auch gerne meine virtuelle appliance exportieren und zum download anbieten.
Zitat von: juppzupp am 12 August 2014, 14:40:35
Und das ist das Problem, wäre eine deiner letzten antworten konstruktiv (aka Lösungsorentiert) gewesen,
Siehst Du, genau solche dämlichen Sätze führen dazu, dass ich grade keine Lust mehr habe.
Das ist kein dämlicher Satz, sondern schlicht und ergreifend, das was sich hier abspielt.
"Bei mir klappt es"
"Du benutzt es außerhalb der Spezifikation"
Hilft niemandem.
Zitat von: juppzupp am 12 August 2014, 14:40:35
Vielleicht erbarmst du dich ja für die (mehreren!) user und setzt ein frisches fhem auf, und spielst es mal durch.
Gestern abend zwei neue Systeme from scratch aufgesetzt, beide laufen problemlos.
Danke für die Rückmeldung, betateilchen.
nach einem get dwd rereadcfg
sieht ein list dwd wie folgt aus :
Internals:
CFGFN
DEF gdsxyz xyz
LOCAL 1
NAME dwd
NR 4147
STATE active
TYPE GDS
CHANGETIME:
Helper:
Dblog:
C_pressure-nn:
Mydblog:
TIME 1407919585.989
VALUE 1005.7
C_temperature:
Mydblog:
TIME 1407919585.989
VALUE 15.9
G_pressure-nn:
Mydblog:
TIME 1407831487.6381
VALUE 1011.4
G_temperature:
Mydblog:
TIME 1407831487.6381
VALUE 15.7
Readings:
2014-08-13 10:46:25 _dF_conditions SXDL99_DWAV_20140813_0814
2014-08-13 10:46:25 _dataSource Quelle: Deutscher Wetterdienst
2014-08-13 10:48:01 _tzOffset 7200
2014-08-13 10:46:25 c_altitude 150
2014-08-13 10:46:26 c_nextUpdate Wed Aug 13 11:06:26 2014
2014-08-13 10:46:25 c_pressure-nn 1005.7
2014-08-13 08:26:22 c_rain12h 0
2014-08-13 10:46:25 c_rain1h 0.0
2014-08-13 09:06:23 c_rain24h 4.0
2014-08-13 08:26:22 c_snow ---
2014-08-13 09:06:23 c_solar ----
2014-08-13 10:46:25 c_stationName Essen
2014-08-13 09:06:23 c_sunshine 6.2
2014-08-13 09:06:23 c_tAvgAir24 15.0
2014-08-13 08:26:22 c_tMaxAir12 14.1
2014-08-13 09:06:23 c_tMaxAir24 20.7
2014-08-13 08:26:22 c_tMinAir12 12.4
2014-08-13 09:06:23 c_tMinAir24 13.0
2014-08-13 09:06:23 c_tMinGrnd24 11.9
2014-08-13 10:46:25 c_temperature 15.9
2014-08-13 10:46:25 c_weather ---
2014-08-13 10:46:25 c_windDir S
2014-08-13 10:46:25 c_windGust ---
2014-08-13 10:46:25 c_windPeak ---
2014-08-13 10:46:25 c_windSpeed 7
2014-08-12 10:18:07 g_altitude 150
2014-08-12 10:18:07 g_pressure-nn 1011.4
2014-08-12 10:18:07 g_rain1h 0.0
2014-08-12 10:18:07 g_stationName Essen
2014-08-12 10:18:07 g_temperature 15.7
2014-08-12 10:18:07 g_weather ---
2014-08-12 10:18:07 g_windDir SW
2014-08-12 10:18:07 g_windGust ---
2014-08-12 10:18:07 g_windPeak ---
2014-08-12 10:18:07 g_windSpeed 25
2014-08-09 15:23:52 state active
Helper:
INTERVAL 1200
PASS xyz
URL ftp-outgoing2.dwd.de
USER gdsxyz
Attributes:
gdsDebug 1
gdsSetCond Essen
room Wetter
verbose 5
im WEBIF bleibt die Anzeige leider wie im Anhang zu sehen auf please_use_rereadcfg_first.
Würde mich freuen, wenn Du eine Idee zur Fehlersuche mit mir teilst.
Welchen Teil meiner Aussage
ZitatIch hab grad keine Lust mehr auf fhem.
verstehst Du nicht?
was ist das denn jetzt für ein kindergarten, Beiträge einzustellen, nach einer antwort darauf zu löschen, und dann wieder bezug auf ältere aussagen zu nehmen ? ist spannenderweise auch nicht das erste mal ( das letzte mal hast du dein beleidigungstirade gelöscht)
siehe anhang. mal gucken, ob der beitrag stehen bleibt.
Ich habe hier nichts gelöscht. Und der von Dir per Screenshot eingebundene Beitrag steht nach wie vor hier im Thread.