Der DWD stellt Werte der pro Tag gefallenen Regenmengen zur Verfügung, die auf Regenradar-Messungen beruhen und deren Werte an die gemessenen Mengen der Wetterstation angeeicht wurden. Die räumliche Auflösung beträgt dabei 1 km, was die Daten für diejenigen interessant macht, die keine eigene Regenmengenmessung zur Verfügung haben.
Ich habe für eigene Zwecke ein Perl-Programm geschrieben, das diese Daten vom DWD-ftp-Server liest und als reading zur Verfügung stellt. Es handelt sich nicht um ein FHEM-Modul, sondern eine utility-Routine, siehe Anhang. Das ganze ist noch etwas rudimentär (insbesondere das Abfangen möglicher Fehler könnte sicher noch besser werden), aber funktionsfähig. Zur Nutzung bitte die Kommentare am Anfang der Datei lesen.
Da dies mein erstes Perl-Programm ist, bitte ich a) um Nachsicht und b) ggf. um Tipps, wie man es besser machen könnte.
-Franz
Nachtrag 09. November 2023Basierend auf diesem Codeschnipsel hat JoWiemann (https://forum.fhem.de/index.php?action=profile;u=94) inzwischen ein ausgewachsenes Modul 98_CDCOpenData.pm (https://forum.fhem.de/index.php?action=dlattach;attach=174312;type=preview;file) erstellt.
Es liefert folgende Daten:
- die Regenmenge der letzten N Tage (N konfigurierbar, default 5); update täglich
- die Regenmenge seit Mitternacht; update stündlich
- die prognostizierten Regenintensitäten der nächsten 120 Minuten; update alle 5 Minuten
(siehe dazu auch diesen Beitrag) (https://forum.fhem.de/index.php?msg=1290038)
Die Werte werden für den akuellen 'Home'-Ort (soweit in global per latitude/longitude definiert) und für weitere konfigurierbare Orte in Deutschland und einigen angrenzenden Bereichen von Nachbarländern geliefert.
ZitatDa dies mein erstes Perl-Programm ist, bitte ich a) um Nachsicht und b) ggf. um Tipps, wie man es besser machen könnte.
Wegen a): dafuer ist es schon ganz ordentlich.
Wegen b):
- Net::FTP kann FHEM blockieren. Ich empfehle HttpUtils_NonblockingGet: https://wiki.fhem.de/wiki/HttpUtils#HttpUtils_NonblockingGet . Die Daten stehen auch per HTTP zur Verfuegung.
- beim Einlesen des Moduls wird ein Fehler gezeigt:
2023.08.13 11:09:37 1: PERL WARNING: Useless use of concatenation (.) or string in void context at ./FHEM/99_myDWDUtils.pm line 170.
2023.08.13 11:09:37 1: PERL WARNING: Useless use of a constant ("AutoClose") in void context at ./FHEM/99_myDWDUtils.pm line 170.- beim Aufruf der Funktion bekomme ich
Can't locate object method "now" via package "DateTime" (perhaps you forgot to load "DateTime"?)DateTime wird per Voreinstellung nicht geladen, das muss jedes Modul selber machen. Falls ein anderes Modul das vorher gemacht hat, dann hat man Glueck, davon sollte man aber nicht ausgehen. DateTime ist ein sehr umfangreiches Paket, und kann nicht immer einfach installiert werden: fuer einfachere Aufgaben verwende ich localtime/mktime oder die FHEM eigene Routinen time_str2num bzw. FmtDateTime.
Danke für die Hinweise, Rudolf!
Zitat von: rudolfkoenig am 13 August 2023, 11:22:16DateTime wird per Voreinstellung nicht geladen, das muss jedes Modul selber machen. Falls ein anderes Modul das vorher gemacht hat, dann hat man Glueck, davon sollte man aber nicht ausgehen.
Ich habe die Abhängigkeit von 'DateTime' beseitigt und den Dateianhang im ersten Beitrag aktualisiert.
Für die Umstellung auf HttpUtils_NonblockingGet werd ich aber noch etwas brauchen...
Hallo alkazaa,
eine sehr schöne Idee. Und, da werden ja noch einige Informationen mehr bereit gestellt, die ich gerne verfügbar machen wwürde. Ich war mal so frech und habe einen ersten nonBlocking Modulentwurf gebastelt. Feel free.
Das Ganze ist ein allererster Entwurf. Doku fehlt z.B.
Grüße Jörg
Zitat von: JoWiemann am 13 August 2023, 23:03:05...Ich war mal so frech und habe einen ersten nonBlocking Modulentwurf gebastelt....
Ich liebe Frechheit (wenn sie so daherkommt)!
Du hast Dein Modul 98_DWDopenData.pm genannt. Es gibt da aber noch das 55_DWD_OpenData.pm von jensb (kennst Du natürlich, im thread dazu hast Du ja mitdiskutiert). Könnte das nicht zur Verwirrung führen?
Mein Eindruck beim groben Überfliegen des threads zu 55_DWD_OpenData.pm war, dass es problematisch ist in der Nutzung. Außerdem nutze ich selbst das 59_Weather.pm mit OpenWeatherMapAPI für Vorhersagen (nur 'Wind', wegen Raffstore hochfahren). Ich wollte dann noch '(zuletzt gefallener) Regen' für eventuelle künftige Bewässerungsaktivitäten. Daher die Lösung mit dem 99_myDWDUtils.pm, die meinem Weather-device ein neues Reading 'Regen_gestern' "unterschiebt". Schien mir einfacher, als das evtl. problematische 55_DWD_OpenData.pm zu nutzen.
Weiter schriebst Du:
Zitat von: JoWiemann am 13 August 2023, 23:03:05...Und, da werden ja noch einige Informationen mehr bereit gestellt, die ich gerne verfügbar machen wwürde....
An welche hast Du da gedacht? Hilfe würd ich gern anbieten, aber Perl-mäßig kann ich Dir nicht das (Regen)Wasser reichen. Als Tester schon eher.
Beste Grüße
Franz
Hallo Franz,
55_DWD_OpenData.pm hatte ich nicht mehr auf dem Schirm. Der Name von mir war eher spontan und kann einfach geändert werden.
Dein Perl Code war doch schon recht anspruchsvoll. Die Moduleinbettung war für mich eher eine Übung in nonBlocking.
Im Verzeichnisbaum des DWD findet sich z.B. Umweltstrahlung.
Grüße Jörg
ich häng mich hier mal ran, damit ich nix verpasse.
Nachdem mein dritter Regenmengenmesser von TFA Dostmann nun auch gestorben ist und der W174 total ungenau ist, scheint mir das was hier entsteht ein gute Alternative zu sein.
Hallo und danke! :)
Ich habe es glatt auf meinem Testsystem mal ausprobiert, in meinem Fall mal die "Modul-Version"...
Musst zunächst "sudo apt-get install libnet-sslglue-perl" ausführen und rebooten...
...aber läuft.
Gut, ja war/ist ja angekündigt: keine Beschreibung bzw. sind noch Reste des Ursprungsmoduls (Fritzbox? ;) ) zu sehen...
Gut mit dem Einstellen eines Moduls kommen nat. auch Bedürfnisse (potentieller) Nutzer 8)
Ich würde gerne für einen Bekannten Regenmengen aufnehmen, allerdings wohnt der (nat.) wo anders...
Es werden aber ja (wohl) die Koordinaten aus global genommen (was prinzipiell ja schon mal schön ist), es gibt aber keine Möglichkeit (Attribut) das zu ändern?
Wollte schon einen Patch versuchen und habe beim "Reinschauen" gemerkt, dass man im Define auch andere Koordinaten angeben kann :)
Gemacht, getan... ;)
Läuft jetzt mal auf dem Testsystem mit :)
Gruß, Joachim
Hallo,
das FritzBox Modul, dass ich seit einiger Zeit verantworten darf, ist eine wirklich gut gemachte Vorlage für nonBlocking. Deswegen auch hier recycled.
Demnächst habe ich wieder etwas Zeit um die Doku zu pflegen und Ideen umzusetzen.
Grüße Jörg
Wenn ich helfen kann einfach melden :)
Danke, Joachim
Ich bin erst heute dazu gekommen, das Modul auszuprobieren. Lief nach der gleichen 'Extrarunde' (sudo apt-get install libnet-sslglue-perl) wie bei MadMax-FHEM dann auch bei mir. Andere Geo-Koordinaten beim define zu setzen hatte ich nicht mitbekommen, ist aber natürlich ganz wichtig. Noch besser würd ich's finden (jetzt geht die Wunschlistenorgie los), andere Orte als (User)Attribute anzulegen, oder beim 'set update' andere Koordinaten als optionale Parameter zu übergeben. Auch andere Tage für die Bestimmung der Regenmenge wären interessant, um z.B. mal nachzuschauen, was an einem bestimmten Tag und Ort denn so runterkam.
In meinem use-case rufe ich meine Utils-Funktion per at nur einmal täglich auf, und ich schiebe die ermittelte Regenmenge einem anderen device (eine ohnehin schon vorhandenes Weather-Modul) unter. Fand ich so für mich am sinnvollsten. Geht natürlich auch, indem man das mit JoWiemanns Modulreadings per at oder notify oder wie auch immer erledigt.
Ach ja, noch zur Namensgebung des Moduls: vielleicht wäre eine Name wie 98_CDCOpenData.pm die bessere Wahl?
Jedenfalls toll, dass sich ein Perl-Profi der Sache annimmt. Auch wenn dadurch meine Motivation gedämpft wird, rudolfkoenigs Hinweis auf HttpUtils_NonblockingGet nachzugehen und dabei etwas mehr Perl zu lernen...
Beste Grüße
Franz
Nachtrag: Hilfe biete ich auch gern an, jedenfalls wenn es darum geht, aus irgenwelchen kryptischen Binärdateien eine Information rauszudestillieren
Zitat von: alkazaa am 20 August 2023, 18:27:50Nachtrag: Hilfe biete ich auch gern an, jedenfalls wenn es darum geht, aus irgenwelchen kryptischen Binärdateien eine Information rauszudestillieren
Hallo Franz,
dass ist super, da es ja noch weitere interessante Daten, wie z.B. natürliche Strahlung, gibt. Mit dem Namen ist ein guter Vorschlag. Und Eure Wünsche finde ich gut. Jetzt fehlt noch Zeit.
Grüße Jörg
Hallo,
anbei eine neue Version. Anregungen ( wie 98_CDCOpenData.pm ) und kritische Hinweise gerne.
Die Doku ist jetzt einigermaßen komplett.
Grüße Jörg
Hallo Jörg,
bei mir stürzt FHEM leider ab, wenn ich "define myCDC CDCOpenData" ausführe:
Fehler: Verbindung fehlgeschlagen
Firefox kann keine Verbindung zu dem Server unter 192.168.188.22:8083 aufbauen.
Eins fiel mir noch auf (unabhängig vom define-Versuch): Nach 'reload 98_CDCOpenData.pm' steht diese Warnung im FHEM-log:
PERL WARNING: using SSL support of Net::FTP 3.11 instead of SSLGlue at /usr/share/perl5/Net/SSLGlue/FTP.pm line 16.
Gruß
Franz
Zitat von: alkazaa am 21 August 2023, 17:20:23Hallo Jörg,
bei mir stürzt FHEM leider ab, wenn ich "define myCDC CDCOpenData" ausführe:
Fehler: Verbindung fehlgeschlagen
Firefox kann keine Verbindung zu dem Server unter 192.168.188.22:8083 aufbauen.
Hallo Franz,
was steht denn im Fhem Log. Das sieht nach einem Absturz aus. Hast Du das alte Modul DWD... gelöscht und Fhem mit dem neuen neu gestartet?
Grüße Jörg
Zitat von: alkazaa am 21 August 2023, 17:20:23Eins fiel mir noch auf (unabhängig vom define-Versuch): Nach 'reload 98_CDCOpenData.pm' steht diese Warnung im FHEM-log:
PERL WARNING: using SSL support of Net::FTP 3.11 instead of SSLGlue at /usr/share/perl5/Net/SSLGlue/FTP.pm line 16.
Hm, ist nur eine Warnung. Auf welchem OS läuft Dein Fhem?
Grüße Jörg
Zitat von: JoWiemann am 21 August 2023, 17:56:06Hast Du das alte Modul DWD... gelöscht und Fhem mit dem neuen neu gestartet?
Ja
Zitat von: JoWiemann am 21 August 2023, 17:56:06was steht denn im Fhem Log. Das sieht nach einem Absturz aus.
Hab's nochmal wiederholt, mit global verbose=5. Hier die letzten Lebenszeichen:
(Die Meldung um 18:04:10 war noch von den normalen Abläufen. Zufällig das Weather-Modul, hängt aber wohl nicht mit dem was ab 18:04:14 passiert zusammen)
2023.08.21 18:04:10 4: Weather Wetter: Rearm new Timer
2023.08.21 18:04:14 5: POST /fhem HTTP/1.1
Host: 192.168.188.22:8083
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 79
Origin: http://192.168.188.22:8083
DNT: 1
Connection: keep-alive
Referer: http://192.168.188.22:8083/fhem?
Cookie: AuthToken=######################==
Upgrade-Insecure-Requests: 1
2023.08.21 18:04:14 4: WEB_192.168.188.20_53488 POST /fhem&fw_id=1692633712.44671&fwcsrf=csrf_369616195317322&cmd=define+myCDC+CDCOpenData; BUFLEN:0
2023.08.21 18:04:14 5: Cmd: >define myCDC CDCOpenData<
2023.08.21 18:04:14 5: Loading ./FHEM/98_CDCOpenData.pm
2023.08.21 18:04:14 1: PERL WARNING: Subroutine get_2bytes_from_binfile redefined at ./FHEM/98_CDCOpenData.pm line 978.
2023.08.21 18:04:14 1: PERL WARNING: Subroutine index_for_geo_position redefined at ./FHEM/98_CDCOpenData.pm line 993.
2023.08.21 18:04:14 1: PERL WARNING: using SSL support of Net::FTP 3.11 instead of SSLGlue at /usr/share/perl5/Net/SSLGlue/FTP.pm line 16.
2023.08.21 18:04:14 3: [myCDC | Define.118] - <latitude> was not provided and will be set to 53.91
2023.08.21 18:04:14 3: [myCDC | Define.125] - <longitude> was not provided and will be set to 11.42
Can't locate object method "new" via package "JsonMod::Cron" (perhaps you forgot to load "JsonMod::Cron"?) at ./FHEM/98_CDCOpenData.pm line 144.
(Zeichen nach AuthToken hab ich durch ### ersetzt)
Zitat von: JoWiemann am 21 August 2023, 17:57:12Hm, ist nur eine Warnung. Auf welchem OS läuft Dein Fhem?
pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
Ich hab's eben auch mal getestet.
Steht nicht viel im Log...
Zugegeben: ich habe weder die Devices noch die alte pm-Datei gelöscht... :-|
2023.08.21 18:14:24 1: PERL WARNING: Subroutine get_2bytes_from_binfile redefined at ./FHEM/98_CDCOpenData.pm line 978.
2023.08.21 18:14:24 1: PERL WARNING: Subroutine index_for_geo_position redefined at ./FHEM/98_CDCOpenData.pm line 993.
2023.08.21 18:15:01 3: [cdcRegenmenge | Define.118] - <latitude> was not provided and will be set to 49.4792629
2023.08.21 18:15:01 3: [cdcRegenmenge | Define.125] - <longitude> was not provided and will be set to 10.9857085
2023.08.21 18:15:02 1: Including fhem.cfg
2023.08.21 18:15:02 3: telnetPort: port 7072 opened
2023.08.21 18:15:02 3: WEB: port 8083 opened
Mache ich gleich...
Gruß, Joachim
Zitat von: alkazaa am 21 August 2023, 18:17:31Can't locate object method "new" via package "JsonMod::Cron" (perhaps you forgot to load "JsonMod::Cron"?) at ./FHEM/98_CDCOpenData.pm line 144.
Ok, dann weiß wo ich nochmal ran muss. Danke Dir
Zitat von: JoWiemann am 21 August 2023, 18:23:59Zitat von: alkazaa am 21 August 2023, 18:17:31Can't locate object method "new" via package "JsonMod::Cron" (perhaps you forgot to load "JsonMod::Cron"?) at ./FHEM/98_CDCOpenData.pm line 144.
Ok, dann weiß wo ich nochmal ran muss. Danke Dir
Anbei eine neue Version.
Grüße Jörg
Stürzt leider (bei mir) auch ab.
Folgendes im Log:
2023.08.21 18:50:00 3: [cdcRegenmenge | Define.117] - <latitude> was not provided and will be set to 49.0000000
2023.08.21 18:50:00 3: [cdcRegenmenge | Define.124] - <longitude> was not provided and will be set to 10.000000
Can't locate object method "new" via package "JsonMod::Cron" (perhaps you forgot to load "JsonMod::Cron"?) at ./FHEM/98_CDCOpenData.pm line 143.
2023.08.21 18:50:01 1: Including fhem.cfg
2023.08.21 18:50:01 3: telnetPort: port 7072 opened
2023.08.21 18:50:02 3: WEB: port 8083 opened
Gruß, Joachim
Zitat von: MadMax-FHEM am 21 August 2023, 18:52:24Stürzt leider (bei mir) auch ab.
Gruß, Joachim
Hallo Joachim,
auch mit der letzten Version aus Post: https://forum.fhem.de/index.php?msg=1284663
Grüße Jörg
Zitat von: JoWiemann am 21 August 2023, 19:07:57Zitat von: MadMax-FHEM am 21 August 2023, 18:52:24Stürzt leider (bei mir) auch ab.
Gruß, Joachim
Hallo Joachim,
auch mit der letzten Version aus Post: https://forum.fhem.de/index.php?msg=1284663
Grüße Jörg
Eigentlich ja...
Ist bei mir ja auch eine andere Zeile?
Ich downloade und kopiere usw. noch mal...
Sicher ist sicher...
EDIT: eben noch mal probiert... Leider bleibt es dabei...
2023.08.21 19:14:01 3: [cdcRegenmenge | Define.117] - <latitude> was not provided and will be set to 49.00000
2023.08.21 19:14:01 3: [cdcRegenmenge | Define.124] - <longitude> was not provided and will be set to 10.00000
Can't locate object method "new" via package "JsonMod::Cron" (perhaps you forgot to load "JsonMod::Cron"?) at ./FHEM/98_CDCOpenData.pm line 143.
2023.08.21 19:14:05 1: Including fhem.cfg
2023.08.21 19:14:05 3: telnetPort: port 7072 opened
Gruß, Joachim
Zitat von: JoWiemann am 21 August 2023, 19:07:57Zitat von: MadMax-FHEM am 21 August 2023, 18:52:24Stürzt leider (bei mir) auch ab.
Gruß, Joachim
Hallo Joachim,
auch mit der letzten Version aus Post: https://forum.fhem.de/index.php?msg=1284663
Grüße Jörg
Sorry, falsche Version hochgeladen.
Anbei eine neue.
Das define läuft schin mal durch. Danke!
-Franz
Jep, bei mir auch! :)
DANKE!!
Gruß, Joachim
Sieht alles sehr gut aus. Ich hab trotzdem mal dran "rumgespielt" und die Abhängigkeit vom DateTime package rausgeschmissen (war ein Rat von rudolfkoening).
Jörg, entscheide Du bitte, was genommen wird.
In der Datei habe ich einige Zeilen auskommentiert (die fangen mit #*# an) und in der jeweils nächsten Zeile die Rechnungen ohne DateTime eingefügt. Ich muss aber sagen, dass mir die ganzen Datums/Zeit-Umrechnungen in Perl bisschen unheimlich sind. Vermutlich geht's auch einfacher oder eleganter, aber es funktioniert bei mir.
Noch ein paar Informationen zu den Radolan Daten:
- Obwohl der DWD die Daten stündlich aktualisiert, und zwar jeweils mit der Regenmengensumme der letzten 24h, wollte ich die Regenmenge genau eines Kalendertages. Und die findet sich in der Radolan Datei mit der Kennung 21:50:00 (GMT Zeit, also 10 min vor Mitternacht in D)
- Andere sind aber vielleicht auch an den stündlichen Reports interessiert (die alle einen Zeitstempel HH:50:00 haben)
- Es gibt auch 'hourly' Daten, die alle 5 min (rollierend) aktualisiert werden. Fällt mir persönlich keine vernünftige Anwendung in der FHEM Welt für ein, aber wer weiß
- Die Aktualisierung auf dem DWD Server erfolgt mit ca. 30 Minuten Verzögerung
- Die Daten vergangener Jahre sind jeweils in tar.gz Dateien anderswo im DWD Verzeichnisbaum zusammengefasst.
Beste Grüße
Franz
Nachtrag 1: Meine Änderung OHNE das DateTime package hat noch Macken, hab's entfernt
Nachtrag 2: Macken sind beseitigt, Anhang ist wieder da
Hallo zusammen,
ich habe auch versucht das Modul zu definíeren und erhalte bei dem Versuch des Updates folgende Fehlermeldung:
2023.08.25 09:04:04 3: [Regenmenge | Set.261] - INFO: set Regenmenge update
2023.08.25 09:04:05 3: [Regenmenge | Readout_Run_FTP.436] - ################ get_Regenmenge called ################
2023.08.25 09:04:05 3: [Regenmenge | Readout_Run_FTP.455] - UTC targettime is 2023-08-24 21:59:59
2023.08.25 09:04:05 3: [Regenmenge | Readout_Run_FTP.485] - file raa01-sf_10000-2308242150-dwd---bin.gz on CDC ftp-server is nearest to targettime
2023.08.25 09:04:05 3: [Regenmenge | Readout_Run_FTP.492] - localname raa01-sf_10000-2308242150-dwd---bin
2023.08.25 09:04:05 3: [Regenmenge | Readout_Run_FTP.508] - Load new local file temp_radolan_data/raa01-sf_10000-2308242150-dwd---bin Net::FTP::I=GLOB(0x559f917400)
Can't locate object method "gunzip" via package "Net::FTP::I" at ./FHEM/98_CDCOpenData.pm line 511.
2023.08.25 09:04:59 1: [Regenmenge | Readout_Aborted.678] - Error: Timeout when reading DWD data.
Gunzip ist in der Version
gunzip (gzip) 1.10
Copyright (C) 2007, 2011-2018 Free Software Foundation, Inc.
installiert.
Die Tagesmenge enthält den Fehler das mit einem GMT+2 die Sommerzeit angenommen wird. Es sollte daher die reale Zeit genommen werden, Kennung 22:50:00
Gruß
Roman
Zitat von: romakrau am 25 August 2023, 09:08:01Die Tagesmenge enthält den Fehler das mit einem GMT+2 die Sommerzeit angenommen wird. Es sollte daher die reale Zeit genommen werden, Kennung 22:50:00
Hallo Roman,
welche Version vom Modul hast Du installiert. Die von Franz (alkazaa) angepasste?
Grüße Jörg
Zitat von: romakrau am 25 August 2023, 09:08:01Hallo zusammen,
ich habe auch versucht das Modul zu definíeren und erhalte bei dem Versuch des Updates folgende Fehlermeldung:
Can't locate object method "gunzip" via package "Net::FTP::I" at ./FHEM/98_CDCOpenData.pm line 511.
2023.08.25 09:04:59 1: [Regenmenge | Readout_Aborted.678] - Error: Timeout when reading DWD data.
Gunzip ist in der Version
gunzip (gzip) 1.10
Copyright (C) 2007, 2011-2018 Free Software Foundation, Inc.
installiert.
Hallo Roman,
mach bitte einmal ein "reload 98_CDCOpenData.pm" in der Fhem Web Kommandozeile. Ich habe auch ab und zu die Fehlermeldung, die dann noch einem reload weg ist. Habe aber im Moment keinen Ansatz, woran das liegen kann.
Grüße Jörg
Hallo Jörg,
Ich habe die letzte Version von Franz genommen.
Gruss Roman
Zitat von: romakrau am 25 August 2023, 09:08:01... Can't locate object method "gunzip" via package "Net::FTP::I" at ./FHEM/98_CDCOpenData.pm line 511. ...
Ich hatte das gunzip-Problem auch schon (allerdings auch auf nicht ganz reproduzierbare Weise) in meiner 99_myDWDUtils.pm Ur-Version. In den 98_CDCOpenData.pm Versionen ist es mir bisher nicht untergekommen.
"Geheilt" habe ich es in der 99_myDWDUtils.pm mit der Zeile
use IO::Uncompress::Gunzip qw(gunzip);einem Hinweis hier (https://stackoverflow.com/questions/39750536/gunzip-gz-file-in-perl) folgend.
ZitatGunzip ist in der Version
gunzip (gzip) 1.10
Copyright (C) 2007, 2011-2018 Free Software Foundation, Inc.
installiert.
Das kriege ich auch auf der Raspbian Kommadozeile. Das Betriebssystem-gunzip hat anscheinend mit dem perl-gunzip nichts zu tun.
ZitatDie Tagesmenge enthält den Fehler das mit einem GMT+2 die Sommerzeit angenommen wird. Es sollte daher die reale Zeit genommen werden, Kennung 22:50:00
Das versteh ich jetzt nicht: Wir haben doch jetzt in der Tat die MESZ Sommerzeit, mit MESZ=GMT+2. In London ist jetzt BST (British summer time), mit BST=GMT+1 (=MESZ-1).
Oder was seh ich da falsch?
Beste Grüße
Franz
Hallo Franz,
die Änderung kann ich jetzt nicht durchführen da ich nicht zu Hause bin. Das mit der Zeit ist immer wieder verwirrend.
21:50 GMT = 22:50 D-Realzeit = 23:50 MESZ
22:50 GMT = 23:50 D-Realzeit = 00:50 MESZ
Die Zeitangabe der Datei ist in GMT?!
Ansonsten muss du den Code immer wieder zur Zeitumstellung ändern.
Gruss Roman
Zitat von: romakrau am 25 August 2023, 15:58:34Hallo Franz,
die Änderung kann ich jetzt nicht durchführen da ich nicht zu Hause bin. Das mit der Zeit ist immer wieder verwirrend.
21:50 GMT = 22:50 D-Realzeit = 23:50 MESZ
22:50 GMT = 23:50 D-Realzeit = 00:50 MESZ
Die Zeitangabe der Datei ist in GMT?!
Ansonsten muss du den Code immer wieder zur Zeitumstellung ändern.
Gruss Roman
Die Zeitangaben der Radolan Dateien sind im UTC (früher GMT genannt), siehe diese Dokumentation (https://www.dwd.de/DE/leistungen/radolan/radolan_info/radolan_radvor_op_komposit_format_pdf.pdf;jsessionid=85B8D28D379B51D5A507D04E49970341.live21071?__blob=publicationFile&v=23).
Die Zeitumrechnungen in Perl haben mich an die Grenzen meines Verstandes gebracht (und ich bin nicht sicher, auf welche Seite der Grenze).
Daher bin ich auf das DateTime package verfallen, das angeblich die Sommerzeitprobleme sicher beherrscht.
Auf Anraten von rudolfkoenig weiter oben in diesem thread habe ich dann aber die DateTime Funktionen durch generische Perl Funktionen ersetzt, allerdings ohne die wirklich verstanden zu haben. Wie die Generika mit der Sommerzeit umgehen, muss ich noch rausfinden.
Als (abschreckendes?) Beispiel hier mal die Umrechnung der UTC-Zeitangabe aus der Radolan-Datei ($filetime) in einen FHEM-kompatiblen timestamp,
a) mit DateTime Funktionen:
$filetime->set_time_zone('Europe/Berlin')->strftime("%Y-%m-%d %H:%M:%S") b) mit generischen Perl Funktionen (so wie ich sie mir gebastelt habe, geht vermutlich/hoffentlich eleganter:
strftime("%Y-%m-%d %H:%M:%S",localtime($filetime+timelocal(localtime)-timelocal(gmtime)))Z.Zt. jedenfalls liefert timelocal(localtime)-timelocal(gmtime) den Wert 7200, und ich hoffe, dass es ab 30.Oktober wieder 3600 liefert
Hallo Franz,
wenn man sich in die Materie reinknien möchte, kann man das machen. DateTime ist zwar schwergewichtig, man kann aber auch nur Teile davon laden. In Fhem nutzen drei Module DateTime.
Du kannst Dir aber auch mal die Funktion, die Rudi bereit stellt ansehen. Vielleicht reichen ja auch die aus.
Grüße Jörg
ZitatDie Zeitumrechnungen in Perl haben mich an die Grenzen meines Verstandes gebracht (und ich bin nicht sicher, auf welche Seite der Grenze).
Das gleiche Gefuehl habe ich auch beim betrachten der Zeitumrechnungen im Modul :)
Wo kommt timelocal her?
Ich vermute, dass es das Gegenteil von localtime ist, damit waere timelocal(localtime) eine langsame Alternative zu time, da localtime ein "shortcut" fuer localtime(time) ist.
Die DateTime Konvertierung von gmt mit "Europe/Berlin" ist nur in Europa richtig, die andere Version ist besser.
Verwirrend ist mAn $filetime als Sekunden seit 1970 minus aktuellen, Sommerzeit abhaengigen UTC Offset zu speichern mit:
$filetime = timelocal(0,$5,$4,$3,$2-1,$1+2000);
Ich wuerde stattdessen
$filetime = fhemTimeGm(0,$5,$4,$3,$2-1,$1+100)
nehmen. Diesen Wert kann man mit
strftime("%Y-%m-%d %H:%M:%S",localtime($filetime))
ausgeben.
Zitat von: rudolfkoenig am 25 August 2023, 20:47:56ZitatDie Zeitumrechnungen in Perl haben mich an die Grenzen meines Verstandes gebracht (und ich bin nicht sicher, auf welche Seite der Grenze).
Das gleiche Gefuehl habe ich auch beim betrachten der Zeitumrechnungen im Modul :)
Wo kommt timelocal her?
Ich vermute, dass es das Gegenteil von localtime ist, damit waere timelocal(localtime) eine langsame Alternative zu time, da localtime ein "shortcut" fuer localtime(time) ist.
Da bin ich wohl paarmal falsch abgebogen...
ZitatDie DateTime Konvertierung von gmt mit "Europe/Berlin" ist nur in Europa richtig, die andere Version ist besser.
Verwirrend ist mAn $filetime als Sekunden seit 1970 minus aktuellen, Sommerzeit abhaengigen UTC Offset zu speichern mit:
$filetime = timelocal(0,$5,$4,$3,$2-1,$1+2000);
Ich wuerde stattdessen
$filetime = fhemTimeGm(0,$5,$4,$3,$2-1,$1+100)
nehmen. Diesen Wert kann man mit
strftime("%Y-%m-%d %H:%M:%S",localtime($filetime))
ausgeben.
OK, das hab ich jetzt so geändert. Die aktualisierte "DateTime'-freie Version ist im Anhang.
@Jörg/JoWiemann:
Danke nochmal für die tolle Umsetzung ins Modul!
Darüber hinaus: Ich hab gerade eine weitere subroutine 'rain_since_midnight' in Arbeit. Was sie tut, sagt der Name. Sie wertet dafür die 'hourly' Daten vom Server aus.
Falls Interesse besteht (stille Beobachter: bitte melden) schlage ich vor, dass beim 'set update' beide readings aktualisiert werden, amount-of-rain und rain-since midnight.
Ich selbst hätte noch den Wunsch (wäre aber nur das Sahnehäubchen), den verschiedenen locations einen sprechenderen Namen zu geben. Die Attribut-Definition könnte dann etwa so aussehen:
locations <ADorf:latitude,longitude> Bdorf:latitude,longitude .... Natürlich nur, wenn's nicht zuviel Aufwand ist.
Und nochwas: Ginge es, die amount-of-rain-time gleich als timestamp zu amount-of-rain hinzuzufügen. aber vielleicht läuft das irgendeiner internen FHEM Logik zuwider? Event-Generierung oder so?
Beste Grüße
Franz
Zitat von: alkazaa am 26 August 2023, 16:30:18Darüber hinaus: Ich hab gerade eine weitere subroutine 'rain_since_midnight' in Arbeit. Was sie tut, sagt der Name. Sie wertet dafür die 'hourly' Daten vom Server aus.
Falls Interesse besteht (stille Beobachter: bitte melden) schlage ich vor, dass beim 'set update' beide readings aktualisiert werden, amount-of-rain und rain-since midnight.
Für mich gekauft.
Zitat von: alkazaa am 26 August 2023, 16:30:18Ich selbst hätte noch den Wunsch (wäre aber nur das Sahnehäubchen), den verschiedenen locations einen sprechenderen Namen zu geben. Die Attribut-Definition könnte dann etwa so aussehen:
locations <ADorf:latitude,longitude> Bdorf:latitude,longitude .... Natürlich nur, wenn's nicht zuviel Aufwand ist.
Nehme ich auf die ToDo Liste
Zitat von: alkazaa am 26 August 2023, 16:30:18Und nochwas: Ginge es, die amount-of-rain-time gleich als timestamp zu amount-of-rain hinzuzufügen. aber vielleicht läuft das irgendeiner internen FHEM Logik zuwider? Event-Generierung oder so?
Hm, dass ist eher eine philosophische Frage. Ich persönlich versuche die Readings vom Namen her einfach zu halten, um weitere Auswertungen nicht zu kompliziert werden zu lassen. Ich glaube ich lasse dem Benutzer die Wahl un mache das über ein Attribut auswählbar.
Wir ein bisschen dauern, da diese Woche echt voll ist.
Grüße Jörg
Wollte nur eben mitteilen das Daten geladen werden. Mal schauen ob sich mit Hilfe des Statistiks Modul eine Aussage über einen Zeitraum von n-Tagen bauen lässt.
Hallo,
anbei eine neue Beta, basierend auf den letzten Änderungen von Franz.
Sowohl bei der Definition, als auch beim Attribut locations kann, getrennt durch Doppelpunkt, vor die Geowerte ein Name gesetzt werden.
Mit gesetztem Attribut datetimeInReadingName wird der Reading Name um den Zeitpunkt ergänzt. Default ist nicht gesetzt.
Hallo,
ein Nichtsetzen des Namen führt wohl zu einer Fehlermeldung. Meine Geo-Daten beziehe ich aus "global".
Gruß
Roman
Use of uninitialized value $geoRef in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 518.
Use of uninitialized value $geoRef in split at ./FHEM/98_CDCOpenData.pm line 527.
Zitat von: romakrau am 29 August 2023, 10:30:54Hallo,
ein Nichtsetzen des Namen führt wohl zu einer Fehlermeldung. Meine Geo-Daten beziehe ich aus "global".
Gruß
Roman
Use of uninitialized value $geoRef in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 518.
Use of uninitialized value $geoRef in split at ./FHEM/98_CDCOpenData.pm line 527.
Hallo Roman,
hast Du nur ein reload gemacht. Wenn ja, dann dürfte das Internal LOCATION nicht vorhanden sein und es entsteht Dein Fehler. Entweder FHEM neu starten oder das Device mit defmod <name> CDCOpenData erneuern.
Grüße Jörg
Danke Jörg!
Bei mir läuft es wie gewünscht. Ich habe allerdings einen FHEM-restart gemacht, damit loc0 durch Home ersetzt wurde.
In der Anwendung mache ich das allerdings nach wie vor so, dass ich meinem vorhanden Weather-device namens 'Wetter' die Werte einmal pro Nacht mit einem 'at' 'unterschiebe':
defmod Get_Regenmenge_gestern at *01:35 {\
fhem "setreading Wetter ".ReadingsVal("myCDC","Home-amount-of-rain-time",0)." Regen_gestern ".ReadingsVal("myCDC","Home-amount-of-rain",-1);;\
fhem "setreading Wetter ".ReadingsVal("myCDC","ADorf-amount-of-rain-time",0)." Regen_gestern_ADorf ".ReadingsVal("myCDC","ADorf-amount-of-rain",-1);;\
fhem "setreading Wetter ".ReadingsVal("myCDC","BDorf-amount-of-rain-time",0)." Regen_gestern_BDorf ".ReadingsVal("myCDC","BDorf-amount-of-rain",-1)}Diese Werte wandern dann in meine dblog-Datenbank.
Ich habe auch gesehen, dass Du ein Attribut numberOfDays vorgesehen hast. Ich hatte mir bereits für einen ähnlichen Zweck einen 'one-liner' für die FHEM-Kommandozeile gebastelt, der mir für ein gewünschtes Datums-Intervall die Werte nachträglich holt und ins 'Wetter'-device schreibt. Auch die wandern auf dem Weg dann in die dblog Datenbank. So sieht der one-liner aus (der Leserlichkeit wegen mit '\' als multi-liner geschrieben):
{\
my $day1=time_str2num("2023-01-01");;\
my $dayN=time_str2num("2023-01-31");;\
my $day;;\
my $result;;\
my $thisday=$day1;;\
while ($thisday <= $dayN) {\
$day=strftime("%Y-%m-%d",localtime($thisday));;\
$result = fhem "get myCDC rainbyDate $day";;\
$result =~ /.*Home:(.*):\s(.*)/;;\
fhem "setreading Wetter ".$1." Regen_gestern ".$2;;\
$thisday += DAYSECONDS};;\
$result =~ /.*Home:(.*):\s(.*)/;;\
"Tägliche Regenmengen von ".strftime("%Y-%m-%d",localtime($day1))." bis ".strftime("%Y-%m-%d",localtime(time_str2num($1)))." eingelesen";;\
}In diesem Beispiel holt er alle Januar-Werte ab. Dauerte 18 sec. Ruft man das dann nochmal auf geht's etwas schneller, da das Übertragen und Unzippen der 31 Dateien wegfällt: 12 sec.
Aus Neugier habe ich dann auch den Zeitraum 2023-03-25 bis 2023-03-26 übertragen, in den die Sommerzeitumstellung fiel.
-rw-r--r-- 1 fhem dialout 1620267 Aug 29 12:13 raa01-sf_10000-2303252250-dwd---bin
-rw-r--r-- 1 fhem dialout 1620267 Aug 29 12:13 raa01-sf_10000-2303262150-dwd---binWie man sieht, wechselt im temp_radolan_data-Verzeichnis der timestamp im Dateinamen brav von '2303252250' auf '2303262150'
Hallo Franz,
ich bin dabei von hermannj aus dem Modul JsonMod die Möglichkeit einer Intervall Definition basierend auf der Linux cron Definition einzubauen. Dauert noch ein bisschen. Dann kann auch eine Uhrzeit vorgegeben werden.
Grüße Jörg
Die neue sub rain_since_midnight() ist soweit fertig, aber Integration ins 98_CDCOpenData.pm hab ich mich nicht getraut. Anbei daher nur eine aktualisierte 99_myDWDUtils.pm mit der rain_since_midnight Routine.
rain_since_midnight liefert die aufsummierten Regenmengen aus den 'hourly' Radolan Dateien nur für den aktuellen Tag, an dem sie aufgerufen wird. Ausgewertet werden die Dateien, die für 00:50, 01:50 usw. an dem Tag veröffentlicht wurden.
Beste Grüße
Franz
Edit:
Fehler in 99_myDWDUtils.pm korrigiert (s. Variable $most_recent_filetime)
Hallo,
aktueller Stand für das Modul:
- rain_since_midnight habe ich integriert und teste gerade
- Ausführung per CRON Systematik, siehe auch Modul jsonmod ist in der Mache
. neues Attribut für das Ablegen der tmp DWD Daten in ein selbst vorgegebenes Verzeichnis
- neues Attribut um Funktionen, aktuell rain_since_midnight und tägliche Regenmenge, Ab-/Anwählen zu können
Grüße Jörg
Hallo Jörg,
ich hänge eine Variante von "sub CDCOpenData_Readout_Run_FTP" an, in welcher der Name der benötigten Datei (raa01-sf_10000-YYMMDD2350-dwd---bin für das Datum 20YY-MM-DD) auf weniger komplizierte Weise ermittelt wird. Da der CDC OpenData Server Daten seit 2006 bereit stellt und die Dateinamenskonvention seitdem nicht geändert wurde, scheint mir das relativ risikolos.
Mit diesem Dateinamen wird zunächst im temp_radolan_data Verzeichnis geschaut, ob's die Datei schon gibt und ggf. die ganze ftp-Kommunikation unnötig ist.
Vorteil:
Wer an historischen Daten interessiert ist, z.B. für eigene "amateur-meteorologische" Zwecke, kann sich händisch aus den *.tar.gz Dateien des CDC Servers die entsprechenden historischen Daten ins temp_radolan_data Verzeichnis laden und danach mit 98_CDCOpenData.pm und zusätzlichem perl-scripting diese Daten in eine dbLog Datenbank bringen. Damit stehen dann viele Möglichkeiten für weitere Auswertung und Visualisierung zur Verfügung.
Details und Anleitungen für ein solches Vorgehen würde ich dann im FHEM-Wiki hinterlegen. Begonnen damit habe ich schon (https://wiki.fhem.de/wiki/CDCOpenData).
-Franz
Zitat von: alkazaa am 18 September 2023, 15:32:49Hallo Jörg,
ich hänge eine Variante von "sub CDCOpenData_Readout_Run_FTP" an, in welcher der Name der benötigten Datei (raa01-sf_10000-YYMMDD2350-dwd---bin für das Datum 20YY-MM-DD) auf weniger komplizierte Weise ermittelt wird. Da der CDC OpenData Server Daten seit 2006 bereit stellt und die Dateinamenskonvention seitdem nicht geändert wurde, scheint mir das relativ risikolos.
Hallo,
anbei eine Version, in der ich die Änderungen von Franz eingebaut habe.
Außerdem die neuen Attribute:
tmpRadolanData => Festlegen eines eigenen TMP Verzeichnisses
disableMidNight:0,1 => abholen der Regenmenge seit Mitternacht abschalten
disableDayRain:0,1 => abholen der Tages Regenmenge abschalten
Das Ganze ist noch nicht ganz rund. Das get ... rainsincemidnight-bydate funktioniert noch nicht.
Die commandRef ist noch nicht angepasst und es gibt noch viele Log Einträge.
Bitte Fhem neu starten. Ein reload reicht nicht aus.
Grüße Jörg
Danke Jörg. Das war ja flott!
Ich habe noch einen Fehler korrigiert, und zwar war in Zeile 825-836 nicht $tmpDir genutzt, sondern das alte hard-coded 'tmp_radolan_data':
if (defined $retr_fh) {
CDCOpenData_Log $name, 3, "Trying to load new local file /$tmpDir/$localname " . $retr_fh
} else {
CDCOpenData_Log $name, 3, "ERROR: ftp /$remotename not found";
$ftp->quit;
$returnStr .= "ERROR: ftp /$remotename not found";
return $returnStr;
}
# use it to gunzip the remote file:
gunzip $retr_fh => "$tmpDir/" . $localname, AutoClose => 1 ;
CDCOpenData_Log $name, 3, "INFO: Loaded new local file /$tmpDir/$localname";Zitat von: JoWiemann am 19 September 2023, 20:27:51Das Ganze ist noch nicht ganz rund. Das get ... rainsincemidnight-bydate funktioniert noch nicht.
rainsincemidnight-bydate macht mMn keinen Sinn: die Funktion sollte nur die Regenmengen liefern, die seit dem letzten 'daily-rain' report z
ur Zeit des Aufrufs der Funktion gefallen sind. Für ne Bewässerungssteuerung ist das hilfreich. Für zurückliegende Tage kriegt man ja die Gesamtmenge ohnehin geliefert.
Gruß
Franz
Hallo,
anbei eine neue Version. Fehler korrigiert.
@Franz,
ausgehend, dass die Dateinamen Datum/Uhrzeit in MEZ/MESZ beinhalten habe ich alles auf timelocal angepasst. Es gab da ein paar Umwandlungen in gmt und andere im local. Dadurch wurden bei rain since midnight noch die beiden letzten Dateien des Vortages verarbeitet.
Das get ... rainsincemidnight-bydate ist nur noch ein get ... rainsincemidnight. Die Rückgabewerte aller get habe ich auf location:Datum Uhrzeit:Regenmenge angepasst. Mehrere Locationen werden durch | getrennt.
Grüße Jörg
Hallo und Danke!
Es funktioniert alles soweit, bis auf dies:
Zitat von: JoWiemann am 20 September 2023, 15:06:20Dadurch wurden bei rain since midnight noch die beiden letzten Dateien des Vortages verarbeitet.
Die letzten beiden Dateien des Vortags sind richtig, denn die im Dateinamen enthaltenen Zeitstempel sind GMT Zeiten.
Beispiel: Als ich heute um ca. 15:48 ein 'set update' machte, standen danach im temp_radolan Verzeichnis diese Dateien:
raa01-rw_10000-2309200050-dwd---bin
raa01-rw_10000-2309200150-dwd---bin
raa01-rw_10000-2309200250-dwd---bin
raa01-rw_10000-2309200350-dwd---bin
raa01-rw_10000-2309200450-dwd---bin
raa01-rw_10000-2309200550-dwd---bin
raa01-rw_10000-2309200650-dwd---bin
raa01-rw_10000-2309200750-dwd---bin
raa01-rw_10000-2309200850-dwd---bin
raa01-rw_10000-2309200950-dwd---bin
raa01-rw_10000-2309201050-dwd---bin
raa01-rw_10000-2309201150-dwd---bin
raa01-rw_10000-2309201250-dwd---binIn MESZ sind das die Dateien von 02:50 bis 14:50 (2 Stunden weiter als GMT). Es fehlen also die Dateien
raa01-rw_10000-2309192250-dwd---bin für MESZ 00:50
raa01-rw_10000-2309192350-dwd---bin für MESZ 01:50Diese Besonderheit der GMT-basierten Zeiten in den Radolan Daten hat ja leider die ganze GMT<->local Gymnastik erforderlich gemacht.
Man siehts auch an der für die daily-rain Daten zutändigen Datei
raa01-sf_10000-2309192150-dwd---bin für MESZ 23:50 vom Vortag im temp-radolan Verzeichnis.
Grüße
Franz
Zitat von: alkazaa am 20 September 2023, 16:08:57Hallo und Danke!
Es funktioniert alles soweit, bis auf dies:
Zitat von: JoWiemann am 20 September 2023, 15:06:20Dadurch wurden bei rain since midnight noch die beiden letzten Dateien des Vortages verarbeitet.
Die letzten beiden Dateien des Vortags sind richtig, denn die im Dateinamen enthaltenen Zeitstempel sind GMT Zeiten.
Grüße
Franz
Ok, dann mache ich Rolle rückwärts.
Hallo,
es läuft, aber noch nicht ganz rund. Nach einer device definition (locations anonymisiert) mit z.B.
defmod myCDC CDCOpenData
attr myCDC INTERVAL 3500
attr myCDC event-on-change-reading .*
attr myCDC locations C:x1,y1 S:x2,y2 B:x3,y3 T:x4,y4ergeben sich die readings wie im angehängten Bild 1. Für die meisten locations taucht _since_midnight-amount-of-rain korrekt auf, für manche (in diesem Beispiel für Ort C) taucht aber nur C_since_midnight-amount-of-rain-time mit einem timestamp als Wert auf. Es scheint zufällig zu sein, bei welcher location das passiert. Eine Ausführung von 'get rainSinceMidnight' z.B. kann das dann auch so ändern wie in Bild 2 gezeigt. Scheint alles irgendwie zufällig zu passieren.
Gruß
Franz
Moin,
gleiches Problem bei mir. Ich habe allerdings die Location in Global definiert.
Ich bekomme nur folgende Readings: Home_day_rain-amount-of-rain, Home_day_rain-amount-of-rain-time, Home_since_midnight-amount-of-rain-time
Gruss
Enno
Zitat von: alkazaa am 21 September 2023, 21:33:44Hallo,
es läuft, aber noch nicht ganz rund. Nach einer device definition (locations anonymisiert) mit z.B.
defmod myCDC CDCOpenData
attr myCDC INTERVAL 3500
attr myCDC event-on-change-reading .*
attr myCDC locations C:x1,y1 S:x2,y2 B:x3,y3 T:x4,y4ergeben sich die readings wie im angehängten Bild 1. Für die meisten locations taucht _since_midnight-amount-of-rain korrekt auf, für manche (in diesem Beispiel für Ort C) taucht aber nur C_since_midnight-amount-of-rain-time mit einem timestamp als Wert auf. Es scheint zufällig zu sein, bei welcher location das passiert. Eine Ausführung von 'get rainSinceMidnight' z.B. kann das dann auch so ändern wie in Bild 2 gezeigt. Scheint alles irgendwie zufällig zu passieren.
Gruß
Franz
Hallo Franz,
das Phänomen habe ich auch. Ich schreibe ins Log den Rückgabestring für die Überführung ins Reading. Schau bitte, ob der String auffällig ist.
Bin aktuell die nächsten Tage wandern. Wird also erst ab 03.10 wieder was.
Grüße Jörg
Hallo Jörg,
Was das merkwürdige Verhalten angeht: mir fiel beim Blick ins log auf, dass jedesmal alle readings mit 'since_midnight' im Namen gelöscht werden, und auch jedesmal wieder neu angelegt. Die Reihenfolge, in der das passiert, ist aber jedesmal eine andere.
Als workaround habe ich die Zeilen 1020-1021, in denen das Löschen passiert, auskommentiert. Dann scheint es zu funktionieren. Ich hoffe, es hat keine Nebenwirkungen.
Was war überhaupt der Grund, die since_midnight readings immer wieder zu löschen?
Aber keine Eile mit der Antwort bitte, sondern erstmal viel Spaß beim Wandern! Und natürlich das passende "indian summer" Wetter dazu!
Gruß
Franz
Zitat von: alkazaa am 22 September 2023, 20:53:37Was war überhaupt der Grund, die since_midnight readings immer wieder zu löschen?
Hallo Franz,
aus meiner Sicht ist _since_midnight nur für den aktuellen Tag sinnvoll. Wird es nicht gelöscht kommen unendlich viele Readings dazu. Auch bei den _day_rain Readings möchte ich eine Begrenzung auf x Tage, kann über eine Attribut gesteuert werden, begrenzen.
Anbei erst einmal eine neue Version, in der das komische Verhalten nicht mehr aufkommt. Das Problem war das Leerzeichen im Reading Namen. Ist nicht zulässig. Außerdem habe ich das Attribut cronTime einegführt. Wird dieses, basierend auf den Regeln von Cron, gesetzt, dann ist INTERVALL deaktiviert und es gilt die Cron Regel.
Grüße Jörg
Zitat von: JoWiemann am 17 Oktober 2023, 14:03:25aus meiner Sicht ist _since_midnight nur für den aktuellen Tag sinnvoll. Wird es nicht gelöscht kommen unendlich viele Readings dazu
OK, klar. Ich hatte das datetimeInReadingName Attribut nicht auf dem Schirm...
Ich habe übrigens noch ein weiteres Gimmick in Arbeit, lasse Dich also noch nicht in Ruhe ;-)
-Franz
Zitat von: alkazaa am 18 Oktober 2023, 10:39:10Ich habe übrigens noch ein weiteres Gimmick in Arbeit, lasse Dich also noch nicht in Ruhe ;-)
Hallo Franz,
da bin ich mal gespannt. Ich fände auch die aktuellen Daten zur Umweltstrahlung interessant.
Grüße Jörg
Was genau meinst Du mit Umweltstrahlung? Solar/UV? Ionisierende (z.B. Radon) doch wohl eher nicht.
Weißt Du vielleicht die Kennung des betreffenden DWD-Produkts?
Gruß
Franz
Zitat von: alkazaa am 18 Oktober 2023, 16:43:34Was genau meinst Du mit Umweltstrahlung? Solar/UV? Ionisierende (z.B. Radon) doch wohl eher nicht.
Weißt Du vielleicht die Kennung des betreffenden DWD-Produkts?
Hallo Franz,
ich dachte an: /climate_environment/CDC/grids_germany/daily/hyras_de/radiation_global/
Grüße Jörg
Hallo Jörg,
Zitat von: JoWiemann am 20 Oktober 2023, 10:52:25ich dachte an: /climate_environment/CDC/grids_germany/daily/hyras_de/radiation_global/
Das schaue ich mir dann mal als nächstes an.
Mein angekündigtes 'Gimmick' ist eine Darstellung der DWD-Regenradar-Vorhersagedaten für einen (oder mehrere) Orte als Liniengraphik. Ich wollte eigentlich den von der DWD-App gezeigten Zeitverlauf hier als Movie zeigen, das klappte aber nicht. Daher nur 3 Aufnahmen aus dem Movie:
Leipzig12-55.png Leipzig13-55.png Leipzig14-40.png
Die vorhergesagten Regenmengen sehen dann für den hier gewählten Ort Leipzig als SVG-Graphik so aus:
SVG-Regenradar.png
Das ganze ist mit der subroutine sub get_RegenRadar_atLocations($) in der beiliegenden 99_myDWDUtils.pm erzeugt und dann in FEHM mit dem code
{open my $fh, '>', "/opt/fhem/log/Regenradar.log";; print $fh get_RegenRadar_atLocations("Leipzig:51.319,12.393");;close $fh} in eine LogDatei geschrieben, die vom SVG-Plot dargestellt wird. Im SVG-Plot sind diese Attribute gesetzt:
attr SVG_RegenRadarLog_1 endPlotNow 1
attr SVG_RegenRadarLog_1 fixedoffset 2
attr SVG_RegenRadarLog_1 fixedrange 2hoursWichtig wäre (wenn Du Zeit dafür fändest) ein Einbinden in NonBlocking-Form in die 98_CDCOpenData.pm, denn das herunterladen, unzippen und un-taren dauert 3 sec (obwohl alles in-memory passiert). Die DWD Daten werden übrigens alle 5 Minuten aktualisiert.
Ach ja: die "sub my_index_for_geo_position ($$$)" musste erweitert werden, da die Regenradar-Daten in einem anderen Raster mit einer anderen Kartenprojektion vorliegen.
Beste Grüße
Franz
Zitat von: JoWiemann am 20 Oktober 2023, 10:52:25ich dachte an: /climate_environment/CDC/grids_germany/daily/hyras_de/radiation_global/
bist Du sicher, dass Du die meinst? Diese Daten stehen ja nur bis Ende 2020 zur Verfügung.
Aktuelle radiation_global Daten im 1km x 1km Raster stehen wohl nur als Monatsdaten in /climate_environment/CDC/grids_germany/monthly/radiation_global/ zur Verfügung.
Gruß
Franz
Zitat von: alkazaa am 20 Oktober 2023, 20:58:36Zitat von: JoWiemann am 20 Oktober 2023, 10:52:25ich dachte an: /climate_environment/CDC/grids_germany/daily/hyras_de/radiation_global/
bist Du sicher, dass Du die meinst? Diese Daten stehen ja nur bis Ende 2020 zur Verfügung.
Hallo Franz,
ups. Habe ich übersehen.
Grüße Jörg
Hallo,
anbei eine neue Version. Es gibt jetzt das Attribut numberOfDays. Damit werden die Readings *_day_rain... auf 1..10 Einträge begrenzt. Ansonsten wird das eine Endlosliste. Default ist 5 Einträge.
Grüße Jörg
Zitat von: JoWiemann am 24 Oktober 2023, 14:37:52anbei eine neue Version.
Danke, Jörg!
Ich würd mich übrigens freuen, wenn Du die Regenradar-Geschichte bei Gelegenheit auch ins Modul integrieren würdest. Vielleicht brauchst Du da noch etwas mehr Info als in meinem letzten Beitrag enthalten. Meld Dich einfach, gern auch mit PN.
Beste Grüße
Franz
Zitat von: alkazaaquote author=alkazaa link=msg=1290486 date=1698164838]
Ich würd mich übrigens freuen, wenn Du die Regenradar-Geschichte bei Gelegenheit auch ins Modul integrieren würdest.
Beste Grüße
Franz
Hallo Franz,
ich schaue mir das die Tage an. Wollte aber erst eine erste stabile und hoffentlich Fehler freie Version haben.
Grüße Jörg
Zitat von: alkazaa
quote author=alkazaa link=msg=1290486 date=1698164838]
Ich würd mich übrigens freuen, wenn Du die Regenradar-Geschichte bei Gelegenheit auch ins Modul integrieren würdest.
Beste Grüße
Franz
Hallo Franz,
anbei eine Version mit Regen Radar.
Das zugehörige FileLog ist wie folgt zu definieren:
Bitte <deinDWD Device> entsprechend ersetzen.
defmod FileLog_DWD_Regen_Radar FileLog ./log/DWD_Regen_Radar-%Y-%m.log <deinDWD Device>:Home_rain_radar:.*
attr FileLog_DWD_Regen_Radar outputFormat { return $1 . " " . $NAME ." " . $EVENT . "\n" if $EVENT =~ /radar:(\d\d\d\d-\d\d-\d\d_\d\d:\d\d:\d\d)/;; return $TIMESTAMP . " " . $NAME ." " . $EVENT . "\n";; }
Da ich nicht im Modul ein FileLog schreiben möchte, habe ich im FileLog Device ein outputFormat hinterlegt, durch das der Reading-Zeitstempel durch den DWD-Zeitstempel ersetzt wird.
Bitte auch das neue Attribut:
attr <name> enableDWDdata <rainByDay, rainSinceMidnight, rainRadarbyLocation>
Anwählen, welche Daten periodisch abgeholt werden. In der Standardeinstellung werden keine Daten vom DWD abgeholt.
beachten. Sonst gibt es keine Daten.
und das neue Attribut clearFileLog:
attr <name> clearFileLog <name of FileLog device>
Wenn gesetzt wird das FileLog des FileLog Device bei einem Update Regen Radar geleert
Macht nur Sinn für FileLogs, die die Daten des Regen Radars für eine Grafik verwenden
Grüße Jörg
Hallo,
anbei eine neue Version. Da war noch ein Fehler beim Löschen eines Device.
Außerdem das neue Attribut: RainRadarFileLog <FileLogName>
Mit dem Attribut wird ein neues FileLog Device mit <FileLogName> angelegt. Ist noch experimentel-
Das Attribut clearFileLog habe ich in clearRadarFileLog umbenannt.
Grüße Jörg
Hallo,
anbei einen neue Version:
- beim Erzeugen des RainRadarFileLog <FileLogName> wird romm/group mit übernommen
- beim Löschen des CDCOpenData Device wird auch das temporäre Verzeichnis gelöscht
Grüße Jörg
Hallo,
anbei eine neue Version.
Fehler bei CRON behoben, die zu mehrfachen internaltimer aufrufen führten.
Grüße Jörg
Hallo,
und noch eine neue Version.
Neues Attribut:
attr <name> updateOnStart <0 | 1>
Wenn gesetzt und der CRON Timer ist aktiv, dann werden die Daten direkt nach der Definition oder Start von Fhem geholt. Ansonsten mit Ablauf des Timers.
Hallo Jörg,
bei der update-Frequenz wird einem ja schwindlig! Ich komme mit dem Testen kaum nach.
Aber immerhin, eine Sache, die nicht ganz richtig ist, hab ich gefunden (das, was klappt, melde ich jetzt erstmal nicht ;) ):
bei den log-File Daten sind die time-stamps nicht zeitlich geordnet, was im SVG-Plot dann so aussieht:Unbenannt-1.png
Das ist die log-Datei (in Stuttgart hats geregnet):
2023-10-26_22:35:00 myCDC Stutt_rain_radar:2023-10-26_22:35:00: 0.1
2023-10-26_21:55:00 myCDC Stutt_rain_radar:2023-10-26_21:55:00: 0.11
2023-10-26_22:50:00 myCDC Stutt_rain_radar:2023-10-26_22:50:00: 0.05
2023-10-26_21:30:00 myCDC Stutt_rain_radar:2023-10-26_21:30:00: 0.04
2023-10-26_21:40:00 myCDC Stutt_rain_radar:2023-10-26_21:40:00: 0.05
2023-10-26_22:20:00 myCDC Stutt_rain_radar:2023-10-26_22:20:00: 0.17
2023-10-26_21:35:00 myCDC Stutt_rain_radar:2023-10-26_21:35:00: 0.05
2023-10-26_21:45:00 myCDC Stutt_rain_radar:2023-10-26_21:45:00: 0.08
2023-10-26_22:15:00 myCDC Stutt_rain_radar:2023-10-26_22:15:00: 0.19
2023-10-26_21:00:00 myCDC Stutt_rain_radar:2023-10-26_21:00:00: 0.03
2023-10-26_22:05:00 myCDC Stutt_rain_radar:2023-10-26_22:05:00: 0.13
2023-10-26_21:50:00 myCDC Stutt_rain_radar:2023-10-26_21:50:00: 0.11
2023-10-26_21:15:00 myCDC Stutt_rain_radar:2023-10-26_21:15:00: 0.03
2023-10-26_22:30:00 myCDC Stutt_rain_radar:2023-10-26_22:30:00: 0.14
2023-10-26_21:05:00 myCDC Stutt_rain_radar:2023-10-26_21:05:00: 0.02
2023-10-26_21:25:00 myCDC Stutt_rain_radar:2023-10-26_21:25:00: 0.03
2023-10-26_22:00:00 myCDC Stutt_rain_radar:2023-10-26_22:00:00: 0.12
2023-10-26_22:55:00 myCDC Stutt_rain_radar:2023-10-26_22:55:00: 0.05
2023-10-26_22:10:00 myCDC Stutt_rain_radar:2023-10-26_22:10:00: 0.15
2023-10-26_22:25:00 myCDC Stutt_rain_radar:2023-10-26_22:25:00: 0.16
2023-10-26_21:20:00 myCDC Stutt_rain_radar:2023-10-26_21:20:00: 0.04
2023-10-26_22:45:00 myCDC Stutt_rain_radar:2023-10-26_22:45:00: 0.05
2023-10-26_22:40:00 myCDC Stutt_rain_radar:2023-10-26_22:40:00: 0.06
2023-10-26_23:00:00 myCDC Stutt_rain_radar:2023-10-26_23:00:00: 0.04
2023-10-26_21:10:00 myCDC Stutt_rain_radar:2023-10-26_21:10:00: 0.02Ich hab die log-Werte händisch (mit Excel) sortiert, dann sieht der SVG-Plot so aus:
Unbenannt-2.png
Gruß
Franz
Anscheinend noch ein Problem issue:
Wenn ich "enableDWDdata = rainByDay,rainSinceMidnight,rainRadarbyLocation" habe, tauchen die since_midnight readings nicht mehr auf
Hallo Jörg,
ich bin auf dieses Modul gestoßen und hab es gleich genutzt.
Ich würde es gerne in der Weise nutzen, dass ich das Reading, das am nächsten zur Abfragezeit ist, als Event/Trigger für ein DOIF einsetzen will.
Geht das und wenn ja, wie?
Viele Grüße Gisbert
Zitat von: alkazaa am 26 Oktober 2023, 21:44:47Anscheinend noch ein Problem issue:
Wenn ich "enableDWDdata = rainByDay,rainSinceMidnight,rainRadarbyLocation" habe, tauchen die since_midnight readings nicht mehr auf
Hallo Franz,
anbei eine neue Version:
- fehlende Readings since_midnight bei enableDWDdata = rainByDay,rainSinceMidnight,rainRadarbyLocation behoben
- Readings rain_radar bekommen Readings-Timestamp des DWD timestamp. Somit ist das Attribut outputFormat im FileLog Device nicht mehr notwendig und die Readings sind richtig sortiert.
Grüße Jörg
PS: (%hash) = split(/\\/, $string); Führt zu einem unsortierten Ergebnis :-(
Hallo Jörg,
Zitatanbei eine neue Version:
Ist leider die gleiche Datei wie vorher...
Zitat von: alkazaa am 27 Oktober 2023, 14:24:16Hallo Jörg,
Zitatanbei eine neue Version:
Ist leider die gleiche Datei wie vorher...
Ups, mein Fehler :(
Super Jörg, Danke!
Es scheint jetzt alles OK, bis auf eine Kleinigkeit, die ich aber selber fixen konnte:
Im log-File stehen Zeilen der Form
2023-10-27_16:15:00 myCDC Home_rain_radar:2023-10-27_16:15:00: 0
2023-10-27_16:20:00 myCDC Home_rain_radar:2023-10-27_16:20:00: 0
usw.D.h. jedes reading hat einen anderen Namen, da der timestamp im reading auftaucht ("Home_rain_radar:2023-10-27_16:15:00:"). Im SVG-Plot Editor kann man dann den interessierenden Ort nicht auswählen (ich habe auch mehrere locations).
Gefixt habe ich das durch
attr FileLog_DWD_Regen_Radar outputFormat { return $TIMESTAMP." ".$NAME." ".$1." ".$2."\n" if $EVENT =~ /(.*?):.*?:\s(.*)/}Die Zeilen der log-Datei sind dann
2023-10-27_18:15:00 myCDC Home_rain_radar 0
2023-10-27_18:20:00 myCDC Home_rain_radar 0
2023-10-27_16:20:00 myCDC CW78_rain_radar 0.08
2023-10-27_16:25:00 myCDC CW78_rain_radar 0.16
usw.
Noch ne Neugierfrage:
wie lange dauert auf Deiner hardware ein kompletter "set <CDC-device> update"? Bei mir (Raspi 3B+) sind es 6...6,5 sec.
Beste Grüße
Franz
Zitat von: alkazaa am 27 Oktober 2023, 16:34:45Super Jörg, Danke!
Es scheint jetzt alles OK, bis auf eine Kleinigkeit, die ich aber selber fixen konnte:
Im log-File stehen Zeilen der Form
2023-10-27_16:15:00 myCDC Home_rain_radar:2023-10-27_16:15:00: 0
2023-10-27_16:20:00 myCDC Home_rain_radar:2023-10-27_16:20:00: 0
usw.D.h. jedes reading hat einen anderen Namen, da der timestamp im reading auftaucht ("Home_rain_radar:2023-10-27_16:15:00:"). Im SVG-Plot Editor kann man dann den interessierenden Ort nicht auswählen (ich habe auch mehrere locations).
Gefixt habe ich das durch
Hallo Franz,
Da ich ja jetzt den Reading Timestamp anpasse, kann der Timestamp aus dem Name ja raus. Soll ich das so ändern? Geht natürlich nicht, weil identische Reading Namen.
Ich werde beim Generieren eines FileLog über das Attribut RainRadarFileLog Deine Idee einbauen.
Zitat von: alkazaa am 27 Oktober 2023, 16:34:45Noch ne Neugierfrage:
wie lange dauert auf Deiner hardware ein kompletter "set <CDC-device> update"? Bei mir (Raspi 3B+) sind es 6...6,5 sec.
Sie bei mir genauso aus.
Grüße Jörg
Zitat von: alkazaa am 27 Oktober 2023, 16:34:45Super Jörg, Danke!
Es scheint jetzt alles OK, bis auf eine Kleinigkeit, die ich aber selber fixen konnte:
Im log-File stehen Zeilen der Form
2023-10-27_16:15:00 myCDC Home_rain_radar:2023-10-27_16:15:00: 0
2023-10-27_16:20:00 myCDC Home_rain_radar:2023-10-27_16:20:00: 0
usw.D.h. jedes reading hat einen anderen Namen, da der timestamp im reading auftaucht ("Home_rain_radar:2023-10-27_16:15:00:"). Im SVG-Plot Editor kann man dann den interessierenden Ort nicht auswählen (ich habe auch mehrere locations).
Gefixt habe ich das durch
Hallo Franz,
leider funktioniert das nicht wirklich. Entstehen durch mehrere Lokationen unterschiedliche Zeilenlängen, so werden, sofern das Log mit kürzen Zeilen startet, diese nicht geplottet. Im gezeigten Fall wird kein Plot für DWD_Regen_Radar Home_rain_radar. Kopiere ich die DWD_Regen_Radar Home_rain_radar Zeilen nach hinten funktioniert es.
2023-10-27_19:10:00 DWD_Regen_Radar Home_rain_radar: 0
2023-10-27_19:15:00 DWD_Regen_Radar Home_rain_radar: 0
...
2023-10-27_21:00:00 DWD_Regen_Radar Home_rain_radar: 0
2023-10-27_21:05:00 DWD_Regen_Radar Home_rain_radar: 0
2023-10-27_21:10:00 DWD_Regen_Radar Home_rain_radar: 0
2023-10-27_19:10:00 DWD_Regen_Radar Bad_Soden_rain_radar: 0
2023-10-27_19:15:00 DWD_Regen_Radar Bad_Soden_rain_radar: 0
...
2023-10-27_21:00:00 DWD_Regen_Radar Bad_Soden_rain_radar: 0
2023-10-27_21:05:00 DWD_Regen_Radar Bad_Soden_rain_radar: 0
2023-10-27_21:10:00 DWD_Regen_Radar Bad_Soden_rain_radar: 0
Grüße Jörg
Hallo Jörg,
das ist merkwürdig. Bei mir funktioniert es. Mit diesen Log-Datei Einträgen
...
2023-10-27_21:30:00 myCDC Home_rain_radar 0.03
2023-10-27_21:35:00 myCDC Home_rain_radar 0.03
2023-10-27_19:35:00 myCDC A_Dorf_rain_radar 0.06
2023-10-27_19:40:00 myCDC A_Dorf_rain_radar 0.16
...führt zu diesem Plot:
Unbenannt.png
Allerdings ist bei mir auch der ":" vor dem Zahlenwert entfernt worden, vielleicht liegt's daran?
Gruß Franz
Zitat von: alkazaa am 27 Oktober 2023, 19:50:56Allerdings ist bei mir auch der ":" vor dem Zahlenwert entfernt worden, vielleicht liegt's daran?
Hallo Franz,
ich hatte den : entfernt, da ich ihn zunächst in Verdacht hatte. Komisch, komisch
Grüße Jörg
Der Auswahldilog beim SVG Ploteditor sieht bei mir so aus (sind hier andere Orte als im vorigen Beispiel):Unbenannt.png
-Franz
Zitat von: JoWiemann am 27 Oktober 2023, 16:48:00Ich werde beim Generieren eines FileLog über das Attribut RainRadarFileLog Deine Idee einbauen.
D.h. Du hast es im *.pm Modul gemacht, nicht per outputFormat Attribut?
Falls ja, lad doch mal den modifizierten 98_CDCOpenData.pm Code hoch.
Zitat von: alkazaa am 27 Oktober 2023, 20:10:17Zitat von: JoWiemann am 27 Oktober 2023, 16:48:00Ich werde beim Generieren eines FileLog über das Attribut RainRadarFileLog Deine Idee einbauen.
D.h. Du hast es im *.pm Modul gemacht, nicht per outputFormat Attribut?
Falls ja, lad doch mal den modifizierten 98_CDCOpenData.pm Code hoch.
Hallo Franz,
nein, dass habe ich verworfen. Ich habe ein FileLog Device mit Deiner Ergänzung.
defmod FileLog_DWD_Regen_Radar FileLog ./log/DWD_Regen_Radar-%Y-%m.log DWD_Regen_Radar:.*
attr FileLog_DWD_Regen_Radar logtype text:linesInTheFile
attr FileLog_DWD_Regen_Radar outputFormat { return $TIMESTAMP." ".$NAME." ".$1." ".$2."\n" if $EVENT =~ /(.*?):.*?:\s(.*)/}
attr FileLog_DWD_Regen_Radar room Wetter
Ich hänge Dir mal das FileLog an. Bitte kopier es doch mal in Dein System und prüfe, ob es bei Dir funktioniert.
Danke und Grüße Jörg
Ich habe dieses FileLog erstellt:
defmod FileLog_DWD_Regen_Radar2 FileLog ./log/DWD_Regen_Radar-%Y-%m.log DWD_Regen_Radar:.*?_rain_radar:.*
attr FileLog_DWD_Regen_Radar2 outputFormat { return $TIMESTAMP." ".$NAME." ".$1." ".$2."\n" if $EVENT =~ /(.*?):.*?:\s(.*)/}
und von dort dann mit 'Create SVG Plot' das SVG device, dessen raw definition so aussieht:
defmod SVG_FileLog_DWD_Regen_Radar2_1 SVG FileLog_DWD_Regen_Radar2:SVG_FileLog_DWD_Regen_Radar2_1:CURRENT
setstate SVG_FileLog_DWD_Regen_Radar2_1 initialized
Damit konnte ich was plotten. Ich habe allerdings einige der 0-Werte in der Log-Datei durch !=0 Werte ersetzt, um was zu sehen.
Hallo Franz,
dann wird es an meiner Umgebung liegen. Ich werde morgen mal auf meinem Cubie testen.
Danke und Grüße Jörg
Hallo Jörg, Du schriebst:
Zitat von: JoWiemann am 27 Oktober 2023, 16:48:00Da ich ja jetzt den Reading Timestamp anpasse, kann der Timestamp aus dem Name ja raus. Soll ich das so ändern? Geht natürlich nicht, weil identische Reading Namen.
Ich schlage vor, den timestamp doch aus dem Namen zu entfernen.
Grund: Das eigentliche "reading" ist ja in diesem Fall ein Array von 25 Werten, die anzuschauen nur in der SVG-Graphik Sinn macht. Solange im Modul die Werte in der FileLog Datei landen, können sie in der readings-Liste ohne Not entfallen.
Und buchstäblich 'Anschauen' wird man sie sich dort ohnehin nicht. Für etwaige automatisierte Auswertungen (z.B. DOIFs oder notifies für Markisensteuerung etc.) wären aber 'verdichtete' Angaben hilfreich: z.B. könnten (bei jedem update des 25-Werte Radars fürs nächste 2-Stunden-Intervall) die readings "<location>_rain_next_5_minutes", "<location>_rain_next_15_minutes" und "<location>_rain_next_30_minutes" erzeugt werden. Die ließen sich dann für solche DOIFs gut automatisiert auswerten.
Gruß Franz
Zu dem anderen Problem (SVG zeigt nichts an):
Zitat von: JoWiemann am 27 Oktober 2023, 21:56:41dann wird es an meiner Umgebung liegen. Ich werde morgen mal auf meinem Cubie testen.
Wichtig für die Anzeige im SVG sind diese Attribute:
attr SVG_FileLog_DWD_Regen_Radar_1 endPlotNow 1
attr SVG_FileLog_DWD_Regen_Radar_1 fixedoffset 2
attr SVG_FileLog_DWD_Regen_Radar_1 fixedrange 2hours Falls die bei Dir fehlten, kam das Problem wahrscheinlich daher.
-Franz
Zitat von: alkazaa am 28 Oktober 2023, 11:32:38Ich schlage vor, den timestamp doch aus dem Namen zu entfernen.
Gruß Franz
Hallo Franz,
die Readings müssen sich im Namen unterscheiden. Durchnummerieren?
Grüße Jörg
Zitat von: Gisbert am 26 Oktober 2023, 23:28:01Ich würde es gerne in der Weise nutzen, dass ich das Reading, das am nächsten zur Abfragezeit ist, als Event/Trigger für ein DOIF einsetzen will.
Hallo Gisbert,
es gibt ja drei Arten von readings (für jeden Ort, falls Du mehrere locations aktiv hast):
- die rain_radar Werte (25 Stück, werden vom DWD alle 5 Minuten aktualisiert, im Modul evtl. seltener, falls INTERVAL oder cron-specs längere Abstände erzwingen)
- die '_since_midnight' Werte (stündlich vom DWD aktualisiert, evtl. seltener, s.o.)
- die '_day_rain' Werte (täglich vom DWD, in der Regel häufiger im Modul)
Welches von denen meinst Du?
Bei 2. und 3. sehe ich generell das Problem, dass ein 'event-on-change' Attribut nicht greift, wenn es nicht regnet, aber dass ein 'event-on-update' immer ausgelöst wird, wenn das Modul ein update macht, also z.B. alle INTERVAL Sekunden.
Bei 3. ist es so, dass Du mehrere Werte hast, falls Du nicht "numberOfDays=1" gesetzt hast. Ich vermute, dass Du dieses reading meinst? Da könnte ein DOIF mit [<deinmodulname>:.*?_day_rain.*] vielleicht funktionieren, wenn 'event-on-update-reading=.*' gesetzt ist. Allerdings (s.o.) bekommst Du dann alle INTERVAL Sekunden ein Event.
Bei 1. würde vielleicht das helfen, was ich in Beitrag #89 vorgeschlagen habe.
Gruß
Franz
Zitat von: JoWiemann am 28 Oktober 2023, 12:29:24Zitat von: alkazaa am 28 Oktober 2023, 11:32:38Ich schlage vor, den timestamp doch aus dem Namen zu entfernen.
die Readings müssen sich im Namen unterscheiden.
Nein, in der log-Datei nicht. Und im device listing könnte das reading Home_rain_radar ja immer wieder überschrieben werden. Idealerweise sollten aber die next_5, next_15, next_30 readings erzeugt werden.
Aber ich habe mich (noch) nicht mit der internen Logik der Werte-Erzeugung in dem *.pm Modul vertraut gemacht. Wahrscheinlich geht das alles gar nicht so einfach.
Gruß
Franz
Zitat von: alkazaa am 28 Oktober 2023, 12:40:35Nein, in der log-Datei nicht. Und im device listing könnte das reading Home_rain_radar ja immer wieder überschrieben werden. Idealerweise sollten aber die next_5, next_15, next_30 readings erzeugt werden.
Aber ich habe mich (noch) nicht mit der internen Logik der Werte-Erzeugung in dem *.pm Modul vertraut gemacht. Wahrscheinlich geht das alles gar nicht so einfach.
Gruß
Franz
Hallo Franz,
soweit ich weiß würde das Überschreiben nicht zu einzelnen Einträgen im FileLog führen, kann ich aber mal ausprobieren.
Was meinst du mit: Idealerweise sollten aber die next_5, next_15, next_30 readings erzeugt werden.
Grüße Jörg
Das mit next_5 usw. bezog sich auf meinen Beitrag #89: wenn nicht mehr alle 25 einzelnen rain_radar Werte auftauchen, könnten aber zumindest die für 5, 15 und 30 Minuten kumulierten Werte nützlich sein, um Markisenschutz oder Ähnliches auszulösen. Nur als Idee...
-Franz
Hallo Jörg,
hallo Franz,
ich könnte sehr gut die Vorhersagewerte in 5, 10, 15, ... Minuten gebrauchen, die bei jedem Update (INTERVALL) neu geschrieben werden.
In einem DOIF könnte ich dann darauf reagieren.
Viele Grüße Gisbert
Zitat von: Gisbert am 28 Oktober 2023, 13:57:48ich könnte sehr gut die Vorhersagewerte in 5, 10, 15, ... Minuten gebrauchen
Dann würde ich vorschlagen, auf das Kumulieren der nächsten 5,15,30 Minuten zu verzichten und alle 25 Radarwerte wie bisher zu behalten, aber so, dass aus
Home_rain_radar:2023-10-28_15:15:00
Home_rain_radar:2023-10-28_15:20:00
Home_rain_radar:2023-10-28_15:25:00
Home_rain_radar:2023-10-28_15:30:00
Home_rain_radar:2023-10-28_15:35:00
...das hier wird:
Home_rain_radar:00
Home_rain_radar:05
Home_rain_radar:10
Home_rain_radar:15
Home_rain_radar:20
...Die timestamps stehen ja eh in der Spalte mit den timestamps. Ein Vorteil wäre auch, dass sich die readings-Namen nicht ständig ändern und die readings daher vom Modul auch nicht jedesmal gelöscht und neu angelegt würden (wenn ich das richtig verstehe).
Gruß Franz
Zitat von: alkazaa am 28 Oktober 2023, 15:31:26Zitat von: Gisbert am 28 Oktober 2023, 13:57:48ich könnte sehr gut die Vorhersagewerte in 5, 10, 15, ... Minuten gebrauchen
Dann würde ich vorschlagen, auf das Kumulieren der nächsten 5,15,30 Minuten zu verzichten und alle 25 Radarwerte wie bisher zu behalten, aber so, dass aus
Home_rain_radar:2023-10-28_15:15:00
Home_rain_radar:2023-10-28_15:20:00
Home_rain_radar:2023-10-28_15:25:00
Home_rain_radar:2023-10-28_15:30:00
Home_rain_radar:2023-10-28_15:35:00
...das hier wird:
Home_rain_radar:00
Home_rain_radar:05
Home_rain_radar:10
Home_rain_radar:15
Home_rain_radar:20
...Die timestamps stehen ja eh in der Spalte mit den timestamps. Ein Vorteil wäre auch, dass sich die readings-Namen nicht ständig ändern und die readings daher vom Modul auch nicht jedesmal gelöscht und neu angelegt würden (wenn ich das richtig verstehe).
Gruß Franz
Hallo Franz,
geht dann nur für eine Stunde.
Grüße Jörg
Zitat von: JoWiemann am 28 Oktober 2023, 15:35:14geht dann nur für eine Stunde.
Ja, sorry. Dann natürlich eher so:
Home_rain_radar:000
Home_rain_radar:005
Home_rain_radar:010
...
Home_rain_radar:115
Home_rain_radar:120
Zitat von: alkazaa am 28 Oktober 2023, 15:58:24Zitat von: JoWiemann am 28 Oktober 2023, 15:35:14geht dann nur für eine Stunde.
Ja, sorry. Dann natürlich eher so:
Home_rain_radar:000
Home_rain_radar:005
Home_rain_radar:010
...
Home_rain_radar:115
Home_rain_radar:120
Hallo Franz,
dann werde ich das mal anpassen.
Grüße Jörg
Hallo,
anbei mein Vorschlag.
Die Readings sehen so aus:
2023-10-28 17:20:00 Home_rain_radar/0000 0
2023-10-28 17:25:00 Home_rain_radar/0105 0
2023-10-28 17:30:00 Home_rain_radar/0210 0
2023-10-28 17:35:00 Home_rain_radar/0315 0
2023-10-28 17:40:00 Home_rain_radar/0420 0
2023-10-28 17:45:00 Home_rain_radar/0525 0
2023-10-28 17:50:00 Home_rain_radar/0630 0
2023-10-28 17:55:00 Home_rain_radar/0735 0
2023-10-28 18:00:00 Home_rain_radar/0840 0
2023-10-28 18:05:00 Home_rain_radar/0945 0
2023-10-28 18:10:00 Home_rain_radar/1050 0
2023-10-28 18:15:00 Home_rain_radar/1155 0
...
Im FileLog muss das Attribut outputFormat folgendermaßen gesetzt werden:
{ return $TIMESTAMP." ".$NAME." ".$1." ".$2."\n" if $EVENT =~ /(.*?)\/.*?:\s(.*)/}
Grüße Jörg
Hallo Jörg,
das passt noch nicht so ganz. Zum einen sehen meine readings so aus (ich zeige nur die 1. Spalte):
Home_rain_radar/0000
Home_rain_radar/0105
Home_rain_radar/0210
...
Home_rain_radar/2250
Home_rain_radar/2355
Home_rain_radar/2400
Berlin_rain_radar/0005
Berlin_rain_radar/0110
Berlin_rain_radar/0215
...
Berlin_rain_radar/2255
Berlin_rain_radar/2300
Berlin_rain_radar/2405
Und weitere locations fangen jeweils mit weiteren 5 Minuten Zeitversatz an.
Zum anderen finde ich die Zahlen nach dem "/" redundant:
Die ersten 2 Ziffern zählen von 0 bis 24, das ist OK. Die nächsten beiden zählen die Minuten modulo 60 womit man nicht wirklich was anfangen kann.
Da würd ich es entweder bei der Zählung von 0 bis 24 belassen (mit dem Wissen, dass Multiplikation mit 5 die Zeit in Minuten ergibt). Oder bei drei Ziffern, die von 000,005 bis 115,120 laufen. Oder mit 4 Stellen von 0:00,0:05,...0:55,1:00,1:05 bis 1:55,2:00.
Die einzelnen Dateien in der DWD-tar Datei folgen übrigens der 000...120 Logik:
DE1200_RV2310281705_000
DE1200_RV2310281705_005
DE1200_RV2310281705_010
...
DE1200_RV2310281705_110
DE1200_RV2310281705_115
DE1200_RV2310281705_120
Sorry fürs viele Kritteln, Du hast ja die Arbeit damit...
Beste Grüße Franz
Hallo Franz,
sehe das weniger als Kritik, sondern eher als Diskussion fürs Ergebnis. Ich habe den Versatz jetzt korrigiert und belasse es bei 00-24.
Anbei die entsprechende Version.
Grüße Jörg
Hallo Jörg,
die Readings kommen jetzt wie beschrieben rein - dankeschön :)
Mit dem Attribut
outputFormat
{ return $TIMESTAMP." ".$NAME." ".$1." ".$2."\n" if $EVENT =~ /(.*?)\/.*?:\s(.*)/}in der Filelog-Datei wird jedoch nichts in die log-Datei geschrieben.
Ich benötige eigentlich die log-Datei (noch) nicht, aber es wäre sicher sinnvoll etwas hineinzuschreiben. Vermutlich haben sich die Änderungen überschnitten.
Viele Grüße Gisbert
Zitat von: Gisbert am 28 Oktober 2023, 20:57:21Hallo Jörg,
die Readings kommen jetzt wie beschrieben rein.
Mit dem Attribut
outputFormat
{ return $TIMESTAMP." ".$NAME." ".$1." ".$2."\n" if $EVENT =~ /(.*?)\/.*?:\s(.*)/}in der Filelog-Datei wird jedoch nichts in die log-Datei geschrieben.
Ich benötige eigentlich die log-Datei (noch) nicht, aber es wäre sicher sinnvoll etwas hineinzuschreiben. Vermutlich haben sich die Änderungen überschnitten.
Viele Grüße Gisbert
Hallo Gisbert,
schau mal hier: https://forum.fhem.de/index.php?msg=1291043hm, funktioniert bei mir. Poste doch mal ein list.
Grüße Jörg
Hallo Jörg,
genau dieses Attribut habe ich benutzt. Das logfile ist leer.
Viele Grüße Gisbert
Zitat von: Gisbert am 28 Oktober 2023, 21:05:39Hallo Jörg,
genau dieses Attribut habe ich benutzt. Das logfile ist leer.
Viele Grüße Gisbert
Hallo Gisbert,
poste doch einmal ein List.
Grüße Jörg
Hallo Gisbert,
du musst evtl. die definition des FileLog anpassen. Sieht bei mir so aus:
defmod FileLog_DWD_Regen_Radar FileLog ./log/myCDC-%Y-%m.log myCDC:.*?:.*
@ Joerg:
Bei mir läuft alles super, Danke!
-Franz
Hallo Franz,
Hallo Jörg,
mit der richtigen Definition des Filelog-Devices in Post #108 werden wieder log-Einträge geschrieben.
Vielen Dank :)
Viele Grüße Gisbert
Hallo Jörg,
Danke nochmal für die tolle Arbeit.
Eins fiel mir jetzt doch noch ein: könnte man nicht auch noch die "..._day_rain" und "..._since_midnight" readings so ändern, dass der timestamp nicht im Namen, sondern als normaler FHEM timestamp erscheint?
Gruß
Franz
Zitat von: alkazaa am 28 Oktober 2023, 21:38:50Hallo Jörg,
Danke nochmal für die tolle Arbeit.
Eins fiel mir jetzt doch noch ein: könnte man nicht auch noch die "..._day_rain" und "..._since_midnight" readings so ändern, dass der timestamp nicht im Namen, sondern als normaler FHEM timestamp erscheint?
Gruß
Franz
Hallo Franz,
steht die Tage noch an. Keine neue Baustelle wenn die alte noch nicht abgeschlossen ist ;)
Grüße Jörg
Guten Morgen Jörg,
es werden nur die aktuellen Werte der Readings Home_rain_radar/00 .. 24 in die log-Datei geschrieben, d.h. in der Datei stehen immer nur 25 Zeilen. Das ist unabhängig davon, ob das Attribut clearRadarFileLog gesetzt ist oder nicht. Ist das so beabsichtigt?
Viele Grüße Gisbert
Zitat von: Gisbert am 29 Oktober 2023, 08:08:10es werden nur die aktuellen Werte der Readings Home_rain_radar/00 .. 24 in die log-Datei geschrieben, d.h. in der Datei stehen immer nur 25 Zeilen.
Moin Gisbert,
ich antworte mal hier, weil ich die Idee mit den Regenradar-Auswertungen in FHEM und den Code-Kern dafür zu verantworten habe. (Allerdings wäre die Idee ohne Jörgs Umsetzung in ein non-blocking-Modul gar nicht vernünftig anwendbar).
Die 25 rain_radar Daten sind das vom DWD bereitgestellte "nowcasting" von Regenradar Bildern für die nächsten 2 Stunden für einen gegebenen Ort (1 km Ortsauflösung). "Nowcasting" bedeutet dabei, dass gemessene Ragenradar-Bilder mittels anderer gemessener Daten (Luftströmung z.B.) in die nahe Zukunft (2 Stunden) extrapoliert werden. Alles was nach den 2 Stunden kommt, beruht auf reinen Modellsimulationen und ist deutlich weniger zuverlässig. Auch die nowcasting-Daten sind natürlich nicht 100% verlässlich, sie werden aber alle 5 Minuten aktualisiert, immer für 2 Stunden in 5 Minuten Abständen. Daher die 25 Daten (die sich halt alle 5 Minuten ändern). In Beitrag #62 (https://forum.fhem.de/index.php?msg=1290038) habe ich versucht zu zeigen, wie die Daten zustande kommen.
Regenradardaten für die Vergangenheit gibt es vom DWD in der Form sogenannter "ankalibrierter" Daten. Dabei werden die per Regenradar "geschätzten" Werte mittels der an DWD-Stationen gemessenen Niederschläge quasi kalibriert und ebenfalls auf einem Raster mit 1 km Auflösung bereitgestellt. Und zwar als tägliche Werte (im Modul ist das das _day_rain reading), als stündliche Werte (im Modul die _since_midnight readings als Summe der stündlichen Werte seit dem letzten _day_rain reading) und sogar als Werte mit 5-Minuten Auflösung, die allerdings nur für den vergangenen und vorherige Tage (und im Modul nicht verfügbar, da vermutlich uninteressant).
Die unkalibrierten Regenradarwerte der unmittelbaren Vergangenheit (zwischen dem letzten _since_midnight reading und jetzt) werden vom Modul nicht geliefert. Zum einen, weil ich sie nicht für so interessant hielt (man bekommt ja beim Blick nach draußen mit, ob es regnet ;) ) und zum anderen, weil ich sie auf den DWD Seiten noch nicht gefunden habe.
Beste Grüße
Franz
Zitat von: Gisbert am 29 Oktober 2023, 08:08:10Guten Morgen Jörg,
es werden nur die aktuellen Werte der Readings Home_rain_radar/00 .. 24 in die log-Datei geschrieben, d.h. in der Datei stehen immer nur 25 Zeilen. Das ist unabhängig davon, ob das Attribut clearRadarFileLog gesetzt ist oder nicht. Ist das so beabsichtigt?
Viele Grüße Gisbert
Hallo Gisbert,
dieses Verhalten gibt es wenn das Attribut clearRadarFileLog und/oder RainRadarFileLog gesetzt ist/sind.
Ansonsten wird das FileLog kontinuierlich geführt. Macht bei Regen Radar aber nicht unbedingt Sinn. Außer man möchte historisch prüfen, wie oft der DWD recht hatte ;D
Grüße Jörg
Moin Jörg,
da ist noch ein Fehler mit der Monatsnummer in 98_CDCOpenData.pm, Zeile 1571: timelocal() kriegt die falsche Monatsnummer übergeben. Hab's für mich gefixt, aber noch nicht geprüft, ob weitere timelocal() Aufrufe im Modul betroffen sind.
Gruß
Franz
Zitat von: alkazaa am 31 Oktober 2023, 07:30:04Moin Jörg,
da ist noch ein Fehler mit der Monatsnummer in 98_CDCOpenData.pm, Zeile 1571: timelocal() kriegt die falsche Monatsnummer übergeben. Hab's für mich gefixt, aber noch nicht geprüft, ob weitere timelocal() Aufrufe im Modul betroffen sind.
Gruß
Franz
Hallo Franz,
danke für den Hinweis. Dadurch, dass ich jetzt die Teimestamps im Namen des Reading weglasse und die DWD Timestamps in den Reading Timestamp schreibe habe ich das jetzt anders gelöst.
Grüße Jörg
Hallo Jörg,
es gibt wohl ein Problem bei der Anzahl von Tagen in einem Monat. Im logfile steht folgendes (nur ein Auszug):
2023.11.02 11:25:16.139 1: ERROR evaluating
...
Day '31' out of range 1..30 at .//FHEM/98_CDCOpenData.pm line 1571.
Ein Update funktioniert seit dem 1.11. nicht mehr. Ich hab die Modulversion vom 28.10.2023, 18:26.
Viele Grüße Gisbert
Hallo Gisbert, das ist der von mir in Beitrag #115 gemeldete Fehler. Wenn Du nicht auf Jörgs Update warten willst, einfach in Zeile 1571 des Codes "$2" durch "$2"-1 ersetzen.
-Franz
Hallo,
ich denke, dass ich morgen eine neue stabile Version posten kann.
Grüße Jörg
Hallo,
anbei eine neue Version. _day_rain und _since_midnight hat jetzt keinen Timestamp merh im Reading Namen.
Grüße Jörg
Ich mal wieder. Ich erhalte folgenden Fehler bei dem Versuch die neue Version von CDCOpenData zu definieren:
[Regenmenge | Define.176] - EMERGENCY: ERROR: Cannot define a CDCOpenData device. Perl modul FHEM::Scheduler::Cron: update Fhem is missing.
2023.11.03 19:57:49 1: define Regenmenge CDCOpenData: ERROR: Cannot define a CDCOpenData device. Perl modul FHEM::Scheduler::Cron: update Fhem is missing.
Gruß Roman
FHEM UPDATE all hatte ich gemacht.
EDIT: Mit der Version aus Post #27 geht es. Allerdings fehelen dann die neuen Funktionen.
Zitat von: romakrau am 03 November 2023, 20:02:18FHEM UPDATE all hatte ich gemacht.
Hast Du Fhem neu gestartet? Schau bitte einmal ob diese Datei:
/opt/fhem/lib/FHEM/Scheduler/Cron.pm
vorhanden ist.
Grüße Jörg
Hallo Jörg,
Ich habe das Verzeichnis /opt/fhem/lib/FHEM/Scheduler
nicht. Welche Option muss ich nachinstallieren?
Gruss Roman
EDIT: werde ich aus dem svn nachistallieren müssen?!
Zitat von: romakrau am 05 November 2023, 21:55:52Hallo Jörg,
Ich habe das Verzeichnis /opt/fhem/lib/FHEM/Scheduler
nicht. Welche Option muss ich nachinstallieren?
Gruss Roman
EDIT: werde ich aus dem svn nachistallieren müssen?!
Hallo Roman,
sollte durch ein update von Fhem erledigt werden.
Grüße Jörg
Hatte ich auch gehofft. Habe ich manuell installiert, jetzt läufts. Danke für das tolle Tool.
Gruss Romman
Hallo Jörg,
ich hatte heute den (bisher von mir nicht abgefangenen) Fall, dass vom DWD ein Regenradar-Wert von 25.0 geliefert wird (2500 vor der Skalierung mit 0.01 ltr/m²/h), wenn 'not-valid' Daten vorliegen (Radar-Ausfall oder was auch immer).
Ich schlage folgenden patch vor: die Zeile
$rain_forecast = 0.01*(unpack( 'v*', $rain_forecast ) & 0xFFF);ersetzen durch
$rain_forecast = unpack( 'v*', $rain_forecast ) & 0xFFF;
# A value of 2500 in the file marks invalid data.
# It is reset to -1 in order to keep the y-axis scale small when plotting.
$rain_forecast = -1 if ($rain_forecast == 2500);
$rain_forecast *= 0.01;
# und gern noch ne log-Meldung an dieser Stelle
Beste Grüße
Franz
Hallo Franz,
danke für den Hinweis. Den Patch werde ich einbauen.
Grüße
Jörg
Oops, mir fällt gerade ein, dass die gleiche '2500' Markierung auch für die daily und hourly Radolan gilt. Müsste da genauso gepatcht werden.
Gruß
Franz
Zitat von: alkazaa am 08 November 2023, 18:13:35Oops, mir fällt gerade ein, dass die gleiche '2500' Markierung auch für die daily und hourly Radolan gilt. Müsste da genauso gepatcht werden.
Gruß
Franz
Hallo,
habe die Änderungen eingebaut. Anbei eine neue Version.
Grüße Jörg
Moin Jörg,
Zitat von: JoWiemann am 08 November 2023, 19:48:59habe die Änderungen eingebaut. Anbei eine neue Version.
Da ist noch ein copy&paste Fehler in Zeile 1494: bei'day rain' muss der Skalierungsfaktor 0.1 sein (wie korrekterweise bei 'since midnight rain'). Nur bei 'rain radar' ist er 0.01.
(Eigentlich müsste man den Faktor aus dem header-Teil der Datei parsen, falls DWD den irgendwann mal zu ändern beschließt. Bin aber im Moment zu faul dazu. Irgendwann vielleicht mal...)
Gruß
Franz
Zitat von: alkazaa am 09 November 2023, 07:19:03Da ist noch ein copy&paste Fehler in Zeile 1494: bei'day rain' muss der Skalierungsfaktor 0.1 sein (wie korrekterweise bei 'since midnight rain'). Nur bei 'rain radar' ist er 0.01.
Gruß
Franz
Hallo Franz,
danke für den Hinweis und habe ich korrigiert.
Grüße Jörg
Hallo Jörg,
danke für die tolle Arbeit, natürlich auch an Franz - in Zeile 492 und 495 ist beidesmal "my $dMod =" deklariert, und führt zu folgender Warning im Log : "my" variable $dMod masks earlier declaration in same scope at ./FHEM/98_CDCOpenData.pm line 495.
Zitat von: Jamo am 09 November 2023, 18:05:37Hallo Jörg,
danke für die tolle Arbeit, natürlich auch an Franz - in Zeile 492 und 495 ist beidesmal "my $dMod =" deklariert, und führt zu folgender Warning im Log :
"my" variable $dMod masks earlier declaration in same scope at ./FHEM/98_CDCOpenData.pm line 495.
Hallo,
danke für den Hinweis. Anbei eine korrigierte Version.
Grüße Jörg
Hi,
basierend auf den html bars der älteren Module '59_RainTMC.pm' und '59_Buienradar.pm', habe ich versucht die CDCOpenData rain_radar Werte auch mal als weblink HTMLbar anzeigen zu lassen. Sieht dann so aus wie im Bild, damit hat man schnell einen Überblick über die Regenvorhersage der nächsten 2 Stunden. Je dunkler die blaue Farbe, je mehr Regen gibt es. Das mit den Farben kann man auch schöner und feingranularer machen, aber dafür fehlt mir im Moment die Zeit und Geduld.
Hier meine Definitionen, der Aufruf des htmlcode für den Bar, und die nötigen subs für die 99_MyUtils.pm. Bitte beachten das ich als rain_radar readings die 'loc0_rain_radar' genommen habe.
Definition des Devices
defmod CDC CDCOpenData 48.1234,11.5678
attr CDC INTERVAL 600
attr CDC alias AtHome
attr CDC enableDWDdata rainRadarbyLocation
attr CDC event-on-change-reading .*/00
attr CDC verbose 2
Definition des weblink für den html bar:
defmod CDC_bar weblink htmlCode {radar2html('CDC','loc0_rain_radar')}Definition der subs in der 99_MyUtils.pm
# This is for htmlCode {radar2html('CDC','loc0_rain_radar')} Niederschlagsvorhersage (CDCOpenData)
# to create a HTML bar table with raincolors for the radarvalues
sub radar2html {
my $name = shift // 'CDC';# return "Error, sub color2html: we need name as parameter!";
my $reading = shift // 'loc0_rain_radar'; # return "Error, sub color2html: we need reading as parameter!";
my $as_htmlBarhead = '<tr style="font-size:x-small">';
my $as_htmlBar = '';
my $count = 1;
my $num = 25;
my $i2;
for (my $i = 0; $i < $num; $i++) {
if ($i <= 9) {$i2 = '0'.$i} else {$i2 = $i}
my $radarvalue = ReadingsNum ($name,$reading.'/'.$i2,'-1');
my $timestamp = substr(ReadingsTimestamp($name,$reading.'/'.$i2,'2000-01-01 00:00:00'),11,5);
my $color = myColor2RGB($radarvalue);
#Log 3, "[radar2html] i2=$i2, radarvalue=$radarvalue, color=$color, count=$count, timestamp=$timestamp"; #starttime=$starttime,
if ($count > 1) {
if ( ( ($count+2) % 4 ) == 0 || $i == 24) {
$as_htmlBarhead .= '<td style="padding-left: 0; padding-right: 0">' . $timestamp . '</td>';
} else {
$as_htmlBarhead .= '<td style="padding-left: 0; padding-right: 0"> </td>';
}
$as_htmlBar .= '<td style="padding-left: 0; padding-right: 0" bgcolor="' . $color . '"> </td>';
}
$count++;
}
my $location = '<b>' . AttrVal($name,'alias','MeineLocation') . '</b>'; # "<font color='red'>" . $body. "</font>"
$as_htmlBar = "Niederschlagsvorhersage für $location (<a href=./fhem?detail=$name>$name</a>)<BR><table>" . $as_htmlBarhead . "</TR><tr style='border:2pt solid black'>" . $as_htmlBar . '</tr></table>';
return $as_htmlBar;
}
sub myColor2RGB {
my $value = shift // return "Error, sub myColor2RGB: we need value as parameter!";
my $a = $value*4;
my $b = ($value-int($value))*2;
my $RGB1 = myCalcColor($a);
my $RGB2 = myCalcColor($b);
return $RGB1.$RGB2.$RGB1.$RGB2.'FF';
}
sub myCalcColor {
my $a = shift // return "Error, sub myCalcColor: we need a as parameter!";
if ($a == 0) {return 'F'} #transparent
elsif ($a <= 0.0625) {return 'E'} #transparent
elsif ($a <= 0.125) {return 'D'}
elsif ($a <= 0.1875) {return 'C'}
elsif ($a <= 0.25) {return 'B'}
elsif ($a <= 0.3125) {return 'A'}
elsif ($a <= 0.375) {return '9'}
elsif ($a <= 0.4375) {return '8'}
elsif ($a <= 0.5) {return '7'}
elsif ($a <= 0.5625) {return '6'}
elsif ($a <= 0.625) {return '5'}
elsif ($a <= 0.6875) {return '4'}
elsif ($a <= 0.75) {return '3'}
elsif ($a <= 0.8125) {return '2'}
elsif ($a <= 0.875) {return '1'}
elsif ($a <= 0.9375) {return '0'}
else {return '0'}
}
Hallo,
ich habe jetzt das Modul im SVN eingecheckt. Steht dann ab morgen im Update zur Verfügung.
Grüße Jörg
Moin Jörg,
ich habe eben ein Update gemacht und das Device angelegt:
Internals:
CFGFN
DWDHOST opendata.dwd.de
FUUID 654f3203-f33f-8a87-d982-06cca6dc5e5e8f27
INTERVAL 300
LOCATION Home:62.384500,9.969590
NAME Regen
NR 1408
STATE 1 values captured in 0.00 s
TIMEOUT 55
TMPDIR temp_radolan_data_Regen
TYPE CDCOpenData
eventCount 1
CONFIG:
IN_REQUEST 0
READINGS:
2023-11-11 08:49:26 retStat_lastReadout 1 values captured in 0.00 s
2023-11-11 08:49:26 state 1 values captured in 0.00 s
fhem:
UPDATE 0
helper:
CronTime 0
FhemLog3Std 0
TimerCmd Regen.Cmd
TimerReadout Regen.Readout
baseTMPDIR temp_radolan_data_Regen
Attributes:
DbLogExclude .*
event-on-change-reading .*
Im Log bekomme ich folgende Warnung:
2023.11.11 08:49:23.755 1: PERL WARNING: Use of uninitialized value $GunzipError in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 66.
2023.11.11 08:49:23.756 1: PERL WARNING: Use of uninitialized value $Bunzip2Error in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 67.
2023.11.11 08:49:23.849 1: PERL WARNING: using SSL support of Net::FTP 3.14 instead of SSLGlue at /usr/share/perl5/Net/SSLGlue/FTP.pm line 16.
Irgendetwas fehlt meinem System (Debian Bookworm) noch.
Gruss
Enno
Zitat von: enno am 11 November 2023, 08:56:08Moin Jörg,
ich habe eben ein Update gemacht und das Device angelegt:
Internals:
CFGFN
DWDHOST opendata.dwd.de
FUUID 654f3203-f33f-8a87-d982-06cca6dc5e5e8f27
INTERVAL 300
LOCATION Home:62.384500,9.969590
NAME Regen
NR 1408
STATE 1 values captured in 0.00 s
TIMEOUT 55
TMPDIR temp_radolan_data_Regen
TYPE CDCOpenData
eventCount 1
CONFIG:
IN_REQUEST 0
READINGS:
2023-11-11 08:49:26 retStat_lastReadout 1 values captured in 0.00 s
2023-11-11 08:49:26 state 1 values captured in 0.00 s
fhem:
UPDATE 0
helper:
CronTime 0
FhemLog3Std 0
TimerCmd Regen.Cmd
TimerReadout Regen.Readout
baseTMPDIR temp_radolan_data_Regen
Attributes:
DbLogExclude .*
event-on-change-reading .*
Im Log bekomme ich folgende Warnung:
2023.11.11 08:49:23.755 1: PERL WARNING: Use of uninitialized value $GunzipError in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 66.
2023.11.11 08:49:23.756 1: PERL WARNING: Use of uninitialized value $Bunzip2Error in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 67.
2023.11.11 08:49:23.849 1: PERL WARNING: using SSL support of Net::FTP 3.14 instead of SSLGlue at /usr/share/perl5/Net/SSLGlue/FTP.pm line 16.
Irgendetwas fehlt meinem System (Debian Bookworm) noch.
Gruss
Enno
Hallo Enno,
die drei Fehlermeldungen habe ich auch beim Start von Fhem. Ich bekomme die einfach nicht weg. Die Funktion wird dadurch behindert. Ich muss demnächst nochmal in Ruhe googeln.
Grüße Jörg
Zitat von: enno am 11 November 2023, 08:56:08Irgendetwas fehlt meinem System (Debian Bookworm) noch.
Hallo Jörg,
was es auch ist, bei Debian 11 (Bullseye) ist es nach einem Serverstart genauso.
Viele Grüße Gisbert
Hallo Jörg,
meine Idee, ungültige Radarwerte durch -1 zu kennzeichnen (siehe Beitrag #126 (https://forum.fhem.de/index.php?msg=1292463)), war leider suboptimal.
Ich hatte jetzt den Fall, dass bei einem 'since_midnight' reading ein Wert von -0.3 auftrat.
Das kam mit Sicherheit dadurch, dass beim Aufsummieren der Stundenwerte ein ungültiger dabei war. Das macht aber die anderen Stundenwerte nicht ungültig. Auf die darf dann natürlich nicht -1 dazu"addiert" werden.
Ich weiß nicht so recht, wir man das lösen sollte. Bei den nicht summierten Einzel-Readings ist ja ein negativer Wert ganz gut als Indikator, aber eben nicht beim Summieren. Vielleicht bei den since_midnight readings statt $x ein max(0,$x) dazuaddieren?
Beste Grüße
Franz
Zitat von: alkazaa am 13 November 2023, 15:32:37Hallo Jörg,
meine Idee, ungültige Radarwerte durch -1 zu kennzeichnen (siehe Beitrag #126 (https://forum.fhem.de/index.php?msg=1292463)), war leider suboptimal.
Ich hatte jetzt den Fall, dass bei einem 'since_midnight' reading ein Wert von -0.3 auftrat.
Das kam mit Sicherheit dadurch, dass beim Aufsummieren der Stundenwerte ein ungültiger dabei war. Das macht aber die anderen Stundenwerte nicht ungültig. Auf die darf dann natürlich nicht -1 dazu"addiert" werden.
Ich weiß nicht so recht, wir man das lösen sollte. Bei den nicht summierten Einzel-Readings ist ja ein negativer Wert ganz gut als Indikator, aber eben nicht beim Summieren. Vielleicht bei den since_midnight readings statt $x ein max(0,$x) dazuaddieren?
Beste Grüße
Franz
Hallo Franz,
bei _since_midnight werden fehlerhafte Werte nicht akkumuliert:
my $upMenge = (unpack( 'v*', $twobytes ) & 0xFFF);
# A value of 2500 in the file marks invalid data.
# It is reset to -1 in order to keep the y-axis scale small when plotting.
if ($upMenge == 2500) {
CDCOpenData_Log $name, 3, "Rain_Since_Midnight: error in value";
} else {
$regenmenge += 0.1 * $upMenge;
}
Grüße Jörg
Zitat von: JoWiemann am 13 November 2023, 15:39:08bei _since_midnight werden fehlerhafte Werte nicht akkumuliert
Hmm, hast Recht. Kopfkratz...
ich schau mal, ob ich das rekonstruieren kan, was ich da gesehen hab.
Gruß
Franz
EDIT: ich hab die Dateien mal durchwühlt (standen ja noch im temp Verzeichnis), keine Auffälligkeiten gefunden. Kein Ahnung, was mich da gefoppt hat..
Moin Jörg,
die negativen Werte bei rain_since_midnight rühren daher, dass in Zeile 1220 (und in Zeile 1239) $regenmenge mit -1 vorbesetzt wird statt mit 0.
(Mir fiel auf, dass die geforkten Prozesse nichts in die log Datei schreiben)
Gruß
Franz
Zitat von: alkazaa am 14 November 2023, 09:49:50Moin Jörg,
die negativen Werte bei rain_since_midnight rühren daher, dass in Zeile 1220 (und in Zeile 1239) $regenmenge mit -1 vorbesetzt wird statt mit 0.
(Mir fiel auf, dass die geforkten Prozesse nichts in die log Datei schreiben)
Gruß
Franz
Ups, passe ich an
Hallo Jörg,
noch ein Punkt: bei der automatischen FileLog-Verwaltung mit dem Attribut RainRadarFileLog müsste es statt
defmod myCDClog FileLog ./log/myCDC-%Y-%m.log myCDC:.*?_rain_radar:.*heißen
defmod myCDClog FileLog ./log/myCDC-%Y-%m.log myCDC:.*?_rain_radar/.*War mir bisher nicht aufgefallen, weil ich's händisch korrigiert hatte. Erst jetzt nach FHEM Neustart merkte ich, dass die händische Korrektur wieder überschrieben wird.
Gruß
Franz
Zitat von: alkazaa am 14 November 2023, 16:42:53Hallo Jörg,
noch ein Punkt: bei der automatischen FileLog-Verwaltung mit dem Attribut RainRadarFileLog müsste es statt
defmod myCDClog FileLog ./log/myCDC-%Y-%m.log myCDC:.*?_rain_radar:.*heißen
defmod myCDClog FileLog ./log/myCDC-%Y-%m.log myCDC:.*?_rain_radar/.*War mir bisher nicht aufgefallen, weil ich's händisch korrigiert hatte. Erst jetzt nach FHEM Neustart merkte ich, dass die händische Korrektur wieder überschrieben wird.
Gruß
Franz
Hallo Franz,
danke und kommt dann morgen mit Update.
Grüße Jörg
Zitat von: JoWiemann am 14 November 2023, 16:50:48Zitat von: alkazaa am 14 November 2023, 16:42:53heißen
defmod myCDClog FileLog ./log/myCDC-%Y-%m.log myCDC:.*?_rain_radar/.*War mir bisher nicht aufgefallen, weil ich's händisch korrigiert hatte. Erst jetzt nach FHEM Neustart merkte ich, dass die händische Korrektur wieder überschrieben wird.
Gruß
Franz
Hallo Franz,
danke und kommt dann morgen mit Update.
Grüße Jörg
Hm,
bei outPutformat: { return $TIMESTAMP." ".$NAME." ".$1." ".$2."\n" if $EVENT =~ /(.*?)\/.*?:\s(.*)/}
wir der slash ja nicht mitgenommen. Bei einer weiteren Definition habe ich kein outPutformat gesetzt und es funktioniert trotzdem.
Grüße Jörg
So sieht meine log-Datei (auszugsweise) aus:
2023-11-14_17:35:00 myCDC Home_rain_radar 0
2023-11-14_17:40:00 myCDC Home_rain_radar 0
2023-11-14_17:45:00 myCDC Home_rain_radar 0
2023-11-14_17:50:00 myCDC Home_rain_radar 0
2023-11-14_17:55:00 myCDC Home_rain_radar 0
2023-11-14_18:00:00 myCDC Home_rain_radar 0
...Bei
ZitatoutPutformat: { return $TIMESTAMP." ".$NAME." ".$1." ".$2."\n" if $EVENT =~ /(.*?)\/.*?:\s(.*)/}
und einer log-Definition mit
myCDC:.*?_rain_radar:.* bleibt bei mir die log Datei aber leer. Mit
myCDC:.*?_rain_radar/.* funktioniert es dagegen.
Aber die ganze regex-erei ist mir ein bisschen unheimlich, versteh es nicht immer...bzw. nur nach Ausprobieren.
Zitat von: alkazaa am 14 November 2023, 17:53:38Aber die ganze regex-erei ist mir ein bisschen unheimlich, versteh es nicht immer...bzw. nur nach Ausprobieren.
Hallo Franz,
geht mir genauso.
Grüße Jörg
Hallo Jörg, tut mir leid, aber in Zeile 492 ist immer noch ein defmod falsch:
my $dMod = 'defmod ' . $aVal . ' FileLog ./log/' . $name . '-%Y-%m.log ' . $name . ':.*?_rain_radar:.*';Richtig:
my $dMod = 'defmod ' . $aVal . ' FileLog ./log/' . $name . '-%Y-%m.log ' . $name . ':.*?_rain_radar/.*';
Hallo Jörg,
mit der letzten VERSION 01.10e des CDCOpenData MOduls, bekomme ich immer noch eine Warning im Log:
PERL WARNING: using SSL support of Net::FTP 3.11 instead of SSLGlue at /usr/share/perl5/Net/SSLGlue/FTP.pm line 16, <$fh> line 13281.Ist nur eine Warnung, aber wäre ganz schön wenn die weg wäre.
Beste Grüsse, Jamo.
Zitat von: Jamo am 20 November 2023, 20:51:36Ist nur eine Warnung, aber wäre ganz schön wenn die weg wäre.
Hallo Jamo,
morgen im Update.
Grüße Jörg
Bedankt!
Moin Jörg,
ich habe bei mir schon Verbose 0 eingestellt, trotzdem bekomme ich mehrmals täglich diese Warnung im Log. Kann ich das irgendwo unterdrücken?
Zitat2023.12.07 10:11:47.368 1: PERL WARNING: Use of uninitialized value $files[-1] in pattern match (m//) at ./FHEM/98_CDCOpenData.pm line 1367.
2023.12.07 10:11:47.371 1: PERL WARNING: Use of uninitialized value $2 in subtraction (-) at ./FHEM/98_CDCOpenData.pm line 1369.
2023.12.07 10:11:47.371 1: PERL WARNING: Use of uninitialized value $1 in addition (+) at ./FHEM/98_CDCOpenData.pm line 1369.
2023.12.07 10:11:47.371 1: PERL WARNING: Use of uninitialized value $mday in addition (+) at fhem.pl line 5253.
2023.12.07 10:11:47.371 1: PERL WARNING: Use of uninitialized value $hour in addition (+) at fhem.pl line 5253.
2023.12.07 10:11:47.371 1: PERL WARNING: Use of uninitialized value $min in addition (+) at fhem.pl line 5253.
Gruss
Enno
Moin Enno,
anscheinend wird in Zeile 1360
my @files = grep /10000.........50/, $ftp->ls(); beim listing des ftp-Verzeichnisses mit "$ftp->ls()" nichts eingelesen. Der Rest sind dann Folgefehler. Ich habe bei den ersten code-Entwürfen viele Dinge nicht abgefangen, u.a. auch diese Stelle nicht. Hatte ja immer alles funktioniert ;-).
Du schriebst, dass das mehrmals täglich passiert. Heißt das, dass nie die rain_since_midnight Daten gelesen werden, oder klappt es manchmal doch?
Zum Testen könntest Du (wiederholt) mal folgendes code-Fragment im FHEM Kommandofenster ausführen:
{my $ftp = Net::FTP->new("opendata.dwd.de", Debug => 0, Timeout => 10);;\
$ftp->login() or die "Cannot login ", $ftp->message;;\
$ftp->cwd("/climate_environment/CDC/grids_germany/hourly/radolan/recent/bin/");;\
my @files = grep /10000.........50/, $ftp->ls();;\
$files[-1] =~ /10000-(\d\d)(\d\d)(\d\d)(\d\d)(\d\d)/;;\
$ftp->quit;;\
"\$1=$1, \$2=$2, \$3=$3, \$4=$4, \$5=$5"}Die Antwort müsste dann z.B. so lauten:
$1=23, $2=12, $3=07, $4=15, $5=50für "07.12.2023 15:50"
Wäre interessant zu sehen, wie oft das gut geht.
(Du könntest dann auch mal den timeout in Zeile 1 variieren, obwohl der mit 10 sec schon sehr lang ist. Ich habe bei mir mal rumgespielt, und bis runter zu 0.04 sec geht alles gut, bei <= 0.03 sec geht's dann schief.)
Da ich immer noch ziemlicher Perl-Anfänger bin, hoffe ich, dass Jörg sich der Sache annimmt und den Fehler abfängt. Macht aber halt nur Sinn, wenn er nicht zu oft auftritt.
Gruß
Franz
Moin Franz,
die Warnungen kommen ca. 3 mal pro Tag. Die Werte für rain_since_midnight sind eigentlich immer da. Gefühlt läuft alles wie erwartet, aber das Log füllt sich halt und ich dachte wenn ich Verbose 0 mache, dann wird nichts mehr ins Log geschrieben. Dein Code-Fragment führt zu folgender Meldung; Experimental aliasing via reference not enabled at (eval 4598025) line 1.
Den Timeout hatte ich schon auf 100 gestellt.
Auf meinem zweiten System 400 km nördlicher habe ich keine Warnungen. Dort scheint der Server immer Werte zurück zu liefern.
Gruss
Enno
Zitat von: enno am 07 Dezember 2023, 20:43:27Dein Code-Fragment führt zu folgender Meldung
OK, ich erwähnte nicht, dass der code im erweiterten KommandoFENSTER (in der f18-style FHEM Oberfläche) laufen muss. Wenn Du den code in der normalen, einzeiligen KommandoZEILE ausführen willst, muss er auch als Einzeiler reinkopiert werden:
{my $ftp = Net::FTP->new("opendata.dwd.de", Debug => 0, Timeout => 0.04);;$ftp->login() or die "Cannot login ", $ftp->message;;$ftp->cwd("/climate_environment/CDC/grids_germany/hourly/radolan/recent/bin/");;my @files = grep /10000.........50/, $ftp->ls();;$files[-1] =~ /10000-(\d\d)(\d\d)(\d\d)(\d\d)(\d\d)/;;$ftp->quit;;"\$1=$1, \$2=$2, \$3=$3, \$4=$4, \$5=$5"}ZitatAuf meinem zweiten System 400 km nördlicher habe ich keine Warnungen. Dort scheint der Server immer Werte zurück zu liefern.
Das deutet darauf hin, dass die 'südliche' deiner Verbindungen zum DWD Server über irgendeinen 'Umweg' abgewickelt wird, und auf diesem Weg dann manchmal schief geht.
Um die warnings zu vermeiden, müsste in der since_midnight routine $files[-1] auf undefined geprüft werden und die Routine mit einer (vom verbose Mechanismus abgefangenen) Fehlermeldung verlassen werden.
@Jörg: ich denke, das geht dir schneller und sicherer von der Hand als mir...
Beste Grüße
Franz
Hallo,
bin morgen aus dem Urlaub zurück. Dann schaue ich mir das an.
Grüße Jörg
Zitat von: enno am 07 Dezember 2023, 11:43:20Moin Jörg,
ich habe bei mir schon Verbose 0 eingestellt, trotzdem bekomme ich mehrmals täglich diese Warnung im Log. Kann ich das irgendwo unterdrücken?
Zitat2023.12.07 10:11:47.368 1: PERL WARNING: Use of uninitialized value $files[-1] in pattern match (m//) at ./FHEM/98_CDCOpenData.pm line 1367.
2023.12.07 10:11:47.371 1: PERL WARNING: Use of uninitialized value $2 in subtraction (-) at ./FHEM/98_CDCOpenData.pm line 1369.
2023.12.07 10:11:47.371 1: PERL WARNING: Use of uninitialized value $1 in addition (+) at ./FHEM/98_CDCOpenData.pm line 1369.
2023.12.07 10:11:47.371 1: PERL WARNING: Use of uninitialized value $mday in addition (+) at fhem.pl line 5253.
2023.12.07 10:11:47.371 1: PERL WARNING: Use of uninitialized value $hour in addition (+) at fhem.pl line 5253.
2023.12.07 10:11:47.371 1: PERL WARNING: Use of uninitialized value $min in addition (+) at fhem.pl line 5253.
Gruss
Enno
Hallo Enno,
anbei eine Version zum Testen. Ich habe eine zusätzliche Fehlerbehandlung eingebaut. Ich selber kann das nicht nachstellen.
Grüße Jörg
Moin Jörg,
danke dafür. Habe ich eben eingebaut, melde mich mit Beobachtungen.
Gruss
Enno
Moin Jörg,
bei Verbose 0 werden die Timeout Warnungen nicht mehr angezeigt. Allerdings sind dann noch diese Warnungen vorhanden.
Can't use an undefined value as a symbol reference at ./FHEM/98_CDCOpenData.pm line 1185.
Can't use an undefined value as a symbol reference at ./FHEM/98_CDCOpenData.pm line 1185.
Gruss
Enno
Zitat von: enno am 12 Dezember 2023, 12:23:00Moin Jörg,
bei Verbose 0 werden die Timeout Warnungen nicht mehr angezeigt. Allerdings sind dann noch diese Warnungen vorhanden.
Can't use an undefined value as a symbol reference at ./FHEM/98_CDCOpenData.pm line 1185.
Can't use an undefined value as a symbol reference at ./FHEM/98_CDCOpenData.pm line 1185.
Hallo Enno,
habe jetzt auch den Fall berücksichtigt. Bitte einmal testen.
Danke Dir
Jörg
Die Möglichkeit mit dem bestehenden DWD Modul anschauliche Plots zu erstellen, die auch die Regenmenge und Regenwahrscheinlichkeit enthalten ist euch bekannt? Das geht sowohl als Tagesansicht, als auch für mehrere Tage.
Zitat von: JoWiemann am 13 Dezember 2023, 11:20:49Zitat von: enno am 12 Dezember 2023, 12:23:00Moin Jörg,
bei Verbose 0 werden die Timeout Warnungen nicht mehr angezeigt. Allerdings sind dann noch diese Warnungen vorhanden.
Can't use an undefined value as a symbol reference at ./FHEM/98_CDCOpenData.pm line 1185.
Can't use an undefined value as a symbol reference at ./FHEM/98_CDCOpenData.pm line 1185.
Hallo Enno,
habe jetzt auch den Fall berücksichtigt. Bitte einmal testen.
Danke Dir
Jörg
Moin Jörg,
läuft seit gestern mit dieser Version ohne Meldungen im Log und soweit ich es erkennen kann auch plausiblen Werten. Danke dafür!
Gruss
Enno
Hallo zusammen, ich bekomme keine Daten von DWD mehr. Hat noch jemand diese Erfahrung gemacht. Gruss Roman
Zitat von: romakrau am 02 Januar 2024, 17:02:55Hallo zusammen, ich bekomme keine Daten von DWD mehr. Hat noch jemand diese Erfahrung gemacht. Gruss Roman
Hallo Roman,
bei mir ist noch alles gut.
Grüße Jörg
Zitat von: romakrau am 02 Januar 2024, 17:02:55Hallo zusammen, ich bekomme keine Daten von DWD mehr. Hat noch jemand diese Erfahrung gemacht. Gruss Roman
Ich hatte den Fehler auch (gerade erst bemerkt, nach Deinem Beitrag).
Es lag anscheinend daran, dass in Zeile 1540 der Wert $time = "2024-1-01" ankam statt "2024-01-01".
Ich habe dann die Formatierung in Zeile 1062 geändert von
$time = ($Jahr + 1900) . "-" . ($Monat + 1) . "-" . substr("00" . $Monatstag, -2);zu
$time = ($Jahr + 1900) . "-" . sprintf("%02d",$Monat + 1) . "-" . substr("00" . $Monatstag, -2);und es geht wieder.
Merkwürdig, dass es bei JoWiemann funktioniert...
Gruß
Franz
Zitat von: alkazaa am 02 Januar 2024, 18:31:15Zitat von: romakrau am 02 Januar 2024, 17:02:55Hallo zusammen, ich bekomme keine Daten von DWD mehr. Hat noch jemand diese Erfahrung gemacht. Gruss Roman
Merkwürdig, dass es bei JoWiemann funktioniert...
Hallo Franz,
gar nicht merkwürdig. Habe ins falsche Device, dem mit Rain Radar, geschaut. Danke für die Fehleranalyse. Kommt dann mit dem Update. Ich weiß aber noch nicht ob ich es heute noch schaffe.
Grüße Jörg
Moin zusammen,
bei mir kam der Fehler auch seit dem 02.01.2024.
2024.01.02 17:15:18.250 1: PERL WARNING: Use of uninitialized value $targettime in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1554.
habe wie von Franz vorgeschlagen die Zeile 1062 geändert. Bei mir geht es damit auch wieder, obwohl die Anzeige vom keinem Niederschlag hier (Niedersachsen) besser für die Nerven wäre ;)
Gruss
Enno
Zitat von: enno am 02 Januar 2024, 18:44:32Bei mir geht es damit auch wieder, obwohl die Anzeige vom keinem Niederschlag hier (Niedersachsen) besser für die Nerven wäre ;)
An dem Codeschnipsel, der den Regen nicht nur meldet oder vorhersagt, sondern einstellt, arbeite ich gerade. Wird aber noch dauern...
Ist halt nicht so dringend für mich, seit ich von der Oker an die Ostsee gezogen bin (16 m über N.N., dh. Wasser fließt direkt ab, und Meerespiegelanstieg wird noch nicht so bald relevant)
Ein schönes neues Jahr an alle!
Hallo Franz,
Danke es funktioniert wieder. Das mit dem Regen einstellen würde mich auch interessieren. Könnte man den Regen im Urlaub abstellen. ;)
Gruss Roman
Hallo zusammen,
bei mir sieht's genauso aus, keine Updates.
Viele Grüße Gisbert
Es gibt da noch weitere Stellen mit Problemen:
Use of uninitialized value $targettime in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1554.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1763.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1879.
Gruss Roman
Zitat von: romakrau am 03 Januar 2024, 06:52:48Es gibt da noch weitere Stellen mit Problemen:
Use of uninitialized value $targettime in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1554.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1763.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1879.
Gruss Roman
Aber die Änderung in Zeile 1062 von 98_CDCOpenData.pm mit anschließendem "reload 98_CDCOpenData.pm" hattest Du gemacht?
Wenn ja: schick doch bitte mal dein device listing.
-Franz
Hallo Franz,
hallo Jörg,
mit der Änderung in Beitrag #166 läuft das Modul wieder.
Eine Frage habe ich noch. Es wird folgendes Reading ausgegeben:
Home_rain_radar/24 -1D.h. der Wert ist -1. Liegt das am Modul, oder kommt diese Information von der Wetterseite so herein?
Heißt es, dass Wasser endlich schneller verdunstet, als Regen nachkommt ;), wäre ja endlich eine positive Wendung.
Viele Grüße
Gisbert
Moin Gisbert,
die -1 ist die Modul-Kennung für ungültige Daten vom DWD (Radar-Ausfall oder was auch immer). Siehe dazu Beitrag #126ff.
In den DWD-Dateien steht an der Stelle eine 25. Die Zahl haben wir ersetzt, damit in der jetzigen Wettersituation keiner einen Herzkasper kriegt ;)
Gruß Franz
Hallo,
die Fehler korrigierte Version 01.12c ist im SVN und kommt dann morgen mit dem Update. Auch die -1 ist jetzt in der commandRef gewürdigt.
Grüße Jörg
Sorry, war ausser Haus. Die Änderung hatte ich eingefügt. Läuft auch und ich bekomme Daten. Anbei das List des Devices.
Internals:
DWDHOST opendata.dwd.de
FUUID 6548137a-f33f-e93f-af40-cc9fd1faaaee5812
INTERVAL 300
LOCATION Home:51.2047222,6.7422222
NAME Regenmenge
NEXT 2024-01-04 02:00:00
NR 379
STATE Regenmenge: 25.7 l/m2
TIMEOUT 55
TMPDIR temp_radolan_data_Regenmenge
TYPE CDCOpenData
eventCount 2185
CONFIG:
IN_REQUEST 0
READINGS:
2024-01-02 23:50:00 Home_day_rain/00 25.7
2024-01-01 23:50:00 Home_day_rain/01 3.1
2023-12-31 23:50:00 Home_day_rain/02 1
2024-01-03 06:27:43 retStat_lastReadout 4 values captured in 0.01 s
2024-01-03 06:27:43 state 4 values captured in 0.01 s
fhem:
UPDATE 0
helper:
CronTime 1
FhemLog3Std 0
TimerCmd Regenmenge.Cmd
TimerReadout Regenmenge.Readout
baseTMPDIR temp_radolan_data_Regenmenge
Attributes:
cronTime * 2 * * *
enableDWDdata rainByDay
numberOfDays 3
stateFormat Regenmenge: {(ReadingsNum("$name","Home_day_rain/00",0))} l/m2
verbose 0
Gruss Roman
Zitat von: mumpitzstuff am 13 Dezember 2023, 11:51:50Die Möglichkeit mit dem bestehenden DWD Modul anschauliche Plots zu erstellen, die auch die Regenmenge und Regenwahrscheinlichkeit enthalten ist euch bekannt? Das geht sowohl als Tagesansicht, als auch für mehrere Tage.
Hallo mumpitzstuff,
hab Deinen Beitrag gerade erst gesehen.
Ich denke, beide Module haben ihre Berechtigung:
Das CDC-Modul liefert Messwerte der Vergangenheit (an Stations-Messwerte 'angeeichte' Niederschlagsmengen) und aus (Radar)Messwerten der unmittelbaren Vergangheit in die unmittelbare Zukunft extrapolierte Niederschlagsvorhersagen ('nowcasting'). Beides mit einer Ortsauflösung von 1x1 km²!
Bei den DWD-Modul-Werten handelt es sich um die üblichen Vorhersagen aufgrund von (Messdaten-basierten) Wettermodellen, gültig auf längeren Zeit- und gröberen Ortsskalen.
Wer wissen will, ob er beim Spaziergang in der nächsten halben Stunde nass wird, oder die Markise lieber jetzt schon einfährt, oder ob er die Gartenbewässerung aktivieren muss weil es die letzten Tage zu wenig regnete, wird mit dem CDC-Modul vielleicht etwas mehr anfangen können.
Ah okay. Danke für die Aufklärung, mir waren die Unterschiede irgendwie nicht so klar und ich hatte es anscheinend für das Gleiche gehalten und deshalb diese Frage gestellt. Dann werde ich es mir wohl doch noch einmal installieren und im Auge behalten, wobei es aktuell wirklich egal ist wohin man schaut. Überall Regen...
Zitat von: romakrau am 03 Januar 2024, 06:52:48Es gibt da noch weitere Stellen mit Problemen:
Use of uninitialized value $targettime in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1554.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1763.
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1879.
Gruss Roman
Hallo Roman,
ich konnte das auch mit einem entsprechend Deinem listing nachgestellten device nicht nachvollziehen.
Tauchen die warnings nach dem update auf JoWiemanns aktualisierte Version immer noch auf?
Gruß Franz
Hallo Franz,
ich habe das Modul aktualisiert und bekomme folgende Fehlermeldung:
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1799.
Das Modul nutze ich nur zur Ermittlung der Regenmenge der letzten Tage zwecks Gartenbewässerung.
Gruß
Roman
Edit: Diese Meldung erscheint 60-mal im Log.
Zitat von: romakrau am 08 Januar 2024, 08:04:05Hallo Franz,
ich habe das Modul aktualisiert und bekomme folgende Fehlermeldung:
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1799.Das Modul nutze ich nur zur Ermittlung der Regenmenge der letzten Tage zwecks Gartenbewässerung.
Gruß
Roman
Edit: Diese Meldung erscheint 60-mal im Log.
Moin Roman,
ich bekomme nach wie vor kein solches warnings. Ich habe zur Sicherheit ein neues CDC-Device 'CDCtest' mit möglichst exakt Deinen Daten angelegt. Dessen listing (mit 'list CDCtest' erzeugt) sieht so aus:
Internals:
CFGFN
DEBUGLOG OFF
DWDHOST opendata.dwd.de
FUUID 659bd66e-f33f-a50b-5c21-e1c32a26e2abb838
INTERVAL 300
LOCATION Home:51.2047222,6.7422222
NAME CDCtest
NEXT 2024-01-09 02:00:00
NR 211
NTFY_ORDER 50-CDCtest
STATE Regenmenge: 0 l/m2
TIMEOUT 55
TMPDIR temp_radolan_data_CDCtest
TYPE CDCOpenData
VERSION 01.12c
eventCount 5
CONFIG:
IN_REQUEST 0
READINGS:
2024-01-07 23:50:00 Home_day_rain/00 0
2024-01-06 23:50:00 Home_day_rain/01 0.7
2024-01-05 23:50:00 Home_day_rain/02 1.2
2024-01-08 12:06:58 retStat_lastReadout 4 values captured in 0.01 s
2024-01-08 12:06:58 state 4 values captured in 0.01 s
fhem:
UPDATE 0
helper:
CronTime 1
FhemLog3Std 0
TimerCmd CDCtest.Cmd
TimerReadout CDCtest.Readout
baseTMPDIR temp_radolan_data_CDCtest
debugLog CDCtest_debugLog
logDebug
rainLog CDCtest_rainLog
hmccu:
Attributes:
cronTime * 2 * * *
enableDWDdata rainByDay
numberOfDays 3
stateFormat Regenmenge: {(ReadingsNum("$name","Home_day_rain/00",0))} l/m2
verbose 0In Details unterscheidet es sich von Deinem listing, z.B. gibt es diverse Einräge mit 'Debug..', die bei Dir nicht vorkommen. Keine Ahnung, warum das so ist. Ich krieg sie bei mir nicht weg und weiß auch nicht, wo sie herkommen.
Wie auch immer: Ich habe zum 'zu-Fuß' debuggen dann mal nach Zeile 1799 diese Zeile eingefügt:
main::Debug("\$rLogFile: $rLogFile; \$dirdef: $dirdef; \$hash->{helper}{rainLog}: ".sprintf("'%s'",$hash->{helper}{rainLog}));Nach 'reload 98_CDCOpenData.pm' und 'set CDCtest update' steht dann in der FHEM log-Datei:
2024.01.08 12:33:59.264 1: DEBUG>$rLogFile: ./logCDCtest_rainLog.log; $dirdef: ./log; $hash->{helper}{rainLog}: 'CDCtest_rainLog'Die in Zeile 1799 auftretenden Parameter $dirdef und $hash->{helper}{rainLog} sind also defined und haben sinnvolle Werte, die dann korrekt zu $rLogFile kombiniert werden. Also alles in Ordnung. Vielleicht probierst Du das auch mal aus. Warum bei Dir (bei nur einem Aufruf von 'update') gleich 60 log-Meldungen kommen, ist mir schleierhaft...
Ich würde übrigens das device löschen und komplett neu anlegen, vielleicht ist der Spuk dann schon vorbe.
Gruß
Franz
Zitat von: alkazaa Dessen listing (mit 'list CDCtest' erzeugt) sieht so aus:
code]Internals:
CFGFN
DEBUGLOG OFF
DWDHOST opendata.dwd.de
FUUID 659bd66e-f33f-a50b-5c21-e1c32a26e2abb838
INTERVAL 300
LOCATION Home:51.2047222,6.7422222
NAME CDCtest
NEXT 2024-01-09 02:00:00
NR 211
NTFY_ORDER 50-CDCtest
STATE Regenmenge: 0 l/m2
TIMEOUT 55
TMPDIR temp_radolan_data_CDCtest
TYPE CDCOpenData
VERSION 01.12c
eventCount 5
CONFIG:
IN_REQUEST 0
READINGS:
2024-01-07 23:50:00 Home_day_rain/00 0
2024-01-06 23:50:00 Home_day_rain/01 0.7
2024-01-05 23:50:00 Home_day_rain/02 1.2
2024-01-08 12:06:58 retStat_lastReadout 4 values captured in 0.01 s
2024-01-08 12:06:58 state 4 values captured in 0.01 s
fhem:
UPDATE 0
helper:
CronTime 1
FhemLog3Std 0
TimerCmd CDCtest.Cmd
TimerReadout CDCtest.Readout
baseTMPDIR temp_radolan_data_CDCtest
debugLog CDCtest_debugLog
logDebug
rainLog CDCtest_rainLog
hmccu:
Attributes:
cronTime * 2 * * *
enableDWDdata rainByDay
numberOfDays 3
stateFormat Regenmenge: {(ReadingsNum("$name","Home_day_rain/00",0))} l/m2
verbose 0[/code]
Gruß
Franz
Hallo Franz,
die Einträge unter helper: sind interne hash Einträge, die der Programmsteuerung dienen. Die kann man nicht ,,weg" bekommen. Wen weg, dann Modul kaputt. Der helper Ast ist vor langer Zeit eingeführt worden, damit nicht innerhalb des Module ,,hunderte" von Variablen an die Modul Sub weiter gereicht werden müssen.
Grüße Jörg
Hab das Device neu angelegt. Hoffe der Fehler ist weg.
Gruss Roman
P.S.: Mir fällt auf das in meinem Listing die Versionsnummer fehlt.
Mal wieder ich. Ich erhalte seit Samstag folgende Meldung:
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1915.
Die Version des Moduls ist 01.12c. Update habe ich gemacht.
Hat jemand eine Lösung?
Gruß
Roman
Zitat von: romakrau am 25 Februar 2024, 18:03:15Hat jemand eine Lösung?
Ich habe gerade auch mal nachgeschaut und gesehen, dass beim DWD server (https://opendata.dwd.de/climate_environment/CDC/grids_germany/daily/radolan/recent/bin/) als letzte Datei "raa01-sf_10000-2402231450-dwd---bin.gz" auftaucht. Anscheinend haben sich die DWD-Computer dem Streik im öffentlichen Dienst angeschlossen. ;)
Mir fiel bei der Fehlersuche allerdings auf, dass ich überhaupt keine Fehlermeldung in der log-Datei hatte (trotz verbose 5). In der sub CDCOpenData_Log habe ich dann mal als Zeile 94
main::Debug($text); eingefügt. Damit kamen dann diese Fehlermeldungen:
2024.02.25 19:33:13.407 1: DEBUG>set myCDC update
2024.02.25 19:33:13.409 1: DEBUG>start CDCOpenData_Readout_Start with myCDC, Readout, 5
2024.02.25 19:33:13.410 1: DEBUG>BlockingCall CDCOpenData_Readout_Run_Data with myCDC, 55
2024.02.25 19:33:13.434 1: DEBUG>Fork process CDCOpenData_Readout_Run_Data
2024.02.25 19:33:13.462 1: DEBUG>start CDCOpenData_Readout_Run_getRain with myCDC, 0, 2024-02-24
2024.02.25 19:33:13.463 1: DEBUG>################ get_Regenmenge called ################
2024.02.25 19:33:13.464 1: DEBUG>targettime is 2024-02-24 23:50:00
2024.02.25 19:33:13.465 1: DEBUG>file raa01-sf_10000-2402242250-dwd---bin.gz on CDC ftp-server is nearest to targettime
2024.02.25 19:33:13.465 1: DEBUG>localname raa01-sf_10000-2402242250-dwd---bin
2024.02.25 19:33:13.617 1: DEBUG>ftp temp_radolan_data_myCDC/raa01-sf_10000-2402242250-dwd---bin.gz not found
2024.02.25 19:33:13.618 1: DEBUG>temp_radolan_data_myCDC/raa01-sf_10000-2402242250-dwd---bin.gz not found
2024.02.25 19:33:13.622 1: DEBUG>Back at main process.
2024.02.25 19:33:13.623 1: DEBUG>BulkUpdate lastReadout: 0 values captured in sIrgendwas scheint da in der "sub CDCOpenData_Log" (oder anderswo) nicht zu funktionieren
Danke für die Antwort. Muss ich mit dem Datenloch leben.
Zitat von: alkazaa am 25 Februar 2024, 19:47:09Mir fiel bei der Fehlersuche allerdings auf, dass ich überhaupt keine Fehlermeldung in der log-Datei hatte (trotz verbose 5). In der sub CDCOpenData_Log habe ich dann mal als Zeile 94
Hallo,
bei verbose 5 wird eine eigene Log-Datei generiert, damit die vielen Log-Einträge auch einfacher durchforstet bzw gepostet werden können. Hier der Auszug aus der commandRef:
attr <name> verbose <0 .. 5>
Wird verbose auf den Wert 5 gesetzt, so werden alle Log-Daten in eine eigene Log-Datei geschrieben.
Name der Log-Datei:deviceName_debugLog.dlog
Im INTERNAL Reading DEBUGLOG wird ein Link <DEBUG Log kann hier eingesehen werden> zur direkten Ansicht des Logs angezeigt.
Weiterhin wird ein FileLog Device:deviceName_debugLog im selben Raum und der selben Gruppe wie das CDCOpenData Device erzeugt.
Wird verbose auf kleiner 5 gesetzt, so wird das FileLog Device gelöscht, die Log-Datei bleibt erhalten. Wird verbose gelöscht, so werden das FileLog Device und die Log-Datei gelöscht.
Die Fehlermeldung:
Use of uninitialized value in concatenation (.) or string at ./FHEM/98_CDCOpenData.pm line 1915.
entsteht durch einen Zustand, der bisher so im Modul nicht als Fehler "vorgesehen" ist. Warum und wieso wird es etwas dauern herauszufinden.
Grüße Jörg
Zitat von: JoWiemann am 26 Februar 2024, 07:58:37bei verbose 5 wird eine eigene Log-Datei generiert, damit die vielen Log-Einträge auch einfacher durchforstet bzw gepostet werden können.
Hatte ich leider nicht gesehen, sorry (bin typischer manual-Ignorierer). Bei der Auswahl von 'verbose' in der FHEM GUI wird allerdings auch nur der Standard-Hilfetext gezeigt:
Unbenannt.png
Vielleicht kann man das ändern? Da ich die Internals auch ausgeblendet hatte, war ich blind.
Ich hatte dann aber auch noch einen falschen Dateinamen: sie hieß bei mir 'log<mydeviceName>_debugLog.dlog' (und stand in /opt/fhem). Manuelles Ändern des Namens zu '<mydeviceName>_debugLog.dlog' machte sie dann für den Link <DEBUG Log kann hier eingesehen werden> sichtbar.
(Ach ja, noch was: in der FHEM Commandref steht bei mir noch ein toter link: CDCOpenData-thread40. Hab aber auch länger kein FHEM update mehr gemacht)
Grüße
Franz
Zitat von: alkazaa am 26 Februar 2024, 13:42:54Hatte ich leider nicht gesehen, sorry (bin typischer manual-Ignorierer). Bei der Auswahl von 'verbose' in der FHEM GUI wird allerdings auch nur der Standard-Hilfetext gezeigt:
Unbenannt.png
Vielleicht kann man das ändern? Da ich die Internals auch ausgeblendet hatte, war ich blind.
Da habe ich leider keine Idee. Dass kommt direkt über FhemWeb.
Zitat von: alkazaa am 26 Februar 2024, 13:42:54Ich hatte dann aber auch noch einen falschen Dateinamen: sie hieß bei mir 'log<mydeviceName>_debugLog.dlog' (und stand in /opt/fhem). Manuelles Ändern des Namens zu '<mydeviceName>_debugLog.dlog' machte sie dann für den Link <DEBUG Log kann hier eingesehen werden> sichtbar.
Hm, kommt mir irgendwie unverständlich vor. Kannst Du das reproduzieren?
Zitat von: alkazaa am 26 Februar 2024, 13:42:54(Ach ja, noch was: in der FHEM Commandref steht bei mir noch ein toter link: CDCOpenData-thread40. Hab aber auch länger kein FHEM update mehr gemacht)
Schau ich mir mal an.
Ich glaube ich habe den Fehle gefunden. Bei einer Fehlersituation wurde der Rückgabewert nicht korrekt bereitgestellt. Werde ich nachher einschecken. Ob es das war...
Grüße Jörg
Zitat von: JoWiemann am 26 Februar 2024, 14:37:37Zitat von: alkazaa am 26 Februar 2024, 13:42:54Ich hatte dann aber auch noch einen falschen Dateinamen: sie hieß bei mir 'log<mydeviceName>_debugLog.dlog' (und stand in /opt/fhem). Manuelles Ändern des Namens zu '<mydeviceName>_debugLog.dlog' machte sie dann für den Link <DEBUG Log kann hier eingesehen werden> sichtbar.
Hm, kommt mir irgendwie unverständlich vor. Kannst Du das reproduzieren?
Ja, ist reproduzierbar bei beiden CDC devices die ich habe.
Beendet man den Verbose=5 Modus mit FhemLog3Std=1, dann wird die Datei "/opt/fhem/log<name>_debugLog.dlog" auch gelöscht. Der dafür zuständige Teil des Programms kennt also die Datei unter diesem (falschen) Namen.
Riecht ein bisschen danach, dass die Datei eigentlich "/opt/fhem/log/<name>_debugLog.dlog" sein sollte, aber irgendwo ein "/" verloren gegangen ist.
Allerdings funktioniert der Programmteil, der bei <DEBUG Log kann hier eingesehen werden> ausgeführt wird, nur, wenn ich die Datei händisch zu "/opt/fhem/<name>_debugLog.dlog" umbenannt habe.
-Franz
Zitat von: alkazaa am 26 Februar 2024, 18:12:14Ja, ist reproduzierbar bei beiden CDC devices die ich habe.
Beendet man den Verbose=5 Modus mit FhemLog3Std=1, dann wird die Datei "/opt/fhem/log<name>_debugLog.dlog" auch gelöscht. Der dafür zuständige Teil des Programms kennt also die Datei unter diesem (falschen) Namen.
Riecht ein bisschen danach, dass die Datei eigentlich "/opt/fhem/log/<name>_debugLog.dlog" sein sollte, aber irgendwo ein "/" verloren gegangen ist.
Allerdings funktioniert der Programmteil, der bei <DEBUG Log kann hier eingesehen werden> ausgeführt wird, nur, wenn ich die Datei händisch zu "/opt/fhem/<name>_debugLog.dlog" umbenannt habe.
-Franz
Hallo Franz,
bitte stell doch von einem Device ein list bereit. Danke Dir.
Grüße Jörg
Hallo Jörg,
listing1.txt erstellt mit "Copy for forum.fhem.de"
listing2.txt erstellt mit "list myCDC"
Gruß Franz
Zitat von: alkazaa am 26 Februar 2024, 19:28:35Hallo Jörg,
listing1.txt erstellt mit "Copy for forum.fhem.de"
listing2.txt erstellt mit "list myCDC"
Gruß Franz
Hallo Franz,
dann mache ich mich mal an die Arbeit.
Grüße Jörg
Zitat von: alkazaa am 26 Februar 2024, 19:28:35Hallo Jörg,
listing1.txt erstellt mit "Copy for forum.fhem.de"
listing2.txt erstellt mit "list myCDC"
Gruß Franz
Hallo Franz,
würdest Du mir bitte noch ein List vom Filelog Device zusenden.
PS: Ich glaube ich habe eine Idee
Vielen Dank Jörg
Zitat von: alkazaa am 26 Februar 2024, 19:28:35Hallo Jörg,
listing1.txt erstellt mit "Copy for forum.fhem.de"
listing2.txt erstellt mit "list myCDC"
Gruß Franz
Bitte teste doch einmal die angehängte Version.
Danke und Grüße
Jörg
Hallo Jörg, leider auch mit der neuen Version 01.12d das gleiche ...
Zu dem device myCDC gibt es gar kein FileLog (arbeitet mit dbLog). Ich hänge die listings meines zweiten devices namens "Regenradar" und des zugehörigen Filelogs an.
Gruß Franz
Zitat von: alkazaa am 26 Februar 2024, 21:51:31Hallo Jörg, leider auch mit der neuen Version 01.12d das gleiche ...
Zu dem device myCDC gibt es gar kein FileLog (arbeitet mit dbLog). Ich hänge die listings meines zweiten devices namens "Regenradar" und des zugehörigen Filelogs an.
Gruß Franz
Hallo Franz,
also suche ich weiter. Schade, wäre so einfach gewesen.
Grüße Jörg
Zitat von: alkazaa am 26 Februar 2024, 21:51:31Hallo Jörg, leider auch mit der neuen Version 01.12d das gleiche ...
Zu dem device myCDC gibt es gar kein FileLog (arbeitet mit dbLog). Ich hänge die listings meines zweiten devices namens "Regenradar" und des zugehörigen Filelogs an.
Gruß Franz
Hallo Franz,
das Filelog sieht richtig aus. Auch der Dateiname ist richtig.
currentlogfile ./log/Regenradar-2024-02.log
Da ich selber kein dbLog nutze bin ich hier etwas ratlos. Ich werde wohl einen neuen RPi mit dbLog aufsetzen müssen und mich mal in dbLog einlesen.
Grüße Jörg
Zitat von: JoWiemann am 26 Februar 2024, 22:11:19Da ich selber kein dbLog nutze bin ich hier etwas ratlos. Ich werde wohl einen neuen RPi mit dbLog aufsetzen müssen und mich mal in dbLog einlesen.
Es hat nichts mit dbLog zu tun: Das device 'Regenradar' nutzt kein dbLog, führt aber zum gleichen Fehler mit der falsch benamten .dlog Datei.
Ich könnte (morgen) mal beide devices löschen und eine neues, möglichst einfaches 'from scratch' definieren und damit testen.
Zitat von: alkazaa am 26 Februar 2024, 22:15:00Es hat nichts mit dbLog zu tun: Das device 'Regenradar' nutzt kein dbLog, führt aber zum gleichen Fehler mit der falsch benamten .dlog Datei.
Ich könnte (morgen) mal beide devices löschen und eine neues, möglichst einfaches 'from scratch' definieren und damit testen.
Ok, mein falscher Dampfer. Dann warte ich einfach erst mal Deinen neuen Test ab.
Grüße Jörg
Habe alle CDCOpenData devices und zugehörige Filelog devices gelöscht, dann 'shutdown restart' und eine neues device angelegt mit
defmod CDCtest CDCOpenData
attr CDCtest room Xprimtl
Dann 'rainSinceMidnight' aktiviert, ein 'update' liefert korrektes Ergebnis.
Danach hat "attr CDCtest verbose 5" das folgende FileLog device erzeugt:
define CDCtest_debugLog FileLog ./log/CDCtest_debugLog-%Y-%m.dlog FakeLog readonly
attr CDCtest_debugLog room Xprimtl
# CFGFN
# DEF ./log/CDCtest_debugLog-%Y-%m.dlog FakeLog readonly
# FH
# FUUID 65ddd181-f33f-a50b-ec7b-61aabe5e3c111d99
# NAME CDCtest_debugLog
# NR 223
# NTFY_ORDER 50-CDCtest_debugLog
# READONLY 1
# REGEXP FakeLog
# STATE active
# TYPE FileLog
# currentlogfile ./log/CDCtest_debugLog-2024-02.dlog
# logfile ./log/CDCtest_debugLog-%Y-%m.dlog
# hmccu:
#
setstate CDCtest_debugLog active
Ein folgendes 'set CDCtest update' erzeugt die Datei "/opt/fhem/logCDCtest_debugLog-2024-02.dlog" mit dem korrekten Inhalt, den man bei verbose 5 erwarten würde.
Hab dann testweise versucht, die Definition des Filelogs zu ändern mit "defmod CDCtest_debugLog FileLog ./log/CDCtest_debuggggggLog-%Y-%m.dlog FakeLog readonly".
Das ändert aber nichts, es wird nach wie vor eine Datei "/opt/fhem/logCDCtest_debugLog-2024-02.dlog" erzeugt. Nach einem 'Save Config' und "shutdown restart" ist die händische Änderung wieder weg, das CDCtest_debugLog wird also anscheinend beim Neustart automatisch neu erzeugt.
Weitere Details:
Nach "set CDCtest verbose 3" kommt im normalen logfile die Meldung [CDCtest | dbgLogInit.245] - BASIC:redirection debugLog: ./log/CDCtest_debugLog-%Y-%m.dlog stoppedNach erneutem Setzen auf verbose 5 kommt entsprechend die log Meldung [CDCtest | dbgLogInit.219] - BASIC:redirection debugLog: ./log/CDCtest_debugLog-%Y-%m.dlog startedNach "set CDCtest FhemLog3Std 1" kommen die log Meldungen:
CDCtest: redirection debugLog: CDCtest_debugLog deleted
CDCtest: redirection debugLog: ./log/CDCtest_debugLog-%Y-%m.dlog stopped
CDCtest: Temporary debug file: ./log/CDCtest_debugLog*.dlog could not be removed:
Was das Verhalten beim Klick auf "DEBUG Log kann hier eingesehen werden" angeht: der liefert eine leere Browserseite, es sei denn, man verschiebt die falsch benamte Datei von "/opt/fhem/logCDCtest_debugLog-2024-02.dlog" nach "/opt/fhem/log/CDCtest_debugLog-2024-02.dlog" (das hatte ich gestern nicht ganz korrekt beschrieben).
Gruß Franz
Hallo Jörg,
ich denke, ich hab's gefunden. Habe Zeile 136 geändert von
my $nfile = $dirdef . ResolveDateWildcards($filename, @t);zu
my $nfile = $dirdef . "/" . ResolveDateWildcards($filename, @t);
Zitat von: alkazaa am 27 Februar 2024, 18:43:15Hallo Jörg,
ich denke, ich hab's gefunden. Habe Zeile 136 geändert von
my $nfile = $dirdef . ResolveDateWildcards($filename, @t);zu
my $nfile = $dirdef . "/" . ResolveDateWildcards($filename, @t);
Hallo,
der Fehler entsteht nur, wenn das globale Attribut logdir gesetzt ist. Da hatte ich nicht berücksichtigt, dass das ohne Slash am Ende ist.
Lade gleich eine neue Version zum Testen hoch.
Grüße Jörg
Hallo,
anbei eine neue Version.
Bei gesetztem globalen Attribut logdir kam es zu einem Fehler in der Bildung des Dateinamen.
Grüße Jörg
Hallo Jörg,
ich die Version aus Thread #205 heruntergeladen, Rechte und Besitz angepasst, sowie das Modul per reload neu geladen.
Die Version ist die Version 01.12d, in Fhem steht in den Internals VERSION 01.12c.
Muss ich Fhem neu starten?
Leider bekomme ich folgende Einträge im log-file (sehr viele davon, konnte am Handy nicht gut kopieren, deshalb nur ein Eintrag):
2024.02.27 19:30:00.740 1: PERL WARNING: Subroutine CDCOpenData_myCalcColor redefined at .//FHEM/98_CDCOpenData.pm line 2398.
Viele Grüße Gisbert
Zitat von: Gisbert am 27 Februar 2024, 19:43:17Hallo Jörg,
ich die Version aus Thread #205 heruntergeladen, Rechte und Besitz angepasst, sowie das Modul per reload neu geladen.
Die Version ist die Version 01.12d, in Fhem steht in den Internals VERSION 01.12c.
Muss ich Fhem neu starten?
Leider bekomme ich folgende Einträge im log-file (sehr viele davon, konnte am Handy nicht gut kopieren, deshalb nur ein Eintrag):
2024.02.27 19:30:00.740 1: PERL WARNING: Subroutine CDCOpenData_myCalcColor redefined at .//FHEM/98_CDCOpenData.pm line 2398.
Viele Grüße Gisbert
Hallo Gisbert,
nun ja, bei einem reload wird das Modul mit seinen Sub neu geladen. Und das meldet Perl schön brav. Also alles gut.
Grüße Jörg
Hallo Jörg,
ich danke dir für deine Antwort.
Kannst du noch was hierzu sagen:
ZitatDie Version ist die Version 01.12d, in Fhem steht in den Internals VERSION 01.12c.
Muss ich Fhem neu starten?
Viele Grüße Gisbert
Zitat von: Gisbert am 28 Februar 2024, 09:24:23Hallo Jörg,
ich danke dir für deine Antwort.
Kannst du noch was hierzu sagen:
ZitatDie Version ist die Version 01.12d, in Fhem steht in den Internals VERSION 01.12c.
Muss ich Fhem neu starten?
Viele Grüße Gisbert
Hallo Gisbert,
eine INTERNALS werden erst bei einem Neustart gesetzt. Das gilt auch für die VERSION.
Grüße Jörg