Twilight - Maintainership (orphan 2020)

Beta-User · 21 Oktober 2020, 15:47:39

...und wieder eine Iteration weiter...

Die ganze Timer-Verwaltung ist jetzt nochmal ungestellt, damit sollten (...) endlich die "verlorenen Timer" erledigt sein (die z.B. für diese "undefined"-Readings verantwortlich waren).

Was extWeather angeht, hat man derzeit zwei Varianten: Zum einen kann "irgendein" Reading an allen möglichen Device-Typen angegeben werden. Das muss nur triggernd aktualisiert werden, dann wird dieser Reading-Wert für alle Berechnungen der s._weather-Zeiten herangezogen. Klappt also auch mit Weather und PROPLANTA.

Bei diesen beiden ist es jetzt aber eigentlich so gedacht, dass bei diesen in der DEF einfach nur der Devicename "solo" angegeben wird, also ohne Reading-Angabe. Dann wird die interne "forecasting"-Funktion herangezogen (was bei PROPLANTA heißt, dass (nur) als Trigger "fc0_cloud06" verwendet wird (bitte Info, wenn was anderes "besser" ist) und die aktuellen Werte für die aktuelle bzw. jeweilige s._indoor-Zeit aus der Umsetzungstabelle ab Zeile 1100 gezogen wird; die sollte dabei die erste 1 Minute des Tages (kann noch geändert werden) dann noch die Forecast-Werte des Folgetages berücksichtigen und danach (=wenn dann später eine triggernde Aktualisierung kommt) dann eben die des aktuellen Tages (bis auf den letzten Wert, der geht dann auf den jeweiligen Folgetag).
Hab's aber bzgl. PROPLANTA noch nicht ausgetestet, das (einfachere) Weather (derzeit nur mit den defaults@darkSky) sieht aber gut aus

...

Bin mal gespannt, ob das jetzt eine gute Lösung (und auch ohne Log-Einträge) ist...
(Wenn das dann passt, muß erst mal der Code von den ganzen auskommentierten Teilen gesäubert werden...)

Falls jemand Erweiterungen des Weather-Codes für andere API's bzw. Einstellungen braucht: Bitte melden.

Falls jemand andere Dispatch-Varianten entwickeln will kurz noch ein paar einführende Worte:
Die ganze "Magie" besteht in der Angabe eines Hashes mit dem Reading, das als Trigger verwendet werden soll ("cloudcover") und einem Funktionsaufruf ("function"). Die Hash-Benennung muß dem TYPE entsprechen, Muster sind ab Zeile 481 zu finden.
Die Rückgabe der "function" ist eine Liste ("Array"), das entweder einen oder drei Werte enthält = den aktuellen Bedeckungsgrad, den bei sr_indoor und bei ss_indoor. Zur Ermittlung der (Uhr)-Zeiten (als Stundenwert) gibt es eine Hilfsfunktion getTwilightHours(), die ebenfalls eine Liste mit den drei betreffenden Uhrzeiten zurückgibt. Gibt eure Funktion nur einen Wert zurück, wird er für alle drei Zeiten berücksichtigt (wie bei "normaler" Reading-Angabe, aber eben flexibler).

Beta-User · 21 Oktober 2020, 16:47:27

@yersinia:
Betr. https://forum.fhem.de/index.php/topic,115158.msg1094250.html#msg1094250 habe ich in der pm aus dem letzen Post dann noch eine kleine Prüfung eingebaut, mit der dieses Warning dann auch weg sein sollte (es gilt aber weiter, dass man diesen Teil des Codes bitte erst man nicht versuchen sollte zu nutzen, falls sich jemand erschließt, was da wie angedockt werden soll

).

yersinia · 21 Oktober 2020, 20:55:19

Zitat von: Beta-User am 21 Oktober 2020, 16:47:27
Betr. https://forum.fhem.de/index.php/topic,115158.msg1094250.html#msg1094250 habe ich in der pm aus dem letzen Post dann noch eine kleine Prüfung eingebaut, mit der dieses Warning dann auch weg sein sollte (es gilt aber weiter, dass man diesen Teil des Codes bitte erst man nicht versuchen sollte zu nutzen, falls sich jemand erschließt, was da wie angedockt werden soll ).

Den Inhalt aus [fhem.pl] uninitialized value $cmd in pattern match (m//) at fhem.pl hatte ich auch unter #134 drangeklatscht, fand ich letztendlich hier besser.
Die neue #135 Version werde ich testen. Danke.

yersinia · 22 Oktober 2020, 08:09:18

So, die neue Version aus #135 hat sich seit dem Update gestern nicht bewegt, keine Neuberechnung, nixe. Man hängt immernoch im ss_astro fest, state und light sind auf 0.
Warnings o.ä. sind im Log nicht zu finden. $:-\$

Beta-User · 22 Oktober 2020, 10:10:54

Anbei wieder was neues. Bitte beachten: Die braucht unbedingt einen Neustart, da sich Funktionsnamen geändert haben!

Zu dem hier ein paar Fragen:

Zitat von: yersinia am 22 Oktober 2020, 08:09:18So, die neue Version aus #135 hat sich seit dem Update gestern nicht bewegt, keine Neuberechnung, nixe. Man hängt immernoch im ss_astro fest, state und light sind auf 0.
Warnings o.ä. sind im Log nicht zu finden. $:-\$

Kannst du vor dem Update auf diese Version mal schauen, ob über "fhemdebug timerList" irgendeiner der zu dem Twilight-Device gehörenden Timer läuft? (Kann sein, dass das etwas schwierig abzulesen ist).

Bestand das Problem schon seit gestern, und wenn ja, hattest du FHEM neu gestartet, oder ist das erst beim "Mitternachtswechsel" entstanden? (letzteres konnte ich bisher mit der neueren Timerverwaltung noch nicht testen; evtl. wäre interessant, wann der letzte sunpos-update war).

Ein logisches Problem habe ich beim dispatchen@Weather noch gefunden: Um Mitternacht haben wir uU. schon ältere fc-Readings, eigentlich müßte man deren Alter noch berücksichtigen (Event-basiert ist das immer aktuell).

BroPi · 22 Oktober 2020, 10:14:39

Kann ich bestätigen: state und light hängen irgendwie fest (keine Aktualisierung seit Gestern).
Eine Aktualisierung gab es allerdings gemäß FileLog bis jetzt 10:07 Uhr:
2020-10-22_08:32:56 HGW_Twilight 6
2020-10-22_08:32:56 HGW_Twilight light: 6
Vorher hingen die noch auf 0 bzw. 12. Um Mitternacht gab es bezüglich dieser Werte keine Aktualisierung.
Im Log:
2020-10-22_00:00:01 HGW_Twilight sr_weather: 09:21:36
2020-10-22_00:00:01 HGW_Twilight ss_weather: 16:19:42
2020-10-22_00:00:01 HGW_Twilight cloudCover: 87.5
2020-10-22_00:00:01 HGW_Twilight sr_weather: 09:21:36
2020-10-22_00:00:01 HGW_Twilight ss_weather: 16:19:42
2020-10-22_00:00:02 HGW_Twilight azimuth: 341.82
2020-10-22_00:00:02 HGW_Twilight elevation: -46.8
2020-10-22_00:00:02 HGW_Twilight twilight: 0
2020-10-22_00:00:02 HGW_Twilight twilight_weather: 0
2020-10-22_00:00:02 HGW_Twilight compasspoint: north-northwest

Beta-User · 22 Oktober 2020, 10:49:14

OK, das klingt logisch.

Dann hier nochmal eine Iteration, auch hier täte wieder ein Neustart von FHEM gut...

yersinia · 22 Oktober 2020, 12:25:10

Zitat von: Beta-User am 22 Oktober 2020, 10:10:54Zu dem hier ein paar Fragen:Kannst du vor dem Update auf diese Version mal schauen, ob über "fhemdebug timerList" irgendeiner der zu dem Twilight-Device gehörenden Timer läuft? (Kann sein, dass das etwas schwierig abzulesen ist).

Bevor ich auf die Version aus #141 gewechselt bin, habe ich fhemdebug timerList ausgeführt, zu Twilight war zu finden:

Code Auswählen

2020-10-22 12:12:34.00000 Twilight_sunpos
2020-10-22 17:18:11.93000 Twilight_fireEvent
2020-10-22 18:04:26.96000 Twilight_fireEvent
2020-10-22 18:17:58.97000 Twilight_fireEvent
2020-10-22 18:57:29.98000 Twilight_fireEvent
2020-10-22 19:35:59.99000 Twilight_fireEvent
2020-10-22 20:14:13.00000 Twilight_fireEvent
2020-10-23 00:00:01.00000 Twilight_Midnight

Zitat von: Beta-User am 22 Oktober 2020, 10:10:54Bestand das Problem schon seit gestern, und wenn ja, hattest du FHEM neu gestartet, oder ist das erst beim "Mitternachtswechsel" entstanden? (letzteres konnte ich bisher mit der neueren Timerverwaltung noch nicht testen; evtl. wäre interessant, wann der letzte sunpos-update war).

Die zweite Version aus #135 hatte ich um 20:55 gestern eingespielt, das war nach ss_astro eintraf. Und dann hat der Mitternachstwechsel nicht geklappt.
Ja, ich starte FHEM immer via shutdown restart neu, wenn ich die 59_Twilight.pm ersetzt habe.

Ich hab jetzt die Version #141 eingespielt und fhem neu gestartet, jetzt heisst es Beobachten. Bisher keine Warnings, Fehler o.ä. Das Twilight Device sieht auch gut aus von den Readings her.
Wenn ich jetzt ein fhemdebug timerList ausführe, fehlt der Mitternacht-Timer. Möglicherweise kommt der noch.

Code Auswählen

2020-10-22 12:26:53.00000 Twilight_sunpos
2020-10-22 17:18:11.95000 Twilight_fireEvent
2020-10-22 18:04:26.96000 Twilight_fireEvent
2020-10-22 18:17:58.97000 Twilight_fireEvent
2020-10-22 18:57:29.98000 Twilight_fireEvent
2020-10-22 19:35:59.99000 Twilight_fireEvent
2020-10-22 20:14:13.00000 Twilight_fireEvent

Passt auch gut zu den ss_.* Readings

Code Auswählen

READINGS:
     2020-10-22 09:14:27   aktEvent        sr_weather
     2020-10-22 12:21:53   azimuth         165.28
     2020-10-22 12:11:53   cloudCover      81.7
     2020-10-22 12:21:53   compasspoint    south-southeast
     2020-10-22 12:21:53   elevation       25.55
     2020-10-22 09:14:27   horizon         7.12
     2020-10-22 09:14:27   light           6
     2020-10-22 09:14:27   nextEvent       ss_weather
     2020-10-22 09:14:27   nextEventTime   17:18:11
     2020-10-22 12:11:53   sr              08:14:36
     2020-10-22 12:11:53   sr_astro        06:18:10
     2020-10-22 12:11:53   sr_civil        07:35:03
     2020-10-22 12:11:53   sr_indoor       08:28:09
     2020-10-22 12:11:53   sr_naut         06:56:28
     2020-10-22 12:11:53   sr_weather      09:14:27
     2020-10-22 12:11:53   ss              18:17:58
     2020-10-22 12:11:53   ss_astro        20:14:13
     2020-10-22 12:11:53   ss_civil        18:57:29
     2020-10-22 12:11:53   ss_indoor       18:04:26
     2020-10-22 12:11:53   ss_naut         19:35:59
     2020-10-22 12:11:53   ss_weather      17:18:11
     2020-10-22 09:14:27   state           6
     2020-10-22 12:21:53   twilight        100
     2020-10-22 12:21:53   twilight_weather 54

[OT]
Kann ich die angehängten Versionen eigtl via wget direkt aus dem Forum ziehen? Würde es etwas einfacher machen, dann hab ich nur zwei Terminal-Befehle....

Beta-User · 22 Oktober 2020, 13:06:31

Code umstrukturiert, das war eine unbeabsichtigte Nebenwirkung, den Midnight-Timer sollte es immer geben...!

Sollte jetzt auch behoben sein

.

yersinia · 22 Oktober 2020, 13:13:27

Auf gehts mit der neuen Version aus #143, fhem neustarten et voila:

Code Auswählen

2020-10-22 13:15:17.00000 Twilight_sunpos
2020-10-22 17:18:11.95000 Twilight_fireEvent
2020-10-22 18:04:26.96000 Twilight_fireEvent
2020-10-22 18:17:58.97000 Twilight_fireEvent
2020-10-22 18:57:29.98000 Twilight_fireEvent
2020-10-22 19:35:59.99000 Twilight_fireEvent
2020-10-22 20:14:13.00000 Twilight_fireEvent
2020-10-23 00:00:01.00000 Twilight_Midnight

Und dann wieder Beobachten.

yersinia · 23 Oktober 2020, 10:20:02

Die #143 sieht für mich als guter SVN Kandidat aus. Die Version lief ohne Probleme durch, sind jetzt beim light 6 / state 6. Seit dem Update gestern Mittag (siehe post zuvor) scheint es echt stabil zu laufen.
Ich hab noch ein Auge drauf, aber es sieht ganz gut aus. Cool.

Beta-User · 23 Oktober 2020, 10:25:22

Danke für's feedback, die lief auch bei mir gut durch, muß aber auch nochmal ins Log sehen.

Zwei Ding sollten möglichst noch anders werden:
- die "gefährliche Schnittstelle" ist zu deaktivieren (kein großes Problem) und
- für die Weather-Mitternachtswerte muß möglichst noch eine Zeitkorrektur rein... (falls jemand Lust hat, dafür einen Vorschlag zu liefern).

Beta-User · 24 Oktober 2020, 17:43:41

Hallo zusammen,

habe eben eine Version eingecheckt, die neben den beiden noch offenen Punkten hoffentlich auch gleich das leidige Thema Sommer-/Winterzeitwechsel beherrschen sollte - es wird an den fraglichen Tagen einfach um 02:00:01 bzw. 03:00:01 dann nochmal eine "Extra- Mitternachtsrunde" gefahren, damit auch die Readings dann wieder passen. (Die Timer für die Events sollten eigentlich trotzdem schon immer gepaßt haben, die werden in "Epoch" "gedacht".)

Wenn das klappt, bau' ich's dann auch bei Gelegenheit in den WDT ein

.

Mutige Tester sind also mal wieder willkommen...

Ansonsten noch zu dem hier:

Zitat von: hckoe am 24 Oktober 2020, 11:18:46
Hallo,

über das Reading twilight_weather steuere ich meine Jalousien und Rollläden. Bisher habe ich sie bei einem Wert zwischen 50 und 60 geöffnet. Seit dem letzten Update und auch mit der aktuellen Test-Version des Moduls hatte ich heute zum Beispiel an einem stark bewölkten Tag bis 11 Uhr einen Wert von 30 und dann plötzlich 98, und das Reading twilight war schon lange auf 100. Hat sich da bei der Berechnung irgendetwas grundlegend geändert?
Ich benutze openweathermap.

Viele Grüße
Helmut

"An sich" sollte sich die Berechnung nicht geändert haben, allerdings wird jetzt eben immer gerechnet, wenn ein entsprechendes Event kommt, vorher immer nur alle Stunde (eben wenn der Aktualisierungstimer durchlief). Von daher würde mich interessieren, ob das ein Einzelfall ist, oder ob noch jemand entsprechende Beobachtungen gemacht hat. Bisher klang das eigentlich nicht so...

Grüße, und viel Freude mit der jetzt offiziellen Version.

swsmily · 24 Oktober 2020, 21:44:46

Ist es normal, dass bei den letzten Versionen hier im Forum und auch bei der im SVN (die ja ab morgen per Update kommen sollte) State, Light usw. bei einem erneuten DEF oder komplett Neuanlegen des Devices nicht gesetzt werden?
Bei der Version die momentan noch per Update verteilt wird, werden beim Neustart von FHEM oder bei DEF alle Readings neu gesetzt.

yersinia · 25 Oktober 2020, 08:51:54

Nein das ist nicht normal. Bei keiner der Versionen aus diesem Thread, die ich getestet habe, wurden light/state gar nicht gesetzt - richtig ist, dass einige Versionen darunter light/state nicht verändert haben. Dies ist aber nach und nach durch Beta-User gefixt worden.
Auch die neuste SVN Version (59_Twilight.pm:0.230180/2020-10-24 von heute) setzt light/state korrekt.
Ein list deines Twilight Devices könnte helfen - wie aktuell ist dein FHEM?