piratewthr - heute 70,7 °C

[wvhn]

In den json-Daten steht ganz unten unter "flags -> untits" das Einheitensystem.
grafik.png
Über das zusätzliche Logging sollte sich herausfinden lassen, ob hier im Fehlerfall "us" steht. Das wäre ein zuverlässigerer Indikator als die 50°C-Schwelle.

Gruß
Wolfram

[Msinn]

Danke! Dann warte ich mal auf die "nächste Hitzewelle"

[Msinn]

Gestern Nachmittag hat mein Logging angeschlagen. Beginnend 16:58 Uhr begann PirateWeather Daten in imperial Units auszuliefern. Im Datensatz steht auch "units": "us". (@wvhn : Danke für den Tipp)

Log Einträge dazu gab es bis heute Nacht 2:17 Uhr)

Vor den fehlerhaften Datensätzen gab es um 16:38: eine Meldung Bad Gateway (502).

[Msinn]

Ich habe bei pirateweather ein neues Issue dazu aufgemacht.

Solange das Problem besteht und wieder auftreten könnte, könnte ich einen Work-Around in das Plugin einbauen, dass Meldungen ignoriert werden, wenn die units der Meldung nicht mit den im Plugin konfigurierten units übereinstimmen. Dann fehlen zwar für einen Zeitraum die Daten, man hat aber wenigstens keine falschen Daten.

Was meint ihr dazu?

[wvhn]

Wenn man sich drauf verlassen könnte, dass die Werte aktuell sind, könnte man die Einheiten ja umrechnen. Aber so lange die Vertrauenswürdigkeit der Daten nicht geklärt ist, bin ich auch für ignorieren.

Gruß
Wolfram

[Msinn]

Das Plugin wäre nicht in der Lage umzurechnen, da es den Inhalt der einzelnen Felder, den es in ein Item überträgt nicht kennt. Es gibt einen Matchcode und wenn der passt, wird der Wert in das Item übertragen, egal ob es eine Temperatur, eine Windrichtung oder anderes ist.

Das für einzelne Matchcodes umzurechnen würde quasi ein neues Plugin erfordern. Ich kann das ja nicht nur auf einen Matchcode beziehen. In einer Message sind alleine ca. 50 verschiedene Temperaturangaben enthalten. Dazu kömen noch Windgeschwindigkeiten, und anderes.

[ElektroRudi]

Heute ist es wieder so weit:
grafik.png

[Msinn]

Heute ist es wieder so weit:

Wie ich geschrieben habe, war es vorgestern bereits wieder so weit. 😉

[Msinn]

In dem Issue, bekam ich den Hinweis, dass die Antwort (die ich geloggt hatte), v1.4.1 des PirateWeather API war und aktuell ist v1.5.5.

Der Autor von PirateWeather schrieb gerade:

Now this is interesting, and shows how I'm still a little green on the cloud side of things. I'm seeing a small number of requests going to 1.4.1; however, @cloneofghosts is correct, that shouldn't be possible! So something is wrong with either the DNS stuff or my gateway, and I'm digging into now which one

[wvhn]

ElektroRudi

hast Du Loggings, aus denen die API-Version hervor geht, von der die Antworten kamen? Meines Erachtens besteht noch ein weiteres Problem, nämlich dass bei Dir die fehlerhaften Werte deutlich länger registriert werden, als die Störung andauert. Die gestrige Störung dauerte nur 19 Minuten ab ca. 16:05 Uhr MESZ, aber bei Dir kamen fehlerhafte Werte bis heute früh an. Nach Deinem Post um 7:44 Uhr habe ich nur 10 Minuten später die Wetterdaten mit dem smartVISU Wetterservice ausgelesen. Die waren in Ordnung.

Gruß
Wolfram

[Msinn]

wvhn Ich habe für gestern (30. August folgende Störungen)

• von vor Mitternacht bis 01:55 CEST
• von 13:02 CEST bis Mitternacht

Ob dazwischen einzelne richtige Meldungen waren (also im Zeitraster Logeinträge 'fehlten'), habe ich nicht geprüft.

Ich habe dazwischen noch einzelne 500er und 503er Fehler.

[wvhn]

Msinn
mich irritiert, dass die Zeiten überhaupt nicht zu den Ausfallzeiten auf der Status-Seite von pirateweather.net passen. Auf den Plots von ElektroRudi stimmen wenigstens die Anfangszeiten überein.

Vielleicht gibt es ja mehrere Ursachen, die u.U. auch mit den API-Keys und deren Nutzungsfrequenz zu tun haben.

Im Wetterwidget von smartVISU konnte ich das Problem bisher nicht reproduzieren. Das wäre halt für mich wichtig um zu sehen, ob ich da auch etwas abfangen muss. Deshalb beobachte ich diesen Thread in erster Linie. Es wäre ganz gut, wenn Ihr das Widget in der Visu mal parallel prüfen könntet, während die Störung in shNG anliegt. Die vollständige Antwort liegt jeweils als JSON-Datei im Ordner ./temp.

Gruß
Wolfram

[Msinn]

Die Zeiten passen aber zu meinen Log Einträgen. Es war ja kein Ausfall verantwortlich. Dann hätte es keine Antwort gegeben, aber nicht eine falsche.

Du kannst das Problem nicht reproduzieren (kann ich auch nicht).. Ich kann es nur beobachten, während es auftritt. Im allgemeinenen merke ich es aber erst nachträglich an den Log Einträgen, die meine Version der Plugins produziert.

Hast Du für die Visu ein Test Tool (wie Selenium) am Start? Dann könntest Du mit dem Tool kontinuierliche Abfragen generieren und die Ergebnisse in der smartVISU loggen. Du wirst aber vermutlich nur das gleiche feststellen wie ich.

Ich warte jetzt erstmal auf die Analyse der Autors von pirateweather.

[Msinn]

Der Autor von PirateWeather hat geschrieben, er habe das Problem gefixt, dass in einigen Fällen auf eine alte Version des API zugegriffen wurde. In einer bestimmten Konstellation auf AWS wurde auf einen Fallback Pathway zugegriffen und der griff auf eine alte (archivierte) Version des Lambda Skripts zu.

Ich gehe erstmal davon aus, dass damit auch das Thema mit den imperial Units erledigt ist (bis zum Beweis des Gegenteils 😉).

[Msinn]

Aktuell gibt es wieder das Problem (seit ca. 21 Uhr und andauernd)

Andere haben das Problem auch bei pirateweather gemeldet. Die json Antwort gibt auch an, 'units': 'us' zu liefern. Das Problem ist allerdings etwas anders als beim letzten mal. Letztes mal waren die fehlerhaften Antworten mit der API Version V1.4.1 (altes API) ausgeliefert worden. Nun werden die Antworten mit API Version V1.5.5 ausgeliefert (aktuelles API), nur eben mit 'us' units.