Modul für DWD Open Data

[juppzupp]

ich hab's jetzt erstmal so gemacht :

Code Auswählen Erweitern

attr DWD event-on-change-reading myAlarm0,myAlarm1,myAlarm2
attr DWD userReadings myAlarm0 {ReadingsVal("DWD","a_0_headline","")},myAlarm1 {ReadingsVal("DWD","a_1_headline","")},myAlarm2 {ReadingsVal("DWD","a_2_headline","")}
und nehm dann im doif (mit do always) halt die myAlarm Meldung

[frank]

ich hab's jetzt erstmal so gemacht :

Code Auswählen Erweitern

attr DWD event-on-change-reading myAlarm0,myAlarm1,myAlarm2
attr DWD userReadings myAlarm0 {ReadingsVal("DWD","a_0_headline","")},myAlarm1 {ReadingsVal("DWD","a_1_headline","")},myAlarm2 {ReadingsVal("DWD","a_2_headline","")}
und nehm dann im doif (mit do always) halt die myAlarm Meldung

du solltest unbedingt auch den trigger für userreadings nutzen, sonst wird jedes userreading für jedes event deines dwd devices berechnet.

ungetestetes beispiel:

attr DWD userReadings myAlarm0:a_0_headline:.* {ReadingsVal("DWD","a_0_headline","")}

[jensb]

Hallo, danke, die o.g. Warnung ist nun weg, aber es gibt eine neue aus 98_HTTPMOD.pm:

Es gibt keinen direkten Zusammenhang zwischen DWD_OpenData_Weblink und HTTPMOD. Das hat eher etwas mit deiner Konfiguration für HTTPMOD zu tun. Vielleicht greifst du auf ein Reading zu, das nicht immer definiert ist. Du kannst dir die im Stacktracke angegebenen Zeile im  Modul-Quelltext anschauen, vielleicht hilft das schon. Aber sehr wahrscheinlich gehört das Problem nicht hierher.

[jensb]

... ich habe den Verdacht, dass bei jeder Abfrage / Aktualisierung (also alle 15 Minuten ...

Das funktioniert auch genau so, siehe Modulhilfe: "Note that all alert readings are completely replaced and reindexed with each update! "

Hintergrund: Die Warnungen vom DWD sind eine Liste. Der Umfang der Liste kann sich mit jeder Abfrage beim DWD ändern (sowohl Anzahl, Inhalt und Reihenfolge). Man könnte versuchen, die Häufigkeit des Löschens/Neuanlegens leicht zu reduzieren, wenn zwei aufeinander folgende Listenabfragen diesbezüglich gleich sind. Aber das prinzipielle Problem lässt sich schwer vermeiden. Früher oder später ändert sich auf jeden Fall etwas. Beispiel: Meldung 2 entfällt und Meldung 3 wird neue Meldung 2. Hier fehlt die Möglichkeit, die Meldung als Objekt zu handhaben, statt sie über einen Index zur Verfügung zu stellen. Prinzipiell wäre es möglich, den Eventcode (z.B. 22) oder den Eventnamen (z.B. Frost) statt des Index im Reading-Namen zu verwenden. Das würde ein Aktualisieren der Readings ohne Löschen erlauben, solange die Meldung ansteht, egal wieviele Meldungen insgesamt gerade anliegen. Aber dann kann man nicht mehr mit einer Schleife auf die Readings zugreifen, zumindest nicht, ohne eine Liste der aktuell anstehenden Eventcodes bzw. Eventnamen als zusätzliche Readings zur Verfügung zu stellen.

... leider kann man den Intervall nicht definieren oder ich habe den Parameter nicht gefunden) alle Readings mit der Bezeichnung "a_<Zahl>_.*" gelöscht und neu erstellt werden ...

Wer die 15 Minuten für die Aktualisierung ändern möchte, kann das in der Funktion "Timer" ab Zeile 1071 des DWD-Moduls machen. Das ist allerdings nicht ganz trivial, da es nicht reicht, aus der 15 in Zeile 1079 eine andere Zahl zu machen. Wenn mir jemand einen guten Grund nennt, warum man einen bestimmten anderen Wert verwenden sollte ohne die Aktualität und die Systemlast nachteilig zu ändern, würde ich das übernehmen.

[holle75]

@jensb, @mumpitzstuff

wir haben damals hier https://forum.fhem.de/index.php?topic=83097.msg877628#msg877628 geschnattert. Was mir komplett entfallen war (ist ja dann doch ne Weile her) und ich jetzt bei der Suche bzgl. der aktuellen Herausforderung wieder gefunden habe.

Die letzten Jahre war ich erst "auf" Proplanta, dann DarkSky, dann VisualCrossing, jetzt würde ich gerne OpenMeteo für eine Zeit mit VisualCrossing vergleichen um evtl. einen Umstieg einzuleiten. DWD ist mir hier in Mittelitalien zu ungenau (vor langer Zeit getestet, vielleicht wäre es jetzt anders) und/aber mein ganzes System ist auf die Rohdaten über HTTPMOD ausgelegt (wir betreiben hier Landwirtschaft und da sind Wetterdaten essentiell ... und auch dementsprechend vielseitig integriert). Das würde ich ungern alles umbauen.

Warum ich eigentlich schreibe: Ich bekomme seit 2 Tagen mumpitzstuff´s (was ich dachte hätte @Frank ursprünglich gebaut) logproxy myUtil Sub nicht umgearbeitet (für DarkSky und VisualCrossing hatte ich es, wie auch immer, hinbekommen) um auch für OpenMeteo (https://open-meteo.com/en/docs) mir meinen Plot zu generieren. RegEx und Perl mögen mich nicht.

Eine etwas unverschämte Frage, aber hätte einer von euch 15 Minuten Zeit? Die Daten kommen wirklich schön in Stunden benannt und separiert. Also wahrscheinlich einfach, wenn man weiß was man tut. Falls, liefere ich die Kerninfos.

Damit auch andere etwas davon hätten (die nicht hauptsächlich in D ihre Zeit verbringen. Ein paar Pages weiter vorne las ich etwas von einem evtl. zu integrierendem spanischen Daten-Provider?) schreibe ich gerne hier https://forum.fhem.de/index.php?topic=132792.msg1297096#msg1297096 eine Zusammenfassung. OpenMeteo macht auf den ersten (neuen) Blick einen ziemlich guten Eindruck.

Grüße!
H.

[mumpitzstuff]

Wenn ich dich recht verstanden habe, dann hast du mittels Httpmod die erforderlichen Daten in ein Logfile geschrieben und versuchst nun mittels Logproxy ein Diagramm daraus zu basteln? Und die Erstellung des Diagramms klappt nicht?
Dann lade doch mal so ein Logfile hoch und was du sonst schon versucht hast, dann muss man nicht von vorn anfangen und hoffentlich nur den Fehler finden.

[holle75]

Exakt! Vielen Dank für deine Antwort

Ich habe mich an meiner hingeschusterten Version von VisualCrossing als Kopie versucht. Warum diese funktioniert ist mir auch schon nicht klar. Trial and Error damals

Device, SVG Plot, etc ist mir, denke ich, bewußt was zu tun ist, nur die Sub bringt mich um den Verstand.

Das ist sehr wilder StatusQuo, die RegEx macht überhaupt nicht was ich will und da mir die ganze Function unverständlich ist kasper ich im Dunklen rum. Auch ist wahrscheinlich die Hälfte überflüssig und den eher komplizierteren Daten von DWD in eurer Sub geschuldet. Es gibt sogar ein "hourly_time_128: 2023-12-22T08:00" als Zeit für die jeweilige Stunde/Reading:

Code Auswählen Erweitern

sub logProxy_WetterOpenMeteo2Plot($$$$;$$) {
    my ($device, $fcValue, $from, $to, $fcHour, $expMode) = @_;
    my $regex;
    my @rl;
    my $hdmreading;
    my $hdmtime;
  
    return undef if(!$device);

if ($fcValue =~ s/_$//)
        {
            $regex = "^hourly_".$fcValue."_[\\d]+\$";
        }
   
    $fcHour = 12 if(!defined $fcHour);
    $expMode = "point" if(!defined $expMode);

#Log3 undef,2, "regex: ".$regex;
#Log3 undef,2, "FCvalue: ".$fcValue;

    if( defined($defs{$device}) ) {
        if( $defs{$device}{TYPE} eq "HTTPMOD" ) {
            @rl = sort{
                my ($an) = ($a =~ m/hourly.*_(\d+):.*/);
#Log3 undef,2, "an: ".$an;
#Log3 undef,2, "a: ".$a;
                my ($bn) = ($b =~ m/hourly.*_(\d+):.*/);
                $an <=> $bn or $a cmp $b;
                }( grep /${regex}/,keys %{$defs{$device}{READINGS}} );
            return undef if( !@rl );
        } else {
            Log3 undef, 2, "logProxy_WetterOpenMeteo2Plot: $device is not a HTTPMOD device";
            return undef;
        }
    }
#Log3 undef,2, Dumper(@rl);

    my $fromsec = SVG_time_to_sec($from);
    my $tosec   = SVG_time_to_sec($to);
    my $sec = $fromsec;
    my ($h,$hdmsec,$hdmmin,$hdmhour,$hdmmday,$hdmmon,$hdmyear,$hdmwday,$hdmyday,$hdmisdst);
    my $timestamp;
  
    my $reading;
    my $value;
    my $prev_value;
    my $min = 999999;
    my $max = -999999;
    my $ret = "";

    # while not end of plot range reached
    while(($sec < $tosec) && @rl) {
        #remember previous value for start of plot range
        $prev_value = $value;

        $reading = shift @rl;
       
        ($h) = $reading =~ m/^hourly.*_(\d+):.*/;
       

        $value = ReadingsVal($device,$reading,undef);

#Log3 undef,2, "reading: ".$reading;
#Log3 undef,2, "h: ".$h;
        use Date::Parse;
        $hdmreading = ReadingsVal($device, "hourly_time_".$h ,undef);

#Log3 undef,2, "hdmvorCONV: ".$hdmreading;
        $hdmtime = str2time($hdmreading);
       
       
#Log3 undef,2, "hdmreading: ".$hdmreading;
#Log3 undef,2, "hdmtime: ".$hdmtime;
       
       
        #($hdmsec, $hdmmin, $hdmhour, $hdmmday, $hdmmon, $hdmyear, $hdmwday, $hdmyday, $hdmisdst) = localtime(ReadingsVal($device, "hfc".$h."_time",undef));
        ($hdmsec, $hdmmin, $hdmhour, $hdmmday, $hdmmon, $hdmyear, $hdmwday, $hdmyday, $hdmisdst) = localtime($hdmtime);       
 
        # necessary conversion of $mon and $year
        $hdmmon += 1;
        $hdmyear += 1900;
  
        $timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $hdmyear, $hdmmon, $hdmmday, $hdmhour, $hdmmin, $hdmsec);
#Log3 undef,2, "timestamp: ".$timestamp;
        $sec = SVG_time_to_sec($timestamp);
      
        # skip all values before start of plot range
        next if( SVG_time_to_sec($timestamp) < $fromsec );

        # add first value at start of plot range
        if( !$ret && $prev_value ) {
        $min = $prev_value if( $prev_value < $min );
        $max = $prev_value if( $prev_value > $max );
        $ret .= "$from $prev_value\n";
        }

        # done if after end of plot range
        last if($sec > $tosec);

        $min = $value if( $value < $min );
        $max = $value if( $value > $max );

        # add actual controll point
        $ret .= "$timestamp $value\n";

#Log 3, "$timestamp $value -0- $reading";
    }
    if(($sec < $tosec) && !@rl && ($expMode eq "day")) {
        $timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $hdmyear, $hdmmon, $hdmmday, 23, 59, 59);
        if(SVG_time_to_sec($timestamp) < $tosec) {
            $ret .= "$timestamp $value\n";
        }
        else {
            $ret .= "$to $value\n";
        }
    }
    elsif(($sec > $tosec) && ($expMode eq "day")) {
           $value = $prev_value + ($value - $prev_value)*(86400 + ($tosec - $sec))/86400;
           $ret .= "$to $value\n";
    }
    return ($ret,$min,$max,$prev_value);
}

angehängt das Logfile vom Device. Da sind jetzt auch noch daily (EDIT: und UNITS ) Readings drin, die man entfernen könnte wenns das komplizierter macht.
Wenn du noch andere Daten brauchst, lass gerne wissen.

Vielen lieben Dank fürs Schauen.

EDIT: Plot angehängt

EDIT2: der Ordnung halber die Devices (lat/lon leicht modifiziert), Logproxy heisst noch immer Proplanta, aber ist ja egal:

Code Auswählen Erweitern

defmod WetterOpenMeteo HTTPMOD https://api.open-meteo.com/v1/forecast?latitude=42.70&longitude=11.50&current=temperature_2m,precipitation,weather_code,cloud_cover,wind_speed_10m,wind_direction_10m,wind_gusts_10m&hourly=temperature_2m,precipitation_probability,precipitation,cloud_cover,wind_speed_10m,wind_direction_10m,wind_gusts_10m,soil_temperature_0cm,uv_index,sunshine_duration&daily=weather_code,temperature_2m_max,temperature_2m_min,sunshine_duration,uv_index_max,precipitation_sum,precipitation_probability_max,wind_speed_10m_max,wind_gusts_10m_max,wind_direction_10m_dominant&timezone=Europe%2FBerlin 3600
attr WetterOpenMeteo enforceGoodReadingNames 1
attr WetterOpenMeteo event-on-change-reading .*
attr WetterOpenMeteo extractAllJSON 1
attr WetterOpenMeteo group Wetter
attr WetterOpenMeteo room Wettervorhersage
attr WetterOpenMeteo stateFormat T: current_temperature_2m &deg - Wind: current_wind_speed_10m km/h mit current_wind_gusts_10m km/h Boen aus current_wind_direction_10m Grad


defmod LogproxyWetterProplanta logProxy
attr LogproxyWetterProplanta group Wetter

defmod FileLog_WetterOpenMeteo FileLog ./log/WetterOpenMeteo-%Y-%m-%d.log WetterOpenMeteo
attr FileLog_WetterOpenMeteo group Wetter
attr FileLog_WetterOpenMeteo logtype text
attr FileLog_WetterOpenMeteo nrarchive 3


[Felix_86]

Wenn mir jemand einen guten Grund nennt, warum man einen bestimmten anderen Wert verwenden sollte ohne die Aktualität und die Systemlast nachteilig zu ändern, würde ich das übernehmen.

Liegt an meiner persönlichen Einstellung. Ich brauche keine 15 Minuten genauen Informationen. Ich behaupte mal mutig, dass ich in keinem Risikogebiet leben. In den Jahren der Nutzung des UWZ-Moduls war hier der Intervall auf 30 oder gar 60 Minuten gestellt und das reicht mir völlig aus.

[holle75]

@mumpitzstuff hats geschafft!

Nochmals vielen Dank.

Auf schnell mal einen Grafikvergleich VisualCrossing vs OpenMeteo, heute Abend arbeite ich den Rest auf.

EDIT: den wird es hier geben https://forum.fhem.de/index.php?topic=132792.msg1297222#msg1297222 ... schon zu sehr im "falschen Thread" genervt.

[Felix_86]

Auf schnell mal einen Grafikvergleich VisualCrossing vs OpenMeteo, heute Abend arbeite ich den Rest auf.

Bleibt jetzt nur die Frage, welcher der beiden Diensten der Realität entsprechend, die genaueren / besseren Werte liefert. Insbesondere bei den Wolken gibt es wohl deutliche Unterschiede. Wie ist hier dein Eindruck, wer stimmt eher?

[jensb]

... Intervall auf 30 oder gar 60 Minuten ... reicht mir völlig aus.

Nehme ich so mit. Werde dafür ein Attribut einführen - allerdings nicht kurzfristig, da ich gerade noch an etwas anderem arbeite.

[holle75]

Bleibt jetzt nur die Frage, welcher der beiden Diensten der Realität entsprechend, die genaueren / besseren Werte liefert. Insbesondere bei den Wolken gibt es wohl deutliche Unterschiede. Wie ist hier dein Eindruck, wer stimmt eher?

Bis jetzt, die Tage, sind die Werte sehr ähnlich (auch Wolken). Open Meteo liefert auch noch Sonnenstunden (VisualCrossing nicht) was ich recht interessant finde. Sympathisch ist bei OpenMeteo, dass man keinen Key braucht und das Ganze vermeintlich OpenSource und ein wenig menschenfreundlicher angedacht scheint. Obs so bleibt? So langsam das "WetterDistributorGewechsel" satt. Die ganze Umbastelei nervt.

Habe den Jungs ins Git auch nochmal die Frage nach den Alerts gehängt. Das ist im Moment (für mich) das einzige was fehlt. Ansonsten wirklich gut gemacht (alleine das Api zusammenklicken finde ich sehr zeitsparend) ... und natürlich, dass es europaweit (auch weltweit?) ist (wieder eher nur für mich interessant).

[Raha66]

Hallo Hallo,

Ich habe eine Frage bezüglich der aktuellen Temperatur und Luftfeuchtigkeit, bezieht sich das z.B. fc0_0_TTT auf die aktuelle Temperatur?
weil, wenn ich die measurement Wert in DWD app aussehen, scheint es Abweichung zu sein, ich habe in mehreren Tage und verschiedene Stunden, ähnliche Ergebnisse... oder gibt es eine andere id für aktuelle Temperatur und Luftfeuchtigkeit?
Danke

[mumpitzstuff]

Ich bin mir nicht mehr ganz sicher, glaube aber das DWD immer Vergangenheitswerte liefert, als immer wie das Wetter in der Stunde vor dem angegebenen Zeitpunkt gewesen war. Also wenn z.b. fc0_0 auf 00:00 Uhr steht, dann ist das der Zustand von ungefähr 23:30 Uhr. Wegen der minimalen Auflösung von 1h kann man das nicht genauer sagen.
Aber bitte meine Antwort mit Vorsicht genießen, das ist nur das, was ich zu wissen glaube und kann auch falsch sein.

0_0 ist glaube ich auch immer die selbe Urzeit des aktuellen Tages.

[jensb]

... oder gibt es eine andere id für aktuelle Temperatur und Luftfeuchtigkeit?

Ist wahrscheinlich klar, aber trotzdem: Die fc-Readings sind alles Vorhersagewerte, haben also nichts mit "aktuell" = Messung zu tun.

Die Zeit zu jedem fcN_M_YYY-Reading ist übrigens ein eigenes Reading namens fcN_M_time.

Wählt man z.B. 2 Stunden Auflösung, dann könnte bei fc0_1_time im Winter in Deutschland "03:00" stehen. Warum? 00:00 + 1 (M) x 2 h (Auflösung) + Zeitverschiebung zu UTC.

Außerdem sind nicht alle Werte an jeder Station im gleichen Zeitraster verfügbar. Das DWD-Modul wählt dann den nächstgelegen Wert oder lässt ihn entfallen, wenn der zeitliche Abstand zu groß wird. Wenn man genau wissen will, welcher Wert welche Zeitauflösung hat, muss man sich die Rohdaten für die eigene Station herunterladen und ansehen.