Twilight - Maintainership (orphan 2020)

[Loctite]

Hallo.
Super das du das Modul übernommen hast !
Eine Frage. Ich habe ein at

*{twilight("LichtWetter","ss_civil","17:00","22:00")} set Steckdose on

welches heute nicht funktioniert hat.
Als Status stand 17:00 Uhr, unter ss_civil sollte es aber 17:16 Uhr sein.
Ich bin mir eigentlich ziemlich sicher, das gestern Abend die richtige Uhrzeit dort stand.
Ein Neustart von FHEM ändert an der Uhrzeit nichts. Die ss_civil wird nicht übernommen.
Erst wenn ich die DEF des at editiere, nichts verändert, sondern nur modify klicke, wird die Uhrzeit richtig eingefügt.

Wie oft wird Twilight überhaupt aktualisiert ? Ich habe es mit Proplanta am laufen.
Ein aktualisieren von Proplante schreibt mir nur die readings twilight und twilight_weather neu (und azimuth, compasspoint...)

Eben ist ein neues Update rein gekommen, mal sehen wie es morgen aus sieht.

[Beta-User]

Muss ich mir ansehen, insgesamt bitte ich um Nachsicht, dass ich mich in diese Funktion grundsätzlich auch erst mal eindenken muss...

Vermutlich ist es auch bei at so, dass der Timer nach der Ausführung neu bestimmt wird - ergo gestern auf den gestrigen Wert gesetzt worden war (das war aber afaik schon immer so(?)) - mit den entsprechenden Wetterwerten.

Ob hier ein modifyTimeSpec die Lösung wäre?

Das Grundproblem ist und bleibt halt, dass man dann mit "relativ veralteten" Werten für die tatsächliche Bedeckung arbeitet. Wer das will, kann btw. auch die "userfunction"-Variante testen: Da seid ihr nicht auf meine Kompabilitätserwägungen angewiesen und könntet auch bequem zwei Twilight-Instanzen nutzen usw.. Die Rückgabe der Funktion muss nur leicht anders sein als intern (siehe cref).

Ich werde mir aber jetzt doch bei Gelegenheit nochmal ansehen, ob es mit vertretbarem Aufwand ginge, morgige Werte irgendwo vorzuhalten und durch einen entsprechenden twilight-Aufruf zu erhalten.

[Loctite]

Ja ich denke das war vorher auch so, das die Werte alt waren.
Das ändert sich aber auch nicht viel von Tag zu Tag, sind nur wenige Minuten, also diese berechneten Werte.
Die _weather Werte können sich natürlich Stündlich verändern, je nach Wetter.
Das müsste dann aber vom Wetter Modul getriggert werden.

Ich beobachte mal und werde mich noch mal melden.
Aktuell steht in meinem at:  TRIGGERTIME_FMT 2020-11-25 17:16:13
(Das ist der cc_civil Wert, jetzt nur zur Info auch für mich selber) 

[yersinia]

Ich schlage vor, jetzt diese DOIF-Problematik hier nicht weiter abzuhandeln. Wir haben das Problem erkannt. Wer DOIF mit Twilight-Funktionsaufruf verwenden will, muß also berücksichtgen  das die Schaltzeiten von heute für morgen genommen werden. Der User muss also selbst Vorsorge treffen, dass sein DOIF die int. Timer (zeitnah) aktualisiert. Einen Vorschlag dazu habe ich angeführt. Inwieweit Twilght mal sx_weather (heute) und sx_weather_tomorrow unterstützen wird, lasse ich mal offen und dir überlassen. Es ist ja nicht eine Kleinigkeit.

[OT]Das mMn subtile DOIF Bashing kann ich nicht nachvollziehen. Als Anfänger kam ich besser mit DOIF als mit at oder notify klar. Mittlerweile habe ich Letztere besser verstanden und kann die Funktionen gezielter einsetzen. Dennoch ist DOIF für mich immer noch eine gern genutztes Modul.[/OT]
Timing-Probleme habe ich mit allen Komponenten in Abhängigkeit vom Zeitpunkt der Abfrage. Wenn ich jetzt

Code Auswählen Erweitern

{twilight("Twilight","sr","06:00","09:00")
aufrufe, bekomm' ich jetzt auch den Wert vom heutigen sr Wert. Natürlich muss man sich dessen bewusst sein, dass die Funktion den Wert zum Zeitpunkt des Funktionsaufrufs zurück gibt.

Ob es nach Mitternacht nochmal eine Neuberechnung der Timer im DOIF, at, whatever-Device geben wird, kann ich nicht sagen. Möglicherweise triggert ein Event aus Twilight heraus die Neuberechnung der DOIF/at-Zeiten. Aber das ist nur eine Vermutung eines unwissenden.

Das Grundproblem ist und bleibt halt, dass man dann mit "relativ veralteten" Werten für die tatsächliche Bedeckung arbeitet. Wer das will, kann btw. auch die "userfunction"-Variante testen: Da seid ihr nicht auf meine Kompabilitätserwägungen angewiesen und könntet auch bequem zwei Twilight-Instanzen nutzen usw.. Die Rückgabe der Funktion muss nur leicht anders sein als intern (siehe cref).

Ich werde mir aber jetzt doch bei Gelegenheit nochmal ansehen, ob es mit vertretbarem Aufwand ginge, morgige Werte irgendwo vorzuhalten und durch einen entsprechenden twilight-Aufruf zu erhalten

Ist dies überhaupt Zielführend? Müsste ich aus Anwendersicht dann nicht auch um Mitternacht herum von Twilight-heute auf Twilight-morgen umschwenken? Das eigentliche Problem der Triggerzeiten ist dadurch nur verschoben aber mMn nicht gelöst. Möglicherweise benötigt man auch keine Lösung da ein Event erzeugt aus der Twilight-Neuberechnung nach Mitternacht eine Neuberechnung der Zeiten in den abhängigen Devices erzeugt!? (zumindest bei meinen DOIF-Devices kann ich das nicht bestätigen, da wird über Nacht nichts neu berechnet wenn man die twilight() Funktion nutzt)
Wie Loctite schreibt, ändern sich die Zeiten marginal (außer s._weather und ggfs s._indoor) - und gerade Wettervorhersagen sind für mich sowieso mehr Glaskugelvorhersage und ein grober Richtwert. [OT]Proplanta sagt gerade ein cloud cover von 62.5 an, während bei strahlend blauem Himmel die aufgehende Sonne auf meinem Monitor scheint.[/OT]

Trotzalledem VIELEN DANK das du (@Beta-User) dich da reinkniest und dieses Modul vorantreibst!

[Beta-User]

Ist dies überhaupt Zielführend?

Gute Frage!

Neige immer mehr dazu, das mit nein zu beantworten, denn neben den genannten Problemen mit der Vorhersagegenauigkeit muss man auch noch die "Basiszeiten" entsprechend berechnen usw. usf. Da bleiben wir doch einfach bei dem was zu Twilight als Basisaussage schon lange in der commandref steht:

Code Auswählen Erweitern

generate twilight & sun related events
Diese Events sollten so "genau" sein, wie es halbwegs sinnvoll ermittelt werden kann und es die zugrundeliegenden Informationsquellen erlauben.

Die twilight()-Funktion ist "Beiwerk" und hat halt die Einschränkung, dass es immer um "heute" geht. Wann "heute" beginnt, wird per Event mitgeteilt, wer mag, kann darauf reagieren, mit was auch immer.

Wer es für das Öffnen und Schließen von Rollläden verwenden will, fährt vermutlich am einfachsten mit WeekdayTimer, denn der denkt auch in täglich, oder eben mit ASC (das aber ggf. eine Reinitialisierung der Timer kurz nach Mitternacht braucht, was aber mir einem einfachen "at" ginge).

[OT]Das mMn subtile DOIF Bashing [...][/OT]

Nette Verharmlosung ...
Im Ernst:
Ich habe am Anfang auch ein paar Sachen damit gemacht und mich gefreut, dass "alles so einfach" ist und die Syntax weniger befremdlich wie Perl-Abfragen etc.. Aber irgendwann habe ich gemerkt, dass die Ergebnisse an der einen oder anderen Stelle nicht ganz so waren wie erwartet. Wie dem auch sei: Ich habe auch meine Beschränkungen und verstehe dieses Modul nicht, und jeder erneute Versuch, mich damit zu beschäftigen, endet für mich mit Frustration. Das mag self-fulfilling prophecy sein, und wir können diese Diskussion auch gerne mal bei einem Glas Bier oder Wein vertiefen, aber es führt hier nicht weiter. Ich für meinen Teil war jedenfalls erleichtert, als das letzte DOIF dann weg war, aber das ist eben meine ganz persönliche Erfahrung und Sichtweise, die muss man nicht teilen.

Also sorry, wenn ich euch mit meinem Frust behelligt habe, erklärt anderen, die ihre Probleme damit lösen wollen, wie es ggf. (z.B. iVm. Twilight/twilight()) geht, aber lasst mich damit in Ruhe, ist für alle besser .


Was Doku/cref angeht:
Ich werde mir das mal bei Gelegenheit für "at" ansehen, denn das ist in meiner Denke der Prototyp eines Timer-Moduls, und das hat im Prinzip dieselben "Schwierigkeiten" mit der Bestimmung der Timer für morgen.

[Loctite]

Hallo !

So das at hat die Zahlen behalten. Vielleicht war da auch auf meiner Seite ein Problem, weil ich Twilight ja erst auf Proplanta umgestellt habe.
Um 00:00:01 wurde ss_civil auf ss_civil 17:15:29 gestzt. Das at hat warum auch immer eine Sekunde früher.
Aber selbst wenn das nun die Uhrzeit von gestern oder morgen wäre...spielt ja gar keine Rolle, denn es ändert sich nur um wenige Minuten von Tag zu Tag...vermutlich auch Jahreszeit bedingt ? Keine Ahnung.

Ich bin auf jeden Fall sehr froh das nun auch eine Berücksichtigung per Wetter möglich ist.
Wer es genauer haben will, muss das dann per Lichtsensor oder so was machen.

Danke noch mal !

[Beta-User]

Danke für's Nachsehen. Das at hat den "gestrigen" Wert behalten, und wie weit die Werte auseinanderliegen, hängt stark von der Jahreszeit, und eben auch von der jeweiligen Bewölkung ab. Gibt es da massive Änderungen zwischen gestern und heute, kann das massiv auseinanderfallen.

Es wäre daher in der Tat wünschenswert, möglichst aktuelle Werte zugrunde zu legen
Tendenziell müßte es gehen, ein notify z.B. auf den sr_indoor-Event anzusetzen und darüber ein modifyTimeSpec (auf den bisherigen Wert) auf einem at auszuführen, das sr_weather via twilight() abfragt. Dann sollte der sr_weather-Wert so aktuell sein, wie es eben geht. Ähnlich dann mit sr_weather=>ss_weather.
Ist aber wirklich umständlich (v.a., wenn man es mit der WeekdayTimer-Variante vergleicht; der läßt sich auch zwischendurch relativ leicht resetten)... Aber evtl. hat da ja noch jemand eine elegantere Lösung?

[Loctite]

Ich dachte eigentlich bis jetzt, das nur bei den readings mit _weather die Bewölkung mit eingerechnet wird.
Alle anderen wie ss_civil oder ss_astro seien berechnete Werte anhand der geographischen Lage.

[Beta-User]

Trigger:sr_indoor => nicht wetterabhängig. Abfrage in twilight() auf sr_weather => veränderlich...

[Loctite]

Ja ok, wie ich zuerst auch vermutet hatte.

Kannst du mir vielleicht bei einer Sache helfen ? Ich möchte den ss_weather Wert verwenden und dort eine gewisse Zeit dazu rechnen.
Dafür habe ich ein userreadings in meinem twilight Device erstellt.
Leider funktioniert das hinzuaddieren aber nicht.

Versucht habe ich diese beiden Varianten
ss_weather2 {ReadingsVal("LichtWetter","ss_weather",0)+[00:20]}
ss_weather2 {ReadingsVal("LichtWetter","ss_weather",0)+1200}

[Beta-User]

Na ja, das Reading liefert eine Uhrzeit in HH:MM:SS. Das musst du halt bei Bedarf dann in Sekunden umrechnen, dann addieren und am Ende (falls du wieder eine Uhrzeit brauchst) wieder in HH:MM:SS umwandeln.

Wie das grundsätzlich funktioniert, wäre in https://wiki.fhem.de/wiki/Zeitangaben,_rechnen_mit dokumentiert, und es gibt auch ein paar Hilfsfunktionen in SUNRISE_EL, die z.B. dann auch Twilight intern verwendet, um das zu vereinfachen.
Reicht das als "Schubs"?

[Loctite]

Die Hilfe kenne ich. Hab da aber nicht richtig durchgeblickt.
Von DOIF kenne ich es so das dort einfach [+00:20:00] dazu kommt.
Aber wenn ich vorher in Sekunden umrechnen muss, dann hilft mir das weiter.

Danke !

[Beta-User]

Als Hilfestellung vielleicht: Es gibt in SUNRISE_EL ein paar Funktionen, die man direkt verwenden kann, z.B. hms2h(), um alles in "dezimale Stunden" umzurechnen: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/99_SUNRISE_EL.pm#L364.

Also wirf mal sowas in die Kommandozeile:

Code Auswählen Erweitern

{ h2hms_fmt(hms2h(ReadingsVal("LichtWetter","ss_weather",0))+0.33) }

[Beta-User]

Ergo müßte man wenn, dann einen Mechanismus haben, der es erlaubt, wahlweise den heutigen oder den morgigen Wert abzurufen. Und das wäre dann in der Tat aufwendig (und auch nicht einfach in der Handhabung). Glaube aber immer noch, dass es Wege innerhalb DOIF gibt, ein "korrektes" Ergebnis zu erzielen.

Hab's mir mal im Detail angesehen, es war dann mit ein paar kleineren Eingriffen in den Code doch möglich, was mAn. halbwegs sinnstiftendes zu basteln...

Hoffe mal, der commandref-Vorschlag ist hinreichend klar:

Optional ist es möglich, auch die morgigen sr_weather bzw. ss_weather abzufragen, dafür werden die "fiktiven" Reading-Namen "sr_tomorrow" bzw. "ss_tomorrow" verwendet. Als Bedeckungsgrad wird dabei ein fiktiver Wert von "50" angenommen, dieser kann mit (optionalem) 5. Parameter auch abweichend (Bereich: 0-100) angegeben werden. Beispiel:
     

Code Auswählen Erweitern

{ twilight('tw_test1','sr_tomorrow','08:00','09:10',100) }

Ist nicht intensiv getestet, aber die Ergebnisse sehen auf den ersten Blick plausibel aus, von daher: viel Spaß beim Testen...

(Wer die "nicht-wetterabhängigen" Werte haben will, kann das mit SUNRISE_EL haben, und an der Stelle habe ich auch nicht vor, den dispatch-Mechanismus auf "morgen" zu erweitern, den Wert müßt ihr also dann schon selbst liefern, wenn "mittlere Bedeckung" zu geraten ist...)

[teufelchen]

Bleiben zur Umsetzung des Wunsches von @teufelchen zwei Optionen: ein Attribut oä., mit dem man das einstellen könnte (bin aber nicht sicher, wie sich sowas im Programmablauf unterbringen ließe), oder (auch hier)
eine Anpassung des DOIF. Ein sehr kurzes "wait" könnte eventuell helfen? (Wie geschrieben: bin DOIF-DAU...).

@teufelchen: Kannst du das mal checken?

Das VErhalten lässt sich über eine Dummyvariable die über ein DoIf gefüllt wird unterdrücken.
Das DoIf übergibt den Light Wert an die Dummyvariable die dann für die eigentlichen Auswerungen verwendet wird. Mit wait wird das DoIf verzögert.