Wetterdaten - Wunderground API

Hi Demel,

danke für Dein Feedback und die guten Hinweise. Ich schaue was ich wie einbauen kann - ich habe die Tage Zeit und kann rundschleifen.

Updates kommen dann im Modul Thread ebenso der Hinweis wann ich Updates habe.

Eine Sache die wirklich sehr suboptimal seitens der API ist, ist der Umstand das immer mal Werte leer sind. Ich werde es mal im WU Forum posten.

Wie findest Du die Konfigurierbarkeit? Ist sie ausreichend granular?

Enno

Ach ja … und zu

Eine Nachfrage zu dem Upload: Du hast in der Doku angegeben, das man das WU-Passwort angeben soll. Nicht den Station-Key? Ich mache im Rahmen von meinem Netatmo-Modul auch den Upload und da verwende ich Station-ID und Station-Key.

Station ID und Passwort werden benötigt. Dein Modul schaue ich mal mal an - da ich keine Netatmo habe, war das nicht auf dem Radar. Weiterhin muss ich meine Upload noch deutlich erweitern, da meine DAVIS eine Menge mehr Daten liefert (aktuell erfolgt der Upload via Meteobridge). Es gibt also noch einiges zu tun.

Das ist meiner Erfahrung nach ein Problem, das viele API’s haben.
Ich verwende daher meistens eine Funktion


    private function GetArrayElem($data, $var, $dflt)
    {
        $ret = $data;
        $vs = explode('.', $var);
        foreach ($vs as $v) {
            if (!isset($ret[$v])) {
                $ret = $dflt;
                break;
            }
            $ret = $ret[$v];
        }
        return $ret;
    }

die wird so aufgerufen


$temperature = $this->GetArrayElem($jdata, 'main.temp', 0);
$conditions = $this->GetArrayElem($ent, 'weather.0.description', '');

  • data ist als array aufgebaut (also json_decode(xxx, true))
  • var ist der Namen des Array-Elementes, wenn das Element tiefer in der Hierarchie liegt werden die einzelnen Ebenen der Pfad hierzu durch ‚.‘ getrennt
  • dflt ist der Standardwert, den ich einsetze, wenn das Element nicht da ist / leer ist

Tja, das ist immer so ein Frage. Da ich eine unlimited Version habe, ist die Anzahl der Variablen nicht so relevant. Du rufst ja sowieso hier nur den Forecast ab, nicht die aktuelle Daten (https://api.weather.com/v2/pws/observations/current). Zwischen den zwei Call würde ich dann unterscheiden.

Die aktuellen Daten hat man ja selber geliefert … wobei (um deine Idee aufzugreifen) … wenn man nur z.B. die Temperatur liefert - bekommt man bei diesem Abruf nur diese Information oder zB den Wind dazu?
Für mich kein Thema, weil ich alle Daten selbst ermittle (ausser UV und Sonneneinstrahlung) und für Dich ja eher auch nicht (wenn ich dich richtig verstehe). Man kann aber auch die aktuellen Daten anderer PWS abrufen …

Zusammengefasst - mir würde die granulieren völlig ausreichen.

Hierzu vielleicht noch eine Anregung: ggfs ist es ja erforderlich, die Daten, die man schicken will, umzurechnen (Windgeschwindigkeit hat der eine in m/s und der andere in km/h).
Man kann das natürlich so machen, das man sich selbst in IPS eine Zusatzvariable erstellt und laufen berechnet und diese dann verwendet - klar geht das. Finde ich aber irgendwie nicht so dolle (ganz persönliches „Gefühl“).
In IPSymconOpenWeatherMap/OpenWeatherStation machen ich das daher so, das ich optional ein Script aufrufe, das bekommt alle vorher ermittelten Daten und liefert diese dann, ggfs umgerechnet oder ergänzt, zurück. Diese zurückgelieferten Daten verwenden ich dann um OpenWeatherMap mit Daten zu versorgen.

Gruß
demel

Ich denke meine Theorie sollten gehen, da der Download von Wetterdaten als Forecast an Geodaten und nicht an die Station gekoppelt ist. Die „Station“ benötigt man „nur“ damit man einen API Schlüssel bekommt - das sollte es sein.

Ich schaue mir das die Woche mal genauer an - wenn das geht kann man die API mehr oder weniger wie bisher nutzen und bekommt genaue Wetterdaten.

sehe ich auch so.

meine letzte Anmerkung war nur auf current (also die aktuellen Daten) bezogen, also schickt Temperatur zu WU und bekommt dann aber den Ist-Zustand von Wind und Regen zurück.
Aber klar, ist eine andere Baustelle.

demel

Ja klar … Current kann nur das liefern was da ist. Bei uns gibt es theoretisch 2 Stationen im Ort und eine 5km weg … wer wirklich auf Wetterdaten angewiesen ist, benötigt lokale Sensoren - da ist m.E. auch WU was ansich genau ist, zu ungenau - es sei denn der Nachbar hat eine Wetterstation.

Hi Demel,
mal eine Frage … verwendest Du die von dir beschriebene Funktion für jede Variable? Wenbn ich den Code richtig lese, die prüfst Du jede Variable ob sie leer ist und ersetzt sie dann mit einem Validen Wert. Das ist soweit ja auch sinnvoll, aber bei über 200 potentiellen Variablen die evtl. leer sind eine Menge Code mit überschaubarem Nutzen?

Sehe ich hier was falsch? Natürlich wäre es super die NULL’s abzufangen. Evtl… macht es Sinn das nur bei denen zu tun wo es oft der Fall ist und das wäre das aktuelle Segment (daypart0).

Sehe ich hier was falsch?

Hallo,

es geht natürlich nur über die Variablen, die Du auch auswerten willst, das ist klar.

Aber unabhängig davon, wie viele es sind, stellen sich ja immer zwei Probleme

a) man greift auf eine Element (egal ob Objekt oder Array) der json-Struktur zu. Ist das nicht da, rumst es, das Script bricht ab.
Also muss man jeden Zugriff mit isset testen - der Code ist dann schon umfangreicher.

Meiner Erfahrung nach kann man sich nie darauf verlassen, das alle Emelente da sind. Ich habe früher auch weniger geprüft, habe aber dann in der Nacharbeit immer wieder mit Abbrüchen aufgrund fehlender Felder zu tun gehabt.

b) was macht man, wenn das Feld zwar da ist, aber keinen Inhalt hat? Es ist natürlich eine eigenen Frage, wie man damit umgeht, wenn für eine bestimmte Variable keine Werte mehr kommen. Manchmal mag das bedeuten, das es keinen (neuen) Wert gibt und der alte weiter gilt, meiner Erfahrung nach ist es aber i.d.R. nicht so zu verstehen, der bisherige Wert ist nicht mehr gültig
Das muss man natürlich selbst entscheiden, wie man das gewichtet bzw. wie das auch in der jeweiligen API zu verstehen ist.

leider gibt es bei den IPS-Variablen nicht einen NULL-Wert - also nicht die Zahl 0, sondern das NICHTS. Das wäre mir am liebsten, denn dann wäre klar, es gibt diesen Wert im Augenblick nicht, also versuche ich Ersatzwerte zu nehmen, die möglichst nicht „falsch“ sind bzw dem Wert entsprechend, die in IPS für neue Variablen verwendet werden (also false für bool bzw. 0 für int/float).

Das eigene SetValue() benutze ich ja, damit das Script nicht rumst, wenn der Datentyp nicht zum IPS-Variablentyp passt.

Eine Menge Code sehe ich da allerdings nicht, das ist ja nicht mehr als der Zugriff auch die Variable

das hier


$temperature = $jdata['main']['temp'];
SetValue($this->GetIDForIdent("TEMP"), $temperature);

bzw das hier


if (isset($jdata['main']['temp'])) {
    $temperature = $jdata['main']['temp'];
    SetValue($this->GetIDForIdent("TEMP"), $temperature);
}

ist doch nicht kürzer als das hier?


$temperature = $this->GetArrayElem($jdata, 'main.temp', 0); 
$this->SetValue('TEMP', $temperature );

Gruß
demel

FYI … am 22.03.2019 wird die alte API für den Wetterdownload abgestellt … wie man an neue Keys kommt steht nochmal in dem Dokument. Für den Download der Wetterdaten könnt ihr das Wunderground PWS Sync Modul verwenden [Modul] Wunderground Wetterstation (PWS) Upload

Turning off PWS-associated keys | The WeatherAPI Community Customer Community

Wichtig auf der Hinweis, dass man den neuen Key am besten mit Chrome oder Edge erstellt wenn man den Link aufruft :slight_smile: