Modul für DWD Open Data

[curt]

PS: Wie wird denn das Problem im "DWD_OpenData_Weblink-Generator" gelöst?

Zwei komplexe Grafiken, eine für 1100 und die andere für 1700 Uhr.

[Paul]

01:00 -> n
04:00 -> n
07:00 -> d
10:00 -> d
13:00 -> d
16:00 -> d
19:00 -> n
22:00 -> n

Diese Zuordnung wäre prima 

Was wäre daran prima?

Im Sommer ist um 19 Uhr sicherlich noch nicht Nacht.

[somansch]

Was wäre daran prima?

Im Sommer ist um 19 Uhr sicherlich noch nicht Nacht.

Das wäre immer noch besser, als gar keine Unterscheidung. Im Moment scheint auch nachts die Sonne 

[Knallkopp_02]

Was wäre daran prima?

Im Sommer ist um 19 Uhr sicherlich noch nicht Nacht.

Nur mal so eingeworfen, wenn du am Polarkreis wohnen würdest, würdest du dann zu den bestimmten Zeiten niemals Nacht/Tag haben? Irgendwo muss man die Grenze setzen, und den Tag halbieren finde ich zu den Zeiten in Ordnung.

Oder man muss es wirklich an den sonnenstand koppeln, was aber bestimmt kompliziert wird.

Gruss

[Paul]

Oder man muss es wirklich an den sonnenstand koppeln, was aber bestimmt kompliziert wird.

Gruss

Genau Time mit Sunset vergleichen

[frank]

Genau Time mit Sunset vergleichen

noch einfacher mit twilight und dem reading light.
wenn kein licht, ist es nacht, sonst tag.

[sinus61]

light ist aber ein aktueller Wert, das ist ja für Vorhersagewerte nicht so geeignet.

Ansonsten sollte Twilight aber schon das gewünschte liefern, wenn man im FTUI Widget den Zeitwert aus den Wetterreadings mit einem Twilight Reading vergleicht. Muß man halt bei der Definition das Twilight Device mit angeben.

[sinus61]

@sinus61
Die neue Version des DWD_OpenData-Moduls mit selektivem Löschen der Wetterwarnungs-Readings ist nun zum Testen auf GitHub verfügbar.

Danke, hab es gerade getestet, das mit den Events funktioniert nun. Ansonsten keine Probleme feststellbar.

Der Einwand bezüglich der Auswertung von a_count ist natürlich richtig, aber dann müsste ja eine Warnung zeitlich genau eine andere ablösen. Man könnte natürlich noch schauen ob sich der Inhalt z.B. der ersten Warnung bei Änderung von a_count auch geändert hat. Allerdings hatte ich letztens auch 2 zeitgleiche Warnungen, die bei verschiedenen Updates aber die Reihenfolge geändert haben. Da hat sich a_count nicht geändert, aber die a_0_* Readings schon, obwohl keine neue Warnung dazugekommen ist.

Da ich hier im Ort ja nicht die Sirenen auslösen will, sondern nur eine Telegram Warnung, scheint mir daher ein notify auf a_count die derzeit mit vertretbarem Aufwand beste Lösung zu sein.

[jensb]

@sinus61
Danke für die Rückmeldung. Werde die neue Version über FHEM zur Verfügung stellen (nachdem ich meinen Raspi auf Strech umgestellt habe).

Deine Anmerkung zu a_count sehe ich im Prinzip genauso. Der Fall ist eher theoretisch, aber ich wollte darauf hinweisen.

Grüße,
Jens

[jensb]

@curt

Wie wird denn das Problem im "DWD_OpenData_Weblink-Generator" gelöst?
Zwei komplexe Grafiken, eine für 1100 und die andere für 1700 Uhr.

Das ist so nicht richtig.

Der DWD_OpenData_Weblink-Generator stellt pro Tag 2 Werte zu Verfügung, vorzugsweise einen von Morgens und einen für Mittags. Für den 1. Tag ist dabei der 1. Wert ungefähr "jetzt". Wie bereits mehrfach erwähnt wird intern auf das FHEM-Modul SUNRISE_EL zurückgegriffen, das sich an den Einstellungen von FHEM global (longitude, latitude, altitude) orientiert. Nachdem für die jeweilige Zeit anhand von SUNRISE_EL ermittelt wurde, ob es Tag oder Nacht ist, wird entweder das Tag-Icon oder das Nacht-Icon aus der FHEM-Iconsammlung verwendet.

Stellt man die FHEM globals z.B. auf den Polarkreis ein, dürft je nach Jahreszeit dauerhaft Tag bzw. Nacht herauskommen.

Grüße,
Jens

[jensb]

Hallo Andreas,

D.h. unterm Strich wird es in deinem Modul niemals die fertigen Readings als Unterscheidung für Tag/Nacht geben, richtig?

Das ist doch nicht das Kernproblem. Entscheidend ist doch, dass du das Reading brauchst. Ich hatte geschrieben "Bei Interesse ...". Wenn du es für hilfreich hältst, dass das Modul ein Reading für Tag/Nacht liefert, würde ich das versuchen einzubauen. Das Kombi-Reading ist dann schnell mit einem notify nachgerüstet. Also entscheide dich ...

PS: Wie wird denn das Problem im "DWD_OpenData_Weblink-Generator" gelöst?

Siehe meine Erläuterungen für curt.

Grüße,
Jens

[somansch]

Hallo Andreas,
Das ist doch nicht das Kernproblem. Entscheidend ist doch, dass du das Reading brauchst. Ich hatte geschrieben "Bei Interesse ...". Wenn du es für hilfreich hältst, dass das Modul ein Reading für Tag/Nacht liefert, würde ich das versuchen einzubauen. Das Kombi-Reading ist dann schnell mit einem notify nachgerüstet. Also entscheide dich ... 

Grüße,
Jens

Hallo Jens,
die Tag/Nacht Unterscheidung an Hand von festen Uhrzeiten ist jetzt im FTUI Weather_Widget umgesetzt. Ich würde es nach wie vor hilfreich finden, wenn die Unterscheidung direkt im Modul durch ein zusätzliches Reading fcx_x_ww_daytime mit dem Wert von fcx_x_ww +d (für Tag) bzw. +n (für Nacht), z.B. 63d bzw. 63n realisiert wäre. Wenn es dann sogar in Abhängigkeit vom Sonnenauf- und -untergang wäre, um so besser .

Viele Grüße
Andreas

[sinus61]

Wenn du es für hilfreich hältst, dass das Modul ein Reading für Tag/Nacht liefert, würde ich das versuchen einzubauen. Das Kombi-Reading ist dann schnell mit einem notify nachgerüstet.

Ich denke zwar, dass es sich auch im FTUI Widget lösen lässt, aber anderseits liefern anscheinend alle Wettermodule etwas ähnliches mit aus. Das kommt ja nicht nur FTUI zugute, sondern allen nachgelagerten Systemen die etwas ähnliches machen.

[jensb]

@somansch + sinus61

Werde neue Vorhersage-Readings einführen, um die Tag/Nacht-Info zur Verfügung zu stellen. Denke dabei an SunAz (Azimuth), SunEl (Elevation) und SunTw (Twilight). Azumith und Elevation sind in [°] und Twilight in [%]. Bei weniger als 50 % Twilight wäre es dann eher Nacht.

Ein Codeanalyse der vorhandenen FHEM-Module vermittelt mir den Eindruck, dass sich der Ansatz des Twilight-Moduls am einfachsten übernehmen lässt. Auf eine Modulverknüpfung werde ich verzichten, da es die Installationsanforderungen erhöht.

Die Vorhersage-Stations-Geokoordinaten stehen ja als Reading "fc_coordinates" zu Verfügung. Damit wird dann die Tag/Nacht-Berechnung durchgeführt.

Grüße,
Jens

[jensb]

Die neue Version des DWD_OpenData-Moduls ist zum Testen über GitHub abrufbar. Es gibt die folgenden neuen Stunden-Readings:

• SunAz: Azimuth der Sonne [°]
• SunEl: Elevation der Sonne [°]
• SunUp: 0 = Nacht, 1 = Tag basierend auf nautischer Dämmerung (-12 °)

Die Werte sind von den Längen- und Breitengraden der ausgewählten Station abhängig. Für wen die nautische Dämmerung aufgrund der besonderen Gegebenheiten des Standorts oder der besonderen meteorologischen Bedingungen nicht geeignet ist, kann sich einen eigenen Tag/Nacht-Wert auf Basis von Azimuth und Elevation mit einem notify bilden. Genauso ist vorzugehen, wenn man ein zusammengesetztes Reading aus ww und SunUp benötigt.

Auch das Modul DWD_OpenData_Weblink wurde auf das neue Reading SunUp umgestellt und ist nun von den globalen FHEM-Standorteinstellungen unabhängig.

Grüße,
Jens