Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[sigi234]

@oFbEQnpoLKKl6mbY5e13 sagte in Test Adapter open-meteo-weather v2.2.x GitHub/Lates:

VIS2 ist tot.

Warum?

[oFbEQnpoLKKl6mbY5e13]

@H5N1

Ich habe noch eine Frage. Gibt die API her, von welcher Station die Pollendaten stammen?

[H5N1]

@oFbEQnpoLKKl6mbY5e13 sagte in Test Adapter open-meteo-weather v2.2.x GitHub/Lates:

3. Nein. Allerdings kommen da auch keinerlei Meldungen, die über den Start der Instanz hinausgehen, was für den Debug-Mode schon ungewöhnlich ist

An den Debug ausgaben arbeite ich gerade, das ist tatsächlich bisher sehr mager, die bearbeiteten Scripte habe ich vor ein paar Minuten hoch geladen und werden mit der nächsten Version erscheinen.

@oFbEQnpoLKKl6mbY5e13 sagte in Test Adapter open-meteo-weather v2.2.x GitHub/Lates:

VIS2 ist tot.

Welchen Grund gibt es dafür, habe selbst vor einem Jahr oder länger auf vis-2 umgestellt und kann nicht klagen. Gerade das React macht es toll.

@oFbEQnpoLKKl6mbY5e13 sagte in Test Adapter open-meteo-weather v2.2.x GitHub/Lates:

Ich habe noch eine Frage. Gibt die API her, von welcher Station die Pollendaten stammen?

Bisher habe ich dazu auf der air-quality-api Seite nichts gefunden oder sehe es nicht.

Bis hier her, erst mal danke für's Testen.

Gruß H5N1

[WG25]

@H5N1 sagte in Test Adapter open-meteo-weather v2.2.x GitHub/Lates:

... ich bin mir nicht ganz sicher was du mit Stunden "schieben" meinst, evtl. die Genauigkeit?

Es gibt in dem Adapter für jeden Tag den stündlichen Forecast, je nach Einstellung 1, 6, 12 oder 24 Stunden. Dabei ist die Stunde "0" immer die aktuelle Stunde, die "1" die nächste und so weiter. Für den aktuellen Tag (0) fand ich es sinnvoll. Dieses ist aber auch für die Forecast Tage 1,2,3,.. so. Sprich bei Tag 1 ist Stunde 0 auch die "aktuelle" Stunde vom aktuellen Tag. Es ist also immer der gleiche Zeitversatz vom Tagesbeginn des jeweiligen Tages. Es würden damit am Tag 1 die Stunden zwischen Tagesbeginn und der Stunde 0 fehlen, es sei denn, es ist auf 24 Stunden Forecast eingestellt (Vermutung). Die Daten sind korrekt vom Tag 1 Stunde 0 usw., ich hab mich halt nur gefragt, ob das so sinnvoll ist bzw. ob diese Granularität für die Tage 1+ notwendig ist.

Wie gesagt, hat nichts mit der Adapter Funktionalität zu tun, kam mir nur merkwürdig vor.

Ich selbst nutze die Stundenvorhersage gar nicht, dachte aber sie mit aufzunehmen, falls User viele Daten wie Stündliche Updates haben wollen.

[H5N1]

@WG25 sagte in Test Adapter open-meteo-weather v2.2.x GitHub/Lates:

Es gibt in dem Adapter für jeden Tag den stündlichen Forecast, je nach Einstellung 1, 6, 12 oder 24 Stunden...

... Wie gesagt, hat nichts mit der Adapter Funktionalität zu tun, kam mir nur merkwürdig vor.

Du hast recht, das ist mir gar nicht aufgefallen, ich bin davon ausgegangen das es z.B für Stunde 0 die Daten für 0.00Uhr - 1.00Uhr sind, für Stunde 1 von 01.00 Uhr - 02.00 Uhr ist, da ich nur darauf fixiert war ob die Datenpunkte gefüllt werden, nebenbei habe ich auch gesehen das für die Stundenvorhersagen die Icons nicht wechseln zwischen Tag und Nacht.
Das habe ich jetzt gefixt, jetzt werden die Tatsächlichen Stunden im entsprechenden Ordner angezeigt, allerdings wird nun für für hourly.day0.hour* ab der Stunde angezeigt wo der Adapter gestartet wurde, d.h. ändert man etwas und startet den Adapter um 19.15 Uhr wird erst ab day0.hour19 - 23 erstellt, das ist aber normal da der Adapter nur Daten aus dem jetzt und Zukunft abruft. Sollte aber mit dem Tageswechsel erledigt sein.

Ich werde das jetzt noch beobachten ob das alles funktioniert und werde die Änderungen demnächst in einer neuen Version hochladen.

Grüße

[Homoran]

@WG25 sagte in Test Adapter open-meteo-weather v2.2.x GitHub/Lates:

Dabei ist die Stunde "0" immer die aktuelle Stunde, die "1" die nächste und so weiter.

das ist in dem DWD API (Adapter Brightsky) genauso.

Das erlaubt dir die Vorhersage für die nächsten Stunden

ohne große Manipulationen der DP-Referenzen darzustellen.
Voraussetzung ist natürlich, dass die Datenpunkte alle Stunde refresht werden

[H5N1]

Was von beiden ist dann nun besser bzw allgemein besser? Ich habe es nun so gebogen das die Stunden auch den entsprechenden Stunden entsprechen, da ich bisher davon ausgegangen bin das es auch tatsächlich so ist und sein soll. Was @homoran beschreibt klingt dabei schon sinnvoll, wobei anders gesehen wer scrollt schon bis zum 7. oder 16 Tag 21.00 Uhr um zu schauen ob da seine Bratwurst Nass werden könnte :), dann würde die vorhersage weiter als 2-3 tage für Stunden keinen Sinn machen außer viele Daten erzeugen. Schwierig jetzt.

[Homoran]

@H5N1 sagte in Test Adapter open-meteo-weather v2.2.x GitHub/Lates:

wer scrollt schon bis zum 7. oder 16 Tag 21.00 Uhr

ich halte es für den aktuellen Tag / die nächsten 12h/24h für sinnvoll.

ich muss mal nachsehen wie @ticaki das gelöst hat

EDIT:
tage ebenfalls mit 0,1,2,.... fortlaufend
hourly, Anzahl konfigurierbar, ich hab 18

Darin jeweils "alle" Werte für die entsprechende Stunde

incl. der Zeit in Klartext

[H5N1]

@Homoran sagte in Test Adapter open-meteo-weather v2.2.x GitHub/Lates:

ich halte es für den aktuellen Tag / die nächsten 12h/24h für sinnvoll.

Ich denke ich werde es wieder in den Ursprung zurück setzen, das ist tatsächlich sinnvoller.

[WG25]

@H5N1 sagte in Test Adapter open-meteo-weather v2.2.x GitHub/Lates:

@Homoran sagte in Test Adapter open-meteo-weather v2.2.x GitHub/Lates:

ich halte es für den aktuellen Tag / die nächsten 12h/24h für sinnvoll.

Ich denke ich werde es wieder in den Ursprung zurück setzen, das ist tatsächlich sinnvoller.

Sehe ich ja genauso. Es macht aus meiner Sicht nur die stündliche Vorhersage für die nächsten 12-24 Stunden Sinn. Muss also nicht unbedingt mit dem Tag 0 verknüpft sein.
Stunde 0 = aktuelle Stunde
Stunde 1 = aktuelle Stunde + 1
...
Stunde 12 = aktuelle Stunde + 12
usw.
Sollte dann möglichst auch über die Tagesgrenze gehen.