55_GDS.pm - komplett überarbeitet - RC1

Begonnen von betateilchen, 09 Oktober 2015, 21:05:42

Vorheriges Thema - Nächstes Thema

betateilchen

ok, das mit dem passive ftp ist ja schonmal ein guter Schritt.

Auf die Sache mit dem GDS_GetUpdate bin ich inzwischen auch gekommen, da arbeite ich grade dran. Kann also mit dem RC6 noch etwas länger dauern als geplant. Jetzt geh ich erstmal pennen.

Das mit den fehlenden Readings hab ich auch schon bemerkt, aber nach dem zweiten oder dritten automatischen Update sind sie irgendwann vollständig. Ich denke, da kommt es manchmal einfach zu Überschneidungen zwischen dem Download vom Server und einer Aktualisierung auf dem Server.
Wobei Deine Aufbereitung der fc_ readings schon ziemlich haarsträubend und nicht wirklich nachvollziehbar ist  8)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

jensb

ZitatWobei Deine Aufbereitung der fc_ readings schon ziemlich haarsträubend und nicht wirklich nachvollziehbar ist
Den Hintergrund hatte ich mal im 1. Beitrag zu http://forum.fhem.de/index.php/topic,38106.msg303560.html kurz beschrieben:
ZitatDie Dateien für den aktuellen Tag werden abhängig von der Uhrzeit schrittweise durch Leerdateien ersetzt und zum Tageswechsel dauert es fast 1 Stunde, bis Daten für den neuen Tag zur Verfügung stehen. Durch eine Rotation der Vorhersage zum Tageswechsel wird das aber kompensiert.
Die Vorhersagedaten vom DWD sind zwischen 23:00 und 01:00 nicht konsistent verfügbar, daher die unschöne Verschiebungslogik. Was kurz vor Mitternacht für "morgen früh" vorhergesagt wurde sollte auch noch kurz nach Mitternacht für das neue "heute früh" gelten, bis der DWD die aktualisierten Daten liefert, wo dann alles wirklich um einen Tag verschoben ist.

Generell wird eine Vorhersagedatei teilweise bereits knapp 1 Stunde vor ihrem Melde-Bezugszeitpunkt vom DWD nicht mehr gefüllt (also z.B. die für heute Mittag 12:00 bereits kurz nach 11:00 nicht mehr). Das ist für ein Vorhersagemodell, das periodisch rechnet, nicht ungewöhnlich, aber für die Auswertung und Anzeige unpraktisch, da ich ja um 11:30 immer noch eine Vorhersage für 12:00 erwarte, wenn sie doch ein paar Minuten vorher noch da war.

Deshalb u.a. auch mein ursprünglicher Code in "sub retrieveForecasts", der nur bei gültigen Vorhersgedaten die Readings ändert und bei fehlenden Vorhersagedaten nicht löscht:

        readingsBeginUpdate($hash);
        while (($k, $v) = each %fread) {
                # skip update if no valid data is available
                if (defined($v) && substr($v, 0, 1) ne '-') {
                        readingsBulkUpdate($hash, $k, utf8ToLatin1($v));
                }
        }
        readingsEndUpdate($hash, 1);


Damit gleichzeitig das Konzept für den dynamischen Stationswechsel aufgeht, könnte man am Anfang von "sub retrieveForecasts" und vielleicht auch von "sub getConditions" prüfen, ob sich der Stationsname geändert hat. Wenn ja, werden die relevanten Readings gelöscht (wie bei set clear forecasts/conditions), ansonsten wird nur aktualisiert, was neu vom DWD kommt.
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

betateilchen

Zitat von: jensb am 27 Oktober 2015, 23:31:56
Mit passivem FTP klappt die Übertragung und es gibt keine Blocking-Timeouts mehr.

Ab RC6 verwendet das Modul passive ftp als Standard, es sei denn, der Anwender hat das per Attribut expliizit abgeschaltet.

Zitat von: jensb am 28 Oktober 2015, 22:06:26
Die Vorhersagedaten vom DWD sind zwischen 23:00 und 01:00 nicht konsistent verfügbar, daher die unschöne Verschiebungslogik.

Von der Verschiebungslogik halte ich gar nichts. Meine einfach Philosophie bei solchen Daten ist: Es sollen nur solche readings generiert werden, deren Inhalt sich eindeutig und zweifelsfrei aus gelesenen (und vorhandenen!) Daten ergibt.

Insofern überlege ich gerade, die gesamte Vorhersagelogik aus meinem Modul wieder auszubauen.

Zitat von: jensb am 28 Oktober 2015, 22:06:26
Damit gleichzeitig das Konzept für den dynamischen Stationswechsel aufgeht, könnte man am Anfang von "sub retrieveForecasts" und vielleicht auch von "sub getConditions" prüfen, ob sich der Stationsname geändert hat. Wenn ja, werden die relevanten Readings gelöscht (wie bei set clear forecasts/conditions), ansonsten wird nur aktualisiert, was neu vom DWD kommt.

In irgendeiner Entwicklungsversion hatte ich das bereits umgesetzt, das muss ich nochmal suchen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

jensb

ZitatVon der Verschiebungslogik halte ich gar nichts.
Ich eigentlich auch nicht, aber:

  • Vorhersagedaten werden vom DWD nicht in Echtzeit aktualisiert, sondern nur getaktet alle Stunde, aber nicht exakt zur vollen Stunde
  • Vorhersagedaten für den aktuellen Tag werden schon knapp eine Stunde vor der Bezugszeit der Vorhersage vom DWD nicht mehr zur Verfügung gestellt
  • das GDS-Modul pollt asynchron zum DWD-Takt
  • um Mitternacht ändert sich der relative Tag
Damit hat man mehrere langsame asynchrone Abläufe für Daten, die sich i.a. nur sehr langsam ändern. Eine Halten der Vorhersagedaten bis zum Ablauf ihrer nominellen Gültigkeit ist ohnehin unkritisch und kompensiert nur die Eigenheiten der Datenquelle. Bei Warnungen wäre das etwas anderes, da kann sich ja jederzeit etwas ändern.

Das Verschieben zwischen den Readings (z.B. von fc1 nach fc0) beim Tageswechsel interpretiert die Daten nicht neu und macht sie auch nicht länger gültig, sondern ordnet sie nur dem richtigen relativen Tag zu, der sich hier unabhängig von den Quelldaten ändert. Damit wird die Auswertung (z.B. per Notify) erleichtert, da man sonst immer wieder vorübergehend mit nicht definierten Readings zu tun hat. Die Alternative, synchron um Mitternacht noch einmal den DWD zu pollen, hatte ich erwogen, doch einige Vorhersagen liegen z.T. erst deutlich nach Mitternacht wieder gültig vor.

Über ein Attribut könnte man das Meldeverhalten für die Vorhersage umschalten. Im einen Fall werden die Readings so befüllt, wie sie zuletzt gepollt wurden, im anderen Fall so, wie das derzeit erfolgt.
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

jensb

Habe die neue Version 9747 des GDS-Moduls bzgl. der Vorhersagefunktionen getestet und einen Patch erstellt, der vor allem die bereits erwähnte mehrfache parallele Abfrage der Vorhersagen unterdrückt.

Besonders merkwürdig war, das auch nach dieser Anpassung die Readings für die Vorhersage bei mir nicht vollständig waren, obwohl sie als Dateien empfangen wurden. Die Suche-Schleife über den Hash 'allForecastData' der Vorhersagedaten in der Zeile 1774 hat bei mir einfach nicht die vorhandenen 87 Einträge durchlaufen, sondern ist nach ein paar Einträgen einfach fertig gewesen, z.T. ohne den vorhandenen Eintrag zu finden. Zum Debuggen hatte ich Loggings eingefügt und u.a. auch die Hash-Größe ausgegeben. Dabei hat die vorherige Ermittlung der Hash-Größe in Zeile 1773 dazu geführt, dass nun immer alle Elemente überprüft werden und die Vorhersage-Readings damit auch bei mir vollständig sind. Da bei mir ansonsten alles so funktioniert wie erwartet, gehe ich nicht davon aus, dass meine Perl-Installation buggy ist aber was gibt es dafür noch für eine Erklärung?
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

betateilchen

Schick mir solche patches bitte demnächst per email, wir schaffen sonst hier ein absolutes Versionschaos, wenn Du hier komplette Module anhängst.

Deine Änderungen habe ich eingebaut, danke.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

jensb

ZitatSchick mir solche patches bitte demnächst per email, wir schaffen sonst hier ein absolutes Versionschaos, wenn Du hier komplette Module anhängst.
Geht in Ordnung, es ist sonst nicht ganz klar was "offiziell" ist.

Damit die manchmal fehlenden c_weather Readings nicht mehr zu hässlichen Darstellungen führen, bereite ich auch noch eine Änderung an GDSweblink vor, die ich selbst nach contrib committen würde, sobald sie getestet ist.
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

viegener

Habe heute abend mal nach dem Update die neue version von 55_GDS eingebunden und die Version funktioniert bei mir auch soweit.  (maps werden geholt, Forecasts in den Readings abgelegt, etc). Also erstmal danke für die Umstellung!

Dabei hat es allerdings (bei mir) eine paar Auffälligkeiten/Fragen gegeben:

1) Ich bekomme momentan nach Neustart immer folgende Meldung:
2015.11.01 23:26:10 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/55_GDS.pm line 661.
Internal GDS_REREAD ist allerdings bei mir gesetzt?

2) Nach einem rereadcfg als FHEM Befehl (nicht GDS) kamen folgende Meldungen:
2015.11.01 23:23:26 1: PERL WARNING: Deep recursion on subroutine "main::GDS_GetUpdate" at fhem.pl line 2725.
2015.11.01 23:23:26 1: PERL WARNING: Deep recursion on subroutine "main::InternalTimer" at FHEM/Blocking.pm line 79.
2015.11.01 23:23:26 1: PERL WARNING: Deep recursion on subroutine "main::InternalTimer" at ./FHEM/55_GDS.pm line 682.
. Ich musste danach den perl prozess abschiessen um den Server neustartetn zu können.

3) Ausserdem ist mir nicht klar, welche Werte bei gdsSetCond und gdsSetForecast eintragen kann, denn es gibt ja unterschiedliche Auswahlen für Statiosnamen/Regionen.

4) Ebenso ist mir die Funktion von gdsUseForecasts nicht klargeworden?

Danke für Eure Hilfe,
Johannes



Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

jensb

zu 3 + 4)
Der DWD teilt Messstationen und Vorhersagestationen unterschiedlich ein und benennt sie auch z.T. leicht unterschiedlich, obwohl es für den Anwender meist keinen relevanten Unterschied gibt. Also nicht daran stören und einfach zweimal wählen.

Mit gdsUseForecasts=1 wird die Vorhersagefunktion im GDS-Device aktiviert. Danach "get rereadcfg" aufrufen, um u.a. die Vorhersage-Stationslisten zu bekommen. Jetzt kann man über "set forecasts" die gewünschte Vorhersagestation aus der Liste auswählen und dauerhaft einstellen (einige Vorhersagestationen stehen sogar in mehrere Regionen zur Verfügung). Für "set conditions" geht man schon immer so vor.
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

viegener

Hi jensb,
Danke für die schnelle Beantwortung!

Also ist der Ablauf (wenn interaktiv):
a) gdsUseForecasts auf 1 setzen
b) get rereadcfg
c) Web oberfläche reload, damit die Auswahllisten aktualisiert werden
d) set forecast entsprechend einstellen
und die Attribute müssen gar nicht manuell gesetzt werden? => Das wäre vielleicht auch etwas für die Doku

Wenn ich schonmal dabeibin dumme Fragen zu stellen: werden bei set forecasts auch die forecastmaps automatisch geholt?

Johannes

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

jensb

Hallo Johannes,

ja, wenn man FHEMWEB zur Konfiguration benutzt, muss man gdsSetCond/Forcast nich unbedingt manuell einstellen,  was die Sache vereinfacht.

Zitat...  werden bei set forecasts auch die forecastmaps automatisch geholt?
Nein, das ist wieder ein anderer "Datentopf", den man - wie in der Wiki beschrieben - am besten per "at" abfragt.

LG, Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

spikeh1

#71
Hallo in die Runde.

Ich habe gestern per Update auf die neue (umgebaute) Version umgestellt. Nun gibt es bei mir folgendes Phänomen.
Aktuell gibt es für meine Region/Stadt eine Warnmeldung, welche mir manuell über die Fhem-Oberfläche abgerufen auch als Reading abgelegt wird.
Rufe ich jedoch über die Warncell-ID ab, laufen bei mir auch andere Readings aus anderen Regionen auf und es kommen immer mehr Ort/Meldungen dazu.

Folgende Definitionen:

define dwd_alerts GDS User Passwort
attr dwd_alerts gdsLong 1
attr dwd_alerts gdsSetCond Brocken
attr dwd_alerts gdsUseAlerts 1
attr dwd_alerts group Wetter
attr dwd_alerts room System

define dwd_get_data at +*00:30:00 get dwd_alerts rereadcfg
attr dwd_get_data alignTime 00:00:30
attr dwd_get_data group Wetter
attr dwd_get_data room System

define dwd_read_data at +*00:30:00 get dwd_alerts alerts 103156000
attr dwd_read_data alignTime 00:05:30
attr dwd_read_data group Wetter
attr dwd_read_data room System



Internals:
   CFGFN      /opt/fhem/FHEM/wetter.cfg
   DEF        User Passwort
   GDS_CAPDATA_READ 1446448240
   GDS_CONDITIONS_READ 1446448230
   GDS_REREAD 1446448230
   NAME       dwd_alerts
   NR         173
   NTFY_ORDER 50-dwd_alerts
   STATE      active
   TYPE       GDS
   Readings:
     2015-11-02 08:10:40   _dF_alerts      Z_CAP_C_EDZW_20151102070651_PVW_STATUS.zip
     2015-11-02 08:10:30   _dF_conditions  SXDL99_DWAV_20151102_0645
     2015-11-02 08:15:30   _dataSource     Quelle: Deutscher Wetterdienst
     2015-11-02 08:14:09   _nextUpdate     Mon Nov  2 08:34:09 2015
     2015-11-02 08:15:30   a_0_areaDesc    Kreis Osterode am Harz
     2015-11-02 08:15:30   a_0_category    Met
     2015-11-02 08:15:30   a_0_certainty   Observed
     2015-11-02 08:15:30   a_0_description Es wird in Bodennähe leichter Frost zwischen 0 °C und -2 °C erwartet.
     2015-11-02 08:15:30   a_0_event       BODENFROST
     2015-11-02 08:15:30   a_0_eventCode_AREA_COLOR 255 255 0
     2015-11-02 08:15:30   a_0_eventCode_AREA_COLOR_hex ffff00
     2015-11-02 08:15:30   a_0_eventCode_GROUP FROST
     2015-11-02 08:15:30   a_0_eventCode_II 21
     2015-11-02 08:15:30   a_0_eventCode_LICENSE Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013
     2015-11-02 08:15:30   a_0_eventCode_PROFILE_VERSION 2.1
     2015-11-02 08:15:30   a_0_expires     2015-11-02T08:00:00+00:00
     2015-11-02 08:15:30   a_0_expires_local 02.11.2015 09:00:00
     2015-11-02 08:15:30   a_0_geoCode_STATE NS
     2015-11-02 08:15:30   a_0_geoCode_WARNCELLID 103156000
     2015-11-02 08:15:30   a_0_headline    Amtliche WARNUNG vor BODENFROST
     2015-11-02 08:15:30   a_0_identifier  ARRAY(0x434f6b0)
     2015-11-02 08:15:30   a_0_language    de-DE
     2015-11-02 08:15:30   a_0_msgType     Alert
     2015-11-02 08:15:30   a_0_onset       2015-11-01T21:00:00+00:00
     2015-11-02 08:15:30   a_0_onset_local 01.11.2015 22:00:00
     2015-11-02 08:15:30   a_0_responseType None
     2015-11-02 08:15:30   a_0_sent        2015-11-02T07:07:00+00:00
     2015-11-02 08:15:30   a_0_sent_local  02.11.2015 08:07:00
     2015-11-02 08:15:30   a_0_severity    Minor
     2015-11-02 08:15:30   a_0_status      Actual
     2015-11-02 08:15:30   a_0_urgency     Immediate
     2015-11-02 08:15:30   a_0_valid       1
     2015-11-02 08:15:30   a_1_areaDesc    Stadt Hagen
     2015-11-02 08:15:30   a_1_category    Met
     2015-11-02 08:15:30   a_1_certainty   Observed
     2015-11-02 08:15:30   a_1_description Es tritt gebietsweise Nebel mit Sichtweiten unter 150 Meter auf.
     2015-11-02 08:15:30   a_1_event       NEBEL
     2015-11-02 08:15:30   a_1_eventCode_AREA_COLOR 255 255 0
     2015-11-02 08:15:30   a_1_eventCode_AREA_COLOR_hex ffff00
     2015-11-02 08:15:30   a_1_eventCode_GROUP FOG
     2015-11-02 08:15:30   a_1_eventCode_II 59
     2015-11-02 08:15:30   a_1_eventCode_LICENSE Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013
     2015-11-02 08:15:30   a_1_eventCode_PROFILE_VERSION 2.1
     2015-11-02 08:15:30   a_1_expires     2015-11-02T09:00:00+00:00
     2015-11-02 08:15:30   a_1_expires_local 02.11.2015 10:00:00
     2015-11-02 08:15:30   a_1_geoCode_STATE NRW
     2015-11-02 08:15:30   a_1_geoCode_WARNCELLID 105914000
     2015-11-02 08:15:30   a_1_headline    Amtliche WARNUNG vor NEBEL
     2015-11-02 08:15:30   a_1_identifier  ARRAY(0x434f6b0)
     2015-11-02 08:15:30   a_1_language    de-DE
     2015-11-02 08:15:30   a_1_msgType     Alert
     2015-11-02 08:15:30   a_1_onset       2015-11-02T00:23:00+00:00
     2015-11-02 08:15:30   a_1_onset_local 02.11.2015 01:23:00
     2015-11-02 08:15:30   a_1_responseType None
     2015-11-02 08:15:30   a_1_sent        2015-11-02T07:07:00+00:00
     2015-11-02 08:15:30   a_1_sent_local  02.11.2015 08:07:00
     2015-11-02 08:15:30   a_1_severity    Minor
     2015-11-02 08:15:30   a_1_status      Actual
     2015-11-02 08:15:30   a_1_urgency     Immediate
     2015-11-02 08:15:30   a_1_valid       1
     2015-11-02 08:15:30   a_2_category    Met
     2015-11-02 08:15:30   a_2_certainty   Observed
     2015-11-02 08:15:30   a_2_description Es tritt Nebel mit Sichtweiten unter 150 Meter auf.
     2015-11-02 08:15:30   a_2_event       NEBEL
     2015-11-02 08:15:30   a_2_eventCode_AREA_COLOR 255 255 0
     2015-11-02 08:15:30   a_2_eventCode_AREA_COLOR_hex ffff00
     2015-11-02 08:15:30   a_2_eventCode_GROUP FOG
     2015-11-02 08:15:30   a_2_eventCode_II 59
     2015-11-02 08:15:30   a_2_eventCode_LICENSE Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013
     2015-11-02 08:15:30   a_2_eventCode_PROFILE_VERSION 2.1
     2015-11-02 08:15:30   a_2_expires     2015-11-02T09:00:00+00:00
     2015-11-02 08:15:30   a_2_expires_local 02.11.2015 10:00:00
     2015-11-02 08:15:30   a_2_headline    Amtliche WARNUNG vor NEBEL
     2015-11-02 08:15:30   a_2_identifier  ARRAY(0x434f6b0)
     2015-11-02 08:15:30   a_2_language    de-DE
     2015-11-02 08:15:30   a_2_msgType     Alert
     2015-11-02 08:15:30   a_2_onset       2015-11-02T02:39:00+00:00
     2015-11-02 08:15:30   a_2_onset_local 02.11.2015 03:39:00
     2015-11-02 08:15:30   a_2_responseType None
     2015-11-02 08:15:30   a_2_sent        2015-11-02T07:07:00+00:00
     2015-11-02 08:15:30   a_2_sent_local  02.11.2015 08:07:00
     2015-11-02 08:15:30   a_2_severity    Minor
     2015-11-02 08:15:30   a_2_status      Actual
     2015-11-02 08:15:30   a_2_urgency     Immediate
     2015-11-02 08:15:30   a_2_valid       1
     2015-11-02 08:15:30   a_3_category    Met
     2015-11-02 08:15:30   a_3_certainty   Observed
     2015-11-02 08:15:30   a_3_description Es tritt Nebel mit Sichtweiten unter 150 Meter auf.
     2015-11-02 08:15:30   a_3_event       NEBEL
     2015-11-02 08:15:30   a_3_eventCode_AREA_COLOR 255 255 0
     2015-11-02 08:15:30   a_3_eventCode_AREA_COLOR_hex ffff00
     2015-11-02 08:15:30   a_3_eventCode_GROUP FOG
     2015-11-02 08:15:30   a_3_eventCode_II 59
     2015-11-02 08:15:30   a_3_eventCode_LICENSE Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013
     2015-11-02 08:15:30   a_3_eventCode_PROFILE_VERSION 2.1
     2015-11-02 08:15:30   a_3_expires     2015-11-02T09:00:00+00:00
     2015-11-02 08:15:30   a_3_expires_local 02.11.2015 10:00:00
     2015-11-02 08:15:30   a_3_headline    Amtliche WARNUNG vor NEBEL
     2015-11-02 08:15:30   a_3_identifier  ARRAY(0x434f6b0)
     2015-11-02 08:15:30   a_3_language    de-DE
     2015-11-02 08:15:30   a_3_msgType     Alert
     2015-11-02 08:15:30   a_3_onset       2015-11-02T04:46:00+00:00
     2015-11-02 08:15:30   a_3_onset_local 02.11.2015 05:46:00
     2015-11-02 08:15:30   a_3_responseType None
     2015-11-02 08:15:30   a_3_sent        2015-11-02T07:07:00+00:00
     2015-11-02 08:15:30   a_3_sent_local  02.11.2015 08:07:00
     2015-11-02 08:15:30   a_3_severity    Minor
     2015-11-02 08:15:30   a_3_status      Actual
     2015-11-02 08:15:30   a_3_urgency     Immediate
     2015-11-02 08:15:30   a_3_valid       1
     2015-11-02 08:15:30   a_4_category    Met
     2015-11-02 08:15:30   a_4_certainty   Observed
     2015-11-02 08:15:30   a_4_description Es tritt gebietsweise Nebel mit Sichtweiten unter 150 Meter auf.
     2015-11-02 08:15:30   a_4_event       NEBEL
     2015-11-02 08:15:30   a_4_eventCode_AREA_COLOR 255 255 0
     2015-11-02 08:15:30   a_4_eventCode_AREA_COLOR_hex ffff00
     2015-11-02 08:15:30   a_4_eventCode_GROUP FOG
     2015-11-02 08:15:30   a_4_eventCode_II 59
     2015-11-02 08:15:30   a_4_eventCode_LICENSE Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013
     2015-11-02 08:15:30   a_4_eventCode_PROFILE_VERSION 2.1
     2015-11-02 08:15:30   a_4_expires     2015-11-02T09:00:00+00:00
     2015-11-02 08:15:30   a_4_expires_local 02.11.2015 10:00:00
     2015-11-02 08:15:30   a_4_headline    Amtliche WARNUNG vor NEBEL
     2015-11-02 08:15:30   a_4_identifier  ARRAY(0x434f6b0)
     2015-11-02 08:15:30   a_4_language    de-DE
     2015-11-02 08:15:30   a_4_msgType     Alert
     2015-11-02 08:15:30   a_4_onset       2015-11-01T17:45:00+00:00
     2015-11-02 08:15:30   a_4_onset_local 01.11.2015 18:45:00
     2015-11-02 08:15:30   a_4_responseType None
     2015-11-02 08:15:30   a_4_sent        2015-11-02T07:07:00+00:00
     2015-11-02 08:15:30   a_4_sent_local  02.11.2015 08:07:00
     2015-11-02 08:15:30   a_4_severity    Minor
     2015-11-02 08:15:30   a_4_status      Actual
     2015-11-02 08:15:30   a_4_urgency     Immediate
     2015-11-02 08:15:30   a_4_valid       1
     2015-11-02 08:15:30   a_5_category    Met
     2015-11-02 08:15:30   a_5_certainty   Observed
     2015-11-02 08:15:30   a_5_description Es tritt gebietsweise Nebel mit Sichtweiten unter 150 Meter auf.
     2015-11-02 08:15:30   a_5_event       NEBEL
     2015-11-02 08:15:30   a_5_eventCode_AREA_COLOR 255 255 0
     2015-11-02 08:15:30   a_5_eventCode_AREA_COLOR_hex ffff00
     2015-11-02 08:15:30   a_5_eventCode_GROUP FOG
     2015-11-02 08:15:30   a_5_eventCode_II 59
     2015-11-02 08:15:30   a_5_eventCode_LICENSE Geobasisdaten: Copyright Bundesamt für Kartographie und Geodäsie, Frankfurt am Main, 2013
     2015-11-02 08:15:30   a_5_eventCode_PROFILE_VERSION 2.1
     2015-11-02 08:15:30   a_5_expires     2015-11-02T09:00:00+00:00
     2015-11-02 08:15:30   a_5_expires_local 02.11.2015 10:00:00
     2015-11-02 08:15:30   a_5_headline    Amtliche WARNUNG vor NEBEL
     2015-11-02 08:15:30   a_5_identifier  ARRAY(0x434f6b0)
     2015-11-02 08:15:30   a_5_language    de-DE
     2015-11-02 08:15:30   a_5_msgType     Alert
     2015-11-02 08:15:30   a_5_onset       2015-11-02T04:10:00+00:00
     2015-11-02 08:15:30   a_5_onset_local 02.11.2015 05:10:00
     2015-11-02 08:15:30   a_5_responseType None
     2015-11-02 08:15:30   a_5_sent        2015-11-02T07:07:00+00:00
     2015-11-02 08:15:30   a_5_sent_local  02.11.2015 08:07:00
     2015-11-02 08:15:30   a_5_severity    Minor
     2015-11-02 08:15:30   a_5_status      Actual
     2015-11-02 08:15:30   a_5_urgency     Immediate
     2015-11-02 08:15:30   a_5_valid       1
     2015-11-02 08:15:30   a_count         6
     2015-11-02 08:15:30   a_valid         1
     2015-11-02 08:14:09   c_altitude      1142
     2015-11-02 08:14:09   c_rain24h       0
     2015-11-02 08:14:09   c_stationName   Brocken
     2015-11-02 08:14:09   c_sunshine      9.6
     2015-11-02 08:14:09   c_tAvgAir24     15.2
     2015-11-02 08:14:09   c_tMaxAir24     18.1
     2015-11-02 08:14:09   c_tMinAir24     10.2
     2015-11-02 08:14:09   c_tMinGrnd24    1.0
     2015-11-02 08:14:09   c_windPeak      70
     2015-11-02 08:15:30   state           active
   File:
     dir        gds/help/
     dwd        legend_warnings_CAP_WarnCellsID.csv
     target     /tmp/capstations.csv
   Helper:
     INTERVAL   1200
     PASS       Passwort
     URL        ftp-outgoing2.dwd.de
     USER       User
Attributes:
   gdsDebug   1
   gdsLong    1
   gdsSetCond Brocken
   gdsUseAlerts 1
   group      Wetter
   room       System


Nach einem Neustart von Fhem kommt Anfangs wieder nur die Meldung für meine Stadt, was sich im Laufe der automaischen (at) Aktualisierung zu obigen Phänomen aufschaukelt.
Ich bin ratlos.

Nachtrag: Beobachtet habe ich jetzt, daß es nach jedem rereadcfg und Aktualisierung der vom DWD-Server geladenen Daten auftritt. Mit jeder Aktualisierung kommt eine andere Stadt/Meldung hinzu.

2. Nachtrag: Jetzt liegen für meine Stadt keine Warnmeldungen mehr vor und damit sind auch alle anderen Meldungen weg.

MfG

betateilchen

Zitat von: jensb am 02 November 2015, 07:43:03
ja, wenn man FHEMWEB zur Konfiguration benutzt, muss man gdsSetCond/Forcast nich unbedingt manuell einstellen,  was die Sache vereinfacht.

*** STOP ***

bei gdsSetCond und gdsSetForecast trägt bitte NIEMAND etwas ein!

Die zu verwendenden Stationen werden ausschließlich über set <name> conditions <stationName> eingestellt (bzw. set forecast) und NICHT über die Attribute.

Zitat2015.11.01 23:23:26 1: PERL WARNING: Deep recursion on subroutine "main::GDS_GetUpdate" at fhem.pl line 2725.

Das muss ich mir anschauen.

Zitat von: spikeh1 am 02 November 2015, 08:25:25
Aktuell gibt es für meine Region/Stadt eine Warnmeldung, welche mir manuell über die Fhem-Oberfläche abgerufen auch als Reading abgelegt wird.
Rufe ich jedoch über die Warncell-ID ab, laufen bei mir auch andere Readings aus anderen Regionen auf und es kommen immer mehr Ort/Meldungen dazu.

Das Problem ist mir bekannt, daran arbeite ich noch. Das Tückische ist, dass ich daran nur arbeiten kann, wenn es zufällig gerade Stationen mit mehr als einer Warnmeldung gibt.

Zitat
define dwd_read_data at +*00:30:00 get dwd_alerts alerts 103156000
attr dwd_read_data alignTime 00:05:30

Dieses zweite at brauchst Du nicht mehr, Du kannst stattdessen das Auswerten der Wetterwarnungen jetzt direkt per notify starten. Das gds Modul liefert nach jeder erfolgreichen Verarbeitung gelesener Daten einen entsprechenden Trigger. Einfach mal den EventMonitor beobachten.

Natürlich funktioniert der "alte" Lösungsweg mit zwei at Definitionen nach wie vor.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

spikeh1

Zitat von: betateilchen am 02 November 2015, 10:26:20

Das Problem ist mir bekannt, daran arbeite ich noch. Das Tückische ist, dass ich daran nur arbeiten kann, wenn es zufällig gerade Stationen mit mehr als einer Warnmeldung gibt.

Dieses zweite at brauchst Du nicht mehr, Du kannst stattdessen das Auswerten der Wetterwarnungen jetzt direkt per notify starten. Das gds Modul liefert nach jeder erfolgreichen Verarbeitung gelesener Daten einen entsprechenden Trigger. Einfach mal den EventMonitor beobachten.

Natürlich funktioniert der "alte" Lösungsweg mit zwei at Definitionen nach wie vor.

Ich danke dir für deine Antwort. War schon am verzweifeln.
Ich habe zwar die E-Mail vom DWD erhalten, das eine Umstellung der Struktur erfolgt, jedoch habe ich diese gelöscht.
Bis wann läuft denn noch die alte Verzeichnisstruktur beim DWD und wie lange kann ich somit auf meinem Produktivsystem noch die alte Version von deinem Modul verwenden?
Auf meinem Testsystem lasse ich die aktuelle Version laufen. Werde beobachten und bei Bedarf berichten.

MfG

viegener

Zitat von: betateilchen am 02 November 2015, 10:26:20

2015.11.01 23:23:26 1: PERL WARNING: Deep recursion on subroutine "main::GDS_GetUpdate" at fhem.pl line 2725.

Das muss ich mir anschauen.


OK, wenn ich das nochmals reproduzieren kann, sag ich Bescheid.
Allerdings hatte ich bei den Attributen selber etwas eingetragen, wie das auch im wiki steht. Vielleicht war das die Ursache?

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können