Modul für DWD Open Data

Begonnen von jensb, 21 Januar 2018, 14:38:48

Vorheriges Thema - Nächstes Thema

smoothlife

Zitat von: KlaGho am 04 Juni 2024, 17:00:28Evtl. Musst du die korrigierte Version erst aus dem contrib Verzeichnis von ds_starter herunterladen.

Siehe #1064

Gruß gho

Oh :-\ , hab ich wohl überlesen

Zitat von: DS_Starter am 04 Juni 2024, 18:36:00
ZitatKann mir vielleicht jemand zusätzlich erklären was mit IODev gemeint ist?
Brauch ich dafür selbst etwas an bestimmter Hardware oder was muss ich da Eintragen?
IODev ist der Verweis auf die Datenquelle, also das DWD-Device welches du angelegt hast und die Daten liefert.
Du stellst in dem Attribut den Namen des DWD Devices ein.

Hast du nach def Definition des DWD dein FHEM mal restarted?

Ja ok, :-[  hab das falsche DWD-Device angegeben


Jetzt funktioniert alles, danke für die schnelle Hilfe an euch

Prof. Dr. Peter Henning

Zitat von: matze1999 am 30 Mai 2024, 18:23:39ist es möglich, die Größe der Gewitterwolke den anderen Wolken anzugleichen?
Fantastisch!  Endlich Wetterkontrolle!

 ;D

pah

FlyingPenguin

Hallo zusammen,

Ich finde leider nirgends eine Antwort auf meine Idee, daher versuche ich es hier. Wahrscheinlich stelle ich die Frage nicht richtig und komme daher nicht weiter.

Ich habe das Modul DWD Open Data installiert und konfiguriert (Station in der Nähe, forecastDays=0, forecastResolution=1) und erhalte pro Stunde einen Satz fc0_XX_yyy Forecast-Werte. Mit diesen möchte ich nun etwas steuern. Dazu suche ich eigentlich immer nur die Werte der aktuellen Stunde. Jetzt (12:46 Uhr) suche ich also fc0_12_yyy, der Rest interessiert mich nicht. Eigentlich brauche ich sogar nur fc0_12_ww und fc0_12_Neff.

Wie kann ich diese beiden Werte immer passend extrahieren?

300P

Schreib dazu etwas Code als ,,subxyxyxy" in eine deiner MyUtils die dir den gesuchten Wert für die aktuelle Stunde zurück gibt.

Geht ganz sicher auch anders - aber so verstehst du dann auch die Logik in FHEM und was dafür gemacht werden muss.
Aber - mit kleinen Schritten anfangen😉

FHEM 6.3 - Raspberry Pi 3 / Pi 4 - VControl300 mit VITOVALOR 300P - SMAEM - SMAInverter - DbLog/DbRep - MariaDB/QNAP - div. HTTPMOD - div. Modbus ser+TCP - SolarForecast - keine Batterieladung mehr mit SMA-SBS25 / LG Resu10H

tobi01001

Zitat von: FlyingPenguin am 28 Juli 2024, 12:49:28Hallo zusammen,

Ich finde leider nirgends eine Antwort auf meine Idee, daher versuche ich es hier. Wahrscheinlich stelle ich die Frage nicht richtig und komme daher nicht weiter.

Ich habe das Modul DWD Open Data installiert und konfiguriert (Station in der Nähe, forecastDays=0, forecastResolution=1) und erhalte pro Stunde einen Satz fc0_XX_yyy Forecast-Werte. Mit diesen möchte ich nun etwas steuern. Dazu suche ich eigentlich immer nur die Werte der aktuellen Stunde. Jetzt (12:46 Uhr) suche ich also fc0_12_yyy, der Rest interessiert mich nicht. Eigentlich brauche ich sogar nur fc0_12_ww und fc0_12_Neff.

Wie kann ich diese beiden Werte immer passend extrahieren?

Da das DWD Device nicht stündlich und nicht zur vollen Stunde aktualisiertz wird, brauchst du einen trigger um bei Wechsel der aktuellen Stunde die Werte neu zu "lesen".

Ein "at" mit Attribut alignTime bietet sich hier an.
In diesem at kannst du im Ausführungsteil entsprechende Readings beschreiben (userReadings gingen auch).

Beispiel
defmod at_dwd_current at +*01:00:00 {\
      use Time::Piece;;\
      my $current_hour = localtime->hour;;\
      my $ww = ReadingsVal("dein DWD Device","fc0_".$current_hour."_ww", "");;\
      my $Neff = ReadingsVal("dein DWD Device","fc0_".$current_hour."_Neff", "");;\
    \
    fhem("set $SELF fc0_ww_Now $ww");;\
    fhem("set $SELF fc0_Neff_Now $Neff");;\
}
attr at_dwd_current DbLogExclude .*
attr at_dwd_current alignTime 00:00
attr at_dwd_current setList fc0_ww_Now fc0_Neff_Now

FHEM@UbuntuServer on Lenovo ThinkCentre M900 [i5-6500T / 8GB RAM] MySQL-DbLog, Grafana, FTUI3 / HmIP incl. CCU3 / LGESS / Wärempumpe über TA CMI und CANoE / Shellies u.v.m.

FlyingPenguin

Zitat von: tobi01001 am 07 August 2024, 14:57:48Da das DWD Device nicht stündlich und nicht zur vollen Stunde aktualisiertz wird, brauchst du einen trigger um bei Wechsel der aktuellen Stunde die Werte neu zu "lesen".

Das war mir klar, mir war nur nicht klar, wie man den Trigger erzeugt.  O:-)

ZitatEin "at" mit Attribut alignTime bietet sich hier an.
In diesem at kannst du im Ausführungsteil entsprechende Readings beschreiben (userReadings gingen auch).

Perfekt, das tut genau das, was ich wollte und jetzt verstehe ich auch endlich, wie man Perl-Schnipsel direkt in FHEM einbinden kann ohne gleich ein eigenes Util zu schreiben. Vielen Dank!

Zwei kurze Rückfragen:
  • DbLogExclude gibt es bei mir nicht als Attribut. Im Dropdown ist es nicht verfügbar, und wenn ich versuche es direkt einzugeben erhalte ich nur "unknown attribute DbLogExclude" als Fehlermeldung. Einfach im RAW-Modus eintragen?
  • So wird das Attribut jede Stunde aktualisiert. Falls sich während der Stunde die Vorhersage ändert würde ich natürlich auch gerne den Wert aktualisieren. Ich nehme an, dazu muss ich die Bedingung des at (+*01:00:00) erweitern und auch bei einem Update des DWD Device ausführen lassen. Richtig?

tobi01001

1. Sorry, DbLogExclude kannst du weglassen. Das wird bei mir standardmäßig gesetzt, damit nicht jedes neue Device mit seinen Events in der Datenbank landet. Die Attribute gibt es aber nur bei Verwendung von DbLog.

2. Ja, das ist vom Ansatz richtig. at kann allerdings nur auf die eingestellte Zeit/Intervall reagieren. Die Änderung im DWD Device erzeugt für die entsprechenden Readings ein Event auf das du (zusätzlich) reagieren musst/möchtest.

Entweder:
  • ein at für den zyklischen Teil und
  • ein notify für Events vom zyklischen Teil und DWD-Device
Damit hättest du zwei triggernde Devices (at zyklisch und DWD bei Änderung) und ein entsprechendes notify was auf die trigger reagiert. Die gewünschten Readings schreibst du dann ins notify und kannst sie weiter verwenden.
Raw definition:
defmod notify_dwd_change notify at_dwd_current:.*|dein_DWD_Device:fc0_.*_Neff:.*|dein_DWD_Device:fc0_.*_ww:.* {\
use Time::Piece;;\
    my $current_hour = localtime->hour;;\
    my $ww = ReadingsVal("dein_DWD_Device","fc0_".$current_hour."_ww", "");;\
    my $Neff = ReadingsVal("dein_DWD_Device","fc0_".$current_hour."_Neff", "");;\
    \
    fhem("set $SELF fc0_ww_Now $ww");;\
    fhem("set $SELF fc0_Neff_Now $Neff");;\
}
attr notify_dwd_change setList fc0_ww_Now fc0_Neff_Now
attr notify_dwd_change stateFormat ww   fc0_ww_Now <br>\
Neff fc0_Neff_Now


defmod at_dwd_current at +*01:00:00 {}
attr at_dwd_current alignTime 00:00

Mit den Readings triggeredByDev und triggeredByEvent

Oder:
In einem DOIF lassen sich timer und events kombinieren und du hättest lediglich ein Device. Für das Verständnis von fhem und der Ereignissteuerrung ist die Kombination aus at und notify (zumindest aus meiner Sicht) besser geeignet.
FHEM@UbuntuServer on Lenovo ThinkCentre M900 [i5-6500T / 8GB RAM] MySQL-DbLog, Grafana, FTUI3 / HmIP incl. CCU3 / LGESS / Wärempumpe über TA CMI und CANoE / Shellies u.v.m.

FlyingPenguin

Zitat von: tobi01001 am 09 August 2024, 09:12:09Raw definition:
defmod notify_dwd_change notify at_dwd_current:.*|dein_DWD_Device:fc0_.*_Neff:.*|dein_DWD_Device:fc0_.*_ww:.* {\
    use Time::Piece;;\
    my $current_hour = localtime->hour;;\
    my $ww = ReadingsVal("dein_DWD_Device","fc0_".$current_hour."_ww", "");;\
    my $Neff = ReadingsVal("dein_DWD_Device","fc0_".$current_hour."_Neff", "");;\
    \
    fhem("set $SELF fc0_ww_Now $ww");;\
    fhem("set $SELF fc0_Neff_Now $Neff");;\
}
attr notify_dwd_change setList fc0_ww_Now fc0_Neff_Now
attr notify_dwd_change stateFormat ww   fc0_ww_Now <br>\
Neff fc0_Neff_Now


defmod at_dwd_current at +*01:00:00 {}
attr at_dwd_current alignTime 00:00

Das at bräuchte dann aber den Berechnungs-Code nicht mehr, sondern müsste nur einen Trigger setzen, z.B. das Update der Uhrzeit. Ansonsten würden die Werte ja zur vollen Stunde doppelt berechnet. Dazu die Bedingung im Notify entsprechend anpassen und den Code für die Werte aus dem at raus. Es wäre also kein at_dwd mehr, sondern ein at_vollestunde. Also nur im übertragenen Sinne, die Benamung ist ja völlig frei.

Und die Readings des notify kann ich in verschiedenen DOIFs weiterverwenden, richtig?

tobi01001

Zitat von: FlyingPenguin am 09 August 2024, 10:36:47Das at bräuchte dann aber den Berechnungs-Code nicht mehr, sondern müsste nur einen Trigger setzen, z.B. das Update der Uhrzeit. Ansonsten würden die Werte ja zur vollen Stunde doppelt berechnet. Dazu die Bedingung im Notify entsprechend anpassen und den Code für die Werte aus dem at raus. Es wäre also kein at_dwd mehr, sondern ein at_vollestunde. Also nur im übertragenen Sinne, die Benamung ist ja völlig frei.
Richtig, den Namen hatte ich nicht geändert, in der def ber nur {} angegeben (siehe raw definition).

Zitat von: FlyingPenguin am 09 August 2024, 10:36:47Und die Readings des notify kann ich in verschiedenen DOIFs weiterverwenden, richtig?
Ja klar, wobei sich die Frage stellt, was du damit vorhast. Eventuell kann man sich den Umweg sparen und das auch direkt im Notify machen?
FHEM@UbuntuServer on Lenovo ThinkCentre M900 [i5-6500T / 8GB RAM] MySQL-DbLog, Grafana, FTUI3 / HmIP incl. CCU3 / LGESS / Wärempumpe über TA CMI und CANoE / Shellies u.v.m.

Ralli

#1089
Heute habe ich meinen LXC-Container mit Ubuntu 22.04.4 LTS auf 24.04.1 LTS gehoben. Damit wird offensichtlich auch perl auf eine andere Version gehoben:

This is perl 5, version 38, subversion 2 (v5.38.2) built for x86_64-linux-gnu-thread-multi
(with 44 registered patches, see perl -V for more detail)

Danach bekomme ich u.a. durch das Modul DWD_OpenData Warning-Einträge im Log:

2024.09.04 07:53:06.119 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 892, <$fh> line 4272.
2024.09.04 07:53:06.119 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 894, <$fh> line 4272.
2024.09.04 07:53:06.119 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 906, <$fh> line 4272.
2024.09.04 07:53:06.119 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 916, <$fh> line 4272.
2024.09.04 07:53:06.119 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 922, <$fh> line 4272.
2024.09.04 07:53:06.119 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 927, <$fh> line 4272.
2024.09.04 07:53:06.119 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 937, <$fh> line 4272.
2024.09.04 07:53:06.119 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 939, <$fh> line 4272.
2024.09.04 07:53:06.119 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 943, <$fh> line 4272.
2024.09.04 07:53:06.119 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 949, <$fh> line 4272.
2024.09.04 07:53:06.119 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 952, <$fh> line 4272.
2024.09.04 07:53:06.119 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 955, <$fh> line 4272.
2024.09.04 07:53:06.120 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 988, <$fh> line 4272.
2024.09.04 07:53:06.120 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 1008, <$fh> line 4272.
2024.09.04 07:53:06.120 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 1024, <$fh> line 4272.
2024.09.04 07:53:06.120 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 1028, <$fh> line 4272.
2024.09.04 07:53:06.120 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 1031, <$fh> line 4272.
2024.09.04 07:53:06.120 1: PERL WARNING: when is deprecated at ./FHEM/55_DWD_OpenData.pm line 1034, <$fh> line 4272.
Gruß,
Ralli

Proxmox 8.3 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.79.6.20241122) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

mumpitzstuff

Da müsstest du woanders nachfragen glaube ich. Hier geht es um das DWD Modul.

Ralli

Danke, Threads vertauscht beim Posten 8) . Obiger Beitrag korrigiert.
Gruß,
Ralli

Proxmox 8.3 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.79.6.20241122) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

gent

Zitat von: jensb am 10 Januar 2024, 22:38:36
Zitat von: betateilchen am 09 Januar 2024, 20:34:08Eine Moduldatei, die über define ein device anlegt, sollte nicht mit 99_ beginnen.
Danke für den Hinweis, erklärt die z.T. merkwürdigen Fehler beim Start.

Habe das Modul in 98_DWD_OpenData_Weblink.pm umbenannt. Die neue Version 2.16.5 kann man von GitHub mit "Link-Ziel speichern unter ..." herunterladen. Altes Modul 98_DWD_OpenData_Weblink.pm aus dem FHEM-Unterordner löschen und in der FHEM-Kommandozeile "reload 98_DWD_OpenData_Weblink" eingeben, wenn man nicht neu starten will. Anpassung der Wiki folgt ...

Grüße,
Jens

Und dann kommt bei mir dieser Fehler:

DWD_OpenData_Weblink: device DWD_Weblink_Generator does not exist or is not a DWD_OpenData_Weblink module
Konnte nichts finden, das zur Lösung des Problems beiträgt. Was kann ich tun?
fhem auf rPi3 mit USB boot und M2, cul866 (hm), homebridge, FlowerSens, Shelly, Harmony, WemosD1, Sonoff/Tasmota, grafana, mqtt/mosquitto

DS_Starter

Hast du denn das Device DWD_Weblink_Generator wie im Wiki beschrieben definiert?:

define DWD_Weblink_Generator DWD_OpenData_Weblink
 attr DWD_Weblink_Generator IODev DWD
 attr DWD_Weblink_Generator forecastDays 4
 # refreshRate nur dann setzten, wenn der Browser Java-Script beherrscht:
 attr DWD_Weblink_Generator refreshRate 900
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

@all,

in meinem contrib liegt ein Update des DWD_OpenData Moduls.
Die forecast Daten des DWD werden jetzt im letzten Viertel der laufenden Stunde abgeholt (vorher im dritten Viertel).
Dadurch sollte gewährleistet sein dass der DWD seine aktualisierten Daten bereitgestellt hat.

Aufgefallen ist es hier. 'Eigentlich' ist die Aussage des DWD seine MOSMIX_S Daten ca. 20 Min nach der vollen Stunde zu aktualiseren was lange Zeit auch so funktioniert hat. Nun ist es ca. XX:40 wie es aussieht.

Durch die Änderung werden die aktuellen Daten des DWD abgerufen.

Grüße,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter