Hi.
Im angehängten Patch wird die Abfrage auf OpenWeatherMap.org von "forecast" auf "onecall" umgestellt. Dies hat den Vorteil dass auch Daten für eine tägliche Wettervorhersage mitgeliefert werden. Diese können nun einfach mittels WeatherAsHtmlX(<name>,"d",<count>) im Webinterface eingebunden werden (bisher wurde hier nur das derzeitige Wetter geliefert).
Bei meiner Implementierung habe ich die Abfrage mittels "forecast" (Wetterdaten alle 3 Stunden für 4 Tage) entfernt. Mir ist bewusst, dass dies ein gewisses Konfliktpotential bietet. Falls es dem User möglich sein soll die Art der Abfrage steuern zu können bin ich natürlich gerne bereit meinen Patch entsprechend anzupassen. Allerdings bräuchte ich dafür 1-2 Tips wie das am Sinnvollsten implementiert werden kann (z.B, über ein Attribut?)
Da die Abfrage über die API "onecall" nicht alle Daten liefert (z.B. Ort Name und Land) muss auch weiterhin ein call auf die API "weather" erfolgen. Damit ich garantieren kann, dass immer beide calls ausgeführt werden, musste ich den Ablauf etwas ändern. Im Detail werden beide request in non-blocking Art und Weise abgesetzt und die internen Strukturen beim Empfang von jedem der beiden aktualisiert. Funktioniert bei mir recht gut.
Übrigens: Ich habe auch einen Fix für die Probleme mit Warnings im Modul OpenWeatherMap (siehe [1] und [2]) einfließen lassen. Im Detail werden die Warnigns mittels no warnings 'uninitialized'; lokal deaktiviert.
[1] https://forum.fhem.de/index.php/topic,95730.msg1196525.html#msg1196525 (https://forum.fhem.de/index.php/topic,95730.msg1196525.html#msg1196525)
[2] https://forum.fhem.de/index.php/topic,95823.msg1191054.html#msg1191054 (https://forum.fhem.de/index.php/topic,95823.msg1191054.html#msg1191054)
Schaue ich mir gerne an. Wird aber etwas dauern. Kann Dir aber jetzt schon sagen das
no warnings 'uninitialized';
nur eine Verschleierung ist und die eigentliche Ursache nicht behebt.
Das auf jeden Fall. Die saubere Variante wäre vor jeder Berechnung abzuprüfen ob der Wert im Hash definiert ist oder nicht. Das würde allerding den Code extrem aufblähen.
Hm, jetzt wo ich so drüber nachdenke könnte man das vielleicht mit einem Makro sauber lösen. Das könnte man dann auch gleich aufs Modul 59_Weather.pm auch anwenden, denn dort treten solche Warnings bei mir auch auf.
Eigentlich sollten im Modul keine Warnings auftreten. Und auch bei Elektrolurch ist was nicht ganz korrekt. Eine Multiplikation gibt es an der Stelle wo das Warning kommt gar nicht.
Wäre echt toll wenn bei OpenWeatherMap.org das neu "onecall" API unterstützt würde.
Könnt Ihr bitte einmal diese Version testen
Readonly ist nun Voraussetzung
apt install libreadonly-perl
https://git.cooltux.net/FHEM/mod-Weather/raw/branch/patch-addOnecallMode/OpenWeatherMapAPI.pm
Aber mit Vorsicht. Und wenn es Probleme gibt brauche ich immer die entsprechende FHEM Logausgabe.
Grüße
Ich probiere das gerne mal aus.
- Werden beide APIs unterstützt oder nur noch ,,onecall"?
- Muss man bei den Einstellungen/Attributen was beachten?
Es wird forecast und onecall unterstützt
Habe die verlinkte Datei ersetzt
-rw-r--r-- 1 fhem dialout 35043 Feb 13 10:52 OpenWeatherMapAPI.pm
-rw-r--r-- 1 root root 23294 Feb 13 10:45 OpenWeatherMapAPI.pm.old
und meine Installation neu gestartet
2022.02.13 11:03:10 0: Server shutdown
2022.02.13 11:03:11 1: Including fhem.cfg
2022.02.13 11:03:11 3: WEB: port 8083 opened
2022.02.13 11:03:11 2: eventTypes: loaded 874 lines from ./log/eventTypes.txt
2022.02.13 11:03:11 3: FHZ opening FHZ device /dev/serial/by-id/usb-ELV_AG_ELV_FHZ_1300_PC_EL65DJ1H-if00-port0
2022.02.13 11:03:11 3: FHZ opened FHZ device /dev/serial/by-id/usb-ELV_AG_ELV_FHZ_1300_PC_EL65DJ1H-if00-port0
2022.02.13 11:03:14 1: define OpenWeather Weather API=OpenWeatherMapAPI,cachemaxage:600 apikey=xxx interval=3600 lang=en: OpenWeather: cannot load API OpenWeatherMapAPI: Can't locate Readonly.pm in @INC (you may need to install the Readonly module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/arm-linux-gnueabihf/perl5/5.32 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl-base /usr/lib/arm-linux-gnueabihf/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl ./FHEM/lib) at FHEM/OpenWeatherMapAPI.pm line 115.
BEGIN failed--compilation aborted at FHEM/OpenWeatherMapAPI.pm line 115.
Compilation failed in require at ./FHEM/59_Weather.pm line 677.
2022.02.13 11:03:14 1: Including ./log/fhem.save
2022.02.13 11:03:14 1: Messages collected while initializing FHEM:configfile: OpenWeather: cannot load API OpenWeatherMapAPI: Can't locate Readonly.pm in @INC (you may need to install the Readonly module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/arm-linux-gnueabihf/perl5/5.32 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl-base /usr/lib/arm-linux-gnueabihf/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl ./FHEM/lib) at FHEM/OpenWeatherMapAPI.pm line 115.
BEGIN failed--compilation aborted at FHEM/OpenWeatherMapAPI.pm line 115.
Compilation failed in require at ./FHEM/59_Weather.pm line 677.
setuuid: Please define OpenWeather first
apt install libreadonly-perl
Zitat von: Hinata am 13 Februar 2022, 11:14:13
Habe die verlinkte Datei ersetzt
Lösche doch bitte mal noch deinen API key aus dem Post..
- apiKey hab ich ausgetauscht, der Alte ist gelöscht.
- Ich verwende Raspberry Pi OS Lite, da ist libreadonly-perl nicht vorinstalliert.
- Die Warnung(en) die ich bisher beim Start von FHEM bekommen habe sind weg.
- Wetterdaten können abgerufen werden, Forecast geht auch.
- Ich benutzen OpenWeather/Free https://openweathermap.org/price#weather, bekomme bei stündlichem Forecast aber nur Werte im 3h Abstand. Erwartet hätte ich eigentlich für jede Stunde.
- OpenWeather bietet auch Historical und Minute, was bei Forecast nicht ausgewählt werden kann.
Bei der Tagesansicht finde ich die Uhrzeit irritierend.
{ WeatherAsHtmlV("OpenWeather","d", 3) }
clear sky
12°C 45%
Wind: S 19 km/h
Sun, 11:00: few clouds
min 1°C max 12°C
Wind: S 11 km/h
Mon, 11:00: few clouds
min 2°C max 10°C
Wind: S 11 km/h
Stündlicher Forecast, Abstand 3h (anstatt 1h).
{ WeatherAsHtmlV("OpenWeather","h", 3) }
12°C 45%
Wind: S 19 km/h
Sun, 18:00: clear sky
min 5°C max 9°C
-
Sun, 21:00: few clouds
min 3°C max 6°C
-
Die Daten kommen genau so 1 z 1 über die API rein. Kann nur das nehmen was ich da angeboten bekomme.
Ansonsten funktioniert es aber bei Dir?
Zitat von: Hinata am 13 Februar 2022, 16:47:30
OpenWeather bietet auch Historical und Minute, was bei Forecast nicht ausgewählt werden kann.
So weit ich das sehe, geht eine Stunde Abstand nur ab Developer, Free hat nur drei Stunden:
http://openweathermap.org/api
http://openweathermap.org/api/hourly-forecast
http://openweathermap.org/forecast5
OpenWeatherMapAPI benutzt endpoint="forecast" (drei Stunden). Stündlich wäre endpoint="forecast/hourly".
So richtig werde ich aus der Beschreibung auch nicht schlau, unter ,,Hourly forecast for 48 hours" verstehe ich aber stündlich?
Hourly Forecast 4 days
API doc Subscribe
Hourly forecast is available for 4 days
Forecast weather data for 96 timestamps
JSON and XML formats
Included in the Developer, Professional and Enterprise subscription plans
One Call API
API doc Subscribe
Make one API call and get current, forecast and historical weather data
Minute forecast for 1 hour
Hourly forecast for 48 hours
Daily forecast for 7 days
Historical data for 5 previous days
National weather alerts
JSON format
Included in both free and paid subscriptions
Wenn ich das API aufrufe bekomme ich stündliche Daten:
https://api.openweathermap.org/data/2.5/onecall?lat=48.74&lon=9.33&appid=xyz
...
hourly":[
{"dt":1644775200,"temp":278.53,"feels_like":276.6,"pressure":1014,"humidity":64,"dew_point":272.38,"uvi":0,"clouds":1,"visibility":10000,"wind_speed":2.38,"wind_deg":163,"wind_gust":5.45,"weather":[{"id":800,"main":"Clear","description":"clear sky","icon":"01n"}],"pop":0},
{"dt":1644778800,"temp":278.67,"feels_like":276.91,"pressure":1014,"humidity":64,"dew_point":272.5,"uvi":0,"clouds":0,"visibility":10000,"wind_speed":2.22,"wind_deg":158,"wind_gust":4.26,"weather":[{"id":800,"main":"Clear","description":"clear sky","icon":"01n"}],"pop":0},
{"dt":1644782400,"temp":278.29,"feels_like":276.52,"pressure":1014,"humidity":64,"dew_point":272.18,"uvi":0,"clouds":1,"visibility":10000,"wind_speed":2.16,"wind_deg":157,"wind_gust":3.67,"weather":[{"id":800,"main":"Clear","description":"clear sky","icon":"01n"}],"pop":0},
{"dt":1644786000,"temp":277.78,"feels_like":275.92,"pressure":1014,"humidity":62,"dew_point":271.37,"uvi":0,"clouds":2,"visibility":10000,"wind_speed":2.17,"wind_deg":161,"wind_gust":3.77,"weather":[{"id":800,"main":"Clear","description":"clear sky","icon":"01n"}],"pop":0},
...
ZitatAnsonsten funktioniert es aber bei Dir?
Sonst habe ich bisher keine Probleme festgestellt.
Zitat von: Hinata am 13 Februar 2022, 19:45:06
Wenn ich das API aufrufe bekomme ich stündliche Daten:
https://api.openweathermap.org/data/2.5/onecall?lat=48.74&lon=9.33&appid=xyz
...
hourly":[
{"dt":1644775200,"temp":278.53,"feels_like":276.6,"pressure":1014,"humidity":64,"dew_point":272.38,"uvi":0,"clouds":1,"visibility":10000,"wind_speed":2.38,"wind_deg":163,"wind_gust":5.45,"weather":[{"id":800,"main":"Clear","description":"clear sky","icon":"01n"}],"pop":0},
{"dt":1644778800,"temp":278.67,"feels_like":276.91,"pressure":1014,"humidity":64,"dew_point":272.5,"uvi":0,"clouds":0,"visibility":10000,"wind_speed":2.22,"wind_deg":158,"wind_gust":4.26,"weather":[{"id":800,"main":"Clear","description":"clear sky","icon":"01n"}],"pop":0},
{"dt":1644782400,"temp":278.29,"feels_like":276.52,"pressure":1014,"humidity":64,"dew_point":272.18,"uvi":0,"clouds":1,"visibility":10000,"wind_speed":2.16,"wind_deg":157,"wind_gust":3.67,"weather":[{"id":800,"main":"Clear","description":"clear sky","icon":"01n"}],"pop":0},
{"dt":1644786000,"temp":277.78,"feels_like":275.92,"pressure":1014,"humidity":62,"dew_point":271.37,"uvi":0,"clouds":2,"visibility":10000,"wind_speed":2.17,"wind_deg":161,"wind_gust":3.77,"weather":[{"id":800,"main":"Clear","description":"clear sky","icon":"01n"}],"pop":0},
...
Bei onecall nehme ich nur die Tagesvorhersage. Die 3 Stundendaten kommen aus forecast
ZitatBei onecall nehme ich nur die Tagesvorhersage. Die 3 Stundendaten kommen aus forecast
Warum nicht für beides? https://openweathermap.org/api/one-call-api scheint doch das neuere API mit mehr Möglichkeiten zu sein?
Die Umstellung würde mehr Zeit in Anspruch nehmen welche ich aktuell nicht habe.
Es geht vor allem darum sich den Response an zu schauen und ab zu schätzen ob aktuell vorhandene Daten für User verloren gehen.
Ich bin neuer FHEM User und kann nur schlecht beurteilen ob etwas fehlt.
Meine Use Cases funktionieren fehlerfrei.
Nach einem Neustart habe ich folgende Meldung erhalten:
PERL WARNING: Use of uninitialized value in multiplication (*) at FHEM/OpenWeatherMapAPI.pm line 452.
Ich schau mal ob ich etwas finde.
Es ist mir auch noch eine andere Sache aufgefallen. Die APIs liefern unterschiedliche Werte für ,,current" bzw. aktuelle Stunde, je nachdem ob man bei Current, Hourly Forecast oder One Call API reinschaut.
Gibt eigentlich nur eine API. Aber die Endpunkte sind unterschiedlich und daher ist die Antwort auch unterschiedlich welche dann kommt. Aber das liegt einzig an der API. Es werden nur die Daten geschrieben welche empfangen wurden.
Ich habe einen weiteren Test gemacht:
WLAN Router 10 min ausgeschaltet und dann wieder ein. Mit aktiviertem OpenWeather Device startet mein Raspi nach einigen Minuten nach dem einschalten des WLAN neu (Reboot). Ohne OpenWeather passiert das nicht.
Ich habe in meinem RaspiOS einen Watchdog aktiviert, der prüft ob regelmäßig in eine Datei geschrieben wird. Über einen FHEM-Timer schreibe ich alle 10 min in die Datei.
Irgendein Aufruf von OpenWeather scheint blockierend zu sein und ganz FHEM anzuhalten?
Zitat von: Hinata am 26 Februar 2022, 11:03:10
Ich habe einen weiteren Test gemacht:
WLAN Router 10 min ausgeschaltet und dann wieder ein. Mit aktiviertem OpenWeather Device startet mein Raspi nach einigen Minuten nach dem einschalten des WLAN neu (Reboot). Ohne OpenWeather passiert das nicht.
Ich habe in meinem RaspiOS einen Watchdog aktiviert, der prüft ob regelmäßig in eine Datei geschrieben wird. Über einen FHEM-Timer schreibe ich alle 10 min in die Datei.
Irgendein Aufruf von OpenWeather scheint blockierend zu sein und ganz FHEM anzuhalten?
Logausgabe bitte
Eine LOG-Datei mit sinnvollem Inhalt habe ich bisher nicht hinbekommen, da ich ein RAM-Disk für die LOG-Dateien verwende und zusätzlich FHEM von außen über einen Watchdog überwache. In den Systemlogs sieht man, das FHEM aufhört die KeepAlive-Datei zu schreiben und der Watchdog dadurch auslöst. Wie gesagt, kann ich das Problem recht einfach beseitigen, in dem ich OpenWeather disable 1 setzte.
Ich kenne mich in Perl zu wenig aus, die Frage die aber doch einfach zu klären sein sollte ist, ob der Abruf der JSON-Daten über das Web-API blockierend ist?
Zitat von: Hinata am 27 Februar 2022, 09:19:49
Ich kenne mich in Perl zu wenig aus, die Frage die aber doch einfach zu klären sein sollte ist, ob der Abruf der JSON-Daten über das Web-API blockierend ist?
Das ist leicht. Nein ist sie nicht.
Die Zeiten für Sonnenaufgang usw. sind um eine Stunde verschoben. Im Modul finde ich bei Zeitumrechnungen immer -3600 ist das correct?
Edit: Anscheined nur für forecast
Edit2: Wenn ich mir was wünschen darf, wäre das der Wert hourly.uvi.
Sodele, ich habe mich mal selbst versucht an dem Code und folgendes geändert:
Block:
push(
@{ $self->{cached}->{forecast}->{hourly} },
eingefügt:
'uvi' => sprintf("%.1f", (
$data->{list}->[$i]->{main}->{uvi}
)
),
im Block:
push(
@{ $self->{cached}->{forecast}->{daily} },
die Substraktion der Zeiten um -3600 Sekunden beseitigt.
Das Ergebnis stimmt mit einem direkten Vergleich der API Abfrage überein.
Keine Ahnung wie ich das Updatefest bekomme.
Gruß Roman
Ich schaue es mir die Tage mal an. Denke aber immer Sommer wird es dann wieder falsch sein.
Sorry für die vielen Postings, aber so langsam fummele ich mich da ein. Die listing für hfc. sind auch nicht richtig:
Beispiel:
hfc3_cloudCover 6 2022-03-17 20:17:12
hfc3_code 32 2022-03-17 20:17:12
hfc3_condition Klarer Himmel 2022-03-17 20:17:12
hfc3_day_of_week Fr, 03:00 2022-03-17 20:17:12
hfc3_high_c 5 2022-03-17 20:17:12
hfc3_humidity 62 2022-03-17 20:17:12
hfc3_icon sunny 2022-03-17 20:17:12
hfc3_iconAPI 01n 2022-03-17 20:17:12
hfc3_low_c 5 2022-03-17 20:17:12
hfc3_pressure 1039 2022-03-17 20:17:12
hfc3_pubDate Fr, 18 Mär 2022 03:00 2022-03-17 20:17:12
hfc3_tempHigh 5 2022-03-17 20:17:12
hfc3_tempLow 5 2022-03-17 20:17:12
hfc3_temp_c 5 2022-03-17 20:17:12
hfc3_temperature 5 2022-03-17 20:17:12
hfc3_uvi 0.0 2022-03-17 20:17:12
hfc3_wind 6 2022-03-17 20:17:12
hfc3_wind_gust 12 2022-03-17 20:17:12
hfc3_wind_speed 6
Meiner Meinung nach sind das die Daten aus dem Block 8:= Fr.,18 Mär 2022 04:00
8 :
dt 1647572400
temp 4.83
feels_like 3.69
pressure 1039
humidity 62
dew_point -1.95
uvi 0
clouds 6
visibility 10000
wind_speed 1.55
wind_deg 30
wind_gust 3.3
weather 0
id 800
main "Clear"
description "Klarer Himmel"
icon "01n"
pop 0
Ich habe allerdings noch nicht verstanden wie die 3H Blöcke gebildet werden , da alle 48 Stunden in dem JSON Datensatz verhanden sind. Die Subtraktion von -3600 Sekunden bei den HFC Daten wäre also auch falsch. Vielleicht kann mir mal jemand erklären wie die Datenabfrage auf den 3 Stunden Rhythmus denn programmiert ist.
Gruß
Roman
@Cooltux: Die Umrechnung erfolgt doch per localtime und sollte also korrekt sein, wenn die Zeitzone stimmt.
Es muss ja Mal einen Grund gegeben haben das ich es so gemacht hatte
OpenWeatherMap hat doch ne API Beschreibung. Ich suche morgen mal.
Bevor du anfängst hier noch ein paar Gedanken dazu.
Der vermeintliche Fehler mit der Sommerzeit ist schlicht ein Denkfehler.
UTC 1100 = MEZ 1200 = MESZ 1300. Somit wäre die fc. Zeit im Sommer mit 13:00 korrekt.
Ich würde vielleicht nur noch onecall abfragen und mit dem Parameter excl. arbeiten , vielleicht noch zsätzlich als Attribut die units aufnehmen.
Attr. units = default, metric, imperial
Attr. forecast = every, daily, hourly = exclude mit dem entsprechendem Werten versehen.
Den hourly forcast könnte man mit einem mod(3) = 0 auf den localtime(Stundenwert) begrenzen. Das verringert das Datenvolumen. Wären bei 48 Stunden halt nur 15 Werte hfc. möglich.
Sind nur ein paar Gedanken.
Gruss Roman
Sorry, hinsichtlich Stundendaten bezog ich mich auf die onecall API. Mein Fehlet.
Vielleicht ist des Rätsels Lösung, dass für die hourly Daten die "forecast" API genutzt wird und für daily die "onecall". Ich würde es persönlich besser finden für beides die "onecall" zu benutzen, da eine stündliche Auflösung möglich ist, aber das hat natürlich auch Nachteile (z.B. Datenverbrauch).
Persönlich hat es mir beim Benutzen von onecall auch nicht so gut gefallen, dass im Web Interface die Daten dann nur mehr stündlich angezeigt werden können. Meine Lösung: Ich hab die Funktionen WeaterAsHtmlX(.) um einen Parameter skip erweitert sodass nur jeder n-te genutzt wird, also z.B.
sub WeatherAsHtmlV($;$$$) {
my ( $d, $op1, $op2, $skip ) = @_;
....
# if skip is undef it accounts as 0 in addition
my $inc = 1 + $skip;
$items *= $inc;
for ( my $i = 1 ; $i < $items ; $i+= $inc ) {
.....
}
}
Zitat von: Hinata am 27 Februar 2022, 09:19:49
Eine LOG-Datei mit sinnvollem Inhalt habe ich bisher nicht hinbekommen, da ich ein RAM-Disk für die LOG-Dateien verwende und zusätzlich FHEM von außen über einen Watchdog überwache. In den Systemlogs sieht man, das FHEM aufhört die KeepAlive-Datei zu schreiben und der Watchdog dadurch auslöst. Wie gesagt, kann ich das Problem recht einfach beseitigen, in dem ich OpenWeather disable 1 setzte.
Ich kenne mich in Perl zu wenig aus, die Frage die aber doch einfach zu klären sein sollte ist, ob der Abruf der JSON-Daten über das Web-API blockierend ist?
Sehr interessant. Bei schmiert FHEM auch regelmäßig ab, vielleicht liegt es ja wirklich am OpenWeather Modul. Ich werde das mal überprüfen.