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.
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.
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.
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.
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).
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
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