59_Weather: neuer Provider gesucht / Mitstreiter für Neuentwicklung gesucht

[Dr. Boris Neubert]

Hallo,

heute morgen wollte ich auf meinem Display im Wohnzimmer nachsehen, wie das Wetter an Ostern ist. Daraufhin habe ich beschlossen, dass wir uns von Yahoo-Wetter verabschieden.

Ich möchte gerne dem hier im Forum vorgebrachten Vorschlag folgen, das Weather-Modul plug-in-fähig zu machen. Ziel ist es, weiter die bestehenden Readings anzubieten inklusive der Icons.

Ich würde 59_Weather.pm überarbeiten. Ich suche Mitstreiter, die Plugins (Perl-Module) bereitstellen, z.B. für Proplanta oder Wetter.com. In einem separaten Thread vereinbaren wir dann ein simples API für die Plugins, z.B. eine Funktion, die die Wettervorhersage als Array von Hashes bereit stellt.

Viele Grüße
Boris

[betateilchen]

Für deutsche Vorhersagegebiete sind die Daten des DWD bereits weitgehend gekapselt und WeatherAsHtml-kompatibel im GDS Modul implementiert (von einem anderen Entwickler zugeliefert) damit könnte man vielleich anfangen.

[Markus Bloch]

Klingt interessant. Würde ich mich beteiligen.

Ich würde vorschlagen den Maintainer von Twilight mit einzubinden da dort auch Yahoo verwendet wird. Evtl. sollte man das mit weather verheiraten, damit dort keine doppelte Pflege notwendig ist.

Gruß
Markus

[CoolTux]

Wenn ich das richtig gesehen habe hat Dietmar gestern Abend schon auf die neuen Umstände reagiert und Anpassungen in Form von ignorieren in Twilight eingebaut wenn keine Daten von Yahoo kommen.

Boris, ich würde gerne versuchen den API Key als Bypasslösung auf die Schnelle ins Weather Modul mit ein zu bauen. Ich brauche es leider. Wäre das ok oder hast du eine andere Idee für eine schnelle kurzfristige Lösung?


Grüße

[Dr. Boris Neubert]

Boris, ich würde gerne versuchen den API Key als Bypasslösung auf die Schnelle ins Weather Modul mit ein zu bauen. Ich brauche es leider. Wäre das ok oder hast du eine andere Idee für eine schnelle kurzfristige Lösung?

Was meinst Du mit API Key?

[CoolTux]

Wenn ich das richtig verstanden habe wurde die API welche bis zum 15.3 Public war auf O-Auth umgestellt. Hierfür kann man einen App API Key beantragen. Ich habe mir mal einen von einen User geborgt und wollte das mal testen.


Grüße
Leon

[Dr. Boris Neubert]

Ah, ich sehe:

Code Auswählen Erweitern

https://developer.yahoo.com/weather/

Sehr gerne. Wenn es klappt, besorge ich mir bzw. dem FHEM-Projekt einen eigenen API-Key.

Viele Grüße
Boris

[herrmannj]

Bin auch dabei. Ich bin verfechter von wu. Ist aber etwas tricky. Wu bietet die api eigentlich als bezahlten dienst an. Gleichzeitig gibt es kostenlose developer keys. Nun bin ich mir nicht sicher was passiert wenn alle loslaufen und sich developer keys holen....

Vg
Joerg

[Markus Bloch]

Ich glaube diese API Key-Geschichte ist nochmal ein eigenes Thema. Ich habe für klicktel.de, search.ch und weiter Telefonbuchanbieter bei FB_CALLMONITOR ebenfalls eigene FHEM API Keys.

Da sollte man nochmal getrennt schauen, wie man sowas handeln sollte. Ist nicht immer rechtlich ganz klar, ob die Applikation selber einen Key braucht, oder jeder enduser einen eigenen benötigt.

Gruß

Markus

[CoolTux]

Mittlerweile habe ich Code welcher ohne API Key geht. Muss nur mal etwas kontrolliert werden

Datei 59_Weather.pm
Zeile 288

Code Auswählen Erweitern


my $url = "https://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20weather.forecast%20where%20woeid%20=%27". $location ."%27%20and%20u=%27". $units. "%27&format=xml&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys";


Datei 59_Twilight
Zeile 362

Code Auswählen Erweitern


url        => "https://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20weather.forecast%20where%20woeid%20=%27". $location ."%27%20and%20u=%27c%27&format=xml&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys",




Grüße

[Dr. Boris Neubert]

Sehr gut. Das funktioniert.

Nur die Einheiten sind US:

Code Auswählen Erweitern

<yweather:units xmlns:yweather="http://xml.weather.yahoo.com/ns/rss/1.0" distance="mi" pressure="in" speed="mph" temperature="F"/>

Wind, Visibility und Pressure werden abgerufen aber vom Modul nicht ausgewertet. Da scheint sich das Format geändert zu haben.

Das lässt sich alles reparieren.

Vielleicht stelle ich dann auch gleich noch auf JSON um.

Wollte an Ostern eigentlich was anderes programmieren 

Viele Grüße
Boris

[CoolTux]

Meine oben genannte URL sollte eigentlich deutsche Einheiten nehmen. Seltsam. Ich kann es leider nur im Browser testen, Dank https muss ich erstmal meinen Proxy konfigurieren.
Denke aber auch das es sich alles reparieren lässt. JSON wäre natürlich leichter zu händeln.

Aber erstmal ist Familie und Ostern.



Grüße

[Dr. Boris Neubert]

Kurzes Update: arbeite dran...

[CoolTux]

Super Boris, vielen lieben Dank für die Info.


Grüße

[Dr. Boris Neubert]

So. Anbei die neue Version mit der Bitte um Test.

Ich habe das YahooWeatherAPI.pm ausgelagert. Vielleicht können sich dann das Twilight-Modul und das Weather-Modul den Code teilen.

Es basiert auf dem JSON-API. Das ist viel einfacher als XML von Hand parsen.

Ich habe herausgefunden, wie man um metrische Einheiten bittet. Aber das API hat noch Bugs, da dennoch die gefühlte Temperatur wind_chill in °Fahrenheit und pressure in inHg geliefert werden. Dafür habe ich einen Workaround eingebaut.

Ich habe dann auch gleich die Timer-Verwaltung nach dem Vorbild von Calendar rationalisiert. Der Timer läuft jetzt erst nach dem Abschluss der FHEM-Initialisierung los.

Dazu auch noch den Code entschlackt - Frühjahrsputz erledigt!

Viel Spaß! Bei mir zeigt er schon wieder das Wetter. Nur schön ist es leider nicht.

Gute Nacht
Boris

[CoolTux]

Guten Morgen Boris,

Das sieht sehr gut aus. Erste kurze Tests zeigen positives. Noch mal meinen allerherzlichsten Dank. Ich schaue mal wie ich das ins Twilight Modul bekomme, eventuell schaffe ich es den Dietmar etwas zu unterstützen.



osterliche Grüße
Leon

[Benni]

Guten Morgen Boris,

ich hab's bei mir auch mal eingespielt.
Sieht soweit schon mal gut aus! 

Danke!

Gruß Benni.

[dev0]

Works like a charm! Thanx!

[Dr. Boris Neubert]

Fein, hab's eingecheckt.

[Dr. Boris Neubert]

Ich schaue mal wie ich das ins Twilight Modul bekomme, eventuell schaffe ich es den Dietmar etwas zu unterstützen.

Falls Dietmar das YahooWeatherAPI auch in Twilight verwenden möchte, schlage ich vor, dass wir einen Cache einbauen und dem Ladebefehl einen optionalen Parameter mitgeben, der angibt, wie alt die Daten im Cache höchstens sein dürfen. Das machen wir bitte in einem separaten Thread.

Viele Grüße
Boris

[CoolTux]

Falls Dietmar das YahooWeatherAPI auch in Twilight verwenden möchte, schlage ich vor, dass wir einen Cache einbauen und dem Ladebefehl einen optionalen Parameter mitgeben, der angibt, wie alt die Daten im Cache höchstens sein dürfen. Das machen wir bitte in einem separaten Thread.

Viele Grüße
Boris

Wenn es ok für Sich ist und ich dazu komme melde ich mich heute Abend mal per PM bei Dir.

Grüße

[Dr. Boris Neubert]

Hallo,

das ist OK. Schönen Ostermontag noch.

Viele Grüße
Boris

[Volker Kettenbach]

Hallo,

habe das Modul installiert. Funktioniert.
Danke, Boris!

Gruß
Volker

[Volker Kettenbach]

Zum Thema "Neuer Provider" hätte ich einen Vorschlag:

In einem anderem Projekt verwenden wir http://forecast.io/
Das ist eine professionelle Wetter-API.

Unter https://developer.forecast.io/ kann sich jeder Nutzer der API einen API-Key besorgen, der für 1000 Calls am Tag kostenlos ist. 1000 Calls reichen für einen privaten Anwender locker aus, insbesondere wenn man einen Cache einbaut.

In dem anderen Projekt beziehen wir von forecast.io die Wetterdaten für mehrere Standorte und haben einen einfachen File-Cache eingebaut, so dass die Daten nicht bei jedem Webseite-Zugriff, sondern nur alle 30 Minuten für jeden Standort aktualisiert werden. So kann ich 20 verschiedene Standorte abfragen, ohne Kosten zu verursachen.

Die API ist sehr gut dokumentiert und in den üblichen Web-Toolkits sehr einfach zu benutzen
https://developer.forecast.io/docs/v2
Hier gäbe es den entsprechenden Perl-Wrapper: http://search.cpan.org/~martyloo/Forecast-IO-0.21/lib/Forecast/IO.pm

Zudem ist die API stabil und wir nicht einfach adhoc geändert, wie das beim Abgriff von Diensten wie Yahoo der Fall ist.

Ich glaube, das wäre eine Alternative.
Kann ggf. Hilfe anbieten.

Gruß
Volker

[herrmannj]

Hi,

ich habe bei Weather underground nachgefragt und denen erklärt das es sich um viele einzelne Installationen handelt. Antwort:

Thank you for reaching out to us and confirming the terms and conditions. To answer your question, it is not legal to ask users to register for separate API keys to be used in an app. You can start with a free developer account and make calls to the API less frequently to save on calls.
Once your user base grows, you can switch to a paid plan and update the weather more frequently.

Die Antwort ist nicht ganz zur Frage passend aber man kann festhalten das unser use-case nicht mit dem model von wu kompatibel ist.

vg
joerg

[justme1968]

zu forecast.io: wie gut und umfangreich sind denn die daten für deutschland? das api schaut interessant aus. aber wenn man die quelle für die daten anschaut ist fast alles usa basiert. ich würde also vermuten das dort die auflösung und auch der umfang sehr viel besser ist. vor allem was die vielen 'where available' punkte betrifft.

zu den api keys: ich vermute dieses problem gibt es mit fast allen diensten und plattformen die solche api keys anbieten ohne eigene hardware zu verkaufen. das geschäftsmodell ist ja über die api keys umsatz zu generieren.

gruss
  andre

[herrmannj]

zu den api keys: ich vermute dieses problem gibt es mit fast allen diensten und plattformen die solche api keys anbieten ohne eigene hardware zu verkaufen. das geschäftsmodell ist ja über die api keys umsatz zu generieren.

Yepp. Zu Recht. Aber machts halt nicht einfacher. Irgendwie auch schade. Also mal bei forecast.io rein schauen. Die europäischen Daten werden scheinbar in Norwegen produziert.

vg
joerg

[Markus Bloch]

Wie ich sehe, hat sich über Ostern hier einiges getan. Da ich über Ostern auf Urlaub war, konnte ich leider nicht helfen. Gibt es jetzt noch Baustellen, Erweiterungen bei denen Hilfe gewünscht ist?

Gruß
Markus

[Sidey]

Hi,

kurzes Feedback zum Modul:

Ich habe soeben geupdated.
Zuerst wurde die Temperatur in Fahrenheit angezeigt (temp_C war 51) nach ein paar Minuten wird sie in Celsius angezeigt (11).

Scheint irgendwo noch ein Detail nicht zu stimmen.

Grüße Sidey

[Dr. Boris Neubert]

Wie ich sehe, hat sich über Ostern hier einiges getan. Da ich über Ostern auf Urlaub war, konnte ich leider nicht helfen. Gibt es jetzt noch Baustellen, Erweiterungen bei denen Hilfe gewünscht ist?

Danke, Markus, für Dein Angebot. Ich glaube, dass ich fertig bin    cooltux hat den entscheidenden Hinweis auf das API geliefert, der Rest war Fleißarbeit.

Viele Grüße
Boris

[Dr. Boris Neubert]

Zuerst wurde die Temperatur in Fahrenheit angezeigt (temp_C war 51) nach ein paar Minuten wird sie in Celsius angezeigt (11).

Merkwürdig. Vielleicht ein Restant aus fhem.save? Wenn es wieder vorkommt, wäre es interessant zu sehen, ob auch die anderen Temperaturen (in den Forecasts) in °F sind.

Viele Grüße
Boris

[Volker Kettenbach]

zu forecast.io: wie gut und umfangreich sind denn die daten für deutschland? das api schaut interessant aus. aber wenn man die quelle für die daten anschaut ist fast alles usa basiert. ich würde also vermuten das dort die auflösung und auch der umfang sehr viel besser ist. vor allem was die vielen 'where available' punkte betrifft.

Also, ohne dass jetzt exakt beweisen zu können: ich habe bisher keinerlei Probleme gehabt und das Wetter hat - im Rahmen der üblichen Ungenauigkeiten - auch gestimmt. Ob ein "Minute-by-minute forecasts out to 1 hour" nötig ist, muss jeder für sich entscheiden. Mir persönlich reicht ein "Hour-by-hour forecasts out to 48 hours" vollkommen aus und den gibt es überall.

Bezogen werden die Daten für Europa vom Norwegischen Wetterdienst (http://forecast.io/raw/).

Ich glaube auch nicht, dass Yahoo oder andere "bessere" Daten liefern. "Bessere" Daten sind im Bereich Wetter sowieso zahlenden Kunden vorbehalten.

zu den api keys: ich vermute dieses problem gibt es mit fast allen diensten und plattformen die solche api keys anbieten ohne eigene hardware zu verkaufen. das geschäftsmodell ist ja über die api keys umsatz zu generieren.

Bei forecast.io muss sich jeder User des Moduls einen eigenen API-Key besorgen. Mit dem bekommt er 1000 Calls pro Tag kostenlos. Für mehr, muss er einen Paymentplan haben.
Eine FHEM-Modul, welches beim define den API-Key des FHEM-Anwenders übergeben bekommt, entspräche den Terms of Use der Schnittstelle https://developer.forecast.io/terms_of_use.txt

Was nicht erlaubt - und zu dem nicht mit 1000 Call/Tag machbar - ist, wäre einen festen API-Key in das FHEM-Modul ein zu bauen.

[justme1968]

@boris: ich hatte heute auch schon zwei mal werte in fahrenheit statt in celsius. es ist mir im vorbeigehen am tablet aufgefallen. die werte um die 50 sind dann tief rot. beim ersten mal hab ich nur ein get update gemacht und es war wieder weg, beim zweiten mal wollte ich genauer schauen da ist dann der automatische update dazwischen gekommen mit dem es auch wieder gut war.

mindestens ein mal war auch der luftdruck auf 1.

@Volker Kettenbach: der hintergrund der frage war eher die ganzen features die mit 'where avalieble' markiert sind wie z.b entfernung und  rrichtung des nächsten sturmes und der warnungen. wenn die in deutschland nicht dabei sind wäre es vielleicht sinnvoller gleich die dwd daten zu verwenden wie oben von betateilchen vorgeschlagen. die kostenlosen daten aus der grundversorgung sind ja schon recht umfangreich.

oder auch konfigurierbar daten aus mehreren quellen zu mischen und auf plausibilität zu prüfen.

[Dr. Boris Neubert]

@boris: ich hatte heute auch schon zwei mal werte in fahrenheit statt in celsius. es ist mir im vorbeigehen am tablet aufgefallen. die werte um die 50 sind dann tief rot. beim ersten mal hab ich nur ein get update gemacht und es war wieder weg, beim zweiten mal wollte ich genauer schauen da ist dann der automatische update dazwischen gekommen mit dem es auch wieder gut war.

mindestens ein mal war auch der luftdruck auf 1.

Das YahooWeatherAPI bringt mich um den Verstand.

Ich habe gerade eine Version eingecheckt, die 4 neue Readings namens unit_ hat. Ich würde gerne wissen, was diese Readings in den Fällen zeigen, wo die Temperaturen offensichtlich in °F sind.

Ich bin ab morgen in Urlaub. Ich verfolge das Treiben hier dann zwar mit und kann auch posten aber nicht FHEM entwickeln. Hilfe nehme ich gerne an.

Viele Grüße
Boris

[CoolTux]

Hallo Boris,

Ich kann schauen ob ich Dir da unter die Arme greifen kann. Wird zwar nur Abends gehen aber so bekommen wir vielleicht etwas Vorarbeit hin.


Grüße

[CoolTux]

Habe gerade !al in mein Log geschaut. Ich habe auch hin und wieder hohehohe Werte. Also Fahrenheit Angaben.
Ich werde mal ein Notify bauen was auf Werte Höher 25 an schlägt und mich Informiert. Ausserdem will ich heute Abend das Modul so bauen das mir die Rohdaten sowie die geparsten zwischen gespeichert werden.
Allerdings gehe ich davon aus das es was mit der Umwandlung von Celsius in Fahrenheit zu tun hat. Kann nur gerade nicht in den Code schauen.


Grüße

[Dr. Boris Neubert]

Allerdings gehe ich davon aus das es was mit der Umwandlung von Celsius in Fahrenheit zu tun hat. Kann nur gerade nicht in den Code schauen.

Das wird nichts umgewandelt. Die Celsius-Grade sollen so vom API geliefert werden. Die einzigen Umwandlungen, die drin sind, sind Workarounds für nachweislich immer in US-Einheiten gelieferte Werte.

Grüße
Boris

[CoolTux]

Ach so, dann habe ich das falsch verstanden. Ich schaue es mir heute Abend mal in Ruhe an.
Dir auf jedenfall einen entspannten Urlaub.


Grüße

[CoolTux]

Hilft das?
Netter Weise zur Verfügung gestellt.

Code Auswählen Erweitern


Internals:
   DEF        12836009 1800 de
   INTERVAL   1800
   LANG       de
   LOCATION   12836009
   NAME       bibi
   NOTIFYDEV  global
   NR         21
   NTFY_ORDER 50-bibi
   STATE      T: 55  H: 45  W: 4  P: 1
   TYPE       Weather
   UNITS      c
   Readings:
     2016-03-29 18:58:46   city            Bietigheim-Bissingen
     2016-03-29 18:58:46   code            26
     2016-03-29 18:58:46   condition       wolkig
     2016-03-29 18:58:46   country         Germany
     2016-03-29 18:58:46   current_date_time Tue, 29 Mar 2016 06:00 PM CEST
     2016-03-29 18:58:46   day_of_week     Di
     2016-03-29 18:58:46   description     Yahoo! Weather for Bietigheim-Bissingen, BW, DE
     2016-03-29 18:58:46   fc10_code       28
     2016-03-29 18:58:46   fc10_condition  überwiegend wolkig
     2016-03-29 18:58:46   fc10_date       07 Apr 2016
     2016-03-29 18:58:46   fc10_day_of_week Do
     2016-03-29 18:58:46   fc10_high_c     57
     2016-03-29 18:58:46   fc10_icon       mostlycloudy
     2016-03-29 18:58:46   fc10_low_c      44
     2016-03-29 18:58:46   fc1_code        12
     2016-03-29 18:58:46   fc1_condition   Schauer
     2016-03-29 18:58:46   fc1_date        29 Mar 2016
     2016-03-29 18:58:46   fc1_day_of_week Di
     2016-03-29 18:58:46   fc1_high_c      54
     2016-03-29 18:58:46   fc1_icon        chance_of_rain
     2016-03-29 18:58:46   fc1_low_c       44
     2016-03-29 18:58:46   fc2_code        39
     2016-03-29 18:58:46   fc2_condition   vereinzelt Gewitter
     2016-03-29 18:58:46   fc2_date        30 Mar 2016
     2016-03-29 18:58:46   fc2_day_of_week Mi
     2016-03-29 18:58:46   fc2_high_c      50
     2016-03-29 18:58:46   fc2_icon        scatteredthunderstorms
     2016-03-29 18:58:46   fc2_low_c       45
     2016-03-29 18:58:46   fc3_code        39
     2016-03-29 18:58:46   fc3_condition   vereinzelt Gewitter
     2016-03-29 18:58:46   fc3_date        31 Mar 2016
     2016-03-29 18:58:46   fc3_day_of_week Do
     2016-03-29 18:58:46   fc3_high_c      66
     2016-03-29 18:58:46   fc3_icon        scatteredthunderstorms
     2016-03-29 18:58:46   fc3_low_c       45
     2016-03-29 18:58:46   fc4_code        28
     2016-03-29 18:58:46   fc4_condition   überwiegend wolkig
     2016-03-29 18:58:46   fc4_date        01 Apr 2016
     2016-03-29 18:58:46   fc4_day_of_week Fr
     2016-03-29 18:58:46   fc4_high_c      52
     2016-03-29 18:58:46   fc4_icon        mostlycloudy
     2016-03-29 18:58:46   fc4_low_c       43
     2016-03-29 18:58:46   fc5_code        30
     2016-03-29 18:58:46   fc5_condition   teilweise wolkig
     2016-03-29 18:58:46   fc5_date        02 Apr 2016
     2016-03-29 18:58:46   fc5_day_of_week Sa
     2016-03-29 18:58:46   fc5_high_c      64
     2016-03-29 18:58:46   fc5_icon        partly_cloudy
     2016-03-29 18:58:46   fc5_low_c       42
     2016-03-29 18:58:46   fc6_code        30
     2016-03-29 18:58:46   fc6_condition   teilweise wolkig
     2016-03-29 18:58:46   fc6_date        03 Apr 2016
     2016-03-29 18:58:46   fc6_day_of_week So
     2016-03-29 18:58:46   fc6_high_c      65
     2016-03-29 18:58:46   fc6_icon        partly_cloudy
     2016-03-29 18:58:46   fc6_low_c       46
     2016-03-29 18:58:46   fc7_code        12
     2016-03-29 18:58:46   fc7_condition   Schauer
     2016-03-29 18:58:46   fc7_date        04 Apr 2016
     2016-03-29 18:58:46   fc7_day_of_week Mo
     2016-03-29 18:58:46   fc7_high_c      59
     2016-03-29 18:58:46   fc7_icon        chance_of_rain
     2016-03-29 18:58:46   fc7_low_c       48
     2016-03-29 18:58:46   fc8_code        39
     2016-03-29 18:58:46   fc8_condition   vereinzelt Gewitter
     2016-03-29 18:58:46   fc8_date        05 Apr 2016
     2016-03-29 18:58:46   fc8_day_of_week Di
     2016-03-29 18:58:46   fc8_high_c      58
     2016-03-29 18:58:46   fc8_icon        scatteredthunderstorms
     2016-03-29 18:58:46   fc8_low_c       48
     2016-03-29 18:58:46   fc9_code        39
     2016-03-29 18:58:46   fc9_condition   vereinzelt Gewitter
     2016-03-29 18:58:46   fc9_date        06 Apr 2016
     2016-03-29 18:58:46   fc9_day_of_week Mi
     2016-03-29 18:58:46   fc9_high_c      57
     2016-03-29 18:58:46   fc9_icon        scatteredthunderstorms
     2016-03-29 18:58:46   fc9_low_c       47
     2016-03-29 18:58:46   humidity        45
     2016-03-29 18:58:46   icon            cloudy
     2016-03-29 18:58:46   lastError
     2016-03-29 18:58:46   lat             48.954899
     2016-03-29 18:58:46   long            9.11773
     2016-03-29 18:58:46   pressure        1
     2016-03-29 18:58:46   pressure_trend  0
     2016-03-29 18:58:46   pressure_trend_sym =
     2016-03-29 18:58:46   pressure_trend_txt gleichbleibend
     2016-03-29 18:58:46   pubDate         Tue, 29 Mar 2016 06:00 PM CEST
     2016-03-29 18:58:46   pubDateComment  okay
     2016-03-29 18:58:46   pubDateRemote   Tue, 29 Mar 2016 06:00 PM CEST
     2016-03-29 18:58:46   pubDateTs       1459267200
     2016-03-29 18:58:46   region           BW
     2016-03-29 18:58:46   state           T: 55  H: 45  W: 4  P: 1
     2016-03-29 18:58:46   temp_c          55
     2016-03-29 18:58:46   temperature     55
     2016-03-29 18:58:46   unit_distance   mi
     2016-03-29 18:58:46   unit_pressuree  in
     2016-03-29 18:58:46   unit_speed      mph
     2016-03-29 18:58:46   unit_temperature F
     2016-03-29 18:58:46   validity        up-to-date
     2016-03-29 18:58:46   visibility      10
     2016-03-29 18:58:46   wind            4
     2016-03-29 18:58:46   wind_chill      13
     2016-03-29 18:58:46   wind_condition  Wind: WNW 4 km/h
     2016-03-29 18:58:46   wind_direction  290
     2016-03-29 18:58:46   wind_speed      4
   Fhem:
     interfaces temperature;humidity;wind
   Helper:
     Bm:
       Weather_get:
         cnt        4
         dmx        0
         mAr
         max        0
         tot        0
       Weather_notify:
         cnt        1
         dmx        0
         mAr
         max        0
         tot        0
       Weather_set:
         cnt        25
         dmx        0
         mAr
         max        0
         tot        0
Attributes:
   room       Test


[Dr. Boris Neubert]

Ja, das miserable API tut nicht, was es soll.

Es gibt zwei Möglichkeiten:
- Die Lieferung ignorieren, wenn nicht die angeforderten metrischen Einheiten kommen.
- Umrechnen ins metrische System, wenn US-Einheiten kommen.

Ich bevorzuge die zweite Variante. Allerdings bin ich mittlerweile geneigt, diese Umrechnungen im API zu machen.

Zur Linderung der größten Not habe ich erst einmal Variante 1 eingecheckt.

[CoolTux]

Eigentlich finde ich persönlich das nicht so schlimm. Aber es gibt halt User die sich Plots erstellen und dann erschrecken. Lach. Aber jetzt weiß ich auch wieso sich Twilight hin und wieder seltsam verhält. Werde ich wohl noch nachbessern dürfen.


Grüße

[Volker Kettenbach]

@Volker Kettenbach: der hintergrund der frage war eher die ganzen features die mit 'where avalieble' markiert sind wie z.b entfernung und  rrichtung des nächsten sturmes und der warnungen. wenn die in deutschland nicht dabei sind wäre es vielleicht sinnvoller gleich die dwd daten zu verwenden wie oben von betateilchen vorgeschlagen. die kostenlosen daten aus der grundversorgung sind ja schon recht umfangreich.
oder auch konfigurierbar daten aus mehreren quellen zu mischen und auf plausibilität zu prüfen.

Nach so speziellen Daten hatte ich bisher keine Nachfrage.

Der große Haken am DWD ist meiner Meinung nach, dass die Schnittstelle aus der Steinzeit ist: man muss Files per FTP holen und dann parsen.

Wenn ich die Tage Luft habe und mit meinem anderen FHEM-Modul fertig bin, schreibe ich ein Modul für forecast.io.

Gruß
VK

[justme1968]

Der große Haken am DWD ist meiner Meinung nach, dass die Schnittstelle aus der Steinzeit ist: man muss Files per FTP holen und dann parsen.

und es ändert sich scheinbar alle paar wochen alles mögliche...

[Prof. Dr. Peter Henning]

Ich bin ein großer Freund von wunderground - hat nach meinen Vergleichen die präziseste Vorhersage. Ich glaube auch, dass die die Frage irgendwie noch nicht ganz verstanden haben - denn eigentlich sollte sich da ein Deal machen lassen.

LG

pah

[herrmannj]

Ich bin ein großer Freund von wunderground - hat nach meinen Vergleichen die präziseste Vorhersage. Ich glaube auch, dass die die Frage irgendwie noch nicht ganz verstanden haben - denn eigentlich sollte sich da ein Deal machen lassen.

LG

pah

Ja sehe ich auch so. (Präzise).

Wenn Du magst kannst Du ja nochmal weiter mir denen ins Gebet gehen. Ich kann Dir anfrage und Antwort gern weiterleiten. Mir fehlt der Nerv auf lange Diskussionen .

Technisch wäre ich bereit einen proxy zu spendieren der den key vorhält. Damit könnte man das Verteilen des keys überflüssig machen.

Herausforderung: es wäre kaum möglich ohne zusätzliche Authentifizierung die Zugriffe (auf fhem Module) zu begrenzen (der code wäre ja im svn sichtbar). Außerdem würde die Anzahl der Abfragen mMn recht fix im bezahlten Bereich liegen.

vg
joerg

[betateilchen]

wo ist denn eigentlich das Problem, wenn man vom Anwender eines Moduls erwartet, dass er sich bei wunderground einen eigenen key besorgt?

Bei den Zugangsdaten für das 55_GDS.pm Modul und beim API Key für 98_openweathermap.pm hat sich jedenfalls noch kein User daran gestört, dies einmalig tun zu müssen.

[herrmannj]

geht schon. Ist aber gegen die Terms. Hab ja deswegen da nachgefragt:

To answer your question, it is not legal to ask users to register for separate API keys

vg
joerg

[betateilchen]

Nein, ich stelle jetzt nicht die Frage, wie man bei wunderground kontrollieren möchte, wofür jemand einen api key verwendet.

[herrmannj]

na das können die nicht prüfen.

Aber: zu erst finde ich das schon ein Gebot von Fairness. Es gibt ja keinen Anspruch auf kostenlose Wetterdaten und wenn wu das bereitstellt (wir sind uns einig das sie das gut machen) dann ist es auch ok wenn die a: die Regeln vorgeben und b: auch etwas einnehmen wollen. Total in Ordnung, dafür müssen sie Server betreiben, Leute bezahlen etc.

Ich persönlich bin auch durchaus bereit da etwas für zu zahlen, wenn das umlegt sind es ja echt nur 'peanuts'.

Natürlich kann man die Vorgaben ignorieren und alle fangen an sich KEYs zu holen. Aber die Leute von WU sind ja auch nicht doof. Das wird mittelfristig doch dazu führen das es eben keine KEYs mehr gibt oder andere Kunstgriffe werden eingeführt und dann wird es nicht mehr nutzbar sein.

Von daher bin ich absolut bei pah, vielleicht läßt sicch was aushandeln. Aber again: da fehlt mir der Nerv und die Zeit.

vg
joerg

[betateilchen]

ja, Du hast ja recht...

[betateilchen]

(http://up.picr.de/25057103pq.png)

Das Debian Paket libjson-perl wird künftig als Voraussetzung für die Installation des .deb Paketes von fhem geführt, da json inzwischen von immer mehr fhem-Modulen verwendet wird.

[CoolTux]

Finde ich sehr gut und sinnvoll.


Grüße

[Dr. Boris Neubert]

Hallo,

ich habe 59_Weather.pm und das YahooWeatherAPI.pm überarbeitet und zum Testen hier angehängt. Folgende Änderungen:

• Neue Funktion YahooWeatherAPI_RetrieveDataWithCache($$): das erste Argument ist das maximal erlaubte Alter der Daten im Cache in Sekunden. Sind die Daten im Cache älter, wird neu abgeholt. Gecachet wird pro WOEID.
• Es wird die Antwort gecachet, sobald von Yahoo eine nichtleere Antwort zurückgegeben wird. Enthält die Antwort kein Ergebnis (count=0), wird das gecachet, weil die abholende Routine nichts vom Inhalt versteht.
• Das Weather-Modul versucht alle 60 Sekunden neu unter Umgehung des Cache Daten abzuholen, bis es eine valide Antwort bekommt, das das Modul den Inhalt versteht.
• Unter normalen Bedingungen akzeptiert das Weather-Modul Daten aus dem Cache, wenn diese nicht älter als 600 Sekunden sind.
• Liefert Yahoo Daten in US-Einheiten, dann werden diese umgerechnet - das habe ich nicht getestet! Wenn umgerechnet wurde, ist das Reading isConverted auf 1, sonst auf 0. Die units-Readings sind entfernt.

Viele Grüße
Boris

[CoolTux]

Mensch Boris Klasse. Vielen Dank. Habe mich gerade heute mit Dietmar wegen dem Caching unterhalten. Und schwupz ist es schon da.

Ich schaue mir das morgen mal in Ruhe an.
Nur ganz kurz das ich das verstehe. Die Zentrale Schnittstelle für die Darstellung des Wetters soll das Weather Modul werden. Die Daten kann es sich aus unterschiedlichsten WeatherAPI Modulen holen. Korrekt?
Wo finde ich Informationen darüber wie die Daten geliefert werden müssen damit das Weather Modul sie korrekt darstellen kann?


Grüße

[Dr. Boris Neubert]

Hallo,

im Prinzip ja, aber einen weiteren Provider für das Wetter gehe ich nur an, wenn der Yahoo-Kram unerträglich wird.

Wenn Du im YahooWeatherAPI.pm oben use Data::Dumper; und in Zeile 240 das Debugging einkommentierst, siehst Du, was das Wetter-Modul gerne hätte. Wobei nur der Teil der Struktur ab/unterhalb von $data->{query}{results}{channel} die interessante Nutzlast ist, die ans Wetter-Modul hochgereicht wird.

Die Code für die Witterung und die Icons ergeben sich aus den @YahooCodes_xx am Anfang des Moduls.

Viele Grüße
Boris

[CoolTux]

Super. Ich danke Dir für die Infos.

Grüße

[Prof. Dr. Peter Henning]

Melde mich freiwillig, um das Interface zu wunderground zu bauen.

Wird aber dauern, da ich noch andere Baustellen habe.

LG

pah

[CoolTux]

Hallo pah

Genau das wollte ich mir auch anschauen. Hast Du Lust auf eine Zusammenarbeit wenn ich meine Baustellen weg habe?



Grüße

[Prof. Dr. Peter Henning]

Klar, machen wir gerne. Betreibe Wunderground schon länger mit HTTPMOD, inklusive der Nachbearbeitung zu vorlesegeeigneten Wetternachrichten.

Das wäre übrigens etwas für das Hauptmodul.

LG

pah

[CoolTux]

Dann würde ich sagen wenn einer von uns beiden dann so weit ist klären wir den Rest per PM.


Grüße

[CoolTux]

Hallo Boris,

Ich fange gerade an für Wunderground die ersten Codeteile vor zu bereiten. Es stehen aber noch einige Fragen im Raum.
59_Weather sollte ja universal sein.

• woeid wird in 59_Weather an gegeben und in der YahooAPI weiterverarbeitet, für Wunderground nennt sich das Station_ID. Es ist ja egal wie man das Kind nennt, daher meine Frage. So lassen??
• wie hand haben wir das define von 59_Weather? Wo gebe ich an welche API er verwenden soll. Sollte im Define angegeben werden finde ich. Es gibt auch API's mit Key. Auch der sollte ins Define

Es wird da sicherlich noch mehr Fragen geben. Aber ich gehe es erstmal langsam an   



Grüße

[Prof. Dr. Peter Henning]

Wenn wir schon bei Fragen der allgemeineneren Module sind:

Bei mir werden Wetternachrichten vorgelesen. Das bedeutet beispielsweise, dass man aus "Temperatur 10.4 °C" ein "Temperatur 10 Komma 4 Grad" machen muss.

So etwas gehört m.E. in die global verfügbaren Utilities - etwa als Funktion "translate2TTS". Die Frage ist aber, ob das dann wirklich von jedem selbst aufgerufen werden soll (man definiert eben einen dummy oder ein readingsProxy, welche diese Funktion ruft), oder ob man es auch als Option in das allgemeine Wettermodul einbaut.

LG

pah

[Dr. Boris Neubert]

Bei mir werden Wetternachrichten vorgelesen. Das bedeutet beispielsweise, dass man aus "Temperatur 10.4 °C" ein "Temperatur 10 Komma 4 Grad" machen muss.

So etwas gehört m.E. in die global verfügbaren Utilities - etwa als Funktion "translate2TTS". Die Frage ist aber, ob das dann wirklich von jedem selbst aufgerufen werden soll (man definiert eben einen dummy oder ein readingsProxy, welche diese Funktion ruft), oder ob man es auch als Option in das allgemeine Wettermodul einbaut.

Ich würde das gerne einbauen, weiß aber nicht, wie es aufgerufen oder verwendet wird. Diesbezügliche Patches nehme ich gerne entgegen und baue sie ein.

Viele Grüße
Boris

[Dr. Boris Neubert]

• woeid wird in 59_Weather an gegeben und in der YahooAPI weiterverarbeitet, für Wunderground nennt sich das Station_ID. Es ist ja egal wie man das Kind nennt, daher meine Frage. So lassen??

Ich denke, dass das nur eine Frage der Dokumentation ist. Ich kann es später in der Dokumentation (und mit Suchen&Ersetzen auch im Code) durch eine allgemeinere Bezeichnung ersetzen, z.B. ID.

• wie hand haben wir das define von 59_Weather? Wo gebe ich an welche API er verwenden soll. Sollte im Define angegeben werden finde ich. Es gibt auch API's mit Key. Auch der sollte ins Define

Das ist schwieriger. Aus Gründen der Abwärtskompatibilität kann die Angabe der verwendeten Quelle nur ganz hinten im define als Option angefügt werden.

Ich könnte das aber auch so machen (meine Präferenz):

Code Auswählen Erweitern

attr MyWeather API Yahoo
attr MyWeather Key 4711.0815

Das wird funktionieren, weil die erste Abfrage an das API erst gestellt wird, nachdem FHEM initialisiert ist, also das Attribut schon am Device bekannt ist. Bei Neuanlagen über die Oberfläche wird halt erst dann ein Aufruf ans API abgesetzt, wenn es ein entsprechendes Attribut gibt.

Viele Grüße
Boris

[justme1968]

ein vorschlag: wenn man die syntax für das define so erweitert das man parameter in der form name=wert angeben kann könnte man erweiterbar auch plugin spezifische werte übergeben.  die aktuelle variante mit der woid wäre dann rückwärtskompatibel nur für yahoo. die neue variante wäre dann

  define wetterxy Weather provider=yahoo woid=...

wenn ein provider noch einen key braucht wird er als zusätzlicher key=meinKey übergeben.

intern könnte man alle parameter in einen hash stecken und ans jeweilige plugin übergeben.

damit wäre auch für neue plugins nichts am framework modul zu ändern.

gruss
  andre

[Dr. Boris Neubert]

  define wetterxy Weather provider=yahoo woid=...

wenn ein provider noch einen key braucht wird er als zusätzlicher key=meinKey übergeben.

intern könnte man alle parameter in einen hash stecken und ans jeweilige plugin übergeben.

Das finde ich super! So wird's gemacht. Sobald ein Gleichheitszeichen in einem Parameter ist, wird die neue Syntax angenommen, ansonsten die alte.

Viele Grüße
Boris