[patch] Tägliche Daten für OpenWeatherMap

Begonnen von nobody, 30 Dezember 2021, 15:32:28

Vorheriges Thema - Nächstes Thema

romakrau

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

CoolTux

Ich schaue es mir die Tage mal an. Denke aber immer Sommer wird es dann wieder falsch sein.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

romakrau

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

romakrau

@Cooltux: Die Umrechnung erfolgt doch per localtime und sollte also korrekt sein, wenn die Zeitzone stimmt.

CoolTux

Es muss ja Mal einen Grund gegeben haben das ich es so gemacht hatte

OpenWeatherMap hat doch ne API Beschreibung. Ich suche morgen mal.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

romakrau

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

romakrau

Sorry, hinsichtlich Stundendaten bezog ich mich auf die onecall API. Mein Fehlet.

nobody

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

nobody

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.