Onkelandy thx. ich schaue heute abend mal rein. hab damals recht schnell nach dem darksky plugin das owm rausgehauen.. hab wohl nur auf die README geachtet. die ist nach dem fehler oben aber auch verbesserungsbedürftig
-
-
Hallo zusammen,
ich wollte dieses Wochenende dieses Plugin in Betrieb nehmen und bin ebenfalls über die nicht wirklich vollständige Anleitung gestolpert. Das Plugin muss wie folgt konfiguriert sein (plugin.yaml):
Nur so funktionieren dann die Items mit dem Keyword 'owm_matchstring@home'.HTML-Code:weather_openweathermap: class_name: OpenWeatherMap class_path: plugins.openweathermap key: xxxxyyyyxxxxyyyy latitude: '48.04712' longitude: '11.81421' # language: de # cycle: 600 instance: 'home'
Das Plugin in dieser Version ruft von Openweathermap die folgenden APIs ab:- Aktuelles Wetter: api.openweathermap.org/data/2.5/weather
- 3h-Vorhersage: api.openweathermap.org/data/2.5/forecast
Gruss MatthiasKommentar
-
Ich vermute es sind einige noch auf dem Darksky Plugin und haben nicht die Notwendigkeit umzusteigen solange das API noch geht. Das wird sich vermutlich zum Jahresende 2021 ändern, dann wird das API von Darksky abgeschaltet.
Vermutlich hat psilo recht viel um die Ohren und ist da bisher nicht weiter zu gekommen das zu pflegen. Wenn Du da Verbesserungen hast dann gerne her damit, idealerweise als PR auf den smarthomeng/plugins develop branch.
Kommentar
-
bmx ein PR wäre super.. Mit 3 Kindern, geschlossener Schule und Kita und derzeit 6-17:00 Arbeitstagen ist leider nix drin.Kommentar
-
Openweathermap bietet den sog. 'OneCall' an: https://openweathermap.org/api/one-call-api
Gemäss der Beschreibung soll so eine Migration von Dark Sky relativ einfach zu machen sein.Kommentar
-
Wenn Du Zeit hast, highly Welcome. Psilo hatte ja geschrieben, dass es ihm im Moment daran mangelt.Viele Grüße
Martin
There is no cloud. It's only someone else's computer.Kommentar
-
Muss leider passen. Bin nicht so gut in Python für eine solche Implementierung. Sorry.Kommentar
-
Arbeitet hier jemand an dem Thema OWM-Plugin?
Ich würde gerne die OWM-basierte smarte Gartenbewässerung auf SHNG portieren:
https://github.com/MTry/homebridge-s.../index.js#L162
Idee: Das OWM-Plugin um die One-Call API ergänzen und die ETO-Berechnung (Verdunstungsrate) als weiteres Item ergänzen. Den Rest der Bewässerungssteuerung kann man ja dann in einer Logik machen.
Wäre der Erhalt der aktuellen matchstring-Struktur im OWM-Plugin wichtig, oder würde dann die Umstellung auf "nur one-call" reichen?
Im One-Call sind keine drei Stunden-Wetterwerte enthalten, sondern nur stündliche oder tägliche. Für die Dark Sky Freunde ist hier sogar das Mapping beschrieben: https://openweathermap.org/darksky-openweatherKommentar
-
Ich würde mich freuen das mal zu testen wenn Du soweit bist. Ende 2021 für Darksky API Abschaltung ist zwar noch lange hin aber da kann ja auch noch viel dazwischen kommen ...
Kommentar
-
Seit ein paar Tagen beschäftige ich mich mit dem Openweathermap Plugin. Nachdem ich meine ganzen Fehler rausgemacht habe, funktioniert es auch ganz gut.
Ich hätte nur einen kleinen Vorschlag zur Verbesserung:
Openweathermap lierfert einige Werte nur, wenn sie auch auftreten, z.Bsp. rain/1h im weather oder rain/3h im forecast. Wenn es nicht regnet, werden diese Werte nicht gesendet. Wenn ich diese Werte in der Datenbank aufzeichne, bleibt der letzte Regenwert stehen, obwohl es schon längst nicht mehr regnet. Hier wäre es schön, wenn das item auf 0 gesetzt wird, wenn es nicht mehr von Openweathermap gesendet wird. Das gleiche gilt vermutlich auch für snow.
Bei der Berechnung des forecast/daily wird die Berechnung des Gesamtwert mit einer Fehlermeldung im Log verworfen, sobald in einer Vorhersage Periode der Wert z.Bsp. rain/3h nicht vorhanden ist. Auch hierbei wäre es gut, sattdessen den Wert 0 anzunehmen und die Berechnung damit durchzuführen.
Ich habe mich schon selbst an einer Korrektur des Plugin versucht, aber dafür reichen meine Python Kenntnisse nicht aus. Es wäre schön, wenn sich das mal jemand ansehen könnte.
Kommentar
-
Schon passiert, nur noch nicht gepusht… Morgen ist hier kein Programm im Urlaub…Kommentar
-
So, hier mal ein Zwischenstand:
https://github.com/jentz1986/smartho...openweathermap
Es ist viel geändert, die Kompatibilität zur Vorgängerversion sollte aber erhalten geblieben sein.- Es wird nun auch die Nutzung der one-call API ermöglicht.
- Die "Zeitmaschine" der One-Call API kann 4 Tage in die Vergangenheit abgerufen werden.
- Die Funktionalität der ETO-Berechnung (Evapotranspiration / Verdunstungsrate ist) eingebaut. Nutzbar über /day/0/eto oder /day/1/eto...
- Es gibt virtuelle Matchstrings, da ich keine andere Möglichkeit gefunden habe, die Regenmenge der letzten/nächsten 12h/24h direkt abzufragen
- virtual/past12h/sum/rain/1h
- virtual/next24h/sum/rain/1h
- Die Logik ist:
- virtual als Einleitung,
- Ein Zeitfenster (momentan kann nur das folgende genutzt werden)
- past12h
- next12h
- past24h
- next24h
- Eine Aggregierungsfunktion
- sum
- max
- min
- avg
- der Selektionsstring in der One-Call API für "hourly" Werte
- Das Webinterface gibt Aufschluss darüber, welche Items welche Datenquelle verwenden, und wie der Selektionspfad in den einzelnen Datenquellen ist, Die Infos werden beim Änderungskommentar mit angegeben, so dass diese auch im Item-Tree sichtbar sind.
- Eine Bewässerungsfunktion kann nun auf Basis der Verdunstung, des Niederschlags und einiger Parameter bestimmen, wie viele Sekunden ein Magnetventil öffnen sollte - die Konfiguration erfolgt am Schalt-Item und sieht so aus:
- Ventil 1 ist im Gewächshaus, Ventil 2 bewässert ein Beet in der prallen Sonne.
-
PHP-Code:
ventil_1:
knx_dpt: 1
knx_cache: 13/1/0
knx_send: 13/1/1
struct:
- openweathermap.irrigation
- uzsu.child
rain:
exposure_factor:
initial_value: 0
evaporation:
exposure_factor:
initial_value: 0.8
factors:
flowrate_l_per_min:
initial_value: 3.7
area_in_sqm:
initial_value: 5
ventil_2:
knx_dpt: 1
knx_cache: 13/2/0
knx_send: 13/2/1
struct:
- openweathermap.irrigation
- uzsu.child
evaporation:
exposure_factor:
initial_value: 1.1
factors:
flowrate_l_per_min:
initial_value: 3.7
area_in_sqm:
initial_value: 3
gut_feeling:
eval: sum
eval_trigger: garten.geraet.bewaesserung.bauchfaktor
- Die Vorherige Implementierung der forecast/daily- Variablen mit der virtual-Thematik zu integrieren
- Bessere Dokumentation
- "Vollständiges" Beispiel als struct beim Item mitgeben
- Widget für SmartVisu für die Bewässerung machen. Hab ich schon fertig aber kanns noch nicht mit dem Plugin ausliefern.
Kommentar
-
So, jetzt auch ein bisschen Doku... Ich mach jetzt wieder Urlaub und lass den Laptop im Rucksack.
https://github.com/jentz1986/smartho...rmap/README.mdKommentar
-
Hi,Zitat von jentz1986 Beitrag anzeigen
ich habe mir den Stand mal gezogen und getestet.
Funktioniert gut!
Probleme gibt es bei 2-stufigen Adressen, wie bspw. "weather/description" oder "weather/icon". Hier zeigt das Log einen Error mit der Beschreibung: "Error: Integer expected in matchstring after 'daily/1' for item wetter.owm.zuhause.vorhersage.akutell_plus_1d.wett er_beschreibung" wobei ich gar nicht "daily/1" sondern "day/1" definiert habe.
Kannst Du da nochmal schauen?Kommentar
-
Hi!Zitat von Sisamiwe Beitrag anzeigen
Danke fürs Ausprobieren!
Ich kann deine Fehlermeldung reproduzieren. Interessanterweise funktioniert das Listen-Assignment ohne Zicken und auch die zweistufige Temperaturzuweisung:
Das Rewriting ist hier beschrieben. https://github.com/jentz1986/smartho...identificationCode:morgen: type: list remark: Geht... owm_matchstring: day/1/weather descr: type: str remark: KAPUUUTT owm_matchstring: day/1/weather/description descr: type: str remark: Lösung des Problems owm_matchstring: day/1/weather/0/description temp: type: num remark: Geht auch... owm_matchstring: day/1/temp/day
Ich mach mich mal an die Lösung des Problems von oben...
EDIT: Hier ist die Lösung:
Tatsächlich ist die Fehlermeldung richtig (bis auf den Fehler, dass der letzte Abzweig nicht mit angegeben wird, es sollte richtig "daily/1/weather" heißen). Beim Objekt "weather" handelt es sich tatsächlich um eine Liste, die wohl meist (ich habs noch nicht anders gesehen) nur ein Element hat. Dieses Element ist ein Dictionary in dem dann description, icon etc. untergebracht sind. Daher wäre der richtige Matchstring dannWas machen wir jetzt damit?Code:day/1/weather/0/description
- Erstens ist das nicht besonders intuitiv.
- Zweitens weiß hier keiner (oder?) ob es nicht auch mal zwei Wetterlagen gibt.
- Entweder: wenn das Matching fehlschlägt und der Datentyp eine Liste ist, aber ein String angegeben ist, man das erste Element nimmt und dann versucht den String zu matchen. Das würde dann auch zu Erfolgen bei day/temp führen, wo das dann "heute" treffen würde.
- Oder: Vor dem Baum durchsuchen "weather/description", "weather/icon", etc. durch "weather/0/description", etc. ersetzen.
Zuletzt geändert von jentz1986; 19.07.2021, 16:55.Kommentar
Kommentar