Twilight - Maintainership (orphan 2020)

[Otto123]

Ich habe im aktuellen Code mal zwei drei Typos gesehen und bereinigt

Ich hatte in dem anderen Thread ein bisschen mitgelesen

....?12 steht da, weil es genau so in der Doku (commandref) von Twilight steht, und ansonsten verstehe ich den Satz schon grammatikalisch nicht...

Und konnte aber irgendwie (in völliger Unkenntnis) nicht rauslesen wo in der Doku der Inhalt von state (die 12) erklärt wird? 

[Beta-User]

  Mist, das scheint wirklich in Bezug auf state nicht in der Doku zu stehen, und auch hier steht es (unter mehreren Gesichtspunkten) "falsch": https://wiki.fhem.de/wiki/Twilight_Anwendungsbeispiel#Zusammenhang_STATE_und_light. (der TE hatte aber ausdrücklich hierher verlinkt, und das vormalige "Springen" war hier auch ein längeres Thema?!?)

Das mit "state" hatte ich dann wohl hier der User-Erwartung (und dem seitherigen Code) entnommen, da kommt dann jetzt ein Halbsatz dazu... (Aber auch so ist doch eigentlich glockenklar, dass "state", "light" und "twilight" etwas unterschiedliches bedeuten sollen, oder...)

Danke für die Hinweise auf die Typos, werd's fixen...

Bei der Gelegenheit die Rückfrage an den einen Tester (!?!) für die "morgige Twilight-Abfrage": Funktioniert das zufriedenstellend?
Dann würde ich das auch gleich mit einchecken...

[BroPi]

Bei der Gelegenheit die Rückfrage an den einen Tester (!?!) für die "morgige Twilight-Abfrage": Funktioniert das zufriedenstellend?
Dann würde ich das auch gleich mit einchecken...

Ich bin wohl gemeint.
Hatte gleich die Testversion installiert und freue mich, dass du über sx_tomorrow immer noch nachdenkst. Bin aber noch beim Testen. Prinzipiell funktioniert die Sache mit sx_tomorrow. Bisher habe ich aber noch zu wenige Schaltpunkte analysiert.

Code Auswählen Erweitern

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.

Bloß was soll das mit dem fiktiven Wert von "50". Da ist ja wohl keine Wetterabhängigkeit dabei, oder sehe ich das verkehrt? Wenn das fest sein sollte, so erreicht man das gleiche, wie mit dem INDOOR_HORIZON und kann gleich das sx_indoor nehmen. Mir wäre es wirklich lieber echte vorliegende Wetter-Daten (z.b. fc1_cloudxx von Proplanta) für sx_tomorrow von Morgen zu verwenden.

[misave]

Hallo an alle, die hier helfen das Twilight umzubauen,

was muss ich denn derzeit tun?

Ich habe das Twilight Modul    
59_Twilight.pm:0.232250/2020-11-24

installiert. als DEF habe ich
51.0963931 6.5144158 1
ohne weitere Angaben und auch ohne das attr useextweather zu setzen.

Ich habe parallel ein altes System mit einem alten Twilight laufen, welches halt jeden tag meckert, dass es kein yahoo-weather erreicht. Kann ich mit leben...

Muss ich derzeit was machen am Twilight welches ich wie oben genannt installiert habe? ich nutze derzeit das ss-weather nicht, ich sehe aber, dass dieser Wert in den beiden Systemen etwa 8 Minuten unterschiedlich ist.

Danke.

[Beta-User]

was muss ich denn derzeit tun?

"Müssen" solltest du nichts, eventuell ändert dir der neue Code die DEF, wenn die long/lat-Angaben identisch sind zu denen in global, dann bleibt nur die "1" stehen.

Wo die ~8 Minuten her sind, kann ich dir im Moment nicht erklären, denke aber, dass der jetzige Code "korrekte" Werte für heute liefert bzw. solche, die so gut sind wie das, was SUNRISE_EL liefert.


Die cref-Typos sind jetzt raus und auch was kurzes zu "state" ist ergänzt, und das mit sr_tomorrow ist auch im svn.

Das mit "50" ist die "alte" Logik, die Twilight "schon immer" angewendet hat, wenn es was nicht besser wußte. Hintergrundgedanke war der, dass ich erst mal einen Einstieg haben wollte, der 100% kompatibel ist mit dem, was heute das Modulverhalten ist (=> zusätzliche keywords). Wer jetzt mit den "50" noch nicht zufrieden ist, hat zwei Möglichkeiten:
- entweder eigenen Code im Vorfeld ergänzen, der z.B. auf einen "halbwegs passenden" Wert zeigt:

Code Auswählen Erweitern

{ twilight('tw_test1','sr_tomorrow','08:00','09:10',ReadingsNum('myProplanat_Device','passendes_8_Uhr_Reading',70)) }
- oder einen (Code-) Vorschlag machen, der bei Aufruf nicht direkt die "50" als Ersatzwert nimmt, sondern erst mal checkt, ob es Möglichkeiten gibt, das für diesen Typ Wetter-Device passend zu ermitteln. Darüber, wie das gehen könnte, müsste man dann halt nachdenken, falls die obige "einfache" Variante mit ReadingsNum() nicht genau genug ist. Im Moment halte ich persönlich das für hinreichend, habe aber auch kein Problem, funktionalen Code einzuchecken, falls er generisch genug ist, dass man "vorhandenen" Code von "nicht vorhandenem Code" (=> Ersatzwert) unterscheiden kann...

[BroPi]

- oder einen (Code-) Vorschlag machen, der bei Aufruf nicht direkt die "50" als Ersatzwert nimmt, sondern erst mal checkt, ob es Möglichkeiten gibt, das für diesen Typ Wetter-Device passend zu ermitteln.

Hier ein Vorschlag um mit Proplanta die Cover-Werte für tomorrow zu ermitteln:

Code Auswählen Erweitern

sub getwTYPE_PROPLANTA {
    my $hash   = shift // return;
   
    my $extDev = $hash->{helper}{extWeather}{Device};
    my @hour  = getTwilightHours($hash);
       $hour[3] = $hour[1];
   $hour[4] = $hour[2];
    my $fc_day0 = secondsSinceMidnight( time() ) > 60 ? 0 : 1;
    my $fc_day1 = $fc_day0 + 1;
   
    my @ret;
    for (my $i = 0; $i < 5 ; $i++) {
$fc_day0 = $i < 3 ? $fc_day0 : $fc_day1;
        $hour[$i] <  4 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud03",0) : (
        $hour[$i] <  7 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud06",0) : (
        $hour[$i] < 10 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud09",0) : (
        $hour[$i] < 13 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud12",0) : (
        $hour[$i] < 16 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud15",0) : (
        $hour[$i] < 19 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud18",0) : (
        $hour[$i] < 22 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud21",0) :
        $ret[$i] = ReadingsNum($extDev,"fc${fc_day1}_cloud00",0)))))));
    }
Log3( $hash, 3, "[$hash->{NAME}] Proplanta data: hours $hour[0]-$hour[1]-$hour[2]-$hour[3]-$hour[4], fc_day0 $fc_day0,fc_day1 $fc_day1, data $ret[0]-$ret[1]-$ret[2]-$ret[3]-$ret[4]");
    return @ret;
}
Dabei sind dann die $ret[3] und $ret[4] die entsprechenden Rückgabewerte für Cloudcover_Tomorrow (früh und abends). Diese Sub ist erprobt und bringt die richtigen Rückgabewerte von Proplanta. Mein Problem ist es, diese Werte dann weiter in Twilight zu verarbeiten (bin leider kein Programmierer). Vielleicht hilft diese Ansatz als Anregung dem Profi aber weiter!?

[Beta-User]

Hm, ich schau's mir an, aber im Moment habe ich Zweifel, ob diese Bedingung erfüllt ist:

[...] der bei Aufruf nicht direkt die "50" als Ersatzwert nimmt, sondern erst mal checkt, ob es Möglichkeiten gibt, das für diesen Typ Wetter-Device passend zu ermitteln. Darüber, wie das gehen könnte, müsste man dann halt nachdenken, falls die obige "einfache" Variante mit ReadingsNum() nicht genau genug ist. Im Moment halte ich persönlich das für hinreichend, habe aber auch kein Problem, funktionalen Code einzuchecken, falls er generisch genug ist, dass man "vorhandenen" Code von "nicht vorhandenem Code" (=> Ersatzwert) unterscheiden kann...

Es fehlt mind. der "Check", also die Unterscheidung für PROPLANTA und Weather (oder zumindest etwas entsprechendes für Weather), und grundsätzlich gefällt mir nicht so recht, dass man für einen (gefühlten) Spezialfall in allen anderen Fällen auch immer noch diese beiden Werte mit ermittelt. Aber dieser Overhead ist wohl nicht besonders groß und liese sich ganz vermeiden, wenn man den Parameter $fc_day0 mit übergeben könnte:

Code Auswählen Erweitern

my $fc_day0 = shift // secondsSinceMidnight( time() ) > 60 ? 0 : 1;
Aber wie das dann bei Weather gehen soll...? Klar kann man dann bei fehlender Rückgabe der [3]/[4]-Werte dann wieder 50 nehmen, aber insgesamt ist da auch nicht für den User transparent, wo das denn funktioniert und wo nicht. M.E. unschön und (v.a.) erklärungsbedürftig (dauerhaft...).

Zusammengefasst: Lieber wäre mir ein separater Funktionsaufruf, bekannt gemacht (wo vorhanden) via "my $dispatch"-Hash (Zeile 484), der dann direkt bei Aufruf mit dem Argument/keyword  (z.b. sr_tomorrow) den zu dieser Zeit passenden Bedeckungsgrad als Zahl zurückgibt, und - wenn schon denn schon ... - dann auch mit "sr_alt" (analog Twilight_calc) den morgigen indoor-Wert berücksichtigt...
Gesamtbild damit klarer?

(Und als "Profi" fühle ich mich bei weitem nicht...)

[kaihs]

Ist es eigentlich so gewollt, dass der state bei einem fhem Neustart alle Zustände bis zur aktuellen Uhrzeit direkt hintereinander durchläuft?

Das sieht dann bei mir z. B. so aus:

Code Auswählen Erweitern


2021.01.02 12:38:37.323 0: Server started with 528 defined entities (fhem.pl:23445/2020-12-31 perl:5.028001 os:linux user:fhem pid:26278)
2021.01.02 12:38:40.741 1: twilight_state=2 event=state: 2 light=2 tempMaxAussen=3 schwellwertAussen=20 weekend=1 abwesend=
2021.01.02 12:38:40.771 1: twilight_state=3 event=state: 3 light=3 tempMaxAussen=3 schwellwertAussen=20 weekend=1 abwesend=
2021.01.02 12:38:40.803 1: twilight_state=4 event=state: 4 light=4 tempMaxAussen=3 schwellwertAussen=20 weekend=1 abwesend=
2021.01.02 12:38:40.804 1: Rolläden werden hochgefahren
2021.01.02 12:38:42.373 1: twilight_state=5 event=state: 5 light=5 tempMaxAussen=3 schwellwertAussen=20 weekend=1 abwesend=
2021.01.02 12:38:42.406 1: twilight_state=6 event=state: 6 light=6 tempMaxAussen=3 schwellwertAussen=20 weekend=1 abwesend=


Das Verhalten war zumindest mit der alten Version des Moduls so nicht vorhanden.

[Beta-User]

Die Frage, wie das gewollt ist, hatte ich hier auch schon mal gestellt und - soweit ich mich entsinne - gab es dazu keine Rückmeldung. Von daher war ich auch davon ausgegangen, dass das so gewünscht ist und auch dem historischen Verhalten entspricht.

Habe daher Skrupel, da was zu ändern, kann mir aber schon Gedanken machen, wenn es allgemein gewünscht ist (ggf. auch als Option).

[kaihs]

Bei mir führt das leider dazu, dass bei jedem Neustart die Rollläden hochfahren auch wenn es schon abends ist.

Und wenn man testet gibt schon mal zahlreiche Neustarts hintereinander.

Daher würde mich über eine Möglichkeit das Verhalten abzuschalten freuen.

[Beta-User]

Hmm, eigentlich finde ich es auch intutiver, wenn man FHEM "irgendwann" starten kann und dann jeweils halt nur der nächste Umschaltpunkt ausgelöst wird und nicht die bereits abgelaufenen. Die sollten ja in der Regel bereits abgearbeitet sein...

Hier jedenfalls eine Testversion, mit der man die Events abschalten kann, die zeitnah zum FHEM-Start gefeuert werden. Dazu das Attribut "triggerAtStartup" auf "0" stellen... Ab featurelevel 6.1 ist "0" derzeit als default vorgesehen.

Da aber jedes weitere Attribut tendenziell zu Verwirrung führt, wäre der eigentliche Plan, das direkt und ganz umzustellen => wer die "Treppe" erhalten will, möge bitte rechtzeitig die Hand heben!

[swsmily]

Hmm, eigentlich finde ich es auch intutiver, wenn man FHEM "irgendwann" starten kann und dann jeweils halt nur der nächste Umschaltpunkt ausgelöst wird und nicht die bereits abgelaufenen. Die sollten ja in der Regel bereits abgearbeitet sein...

Hier jedenfalls eine Testversion, mit der man die Events abschalten kann, die zeitnah zum FHEM-Start gefeuert werden. Dazu das Attribut "triggerAtStartup" auf "0" stellen... Ab featurelevel 6.1 ist "0" derzeit als default vorgesehen.

Da aber jedes weitere Attribut tendenziell zu Verwirrung führt, wäre der eigentliche Plan, das direkt und ganz umzustellen => wer die "Treppe" erhalten will, möge bitte rechtzeitig die Hand heben!

Nur meine Meinung:
"Treppe" bei Neustart muss nicht sein. Jedoch sollte nach einem Neustart von FHEM der aktuelle State entsprechend der Uhrzeit gesetzt werden. Das heißt, selbst wenn ich zum Beispiel mal Tagsüber 12 Uhr FHEM runterfahre (evtl. Stromausfall) und Abends gegen 21 Uhr erst wieder gestartet wird, sollte der State direkt auf 12 schalten. Nicht bei 6 und erst warten, bis der nächste Schaltzeitpunkt eintritt.
Persönliche fände ich also in dem Moment wo FHEM startet, dass direkt auf den zur Uhrzeit passenden State gestellt wird.

[Beta-User]

Werd's mir mal anschauen, aber zeitnah zum Start gar nicht triggern ist sehr viel einfacher als "nur den letzten zurückliegenden state nochmal triggern".
Von daher ist die Wahl derzeit eben tendenziell beschränkt Treppe oder kein trigger (mit der Tendenz zu kein trigger...)?

[kaihs]

Hier jedenfalls eine Testversion, mit der man die Events abschalten kann, die zeitnah zum FHEM-Start gefeuert werden. Dazu das Attribut "triggerAtStartup" auf "0" stellen... Ab featurelevel 6.1 ist "0" derzeit als default vorgesehen.

Da aber jedes weitere Attribut tendenziell zu Verwirrung führt, wäre der eigentliche Plan, das direkt und ganz umzustellen => wer die "Treppe" erhalten will, möge bitte rechtzeitig die Hand heben!

Danke, funktioniert bei mir mit der Testversion mit gesetztem Attribut wie gewünscht.

Wegen mir kann das auch das Standardverhalten ohne Umschaltmöglichkeit sein.
M. E. war das bei der alten Version des Moduls auch so.

[teufelchen]

Ich fände ohne Treppe besser, habe mir aber mit einen DoIf mit wait und einer Dummyvariablen geholfen.