Modul für DWD Open Data

[curt]

@jensb Knallkopp_02 @frank
Das bedeutet im Grunde, dass mein in #365 erwähntes Konstrukt sofort wieder (aber völlig anders) Sinn bekommt? Ja, so scheint es.

Darf ich bitte als immer-wieder-Anfänger auf die Mühen der Ebene zurück kommen? Ich habe eine Frage.

Die Werte sind ja in Drei-Stunden-Scheiben. Beispielsweise kann man die Temperatur von 18 bis 21 Uhr adressieren, wenn ich richtig rechne.

Aber wie mache ich es, wenn ich grundsätzlich ein Reading auf "gleich passiert es" haben möchte? Also eine Vorschau auf das nächste 3h-Fenster?

Vermutlich muss ich da ziemlich wild mit Perl rummanschen und ein völlig neues Reading erzeugen? Ich gebe zu, dass ich das nicht kann. Habt ihr so etwas? Wie geht das denn genau?

[jensb]

@curt

Das bedeutet im Grunde, dass mein in #365 erwähntes Konstrukt sofort wieder (aber völlig anders) Sinn bekommt? Ja, so scheint es.

Ja, event-on-... sollte genau anders herum eingesetzt werden, als du es versucht hast, also für weniger statt mehr FHEM interne Update-Meldungen (sofern man sie nicht wirklich braucht, und das Weblink-Modul z.B. braucht sie nicht, da es selbst periodisch pollt).

Aber wie mache ich es, wenn ich grundsätzlich ein Reading auf "gleich passiert es" haben möchte?

Um ein Stück Programmcode kommt man für so etwas nicht herum. FHEM ist kein Wahrsager und kennt die Zusammenhänge zwischen den Readings des OpenData-Moduls nicht. Deshalb muss man so etwas selbst machen und warum nicht in Perl. Dafür ist z.B. 99_myUtils.pm gut zu gebrauchen oder ein notify oder at. Der erforderliche Ablauf ist relativ überschaubar:

• Istzeit bestimmen
• Uhrzeit (nur Stunden) in UTC bestimmen
• stundenIndex = floor(Stunden:forecastResolution)+1
• wenn stundenIndex größer gleich 24/forecastResolution, tagIndex erhöhen und stundenIndex auf 0
• Reading-Namen aus Präfix, tagIndex und stundenIndex zusammenbauen und abholen

Der Rest ist die Verpackung in Perl. So ähnlich wird das für "jetzt" im Weblink-Modul gemacht.

Grüße,
Jens

[jensb]

Die hier angekündigte Version des OpenData-Moduls ist nun per FHEM-Update verfügbar. Noch mal Dank an alle Tester für die Rückmeldungen.

Grüße,
Jens

[Intruder1956]

hallo Jens,
bekomme nach Update heute folgende Meldung immer nach einem "shutdown restart"

Code Auswählen Erweitern


2018.12.16 21:20:21 1 : PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/99_Utils.pm line 21.
2018.12.16 21:20:21 1 : PERL WARNING: Use of uninitialized value $fcStart in addition (+) at ./FHEM/99_DWD_OpenData_Weblink.pm line 1070.

Gruß Werner

[mlmss]

Hallo zusammen,

beim erstmaligen Einrichten dieses Moduls ist mir gerade aufgefallen, dass im Wiki-Artikel der Link zum Modul 99_DWD_OpenData_Weblink.pm tatsächlich auf https://raw.githubusercontent.com/jnsbyr/fhem/master/FHEM/55_DWD_OpenData.pm zeigt.

Nach meinem Verständnis ist das so nicht richtig.

[jensb]

Hallo Werner,

das mit den Warnings ist nicht schön.

Die Frage ist aber:
a) Tritt es nur beim Neustart auf oder bei jeder Aktualisierung des Weblinks und
b) hat es überhaupt einen Einfluss auf die Darstellung im Weblink (betroffen wären die Wetterwarnungen)

Habe das bei mir auch schon sporadisch beobachtet, habe aber noch keine wasserdichte Lösung.

Grüße,
Jens

[jensb]

@mlmss

Nach meinem Verständnis ist das so nicht richtig.

Was ist deiner Meinung nach hier nicht "richtig"?

Hintergrund: Wenn man nicht die RAW-Version herunterlädt, ändert man z.T. das Encoding und es kommt dann zu Fehlern bei der Ausführung. Der Link wurde daher wegen entsprechender Rückmeldungen hier im Thread auf die jetzige Version geändert, damit dieses Problem nicht auftritt.

Grüße,
Jens

[somansch]

Hallo Jens,

habe heute auch das Update gemacht. Soweit keine Probleme  .

Jedoch hätte ich noch einen "Feature Request":

Da bei der jetzigen Wetterlage (Winter) quasi permanent eine Wettermeldung bezüglich FROST existiert, möchte ich gerne Meldungen hierfür deaktivieren. Eine solche Warnung hat momentan diese Readings:

Code Auswählen Erweitern

setstate DWD alerts updated
setstate DWD 2018-12-17 20:15:09 a_0_altitude 0
setstate DWD 2018-12-17 20:15:09 a_0_area xxxxx
setstate DWD 2018-12-17 20:15:09 a_0_areaColor 255, 255, 0
setstate DWD 2018-12-17 20:15:09 a_0_areaDesc Gemeinde xxxxx
setstate DWD 2018-12-17 20:15:09 a_0_category Met
setstate DWD 2018-12-17 20:15:09 a_0_ceiling 3000
setstate DWD 2018-12-17 20:15:09 a_0_description Es tritt leichter Frost zwischen -1 °C und -5 °C auf.
setstate DWD 2018-12-17 20:15:09 a_0_event 22
setstate DWD 2018-12-17 20:15:09 a_0_eventDesc FROST
setstate DWD 2018-12-17 20:15:09 a_0_eventGroup FROST
setstate DWD 2018-12-17 20:15:09 a_0_expires 2018-12-18 10:00:00
setstate DWD 2018-12-17 20:15:09 a_0_headline Amtliche WARNUNG vor FROST
setstate DWD 2018-12-17 20:15:09 a_0_instruction
setstate DWD 2018-12-17 20:15:09 a_0_onset 2018-12-17 21:00:00
setstate DWD 2018-12-17 20:15:09 a_0_responseType None
setstate DWD 2018-12-17 20:15:09 a_0_severity Minor
setstate DWD 2018-12-17 20:15:09 a_0_urgency Immediate

Wäre die "a_x_event"-Nummer (hier 22) eindeutig für nur Frostwarnung? Könntest ein Attribute für Excludes hinzufügen?

Danke und Gruß
Andreas

[mumpitzstuff]

Ich habe mir für Proplanta einen Plot erstellt und würde gern etwas ähnliches für dwd Open Data machen, habe aber Schwierigkeiten die entsprechenden Readings zu finden. Folgendes habe ich bisher zuordnen können:

sun: SunD (nutzbar nach Konvertierung in % aus 12h bezogen)
temp: TTT
tempMax: Tx
tempMin: Tn
cloud: Neff

Was mir noch fehlt ist:

rain
chanceOfRain

Hat jemand einen Tipp was man da nehmen könnte? Für chanceOfRain habe ich schon R600 versucht, das unterscheidet sich aber sehr von Proplanta, so das ich mir hier unsicher bin.

[jensb]

Hallo Andreas,

deinen Vorschlag mit dem Filter für bestimmte Warnungen finde ich gut. Dazu den CAP Event Code zu verwenden ist auch eindeutig (siehe Abschnitt 3.1.1), wobei der genaue Event-Text auch von den Eigenschaften Urgency und Certainty abhängt, sich aber immer auf das gleiche Wetter- bzw. Gesundheitsphänomen bezieht.

Ein Anwender müsste sich entweder gegen bestimmte bereits empfangene Warnungen entscheiden oder sich dieses Dokument ansehen, um die richtigen Event-Codes zur Verfügung zu haben.

Es ist ja bald Weihnachten. Wenn ich die Zeit finde, werde ich es einbauen.

Grüße,
Jens

[jensb]

@mumpitzstuff
Folge den Brotkrumen (hier: Modulhilfe)

1. In der Modulhilfe steht:

    RR6c [kg/m2] - precipitation amount in the last 6 hours
    R600 [%] - probability of rain in the last 6 hours
    RRhc [kg/m2] - precipitation amount in the last 12 hours
    Rh00 [%] - probability of rain in the last 12 hours
    RRdc [kg/m2] - precipitation amount in the last 24 hours
    Rd00 [%] - probability of rain in the last 24 hours

2. Alle möglichen Werte sind hier aufgelistet.

Für chanceOfRain habe ich schon R600 versucht, das unterscheidet sich aber sehr von Proplanta, so das ich mir hier unsicher bin.

Schau dir die Definition für die beiden gesuchten Werte bei Proplanta an. Vermutlich ist der Betrachtungszeitraum und der Bezugszeitpunkt unterschiedlich. Wenn du z.B. einen 12 Stunden-Wert verwendest, dann spielt es eine Rolle, ob er sich auf 00:00, 06:00 oder ... bezieht.

Grüße,
Jens

[mumpitzstuff]

Okay hab's mal damit versucht. Von Proplanta kenne ich leider die Bezugszeiträume nicht, deshalb ist es natürlich etwas schwierig zu vergleichen. Ich spiel mal noch ein wenig und poste mal das Ergebnis.

Danke für die Information.

An der Beschreibung hatte mich vor allem immer das "in the last" verwirrt. Hat für mich immer so nach Vergangenheit und nicht wie eine Vorhersage geklungen. Eventuell muss ich die Zeitpunkte auch noch verschieben, denn ich muss ja quasi rückwärts den Punkt setzen.

Wenn also z.b. um 6:00 ein Reading existiert, das in den letzten 6h irgendwas auf beispielsweise 100 stand, dann muss ich auf der Zeitachse die 100 bei 3:00 Uhr setzen, wenn ich das richtig verstanden habe.

[mumpitzstuff]

Das ist das Resultat bisher. Insbesondere der Wert für Sonneneinstrahlung macht wenig Sinn bei DWD. Über 80% Bewölkung und 60% Sonne? Passt irgendwie nicht zusammen. Habe aber jetzt mehrfach die Rohwerte verglichen und eigentlich passt die Auswertung. Insgesamt sehen die Proplanta Werte plausibler aus.

[frank]

da du für sun nur einen wert pro tag hast, müstest du wohl ein reading nutzen, das einen wert für 24h bereitstellt. in der dwd liste beziehen sich die daten aber immer auf einen zurückliegenden zeitraum.

bei sunD, habe ich gesehen, stand last day.
sunD für nächsten sonntag müsste dann der wert für samstag sein.

wenn du also alle sun werte um einen tag vorziehst, passt es doch dann im vergleich zu proplanta eigentlich, oder?

[jensb]

@mumpitzstuff + @frank

in the last ... hours

bedeutet, dass es sich auf die entsprechende Anzahl Stunden vor dem Meldezeitpunkt bezieht.

Beispiel 1: Meldezeitpunkt ist 12:00, Wert ist "in the last 6 h". Dann ist also 06:00 bis 12:00 gemeint.
Beispiel 2: Meldezeitpunkt ist 12:00 Sonntag, Wert ist "in the last 24 h". Dann ist also 12:00 Samstag bis 12:00 Sonntag gemeint.

Bei sunD wird glaube ich um 06:00 UTC gemeldet. Dann muss man also am Sonntag nachsehen, wie viel Sonne am Samstag scheint. Ähnlich wie in der Wirklichkeit weiß man auch bei der Vorhersage erst am Ende was heraus kommt.

Die Summe aus % Bewölkung und % Sonne muss je nach beteiligten Messgrößen nicht zwingend 100% ergeben.

Man sollte bei so einem Vergleich auch versuchen, die Daten mit den eigenen Wetterbeobachtungen abzugleichen. Zumindest in Tagessumme stimmen bei mir z.B. die Niederschlagmengen in etwa mit meinem Regensensor überein.

Im Endeffekt hat jeder Vorhersagedienst seine Spezialitäten, so dass Unterschiede nicht verwunderlich sind. Der Vergleich ist allein deshalb oft schon schwierig, weil die Messgrößen nicht identisch sind. Dahinter stecken komplexe meteorologische Modelle mit Millionen von Werten, die mit einer bestimmten räumlichen und zeitlichen Auflösung über einen magischen Algorithmus in für uns fassbare Datenmengen herunter gebrochen werden.

Grüße,
Jens