55_GDS.pm - es muss nicht immer Yahoo, openweathermap usw. sein

[yogiflop]

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.

Code Auswählen Erweitern


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

[betateilchen]

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

[yogiflop]

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

[betateilchen]

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)

[betateilchen]

So... jetzt hab ich nochmal in aller Ruhe nachgesehen.

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.

Code Auswählen Erweitern


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.

[betateilchen]

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

[yogiflop]

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

[betateilchen]

hm... *grübel* Ich denk nochmal drüber nach. Vermutlich aber erst am Wochenende.

[betateilchen]

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

[duffy6]

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

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

[betateilchen]

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.

Code Auswählen Erweitern

define startGDS notify global:(INITIALIZED|REREADCFG) set mygds conditions irgendwo

[duffy6]

define 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

set 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

[betateilchen]

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

[Hollo]

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 !?

[yogiflop]

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.