Modul für DWD Open Data

[Tsturm]

@ Jens - Du meintest wahrscheinlich forecastProperties - jetzt gesetzt, thx.

Allerdings liefert der Flughafen Muc noch nicht "PEvap" (hat er letztes Jahr getan). Ich habe mal verschiedene Stationen ausprobiert - keiner hatte es.. aber das ist natürlich stochern (oder gibt es einen Überblick über die Stationen mit deren Readings?)

Ich beobachte das mal, vielleicht wird der nur manchmal aktualisiert.

Hm - Nachtrag: ich habe mir mal die kmz-Datei angeschaut - da ist eine Sektion für PEvap mit vereinzelten Werten drin. Ist da vielleicht ein Dreher im Parser - verstehen tue ich das Format allerdings nicht..?

Code Auswählen Erweitern

<dwd:Forecast dwd:elementName="PEvap">
                    <dwd:value>         -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -       0.60          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -       0.90          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -       0.70          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -       0.60          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -       0.90          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -       1.00          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -          -</dwd:value>
                </dwd:Forecast>

Link zur Datei wie im Log von DWD (Verbose =5)
https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_L/single_stations/10870/kml/MOSMIX_L_LATEST_10870.kmz

Def:

Code Auswählen Erweitern

Internals:
   FHEM_TZ    Europe/Berlin
   FUUID      5c436478-f33f-b872-c1f0-bc9677883de3bd98
   NAME       DWD
   NR         255
   STATE      forecast updated
   TYPE       DWD_OpenData
   Helper:
     DBLOG:
       fc0_3_DD:
         logdb:
           TIME       1555177461.41126
           VALUE      53
       fc0_3_PPPP:
         logdb:
           TIME       1555177461.41126
           VALUE      1018.2
       fc0_3_RR3c:
         logdb:
           TIME       1555177461.41126
           VALUE      0.00
       fc0_3_TTT:
         logdb:
           TIME       1555177461.41126
           VALUE      5.90
       fc0_3_time:
         logdb:
           TIME       1555177461.41126
           VALUE      20:00
       fc0_Tx:
         logdb:
           TIME       1555177461.41126
           VALUE      9.90
       fc0_date:
         logdb:
           TIME       1555177461.41126
           VALUE      2019-04-13
       fc0_weekday:
         logdb:
           TIME       1555177461.41126
           VALUE      Sa
       fc1_0_DD:
         logdb:
           TIME       1555177461.41126
           VALUE      43
       fc1_0_PPPP:
         logdb:
           TIME       1555177461.41126
           VALUE      1019.1
       fc1_0_RR3c:
         logdb:
           TIME       1555177461.41126
           VALUE      0.00
       fc1_0_TTT:
         logdb:
           TIME       1555177461.41126
           VALUE      2.30
       fc1_0_time:
         logdb:
           TIME       1555177461.41126
           VALUE      02:00
       fc1_1_DD:
         logdb:
           TIME       1555177461.41126
           VALUE      40
       fc1_1_PPPP:
         logdb:
           TIME       1555177461.41126
           VALUE      1019.9
       fc1_1_RR3c:
         logdb:
           TIME       1555177461.41126
           VALUE      0.00
       fc1_1_TTT:
         logdb:
           TIME       1555177461.41126
           VALUE      2.40
       fc1_1_time:
         logdb:
           TIME       1555177461.41126
           VALUE      08:00
       fc1_2_DD:
         logdb:
           TIME       1555177461.41126
           VALUE      55
       fc1_2_PPPP:
         logdb:
           TIME       1555177461.41126
           VALUE      1019.9
       fc1_2_RR3c:
         logdb:
           TIME       1555177461.41126
           VALUE      0.00
       fc1_2_TTT:
         logdb:
           TIME       1555177461.41126
           VALUE      6.30
       fc1_2_time:
         logdb:
           TIME       1555177461.41126
           VALUE      14:00
       fc1_3_DD:
         logdb:
           TIME       1555177461.41126
           VALUE      16
       fc1_3_PPPP:
         logdb:
           TIME       1555177461.41126
           VALUE      1022.4
       fc1_3_RR3c:
         logdb:
           TIME       1555177461.41126
           VALUE      0.20
       fc1_3_TTT:
         logdb:
           TIME       1555177461.41126
           VALUE      5.5
       fc1_3_time:
         logdb:
           TIME       1555177461.41126
           VALUE      20:00
       fc1_Tg:
         logdb:
           TIME       1555177461.41126
           VALUE      -0.80
       fc1_Tx:
         logdb:
           TIME       1555177461.41126
           VALUE      7.10
       fc1_date:
         logdb:
           TIME       1555177461.41126
           VALUE      2019-04-14
       fc1_weekday:
         logdb:
           TIME       1555177461.41126
           VALUE      So
       fc_coordinates:
         logdb:
           TIME       1555177461.41126
           VALUE      11.8,48.37,453.0
       fc_copyright:
         logdb:
           TIME       1555177461.41126
           VALUE      Datenbasis
       fc_description:
         logdb:
           TIME       1555177461.41126
           VALUE      MUENCHEN-FL.
       fc_state:
         logdb:
           TIME       1555177461.44321
           VALUE      updated
       fc_station:
         logdb:
           TIME       1555177461.41126
           VALUE      10870
       fc_time:
         logdb:
           TIME       1555177461.41126
           VALUE      2019-04-13 17:00:00
   OLDREADINGS:
   READINGS:
     2019-04-13 19:44:21   fc0_3_DD        53
     2019-04-13 19:44:21   fc0_3_PPPP      1018.2
     2019-04-13 19:44:21   fc0_3_RR3c      0.00
     2019-04-13 19:44:21   fc0_3_TTT       5.90
     2019-04-13 19:44:21   fc0_3_time      20:00
     2019-04-13 19:44:21   fc0_Tx          9.90
     2019-04-13 19:44:21   fc0_date        2019-04-13
     2019-04-13 19:44:21   fc0_weekday     Sa
     2019-04-13 19:44:21   fc1_0_DD        43
     2019-04-13 19:44:21   fc1_0_PPPP      1019.1
     2019-04-13 19:44:21   fc1_0_RR3c      0.00
     2019-04-13 19:44:21   fc1_0_TTT       2.30
     2019-04-13 19:44:21   fc1_0_time      02:00
     2019-04-13 19:44:21   fc1_1_DD        40
     2019-04-13 19:44:21   fc1_1_PPPP      1019.9
     2019-04-13 19:44:21   fc1_1_RR3c      0.00
     2019-04-13 19:44:21   fc1_1_TTT       2.40
     2019-04-13 19:44:21   fc1_1_time      08:00
     2019-04-13 19:44:21   fc1_2_DD        55
     2019-04-13 19:44:21   fc1_2_PPPP      1019.9
     2019-04-13 19:44:21   fc1_2_RR3c      0.00
     2019-04-13 19:44:21   fc1_2_TTT       6.30
     2019-04-13 19:44:21   fc1_2_time      14:00
     2019-04-13 19:44:21   fc1_3_DD        16
     2019-04-13 19:44:21   fc1_3_PPPP      1022.4
     2019-04-13 19:44:21   fc1_3_RR3c      0.20
     2019-04-13 19:44:21   fc1_3_TTT       5.5
     2019-04-13 19:44:21   fc1_3_time      20:00
     2019-04-13 19:44:21   fc1_Tg          -0.80
     2019-04-13 19:44:21   fc1_Tx          7.10
     2019-04-13 19:44:21   fc1_date        2019-04-14
     2019-04-13 19:44:21   fc1_weekday     So
     2019-04-13 19:44:21   fc_coordinates  11.8,48.37,453.0
     2019-04-13 19:44:21   fc_copyright    Datenbasis: Deutscher Wetterdienst
     2019-04-13 19:44:21   fc_description  MUENCHEN-FL.
     2019-04-13 19:44:21   fc_state        updated
     2019-04-13 19:44:21   fc_station      10870
     2019-04-13 19:44:21   fc_time         2019-04-13 17:00:00
     2019-04-13 19:44:21   state           forecast updated
Attributes:
   forecastDays 1
   forecastProperties EDD,Tx, Tg, TTT, DD,  RR3c, PEvap,PPPP
   forecastResolution 6
   forecastStation 10870
   group      Wetter
   room       6.1_Rain,9.6_Umwelt
   verbose    5

Vielen Dank - Timmo

[jensb]

@Tsturm
Sorry mit dem Namen von forecastProperties habe ich mich vertan, aber du hast es ja trotzdem gefunden.

Der 1. Wert für PEVap ist der 39. Eintrag basierend auf 16:00 UTC. Damit landen wir bei Übermorgen 08:00 Europe/Berlin. PEVap ist ein 24h-Wert. Dieser Wert gilt dann für Morgen 08:00 bis Übermorgen 08:00. Das klingt vielleicht verwirrend, ist aber vom DWD so definiert.

Du kannst ihn also nur dann sofort abrufen, wenn du forecastDays mindestens auf 2 stellst. Wenn du wartest, sollte er ab 02:00 auch so erscheinen.

Grüße,
Jens

[Tsturm]

@Jens
wow... höhere Mathematik.. Ich glaube, das war letztes Jahr noch leicht anders definiert (da hatte ich das schonmal verwendet). Nja, macht auch nichts, gehts in dblog, und dann mit avg gemittelt - das klappt.

Vielen Dank, dann kann ich ja mal wieder die Beregnungsanlage koppeln..

VG und schönes WE!
VG timmo

[jensb]

In der Brechung von Azimut und Elevation der Sonne war ein Bug, entsprechend hat das Reading SunUp nur zu bestimmten Stunden gestimmt (die "Rektaszension" wurde nicht berücksichtigt).

Auf GitHub ist die korrigierte Version zu Ausprobieren.

Grüße,
Jens

[sfeli]

Moin,
herzlichen Dank für die Aktualisierung des Moduls DWD - freue mich schon auf das gute Wetter in Hamburg
Falls jemand noch Probleme mit der Erstellung einer readingsGroup  wo einige Werte (Vergangenheit) bei den Readings fehlen, dann hier eine praktikable Lösung:
[/size]

Code Auswählen Erweitern

DWD:<Wochentag>,*_weekday
DWD:<Temperatur.min>,*_Tn
DWD:<Temperatur.max>,*_Tx
<hr>
DWD:<Uhrzeit[hh:mm]:>,*_0_time
DWD:<Windrichtung:>,*_0_DD
DWD:<max.Windgeschwindigkeit:>,*_0_FX1
DWD:<Durchschnittstemperatur:>,*_0_TTT
DWD:<Regenwahrscheinlichkeit:>,*0_R600
DWD:<Regenmenge:>,*0_RR6c
<hr>
DWD:<Uhrzeit[hh:mm]:>,*_1_time
DWD:<Windrichtung:>,*_1_DD
DWD:<max.Windgeschwindigkeit:>,*_1_FX1
DWD:<Durchschnittstemperatur:>,*_1_TTT
DWD:<Regenwahrscheinlichkeit:>,*_1_R600
DWD:<Regenmenge:>,*_1_RR6c
<hr>
DWD:<Uhrzeit[hh:mm]:>,*_2_time
DWD:<Windrichtung:>,*_2_DD
DWD:<max.Windgeschwindigkeit:>,*_2_FX1
DWD:<Durchschnittstemperatur:>,*_2_TTT
DWD:<Regenwahrscheinlichkeit:>,*_2_R600
DWD:<Regenmenge:>,*_2_RR6c
<hr>
DWD:<Uhrzeit[hh:mm]:>,*_3_time
DWD:<Windrichtung:>,*_3_DD
DWD:<max.Windgeschwindigkeit:>,*_3_FX1
DWD:<Durchschnittstemperatur:>,*_3_TTT
DWD:<Regenwahrscheinlichkeit:>,*_3_R600
DWD:<Regenmenge:>,*_3_RR6c

und nun das Wesentliche readings vom nächsten Tag (fc1) werden in die zweite Spalte geschrieben:

Code Auswählen Erweitern

{ if (substr($READING,0,3) eq "fc1") {return 3} }


mit:

Code Auswählen Erweitern

valueFormat { if (substr($READING,6,4) eq "R600") {return "%.0f"}
elsif (substr($READING,6,4) eq "time") {return "$4"}
elsif (substr($READING,4,7) eq "weekday") {return "$2"}
else {return "%.0f"}}

sieht es noch gut aus. Analog können valueStyle und valueSuffix individuell gesetzt werden.

Wäre vielleicht ein Anfang für das Wiki - damit schnell ein Ergebnis erzieht werden kann.

[somansch]

Hallo Jens,

mir ist aufgefallen, dass irgendwie die Regendaten falsch sind. Ich habe das Gefühl, dass nach dem letzten Update die Regenmengen (fcx_x_RRhc, RR3c bzw. RR6c) immer 0.00 sind, obwohl wwd "durchgehend leichter Regen" und "durchgehend starker Regen"?! Weiterhin ist die Regenwahrscheinlichkeit immer 24% bzw. 25% (fcx_x_Rh00)?!

Hat noch jemand dies so beobachtet?

Danke und Gruß
Andreas

[jensb]

Hallo Andreas,

diesen Effekt habe ich bei mir nicht. Das Update hatte nichts mit dem Datenabruf vom DWD zu tun und sollte sich deshalb auch nicht so auswirken. Es ist auch zu beachten, dass der DWD ww und die Rxyz-Werte unabhängig voneinander bildet, so dass gelegentliche Widersprüche möglich sind.

Um die Ursache einzugrenzen kannst du entweder selbst in den DWD-Rohdaten nachsehen (Datei für Station herunterladen und entpacken und die Werte aus der Datei mit denen in FHEM vergleichen). Ansonsten kannst du mir auch deine Station mitteilen (z.B. per PM) und einen Zeiptunkt, wo dieser Widerspruch auftritt, dann sehe ich mir das an.

Grüße,
Jens

[somansch]

Hallo Jens,

ich habe die Readings mal mit den DWD Rohdaten verglichen. Das geht im Moment gut, da ja Unwetterwarnung für bayern und jede Menge Regen vorhergesagt wird  (Wetterstation 10870 - Flughafen München).

Das Problem ist, dass teilweise stündliche Readings erzeugt werden, aber keine Daten geliefert werden. Hier die Übersicht meiner Analyse:

Rh00   7,19 - keine Daten, aber Reading
   8,20 - richtig

Rhhc   7,19 - keine Daten, aber Reading
   8,20 - richtig

RR3c   1,4,7,10,13,16,19,22 - keine Daten, aber Reading
   2,5,8,11,14,17,20,23 - richtig

RRS3c - vermutlich genauso (mangels Schnee nicht zu prüfen  )

Kannst du die stündlichen Readings, welche keine Daten liefern noch rausnehmen?

Danke und Gruß
Andreas

Hier zur Referenz meine Moduldefinition:

Code Auswählen Erweitern

defmod DWD DWD_OpenData
attr DWD alertArea xxxxxxxxxxxx
attr DWD alertExcludeEvents 22
attr DWD alertLanguage DE
attr DWD event-on-update-reading 1
attr DWD forecastDays 10
attr DWD forecastProperties DD,FF,RRS3c,RR3c,RR6c,RRhc,Rh00,SunD,TTT,Tx,Tn,ww,wwd,SunUp,SunRise,SunSet
attr DWD forecastResolution 1
attr DWD forecastStation 10870
attr DWD forecastWW2Text 1

[jensb]

Hallo Andreas,

habe versucht deine Situation nachzustellen, aber irgendeine Info fehlt mir wohl noch. Da ich erst vorhin deine Einstellungen übernommen habe, werde ich heute wahrscheinlich nicht mehr den Effekt sehen können - werde das aber auf jeden Fall weiter beobachten.

Das Problem ist, dass teilweise stündliche Readings erzeugt werden, aber keine Daten geliefert werden. [...] Kannst du die stündlichen Readings, welche keine Daten liefern noch rausnehmen?

Alle Daten der MOS-Wettervorhersage haben ein Stundenraster, aber es gibt nicht für jede Stunde einen Wert - dann steht in den DWD-Rohdaten ein "-". Das ist soweit normal und in FHEM wird dann für diesen Wert auch kein Reading angelegt.

Alle Vorhersage-Readings werden um Mitternacht aus der Zukunft um 1 Tag in die Vergangenheit rotiert. Damit sind immer gültige Readings da, auch wenn noch keine Neuen vom DWD abgerufen wurden. Falls es nicht doch den Sonderfall gibt, dass die Readings aus der Zukunft zu anderen Stunden gültig sind als die von "heute", dürfte es auch keine Readings für "heute" geben, die nicht mehr aktualisiert werden. Insofern ist da nichts, was herauszunehmen wäre, wenn alles so funktioniert wie es sollte.

Zu deinen Analyseinfos: Meinst du mit "7,19" 7:00 und 19:00 und wenn ja UTC oder CEST? Meinst du mit "keine Daten", dass in den DWD-Rohdaten keine Daten sind?

Wie sieht der FHEM-Zeitstempel von den Readings aus, für die es keine DWD-Werte gibt (aktuell, alt)?

Grüße,
Jens

[somansch]

Hallo Jens,

Mit "7,19" meine ich jeweis die Readings "fcx_7_Rh00" bzw. "fcx_19_Rh00". Ich hoffe, dass das Reading mit 7 bzw. 19Uhr CEST befüllt wird  . Mit "keine Daten" meine ich, dass in den DWD Rohdaten dort ein "-" steht.

Der Zeitstempel sämtlicher Readings ist aktuell.

Ich hänge mal die "Raw Definition" als txt ran zur besseren Lesbarkeit des Threads.

Viele Grüße
Andreas

[jensb]

Hallo Andreas,

habe mir die Raw-Daten angesehen.

Mein Testsystem ist seit gestern auf die gleiche Station eingestellt, hat aber nicht die gleichen Daten. Damit meine ich nicht bestimmte Zahlenwerte sondern dass es bei mir keine Readings gibt, wenn in den DWD-Daten keine sind, so wie es sein sollte. Deshalb hatte ich wegen 7 und 19 auch nachgefragt.

Bei dir haben nicht alle Readings den gleichen Zeitstempel. Die meisten sind von 2019-05-20 00:00:05, aber es gibt auch welche von 2019-05-20 00:15:07 und auch von 2019-03-21 23:00:05. Abweichende ältere Zeitstempel sind nur für die ältesten Einträge von "heute" normal. Letzteres deutet darauf hin, dass du mit dem Device u.U. mehrere Stationen ausprobiert hast oder die forecastResolution geändert hast. In der Modulhilfe stand/steht bei einigen Attributen, dass man dann die Readings manuell löschen soll. Die aktuelle Modulversion macht das in einigen Situationen inzwischen automatisch.

Warum du auch Readings hast, die etwas neuer sind als die meisten anderen kann ich nicht erklären. Ist das nur die Momentaufnahme der angehängten Datei (z.B. wegen gerade erfolgtem Tageswechsel) oder ist das auch sonst so? Hast du vielleicht einen anderen FHEM-Ablauf, der auch auf die DWD-Readings schreibt?

Vorschlag: Einmal alle fc.* Readings löschen, "get forecast" aufrufen und noch einmal beobachten.

Grüße,
Jens

[somansch]

Hallo Jens,

danke für deine Vorschläge. Ich habe heute alle fc_* Readings gelöscht. Nach einem Update wurden die "fehlerhaften" Readings nicht neu erzeugt. Ich vermute, dass es mit dem Wechsel der forecastResolution zusammengehängt hat. Ich melde mich, falls die Readings wieder auftauchen sollten.

Vielen Dank und viele Grüße
Andreas

[Loredo]

Nicht gefallen tut mir, dass im DWD_OpenData-Modul die vermutlich vierte Sonnenparameterberechung von FHEM steckt - die anderen mir bekannten stecken in SUNRISE_EL, Astro und Twilight. Nur SUNRISE_EL ist so aufgebaut, dass man es aus anderen Modulen aufrufen kann und es hat die meisten Gemeinsamkeiten mit dem von mir gewählten Ansatz, verzichtet aber auf die von mir implementierte Genauigkeitsoptimierung, den Betrachter-Zeitzonenbezug und ein paar andere Details. Astro und Twilight sind wie das DWD_OpenData-Modul keine Funktionsmodule (lassen sich also nicht ohne weiteres in anderen Modulen), wobei Astro einen anderen wissenschaftlichen Ansatz als SUNRISE_EL und DWD_OpenData verwendet und Twilight die Daten gar nicht selbst berechnet sondern von einem Webdienst übernimmt. Wer sich mit der Theorie einmal auseinander gesetzt hat, den dürfte es nicht wundern, dass keine der 4 Ansätze die gleichen Werte liefern. Welcher Algorithmus der "wahre" ist, muss jeder selbst entscheiden. Meiner Ansicht nach würde es sich anbieten, SUNRISE_EL zu erweitern und den Code aus dem DWD_OpenData-Modul wieder zu entfernen.

Da ich gerade darauf gestoßen bin: Astro bietet ein Programmierer Interface an, auch ohne ein Device anzulegen. Dieses wurde jüngst auch erst optimiert. Ich bin gerade dabei eine optionale Kompatibilitätsschicht für den Ersatz von SUNRISE_EL einzubauen.
DaySchedule macht es vor, dort kann man auch ein Astro Device explizit angeben, wenn man dessen Einstellungen für die Berechnung verwenden möchte. DaySchedule bietet außerdem das gleiche Programmierer Interface und stellt die selben Astrodaten bereit, erweitert durch Werte aus dem kalendarischen Bereich.


Beide Module funktionieren gut im Tandem Betrieb und sind darauf ausgelegt doppelte Daten und Readings zu vermeiden. Ein DWD Modul sollte meiner Meinung nach nicht noch ein Reading für astronomische Werte anbieten, sondern sich auf das Wetter konzentrieren. Streng genommen sind die Astro Daten für die nächsten Tage ja keine Vorhersage, sondern eine Vorausberechnung und quasi eine Tatsache, die schon feststeht. Daher gehört es IMHO nicht zu Forecast Daten.

[jensb]

Hallo Loredo,

danke für den Hinweis, dass das Astro-Modul auch eine API hat - das werde ich mir ansehen. Es ist allerdings zu beachten, dass die verschiedenen Module unterschiedliche Ansätze und Approximationen nutzen und daher unterschiedlich genau sind. Das DWD-Modul stellt z.B. die genauere Version des Ansatzes von SUNRISE_EL zur Verfügung. Ob das Astro- oder das DWD-Modul absolut gesehen genauer sind, kann ich nicht beurteilen.

Ich stimme dir auch zu, dass diese Daten eigentlich nicht in das DWD-Modul gehören. Der Wunsch kommt ursprünglich von den Nutzern und ist aus deren Sicht zu verstehen. Es ist einfacher, im vorhandenen Verarbeitungskontext weitere Readings zu lesen, als die Daten über andere Wege zu bestimmen. Wenn es sich um eine nicht gerade selten genutzte Funktion handelt, macht es auch Sinn, sie zu integrieren, damit nicht jeder Nutzer das Rad neu erfinden muss, indem er diverse längliche Wiki-Artikel abarbeitet, um die gewünschte Funktion zu erhalten.

Grüße,
Jens

[Loredo]

Hi Jens,

Kannst du den Begriff von "genau" näher erläutern? Worin genau will das DWD Modul genauer sein?
Ich glaube pah hat bei dem Astro Modul ebenfalls die Absicht verfolgt, die Sache möglichst wissenschaftlich anzugehen. Deshalb fände ich es lohnenswert, wenn man hier die Bemühungen bündelt und das, was evtl. noch fehlt, in Astro hinzubaut (sofern es nicht pah's Vorgabe/Grundsatz entgegen steht, dass es was mit astronomischen Daten zu tun haben muss  ).


Ob man die selben Werte dann unterschiedlich benannt in mehreren Devices anzeigt oder nicht, sehe ich als zweitrangig an - sie sollten eben nur übereinstimmen und ich behaupte das geht am besten und einfachsten, wenn der selbe Code dafür verwendet wird 
Leider wurde aus der Idee, SUNRISE_EL ganz zu ersetzen, nichts. Aber muss es deshalb trotzdem zig Module geben, die das selbe tun? Genau in dieser vorausschauenden Absicht hat pah glaube ich die Programmierschnittstelle in Astro vorgesehen, damit man kein FHEM Device braucht (aber haben kann). DaySchedule macht das ja auch genauso: Es zeigt auch alle Astro Daten mit an, es sei denn man verlinkt ein bestehendes Astro Device. In jedem Fall bleibt aber die Berechnung unabhängig voneinander, trotzdem wir der selbe Code dafür verwendet.


Du schreibst ja auch etwas von Nutzererfahrung, wir liegen hier also glaube ich nicht weit auseinander und haben eigentlich das gleiche im Sinn.