Twilight - Maintainership (orphan 2020)

[Beta-User]

Die Sprünge könnten aber auch von der Bewölkung kommen.
mehr und dunklere Wolken = kleinerer light Wert.
Das könnte auch evtl erklären warum er gestern nicht über 5 raus ist.

Danke für die (eventuelle) Erklärung!

Anbei dann der Versuch, die eventbasierten Timer-updates dann auch zu überspringen, wenn der Zeitpunkt bereits um ist. Ist etwas "mit heißer Nadel gestrickt", bin also noch nicht so recht sicher, ob es wirklich "so einfach" ist, aber wenn ihr testet, dann ggf. gleich mit dieser Version.

Vom weiteren Vorgehen her wäre ich jetzt dankbar, wenn ihr zu dieser Version Rückmeldung geben könntet, die anderen werde ich entfernen.

Ziele in dieser Phase sollten sein:
- Probleme mit der package-Umstellung erkennen;
- "look&feel" erkunden, ob da noch was Nebenwirkungen hat, die mir bisher entgangen sein könnten;
- checken, ob die Werte "gut" sind (also in etwa dem entsprechen, was bisher so raukam)...

Nächster Schritt wäre dann ein grundlegender Cleanup (und extl. etwas Doku). Da ist noch einiges drin, was nicht mehr gebraucht wird, und manche Code-Aufruf-Ketten machen nur Sinn, wenn man auf externe Aktualisierungen wartet; da bin ich noch nicht sicher, ob man das in der Form noch braucht oder nicht das ganze auf eine rein eventbasierte Systematik umgestellt werden sollte, selbst wenn man "komplette" externe Wetterdienste anflanschen würde. Damit würde ich aber noch etwas (mind. mehrere Tage!) warten, erst sollten die grundlegenden Dinge passen...

[BroPi]

woher hast du die Vergleichswerte? Kopie des Moduls unter anderem Namen?).

Die Vergleichswerte sind vom 19.09. , das war wohl noch das Twilight mit dem alten Stand. Da waren immer die Sprünge drin, die schon mehrmals hier im Forum angemerkt wurden. Ich glaube die traten erst auf, als Yahoo seinen Dienst einstellte.
Ich lade immer die aktuelle Twilight auf meinem Aktivsystem (bin aber vorsichtig).

Die Sprünge könnten aber auch von der Bewölkung kommen.
mehr und dunklere Wolken = kleinerer light Wert.
Das könnte auch evtl erklären warum er gestern nicht über 5 raus ist.
Eventuell wäre es ja noch hilfreich den cloudcover mit in die Grafik zu ziehen?

Das könnte so sein. Früher hatte Cloud aber darauf aber keinen Einfluß.
Ich nehme deinen Vorschlag auf und nehme cloudcover mit in die Grafik rein. Bei Bedarf oder Auffälligkeiten kann ich wieder Bilder hier zur Verfügung stellen.
In meinem System ist es so, dass ich um 4 Uhr die fc0_cloud06 und um 15 Uhr die fc0_cloud18 aus Proplanta auslese und in ein Dummy schreibe. Dieses wird dann über useExtWeather in Twilight eingebunden. Also erfolgt 2 x am Tag eine Aktualisierung.

[Beta-User]

In meinem System ist es so, dass ich um 4 Uhr die fc0_cloud06 und um 15 Uhr die fc0_cloud18 aus Proplanta auslese und in ein Dummy schreibe. Dieses wird dann über useExtWeather in Twilight eingebunden. Also erfolgt 2 x am Tag eine Aktualisierung.

Lese ich das richtig: bei Proplanta könnte man z.B. den Vorhersagewert für 06:22 (für sr_indoor) aus fc0_cloud06 nehmen (gilt für 06:00 Uhr bis 06:59 Uhr) und damit arbeiten? Und für 07:02 Uhr aus fc0_cloud07?
Wie oft wird das aktualisiert?

(Ist schon klar, dass das ggf. wieder etwas größere Eingriffe in den Code geben würde, aber langsam glaube ich, ein gewisses Gefühl dafür zu haben, wie die vorhandenen Puzzleteile in etwa zusammengehören...)

[yersinia]

Lese ich das richtig: bei Proplanta könnte man z.B. den Vorhersagewert für 06:22 (für sr_indoor) aus fc0_cloud06 nehmen (gilt für 06:00 Uhr bis 06:59 Uhr) und damit arbeiten? Und für 07:02 Uhr aus fc0_cloud07?
Wie oft wird das aktualisiert?

Jaein, der Abstand ist drei-stündlich (3-6-9-12 usw). Wie oft auf der Proplanta-Seite aktualisiert wird, weiss ich nicht. Hier ein Auszug aus den Readings eines Proplanta-Devices (fc0 ist heute):

Code Auswählen Erweitern

READINGS:
     2020-09-24 12:18:57   fc0_cloud00     87.5
     2020-09-24 12:18:57   fc0_cloud03     100
     2020-09-24 12:18:57   fc0_cloud06     25
     2020-09-24 12:18:57   fc0_cloud09     0
     2020-09-24 12:18:57   fc0_cloud12     25
     2020-09-24 12:18:57   fc0_cloud15     87.5
     2020-09-24 12:18:57   fc0_cloud18     87.5
     2020-09-24 12:18:57   fc0_cloud21     87.5
[...]
     2020-09-24 12:18:57   fc1_cloud00     100
     2020-09-24 12:18:57   fc1_cloud03     87.5
     2020-09-24 12:18:57   fc1_cloud06     87.5
     2020-09-24 12:18:57   fc1_cloud09     0
     2020-09-24 12:18:57   fc1_cloud12     37.5
     2020-09-24 12:18:57   fc1_cloud15     50
     2020-09-24 12:18:57   fc1_cloud18     37.5
     2020-09-24 12:18:57   fc1_cloud21     62.5
Wären hier userReadings bzw Attribute nicht besser - um die Readings aus anderen Devices dynamischer einbinden zu können. Wer weiss welche Wetterdevices noch dazu kommen. WeatherUnderground, eigene Devices, Lichtsensoren vom ESP usw...


Btw, bei DarkSky sieht es so aus (fc1 wäre dann heute, fc2 morgen):

Code Auswählen Erweitern

READINGS:
     2020-09-24 12:24:00   cloudCover      35
[...]
     2020-09-24 12:24:00   fc1_cloudCover  76
[...]
     2020-09-24 12:24:00   fc2_cloudCover  65
obwohl ich hier daily forecast habe, das würde auch stündlich gehen.

Stündlich habe ich bei openweathermap, da ist es aber fortlaufend von jetzt an:

Code Auswählen Erweitern

READINGS:
     2020-09-24 12:21:35   cloudCover      36
     2020-09-24 12:21:35   current_date_time Do, 24 Sep 2020 12:21
[...]
     2020-09-24 12:21:35   hfc1_cloudCover 41
     2020-09-24 12:21:35   hfc1_day_of_week Do, 13:00
[...]
     2020-09-24 12:21:35   hfc2_cloudCover 84
     2020-09-24 12:21:35   hfc2_day_of_week Do, 16:00
[...]
     2020-09-24 12:21:35   hfc7_cloudCover 76
     2020-09-24 12:21:35   hfc7_day_of_week Fr, 07:00


[Beta-User]

Danke für den Überblick, das zeigt schon, wie "bunt" die Welt da ist...

Wären hier userReadings bzw Attribute nicht besser - um die Readings aus anderen Devices dynamischer einbinden zu können. Wer weiss welche Wetterdevices noch dazu kommen.

Also "können" sollte man das seit heute wieder , und wie es ausschaut, kennt der Code heute (und schon immer?) auch nur "den einen Bedeckungsgrad".

Das "Problem" ist nur, dass wir ggf. die User damit ziemlich alleine lassen, wie die Umrechnung sein soll usw.. Das ist erfahrungsgemäß fehleranfällig, und wer beim Erstellen von userReadings nicht aufpasst, triggert ggf. dann auch Twilight entsprechend häufig, usw., usf....

Mein gedanklicher Ansatz war, ggf. eine Art Tabelle zu erstellen, in der z.B. die von jeweiligen TYPE gelieferten Werte für jede Stunde des Tages stehen, da wäre dann eben für ein TYPE=proplanta ein 3-Stunden-Wert 3x gestanden. Ab da könnte man schauen, ob es die Tabelle gibt und die noch in der Zukunft liegenden Werte entsprechend der jeweils aktuellsten Vorhersage berechnen statt mit dem aktuellen Meßwert? Die "Sonderbehandlung" ergäbe sich dann ggf. daraus, dass Twilight diesen TYPE kennt und entsprechend eine andere Logik anwendet zur Ermittlung des Messwerts (und z.B. wieder eine "moderierende" Timer-Lösung anbietet statt der "trigger"-Variante)?

Wäre ja keine Plicht, sondern Kür...

[yersinia]

Vollkommen dacor.

Stellt sich  mMn nur die Frage des geringeren Aufwands. Deine vorgeschlagene Kür über den TYPE zu gehen, wäre echt super, zieht aber noch einiges nach sich - wenn TYPE=weather und API ist OpenWeathermap und Attribut forecast ist auf daily gesetzt, dann [Ableitungsregel], wenn forecast eq hourly, dann [andere Ableitungsregel]. Du müsstest dann im Twilight Modul alle Fälle abfangen und behandeln. Und aufpassen, wenn sich irgendwas an den abhängigen Modulen (weather, proplanta, httpmod, espbridge, mqtt usw) ändert.
Ich weiss nicht ob dann (wo auch immer) dokumentierte Twilight-spezifische(!)-userReading-codes (analog zu den httpmod/mqtt templates) dann einfacher wären, ein Reading cloudCover (oder jeweils eins für sr und ss) zu generieren, wenn immer Twilight sich selbst aktualisiert - also nicht durch Trigger von Außen. Alle Werte außerhalb von 0-100 würden dann ignoriert, die Definition wäre der Bewölkungsgrad in Prozent: 0[%]=strahlend blauer Himmel/Sternenklare Nacht, 100[%]=Zappenduster.
Wer FHEM halbwegs bedienen kann, kann auch auch RAW kopieren - mein ich.
Just my 2 Pfennich.

[Christoph Morrison]

Vielleicht kannst du ja mal Kontakt mit den Maintainer des Weather-API-Plugins aufnehmen und schauen, ob die vielleicht in der API eine Änderung machen können, dass du von dort z.B. currentWeather oder currentCloudage bekommen könntest, dann muss du nicht für jedes mögliche Wettermodul eine eigene Lösung implementieren.

[Beta-User]

Ihr seid lustig...

Est sollte mal das Grundgerüst wieder halbwegs vollständig laufen ...

Und was "du musst" etc. angeht: Ich hatte das eher so gedacht, dass ich bestenfalls eine Art "standardisierter Schnittstelle" anbiete und die eigentliche Datenaufbereitung dann ggf. außerhalb des Moduls läuft... So könnte jeder interessierte User was unter "lib" anbieten; das könnte man ggf. auch erweitern um die Regenmenge, whatever.... Oder eben so aufbauen, dass man einfach nur den Befehl "liefer mir den Bedeckungsgrad heute um x Uhr" raushauen kann und alles andere dann in einer entsprechenden sub abläuft, die dann eben im Modul ist.

Aber zum einen habe ich eben erst angefangen, mich etwas intensiver mit dem ganzen auseinanderzusetzen und zum anderen eigentlich auch keine Ahnung, wie sowas "richtig" geht, von daher: kommt Zeit, kommt Rat, und evtl. hat ja einer der bereits Mitlesenden (v.a. @CoolTux) eine noch bessere Idee...


Was anderes noch:
Im Moment findet sich der Bedeckungsgrad an drei Stellen: CONDITION, condition und extWeatherValue.
Meine Neigung wäre, das im Zuge des aktuellen Umbaus nur noch an einer Stelle vorzuhalten, und zwar entweder weiter als "condition" (mir persönlich eigentlich zu nichtssagend), oder als Reading "cloudCover" (wer was besseres weiß: tell me).

[BroPi]

"standardisierter Schnittstelle" anbiete und die eigentliche Datenaufbereitung dann ggf. außerhalb des Moduls läuft... So könnte jeder interessierte User was unter "lib" anbieten

Finde ich gut.

Was anderes noch:
Im Moment findet sich der Bedeckungsgrad an drei Stellen: CONDITION, condition und extWeatherValue.
Meine Neigung wäre, das im Zuge des aktuellen Umbaus nur noch an einer Stelle vorzuhalten, und zwar entweder weiter als "condition" (mir persönlich eigentlich zu nichtssagend), oder als Reading "cloudCover" (wer was besseres weiß: tell me).

Ich bevorzuge cloudCover.

Nachtrag:
Proplanta Abfrageintervall in Sekunden (Standard 3600 = 1 Stunde)

[swsmily]

Die Vergleichswerte sind vom 19.09. , das war wohl noch das Twilight mit dem alten Stand. Da waren immer die Sprünge drin, die schon mehrmals hier im Forum angemerkt wurden. Ich glaube die traten erst auf, als Yahoo seinen Dienst einstellte.

Kann ich bestätigen. Seit Yahoo den Dienst eingestellt hat, hatte ich auch diese Sprünge. Auch ohne extWeather.

Wie schon erwähnt, habe ich

Code Auswählen Erweitern

  my @horizons = ("_astro:-18", "_naut:-12", "_civil:-6",":0", "_indoor:$hash->{INDOOR_HORIZON}", "_weather:$hash->{WEATHER_HORIZON}");

zu

Code Auswählen Erweitern

  my @horizons = ("_astro:-18", "_naut:-12", "_civil:-6",":0", "_indoor:$hash->{WEATHER_HORIZON}", "_weather:$hash->{INDOOR_HORIZON}");

geändert.
Damit hab ich keine Sprünge mehr.

[Beta-User]

Hm, also das mit den unterbundenen Triggern war wohl eine Stufe too much, damit kamen dann nur noch die .*_weather-Readings...

Daher hier nochmal die Version von vor davor.

Die hatte dann auch wieder die .*_indoor-Zeiten geliefert, es könnte sein, dass das mit dem Springen auch daher kam, dass das in/outdoor ggf. immer beieinander war, weil aus irgendeinem Grund WEATHER dabei gar nicht berücksichtigt wurde. Evtl. muß ich da für die Zukunft etwas tricksen, damit das auch in Zukunft nicht wieder vorkommt (man könnte z.B.  indoorHorizont mal testweise auf 0.01 stellen, wenn nichts angegeben ist).

[swsmily]

Meinst du damit den Indoor_Horizon der im DEF definiert wird?
Den habe ich mit Yahoo und auch ohne immer auf 4 gehabt.
Aktuell:

Code Auswählen Erweitern

defmod Daemmerung Twilight 51.xxxxxxx 12.xxxxxx 4

[Beta-User]

Meinst du damit den Indoor_Horizon der im DEF definiert wird?

Jein. Diese Angabe kann zwar in den letzten hier angehängten Versionen noch in der DEF gemacht werden, allerdings ist das neuerdings ein Attribut. Wie geschrieben hatte das aber nach meinen bisherigen Erfahrungen ohne Yahoo gar keine Auswirkungen mehr.

Nochmal zu dem vorgeschlagenen "Tauschfix": ich _glaube_  nicht, dass dieser "Tausch" des Rätsels Lösung ist, vielmehr scheint der fehlende WEATHER-Internal-Wert einfach dazu geführt zu haben, dass eben 2*beide Werte nicht richtig berechnet wurden (für .*_weather und *._indoor). Nachdem dieses Internal aber wieder vorhanden ist, klappt das auch wieder mit *._indoor, ich habe nur noch keine Info, ob die Ergebnisse plausibel sind.   

Anbei jetzt nochmal der "letzte Stand der Dinge", das mit dem Unterdrücken der triggernden Updates für vergangene Timer klappt leider immer noch nicht so recht, aber evtl. stört das auch in der Praxis nicht...?

Da sind Weather- und Indoor-Horizont jeweils geringfügig gegeneinander verschoben, wenn sie "0" sind.

[BroPi]

Seit der gestrigen Version kommen state und light am Abend nicht mehr. Das sind die letzten Werte:

2020-09-24_17:47:08 HGW_Twilight 7
2020-09-24_17:47:08 HGW_Twilight light: 5

Heute beginnt es mit:

2020-09-25_08:43:10 HGW_Twilight 6
2020-09-25_08:43:10 HGW_Twilight light: 6

Siehe Bild im Anhang. Dort ist jetzt auch cloud mit aufgenommen. 

[Beta-User]

Jetzt hast du die Version von heute morgen am Start, oder?

Beide Versionen von gestern hatten je ein Problem, leider war mir das bei der 2. Variante erst abends dann aufgefallen (die erzeugte nur noch die weather-Readings, die anderen gar nicht).
Das sollte jetzt bei der aktuellsten beides behoben sein, und da sind dann auch long/lat per default nicht mehr in den Internals sichtbar, das Reading heißt cloudCover, und noch ein paar andere Kleinigkeiten...
Die Initialisierung ist noch nicht ganz optimal, wenn man useExtWeather gesetzt hat, aber abgesehen davon könnte das eine Version sein, die für etwas längeres Testen ok ist...