Modul für DWD Open Data

[curt]

@jensb @Knallkopp_02

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

Missverständnis. - Das Attribut habe ich auf Deinen Hinweis hin geändert. Das hatte das Ergebnis, dass auf mehreren Browsern die meisten Werte (leider nicht alle) nun tatsächlich aktuell via FTUI/widget-weather/widget-label dargestellt werden. Ich habe keine Ahnung, warum das so ist - aber es ist so.

Hier:

Code Auswählen Erweitern

attr DWD event-on-update-reading wwP,wwD,FF,DD,FX1,Neff,TTT,ww,Tg,Tn,Tx,RR6c,RRhc,Rh00,SunD,a_0_description,a_0_eventDesc,SunDh[/quote]

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.

Sekundär schon, siehe oben.
Ansich hast Du völlig recht. Mir ist schon klar, wie viele Komponenten da rein spielen. (Ich habe z.B. den Effekt, dass Vivaldi auf RPi sowie alle schnell greifbaren Browser auf Ubuntu-14.04 identische Werte darstellen - aber Vivaldi auf Ubuntu-18.04 schwer hinterher hängt, also teils veraltete Werte zeigt. Cache usw, ich weiß ... alles probiert.

Ansich müsste ich in dem parallelen FTUi-Thread meine aktuelle Konfiguration zeigen. Ich zögere, da sind vermutlich formale Gurken drin, optisch sieht der Prototyp auch alles andere als gut aus. Vielleicht am Wochenende.

[jensb]

Vielleicht noch einmal zur Klarstellung:

Code Auswählen Erweitern

event-on-update-reading=1
bewirkt wahrscheinlich, dass du gar keine Reading-Update-Events von dem Device mehr bekommst.

Code Auswählen Erweitern

event-on-update-reading=wwP,wwD,FF,DD,FX1,Neff,TTT,ww,Tg,Tn,Tx,RR6c,RRhc,Rh00,SunD,a_0_description,a_0_eventDesc,SunDh
bewirkt wahrscheinlich, dass du für die Readings a_0_description und a_0_eventDesc Update-Events bekommst. Alle anderen Elemente der Liste sind keine Reading-Namen des Devices und keine regulären Ausdrücke, und damit kann event-on-update-reading nichts anfangen. Wenn du z.B. alle Readings für FF angeben willst, solltest du .*_FF schreiben.

Wenn du aber sowieso für alle Readings Update-Events erhalten willst, macht es keinen Sinn, das Attribut event-on-update-reading überhaupt zu setzten, darauf hatte frank schon hingewiesen.

Du kannst das leicht mit FHEMWEB überprüfen. Da, wo sich die Zeitstempel der Readings ohne Seitenneuaufbau aktualisieren, sind die Update-Events aktiv.

Grüße,
Jens

[curt]

Code Auswählen Erweitern

event-on-update-reading=wwP,wwD,FF,DD,FX1,Neff,TTT,ww,Tg,Tn,Tx,RR6c,RRhc,Rh00,SunD,a_0_description,a_0_eventDesc,SunDh
bewirkt wahrscheinlich, dass du für die Readings a_0_description und a_0_eventDesc Update-Events bekommst. Alle anderen Elemente der Liste sind keine Reading-Namen des Devices und keine regulären Ausdrücke, und damit kann event-on-update-reading nichts anfangen. Wenn du z.B. alle Readings für FF angeben willst, solltest du .*_FF schreiben.

Also ".*_Neff" beispielsweise?

Wenn du aber sowieso für alle Readings Update-Events erhalten willst, macht es keinen Sinn, das Attribut event-on-update-reading überhaupt zu setzten, darauf hatte frank schon hingewiesen.

Satz leider nicht verstanden.

Du kannst das leicht mit FHEMWEB überprüfen. Da, wo sich die Zeitstempel der Readings ohne Seitenneuaufbau aktualisieren, sind die Update-Events aktiv.

Leider auch nicht verstanden. (Ich ahne aber, was gemeint sein könnte.)

Nein, das stimmt nicht. Min/Max-Temperatur aktualisieren in FTUI erst seitdem ich meine vermutlich falsche attr-Konstruktion habe. Es ist so - warum auch immer es so ist.

[jensb]

@curt

Also ".*_Neff" beispielsweise?

Ja, und auch ".*Neff" sollte funktionieren.

Satz leider nicht verstanden.

Die verschiedenen Weboberflächen nutzen für die Aktualisierung der Anzeige die internen FHEM Events, die beim Update eines Readings erzeugt werden. Mit dem Setzen des Attributs event-on-update-reading kann man diese Standardfunktion auf bestimmte Readings EINSCHRÄNKEN. Es macht also keinen Sinn, dass Attribut zu setzten, wenn man keine Einschränkung will.

Leider auch nicht verstanden.

Drück beim OpenData-Modul über die normale FHEM-Weboberfläche (FHEMWEB) auf "get forecast" und schau dir an, welche fc-Readings anschließend einen neuen Zeitstempel haben. Das stellt FHEM mit einem Farbumschlag dar.

Grüße,
Jens

[frank]

auch mal auf den eventmonitor schauen.
nur hier "sieht" man den gesamten event kosmos von fhem.

[curt]

@jensb

Code Auswählen Erweitern

event-on-update-reading=wwP,wwD,FF,DD,FX1,Neff,TTT,ww,Tg,Tn,Tx,RR6c,RRhc,Rh00,SunD,a_0_description,a_0_eventDesc,SunDh
bewirkt wahrscheinlich, dass du

Jens,
ich habe das komplette Konstrukt rausgeworfen. Ihr seid die Profis - und ich der mit dem ganz schmalen Fuß.

Danke für die Zeit, die Ihr mit mir investiert.

[Knallkopp_02]

@jensb

wir hatten ja schonmal wegen Erweiterungen des Moduls gesprochen. Du sagtest damals, dass du das Modul als reines Datenmodul siehst welches Daten zur verfügung stellt, was ich auch verstehe.

Ich würde gerne folgendes wissen, der Wert "wwd" wird nicht von DWD geholt, sondern von deinem Modul aus "ww" generiert, ist das richtig?

Wäre es möglich das gleiche für "DD" zu machen?

Wäre es ebenso denkbar eine Wert "fc_condition" aus der aktuellen Vorhersage"fc0_* und der aktuellen Zeit zu generieren für die nächste Stunde zu generieren?

so wäre das Anzeigen wesentlich einfacher, als mit irgendwelchen Konstrukten aus JS, FTUI, IF usw. die ich bislang noch nicht hinbekommen habe.

Gruß

[jensb]

... der Wert "wwd" wird nicht von DWD geholt, sondern von deinem Modul aus "ww" generiert, ist das richtig?

Ja, und es fehlt noch die englische Version.

Wäre es möglich das gleiche für "DD" zu machen?

Mit Software kann man (fast) alles machen, also ja, aber: die Windrichtung will der eine in 4, der andere in 8 und noch ein andere in 16 Teile geteilt haben. Das ist also wieder eine Darstellungsfunktion. Eine mögliche Umsetzung ist, wie schon mehrfach erwähnt, im OpenData Weblink enthalten. Ich rate noch einmal dazu, das Weblink-Modul als Basis für die Weiterverarbeitung zu verwenden. Dazu müsste man, wie schon mehrfach erwähnt, aus den Weblink-Modul-internen Daten noch Readings generieren und dann könnten FTUI & Co. die Daten aus dem Weblink-Device abholen. Es wären die Daten, die man jetzt im OpenData-Weblink zu sehen bekommt. Natürlich könnte man auch die Daten von einem OpenData-Device und einem Weblink-Device für die Darstellung mischen. Wenn jemand einen Patch für das Weblink-Modul bereit stellt (ein neues Attribut für die Reading-Generierung + Code + Modulhilfe + Wiki), werde ich ihn integrieren.

Wäre es ebenso denkbar eine Wert "fc_condition" aus der aktuellen Vorhersage"fc0_* und der aktuellen Zeit zu generieren für die nächste Stunde zu generieren?

fc0_* sind im Wesentlichen die Eigenschaften des 1. und 2. Icons des Weblink-Moduls: siehe vorherige Antwort. - Habe noch einmal geprüft, ob man hierfür statt Vorhersagewerte die Istwerte des DWD nutzen könnte (siehe https://opendata.dwd.de/weather/weather_reports/poi/): es würde gehen und man erhält dann vor allem ein paar Temperaturen und die Luftfeuchtigkeit. Allerdings sind die Daten nicht wirklich aktuell sonder knapp 1 Stunde alt. Außerdem liegen sie im CSV-Format vor. Das ist für sich keine Problem, aber dieses Format steht beim DWD auf der Abschussliste (vgl. Vorhersgedaten 17.09.2018). Es könnte also sein, dass diese Daten nach ein paar Monaten abgelöst würden oder entfallen.

Grüße,
Jens

[jensb]

Eine Vorabversion des neusten OpenData-Moduls ist ab sofort auf GitHub verfügbar.

Es handelt sich um einen größeren interner Umbau des Codes mit dem Hauptziel, die Performance und die Fehlerbehandlung weiter zu verbessern. Es gibt auch ein paar kleine funktionelle Erweiterungen. Hier die Details:

• Feature: Erweiterte Parallelverarbeitung für die Vorhersagedaten außerhalb des FHEM Hauptprozesses
  
• Feature: Sequentieller statt paralleler Start der Aktualisierung von Vorhersage und Wetterwarnungen, um die Systemlast besser zu verteilen
  
• Feature: Verbessertes Aufräumen der internen Strukturen beim Herunterfahren von FHEM und Löschen des Moduls
  
• Feature: Verbesserung der Fehlererkennung beim Verarbeiten von Updates für Vorhersage und Wetterwarnungen (Download, Daten, etc.)
  
• Feature: Neue Readings a_state und fc_state
  
• Feature: Bei einem Fehler in der Verarbeitung von Wetterwarnungen wird eine zusätzliche "Wetter"-Warnung mit dem Störgrund angelegt, um deutlich darauf aufmerksam zu machen
  
• Bugfix: Fehlerbehandlung für Timeout beim Herunterladen von Vorhersagedaten korrigiert
  
• Bugfix: Berechnung des Umfangs der zu löschenden Vorhersagedaten bei Tageswechel korrigiert
  
• Bugfix: Update-Scheduler ist nun unabhängig von der Sommerzeitumstellung
  
• Modulhilfe erweitert
  

Obwohl es eines der Hautziele war, die Performance des Moduls zu verbessern, indem die Auslastungsdauer von FHEM pro Modulaktion verringert wird, liegt das größte Potential im Setzten des Attributs "event-on-update-reading" (z.B. auf "state,fc_time,a_time"). Diese Ansatz ist nicht für jeden sinnvoll, aber er zeigt, wie man viel erreichen kann. Hintergrund ist, dass vor allem die Vorhersage je nach Einstellung des OpenData-Devices relativ viele Readings aktualisiert. In den Standardeinstellungen generiert FHEM für jede Reading-Änderung ein Ereignis, dass dann von allen Beobachtungsmodulen (z.B. notify, DOIF) empfangen und geprüft wird. Wenn sich für ein Reading aber kein Modul interessiert, ist das nur Overhead. Daher kann man mit "event-on-update-reading" diese Ereignisgenerierung auf das Notwendige reduzieren. Bei mir macht das fast 2 Sekunden bei der Vorhersage-Aktualisierung aus.

Ich würde es begrüßen, wenn sich jemand die Mühe macht, die neue Version zu testen und nach ein paar Tagen Rückmeldung gibt.

Grüße,
Jens

[moskito]

Ach es hätte so schön sein können... 

Leider wird das neue Modul nicht geladen.

Code Auswählen Erweitern


2018.12.09 15:28:14 1: reload: Error:Modul 55_DWD_OpenData deactivated:
Experimental each on scalar is now forbidden at ./FHEM/55_DWD_OpenData.pm line 1300.


Code Auswählen Erweitern


This is perl 5, version 24, subversion 1 (v5.24.1)


und nach ein paar Tagen Rückmeldung gibt

So lange wollte ich dann doch nicht warten. 

Gruß
Danny

[jensb]

@moskito
Danke für die Rückmeldung, auf GitHub warte eine neue Version, der ich in den Zeile 1300 und 1344 noch ein zusätzliches %{} spendiert habe. Mein Perl (v5.14.2 + v5.22.1) sieht in beiden Versionen leider kein Problem. Ob die neue Version bei dir laufen wird, kann ich daher nicht sicher sagen.

Grüße,
Jens

[moskito]

Hallo Jens,

läuft wieder und macht einen guten Eindruck.
Werde dann mal weiter beobachten...

Besten Dank!

Gruß
Danny

[klausw]

Hallo Jens,

Eine Vorabversion des neusten OpenData-Moduls ist ab sofort auf GitHub verfügbar.

Ich würde es begrüßen, wenn sich jemand die Mühe macht, die neue Version zu testen und nach ein paar Tagen Rückmeldung gibt.

habe beide Dateien mal aufgespielt.
Macht einen guten Eindruck, keine Fehler, Aktualisierung klappt.

Obwohl es eines der Hautziele war, die Performance des Moduls zu verbessern, indem die Auslastungsdauer von FHEM pro Modulaktion verringert wird, liegt das größte Potential im Setzten des Attributs "event-on-update-reading" (z.B. auf "state,fc_time,a_time"). Diese Ansatz ist nicht für jeden sinnvoll, aber er zeigt, wie man viel erreichen kann. Hintergrund ist, dass vor allem die Vorhersage je nach Einstellung des OpenData-Devices relativ viele Readings aktualisiert. In den Standardeinstellungen generiert FHEM für jede Reading-Änderung ein Ereignis, dass dann von allen Beobachtungsmodulen (z.B. notify, DOIF) empfangen und geprüft wird. Wenn sich für ein Reading aber kein Modul interessiert, ist das nur Overhead. Daher kann man mit "event-on-update-reading" diese Ereignisgenerierung auf das Notwendige reduzieren. Bei mir macht das fast 2 Sekunden bei der Vorhersage-Aktualisierung aus.

Ich habe mich jetzt nicht im Detail mit der Datenaktualisierung befasst, vielleicht macht es aber Sinn im Modul (vielleicht auch nur teilweise) "readingsBulkUpdateIfChanged" einzusetzen.
Damit wird unabhängig der event-on-.* Attribute bei den entsprechenden Readings nur bei Änderung ein Event ausgelöst.

Klaus

[frank]

ich würde es begrüssen, wenn das event-verhalten der "norm" entspricht.

also, ohne event-attribute erzeugt dann jedes reading bei jedem update ein event. das kann dann jeder user bis auf 0 events drosseln.

das zusammenspiel der event-attribute ist eh schon tricky, wie man es im forum an jeder ecke sehen kann. unterschiedliches modulverhalten wird es sicher nicht verbessern.

[jensb]

@Klaus+ Frank
Es ging mir bei meiner Beschreibung der Nebenwirkungen nicht nur um das OpenData-Modul. Der Effekt tritt prinzipbedingt bei allen datenlastigen Modulen so auf.

Ich hatte mir die Möglichkeiten die Event-Flut zu bändigen schon länger durch den Kopf gehen lassen und die Varianten getestet. Am beruhigensten ist es natürlich, wenn man die Reading-Updates ohne Notifikation auslöst, dann reichen auch für ca. 100 Readings auf einem RPi ein paar Millisekunden. Allerdings bekommt man dann nichts mehr davon mit, selbst wenn man es will. Das Ganze über ein Modul-Attribut ein- und ausschaltbar machen ist nicht selektiv genug und der konfigurierbare Weg ist mit den even-on-Attributen bereits in FHEM vorhanden und muss nicht noch einmal im Modul nachgebaut werden. Auch die Variante readingsBulkUpdateIfChanged allein ist keine optimale Lösung für das OpenData-Modul. Die Wetterwarnungen werden sowieso immer gelöscht und neu geschrieben, da sich Anzahl und Reihenfolge beliebig ändern können. Und die Vorhersagedaten werden tagsüber aktualisiert, wo ein readingsBulkUpdateIfChanged Sinn machen würde, und zum Tageswechsel vollständig ersetzt, wo ein normales Update meiner Ansicht nach besser ist. Hier könnte man natürlich differenziert vorgehen. Mit einem event-on-... für 3 Readings hat es in meinem Test schon über 100 ms länger gedauert als ohne Notifikation und ganz ohne Filterung über 2000 ms.

Meine Bedenken gehen vor allem dahin, dass eine Reihe Anwender keine event-on-Attribute verwenden werden, obwohl sie es könnten, und sich dann aber wundern, dass z.B. bei einem Tastendruck nicht immer sofort etwas passiert. Dagegen kann man aber wohl nichts machen. Andererseits werden die Vorhersagedaten nur einmal pro Stunde aktualisiert. Die Trefferwahrscheinlichkeit ist also klein.

Danke für eure Rückmeldungen und Grüße,
Jens