Modul für DWD Open Data

[Knallkopp_02]

@curt

die "Übersetzung" der ganzen Werte erfolgt in der widget_weather.js, dort bin ich aktuell auch dran, aber wie setstate irgenwann gesagt hatte, das ist alles etwas verwirrend, warscheinlich weil das widget gewachsen ist, und immer nur erweitert wurde.

Gruß

[curt]

(Zitate aus dem allgemeinen DWD-opendata-Thread)

Zum Thema Icons Tag/Nacht und vorallem einheitlicher Nutzung für FTUI oder andere Frontends stecke ich fest.
Das Tag/Nacht scheint zu klappen, aber nur für DWD->Kleinklima.
Für mich selbst wäre das jetzt erledigt, da ich diese Konstellation für mich angepasst habe.

Das würde ich mir gern mal ansehen.
Insbesondere ist mir Dein konzeptioneller Tag/Nacht-Ansatz nicht klar. - Wir müssten gelegentlich (wenn Du magst) mal ganz substanziell über das Sonne/Mond/Wolke-Icon reden: Was wollen wir da eigentlich genau darstellen? Und wo bekommen wir sinnvolle Werte her?

Aber für die Allgemeinheit ist es keine Lösung. Ich habe testweise Proplanta, Yahoo und DWD mal als Datenlieferanten erstellt und für die 3 FTUI Anzeigemöglichkeiten meteocons, weathericons und Kleinklima einen Bereich in FTUI definiert. Mal funktioniert diese Anzeige, mal eine andere. Je nach dem was man kombiniert.

Was fällt euch dazu ein, sowas global Nutzbar zu machen, damit der User einfach nur sein Frontend mit dem passenden Modul wählen muss und die Anpassungen für die anzuzeigenden Daten erstellen muss.

Ich hatte vor Tagen mal ziellos im Web nach lizenzfreien Icon-Sätzen gesucht. Da fiel mir ein stark stilisierter Satz auf (der vielleicht sogar in FHEM ist, das habe ich nicht geprüft). Solche stark vereinfachten Symbolsätze haben ja den Vorteil, dass man da zusätzlich mit Farben arbeiten kann. Das geht bei Kleinklima nicht - der sieht einfach nur "schön" aus.

Vermutlich gibt es noch -und da würde es spannend- einen Iconsatz von DWD-opendata: In einer Excel-Tabelle vom DWD (wohl ein Link von @somansch , müsste hier verlinkt sein) tauchen genaue Zuordungen zu Dateinamen auf, die wohl Icons sind. [Siehe P.S.]

Zu Deiner Frage:
Im Grunde läuft es darauf hinaus, in einer Tabelle in den ersten Spalten die denkbaren Readings der verschiedenen Wetter-Devices, in den weiteren Spalten die zuzuordnenden verschiedenen Icon-Sätze (da konkrete Icons) zu erfassen. Eine Fleißarbeit mit vermutlich hohem Frustfaktor.

Mein Status:
Inzwischen habe ich die auszuwertenden Readings bei mir präzisiert (erweitert). Unter anderem kommen dann (bei mir) nun Wetterwarnungen. Dabei fiel ein unschöner Konzept-Fehler auf: Beim DWD heißt es z.B: TN, bei @jensb heißt es Tn. Das ist nicht ganz ungefährlich, da das case-sensitiv ist.

Ich habe den Template-Gedanken aufgenommen und die aus meiner Sicht wichtigen Readings vereinzelt. Das ist dann deutlich übersichtlicher und weniger fehlerträchtig - ich kann meine Dateien gern vorstellen. (Rein optisch macht das bei mir absolut nichts her - ich bin noch in der Phase der Tests.

Ein Problem tut sich bei mir mit verschiedenen Browsern auf: Textausgaben, die über zuerst über das Widget DWD-opendata und danach noch über das Widget Label laufen, werden nicht bzw. nur stochastisch aktualisiert. Da hilft kein class=nocache, das geht einfach nur schief. - Das Problem scheint es nicht nur bei mir zu geben, im Forum fand ich zwei oder drei unbeantwortete sehr ähnliche Themen.

Da es so schön kalt ist:
Ich fand einen Thread, der Frostwarnung spielt. Der Thread gleitet dann ab, bei anderen Devices gibt es wohl direkt ein fc0_frost. Aber der ganz vorn erörterte Ansatz ist sehr schön: https://forum.fhem.de/index.php/topic,63067.msg543345.html#msg543345 - Habe ich nicht umgesetzt, nur erstmal gefunden.

Ich selbst bin etwas in Stress, ich bin die nächsten Tage unterwegs.

P.S: Ja, war Hinweis von @somansch : https://www.dwd.de/DE/leistungen/opendata/help/inhalt_allgemein/opendata_content_de_en_xls.xls

[jensb]

Beim DWD heißt es z.B: TN, bei @jensb heißt es Tn. Das ist nicht ganz ungefährlich, da das case-sensitiv ist.

Das war mein Versuch im Sinn einer Abwärtskompatibilität, um nicht alle vor der letzten Umstellung des DWD bekannten Readings über den Haufen zu werfen. Auf diesem Umstand habe ich hier zum Zeitpunkt der Umstellung hingewiesen. Wer selbst programmiert kann ggf. case-insensitiv vergleichen oder mappen. Wenn jemand einen guten Grund kennt, die Abwärtskompatibilität des OpenData-Moduls aufzuheben, dann muss er ihn nennen.

Ich fand einen Thread, der Frostwarnung spielt ...

Das ist in ähnlicher Form im OpenData-Weblink umgesetzt. Solange man aber nur die Temperatur heranzieht, hat das in etwa die gleiche Aussage wie die Schneeflocke in vielen Autos.

Grüße,
Jens

[Knallkopp_02]

@curt

Das würde ich mir gern mal ansehen.
Insbesondere ist mir Dein konzeptioneller Tag/Nacht-Ansatz nicht klar. - Wir müssten gelegentlich (wenn Du magst) mal ganz substanziell über das Sonne/Mond/Wolke-Icon reden: Was wollen wir da eigentlich genau darstellen? Und wo bekommen wir sinnvolle Werte her?

Ich habe mal 2 Grafiken angefügt, die meine Vorstellung der Anzeige darstellen und mit den von mir gemachten Anpassungen auch laufen. Das ist aber nur hingefuscht weil mir die Kenntnisse fehlen.

Sinnvolle Werte werden von den einzelnen Wetter-Modulen ja schon geliefert. Leider werden sie nicht sauber in FTUI über das Wetter Widget ausgegeben, was auch echt kompliziert ist, ich steige auch nicht durch.

BTW: Großen Danke an setstate das du das wenigsten übernommen hast und etwas pflegst. Ist nicht einfach etwas von jemandem zu übernehmen und dann auch noch zu verstehen, was da eigendlich vor geht, wenn man es nicht nutzt.

Ich hatte vor Tagen mal ziellos im Web nach lizenzfreien Icon-Sätzen gesucht. Da fiel mir ein stark stilisierter Satz auf (der vielleicht sogar in FHEM ist, das habe ich nicht geprüft). Solche stark vereinfachten Symbolsätze haben ja den Vorteil, dass man da zusätzlich mit Farben arbeiten kann. Das geht bei Kleinklima nicht - der sieht einfach nur "schön" aus.

Insgesamt sind ja 3 verschiedene Darstellungsmöglichkeiten in FTUI integriert.
Icons von Meteocons, Icons von Weathericons und Grafiken von Kleinklima.
Das ist ja schonmal eine entsprechende Auswahl. Funktionieren scheint aber nur DWD und Kleinklima obwohl es dank setstate auch schon mal mit Proplanta und weathericons funktioniert hat. habe bestimmt irgendwas versaut beim basteln.

Gruß           
Gruß

[curt]

@Knallkopp_02
Es scheint da noch einen weiteren Grafik-Satz zu geben, der mir geeignet erscheint. Aber ich bin wirklich erst in diesem Moment zurück von Reisen - ich habe mir das noch nicht näher angesehen.

Ganz allgemein:
Mir fehlt die Übersetzungsmöglichkeit des schnellen Blicks: "Wie wird es denn morgen?"

Die meisten von uns sind ja keine Landwirte - die meisten interessiert eher: Wird es ein sonniger Tag oder trüb oder regnerisch? Und das mit genau einer Grafik übersetzt ...

[curt]

Beim DWD heißt es z.B: TN, bei @jensb heißt es Tn. Das ist nicht ganz ungefährlich, da das case-sensitiv ist.

Das war mein Versuch im Sinn einer Abwärtskompatibilität, um nicht alle vor der letzten Umstellung des DWD bekannten Readings über den Haufen zu werfen.

Mein Hinweis war doch nur "Herr Lehrer, ich weiß auch was". Mir fiel das auf. - Mal allgemein gefragt: Spielt case-Sensitivität überhaupt eine Rolle? Sonst wäre es doch besser, wenn Du im Modul ganz pauschal alles mappst.

Ich fand einen Thread, der Frostwarnung spielt ...

Das ist in ähnlicher Form im OpenData-Weblink umgesetzt.

Falls ich nichts übersehen habe, ist der OpenData-Weblink für FTUI unbrauchbar. Man kann ihn dort nicht sinnvoll integrieren.

Solange man aber nur die Temperatur heranzieht, hat das in etwa die gleiche Aussage wie die Schneeflocke in vielen Autos.

So sind sie, die unterschiedlichen Kinderchen: Ich wohne (ohne es näher beschreiben zu wollen) in einer Gegend mit einem etwas ungewöhnlichem Mikroklima. Und mir würde diese grafische Auto-Aussage wirklich helfen; mit Betonung auf "graphisch". (Denn ich steige bei angeblichen 3°C ins Auto, vorher kratze ich diese 3°C von der Frontscheibe. Dann fahre ich los und nach 2km kommt eine Senke ... und so weiter.)

[jensb]

@curt

Mal allgemein gefragt: Spielt case-Sensitivität überhaupt eine Rolle?

Das kommt auf die Programmiersprache bzw. die Daten an. Jeder, der das aber wirklich ausnutzt und mit z.B. Tn, TN, tN und tn herum operiert, der sollte mit dem Programmieren aufhören. In den meisten Fällen kann man zumindest Daten ohne Mehrdeutigkeiten in Lower- oder Uppercase vergleichen. Da spielen dann eher noch Stylguides oder Lesbarkeit eine Rolle. "T" für Temperatur, "n" für einen Index, den man ja ohne Textverarbeitung nicht wirklich tief stellen kann. "TN" würde das nicht so gut 'rüber bringen und "tn" auch nicht.

Sonst wäre es doch besser, wenn Du im Modul ganz pauschal alles mappst.

Besser ist relativ. Jeder der es braucht kann sich austoben: einfach die Zeile 71 vom OpenData-Module (die mit "forecastPropertyAliases") und die davon abhängigen Zeilen 78 und 83 nach belieben anpassen.

Ich fand einen Thread, der Frostwarnung spielt ...

Ihr arbeitet doch an einer Lösung. Wollte nur anmerken, dass ihr auch im OpenData-Weblink-Modul nachsehen könntet, um ein paar Ideen zu bekommen.

Und mir würde diese grafische Auto-Aussage wirklich helfen ...

Mir auch, vor allem wenn man sie vorhersagen könnte. Dann wäre das der Schalter für die Auto-Standheizung. Ich suche aber noch nach einer besseren Lösung als die bloße Temperatur. Meiner Ansicht nach benötigt man für die bessere Schneeflocke den Temperaturverlauf der letzten Stunden und vielleicht auch die Windgeschwindigkeit. Es geht ja bei Frost um Kondensation auf kalten Flächen. Dazu muss die Fläche (als z.B. das Autoglas) kälter sein als die Luft und die Luft muss eine bestimmte Feuchtigkeit bzw. einen bestimmten Taupunkt bzw. eine bestimmte Taupunktdifferenz haben (oder so ähnlich).

Grüße,
Jens

[curt]

@jensb
Alles verstanden. (War ja nur Diskussion. Ich lebe gut mit dem case-sensitiven Stand; ich stolperte halt darüber.)

Frostwarnung:
Eigentlich will man (ich) ja etwas anderes. Es soll vor Frost gewarnt werden, wenn Frost mit einer Wahrscheinlichkeit x kommt. - Meine Situation: Obwohl ich auf ca. 150m Seehöhe lebe, habe ich hier Mittelgebirgsklima. Das liegt an der exponierten Lage hinter dem Harz sowie am Übergang Elbe->Endmoräne. Beispiel: Die fährst die BAB 9 von süd nach Berlin. Es regnet leicht. Du passierst die Elbebrücke Vockerode, wenige Kilometer später steht "120". Dabei ist es nur leicht kurvig, es geht unmerklich hoch. Und Du hast gute Chancen, völlig unerwartet auf Glatteis weiterzufahren.

Ich verstehe Deinen Gedankengang und habe da vielleicht einen Hinweis: Vor so einigen Jahren hatte ich eine Wetterstation WS2300 seriell an einem kleinen Linux-Server. Die Software entstammte einer damals regen Community; Grafiken, Vorhersagen, Statistiken usw. Vermutlich habe ich die Software (war Perl) noch irgendwo. Auf alle Fälle erinnere ich mich da an etwas. Vielleicht suchst Du "windchill" bzw. dessen Berechnung (unzureichend mit "gefühlte Temperatur" übersetzt).

Andere Baustelle, vielleicht kannst Du mir da helfen:
Einige Textwerte (wie: Minimaltemperatur Tag3) werfe ich mit dem FTUI-Widget Label raus. Leider muss ich feststellen, dass das in FTUI nicht bzw. nur sporadisch aktualisiert. Dafür gibt es zig mögliche Ursachen. Ich fange mal bei Deinem Modul an:

Mache ich da etwas mit event-on-... falsch? Schaue Dir mal bitte meine Definition an, ist die richtig oder mache ich da Fehler?

Code Auswählen Erweitern


define DWD DWD_OpenData
attr DWD alertArea 815091375
attr DWD alertLanguage DE
attr DWD event-on-update-reading 1
attr DWD forecastDays 4
attr DWD forecastProperties wwP,wwD,FF,DD,FX1,Neff,TTT,ww,Tg,Tn,Tx,RR6c,RRhc,Rh00,SunD
attr DWD forecastResolution 3
attr DWD forecastStation 10474
attr DWD forecastWW2Text 1
attr DWD room 99_System
attr DWD userReadings fc0_SunDh {ReadingsVal("DWD","fc0_SunD","")/3600},\
fc1_SunDh {ReadingsVal("DWD","fc1_SunD","")/3600},\
fc2_SunDh {ReadingsVal("DWD","fc2_SunD","")/3600},\
fc3_SunDh {ReadingsVal("DWD","fc3_SunD","")/3600},\
fc4_SunDh {ReadingsVal("DWD","fc4_SunD","")/3600}


[jensb]

@curt

Vielleicht suchst Du "windchill" ...

Über den habe ich mir auch schon Gedanken gemacht. Ob es (fast) das Gleiche ist wie zugefrorene Fensterscheiben kann ich (noch) nicht sagen.

Mache ich da etwas mit event-on-... falsch?

Soweit ich weiß, ja. Das Attribut braucht eine mit Kommas getrennte Liste von Readings und keinen Zahlenwert. Wenn du etwas zeitlich zusammenfassen willst, dann solltest du dir event-aggregator ansehen.

Grüße,
Jens

[curt]

Vielleicht suchst Du "windchill" ...

Über den habe ich mir auch schon Gedanken gemacht. Ob es (fast) das Gleiche ist wie zugefrorene Fensterscheiben kann ich (noch) nicht sagen.

Das (windchill) kommt schon einigermaßen hin. Mehr wird nicht zu haben sein. (es fehlt noch die Luftfeuchte als Wärmeträger. Aber das ist Kaffeesatzleserei - Stichwort Eisregen.)

Mache ich da etwas mit event-on-... falsch?

Soweit ich weiß, ja. Das Attribut braucht eine mit Kommas getrennte Liste von Readings und keinen Zahlenwert.

<seufzt>
Woher auch immer ich das mit cut+paste holte ... ich habe da also noch so eine Gurke irgendwo in der config.

Ok, ich habe nun die Parameter aus "attr DWD forecastProperties wwP,wwD,FF,DD,FX1,Neff,TTT,ww,Tg,Tn,Tx,RR6c,RRhc,Rh00,SunD" genommen und werde beobachten.

Wenn du etwas zeitlich zusammenfassen willst, dann solltest du dir event-aggregator ansehen.

Satz nicht verstanden.
Was meinst Du mit "etwas zeitlich zusammenfassen"? Was möchte ich zeitlich zusammenfassen? Wofür kann man (ich) das ggf. brauchen?

[curt]

@jensb

Ok, ich habe nun die Parameter aus "attr DWD forecastProperties wwP,wwD,FF,DD,FX1,Neff,TTT,ww,Tg,Tn,Tx,RR6c,RRhc,Rh00,SunD" genommen und werde beobachten.

Es geht um event-on-update-reading - dazu habe ich noch Fragen: a_0_eventDesc und a_0_description hätte ich da auch ganz gern drin. Mir ist leider nicht klar, wie ich die beiden adressiere: Ohne das "a_0_" oder wie genau?

Weiteres Verständnisproblem: SunDh bekomme ich auch nicht aktualisiert in das Widget. Ist SunDh ein Attribut Deines Moduls, also vom DWD? (Ich habe da ein entsprechendes userReading ...)

Ansonsten kommt das langsam in das Gleis, in das es gehört.

[frank]

wozu brauchst du "event-on-update"?
das ist sowieso schon eingeschaltet. wenn das dein einziges event-on attribut ist, dann einfach löschen und gut ist.

[jensb]

@curt
Bzgl. event-on-update-reading und event-aggregator hilft wie so oft die Commandref. Ich dachte, dass du vielleicht mit event-on-update-reading=1 erreichen wolltest, dass z.B. nur jede Sekunde ein Update des Readings gemeldet wird, auch wenn sich das Reading tatsächlich häufiger ändert. Das geht mit event-aggregator. Aber genau wie frank das bzgl. event-on-update bereits gesagt hat, brauch man auch event-aggregator beim OpenData-Modul nicht, da sich die Readings nicht so schnell ändern können.

SunDh bekomme ich auch nicht aktualisiert ...

SunDh gibt es nicht vom DWD, aber SunD und das ist ja in deinen Attribut forecastProperties aufgeführt. Ein Reading wird aber nur erzeugt, wenn der DWD dafür auch Daten liefert und das tut er nicht für alle Stationen in gleicher Weise. In der Modulhilfe steht dazu, dass man sich eine Messdatendatei für seine Station vom DWD-Server herunterladen sollte, um nachzusehen, was für Daten tatsächlich verfügbar sind. Dazu dem Link in der Modulhilfe folgen, in das Unterverzeichnis kml wechseln, eine der Dateien herunterladen, in .zip umbenennen und eine der im Archiv enthaltenen Dateien mit einem Texteditor öffnen.

Grüße,
Jens

[curt]

@frank

wozu brauchst du "event-on-update"?

Ich nutze das Modul DWDopendata mit nachgelagertem FTUI-Widget weather sowie weiteren wie label. Dort stellt sich heraus, dass nicht korrekt aktualisiert wird. Dafür gibt es zig Verdächtige: Der Browser mit seinem Caching selbst. FTUI mit ziemlich viel Javascript-Budenzauber und insbesondere dem class-Parameter  "nocache". Und interessanterweise auch event-on-update im DWDopendata-Modul, das bewirkt tatsächlich, dass veränderte Daten zügig durch die genannte Kette durchgereicht werden.

EDV ist halt immer auch eine Priese magisches Zaubersalz ...

BTW: Ich rede hier auch über schmale Browser wie Vivaldi. Sowas braucht man, wenn man erstens den Client aud RPi mit Monitor laufen läßt und zweitens keine Browser mag, die jede URL an den Hersteller oder sonstwen verpetzen.

@jensb

SunDh gibt es nicht vom DWD, aber SunD und das ist ja in deinen Attribut forecastProperties aufgeführt. Ein Reading wird aber nur erzeugt, wenn der DWD dafür auch Daten liefert und das tut er nicht für alle Stationen in gleicher Weise.

Ok, verstanden.
Im Moment habe ich das interessante Phänomen, dass das errechnete Reading SunDh mit Vivaldi auf dem RPi korrekt dargestellt wird - auf meinem riesig großen PC mit Ubuntu 18.04 aber nicht aktualisiert wird. Ja, gleiche Browserversionsstände, gleiche Einstellungen. Ähnlich ist das bei den Warnungen: Der Vivaldi auf dem Ubuntu-PC kommt nicht damit zurecht, dass Warnungen (also ein Reading) einfach so verschwindet. - Aber alles nicht Dein Problem: Ich erzähle es nur.

[jensb]

@curt
Ich kann im Detail deine merkwürdigen Phänomene nicht erklären, aber dass event-on-update=1 irgendetwas (positives) bewirkt, kann ich mir nicht vorstellen. Das gibt die Verarbeitung in fhem.pl meiner Ansicht nach nicht her.

Die Aktualisierungsprobleme, die du beschreibst, haben eher etwas mit Browsern, Websockets und JavaScript zu tun. Habe selbst Epiphanie als Browser auf dem RPi. Der zeigt den gleichen Effekt selbst bei einer Mini-FTUI-Seite mit 3 Elementen. Die Zeitanzeige läuft einwandfrei, aber Änderungen der Readings kommen nicht immer an, meist erst nach einem Reload. Bin der Sache aber noch nicht nachgegangen, sie hat jedenfalls nichts mit dem OpenData-Modul zu tun.

Grüße,
Jens