Twilight - Maintainership (orphan 2020)

[Beta-User]

Thx, ist eingecheckt.

Daneben ist jetzt auch das feature für eigenen Code grundsätzlich mal enthalten, aber als experimentell gekennzeichnet.

Jetzt muss bei Gelegenheit nochmal aufgeräumt werden, da ist noch nicht alles "gut" (@Christoph: du darfst gerne...).

[Heuberg]

Danke für die gute Weiterentwicklung 
Irgendwo bin ich jetzt vom Wagen gefallen  Wenn ich Proplanta verwende, was muß ich bei useExtWeather angeben? 
"MyProplanta" oder "MyProplanta:Reading" -> aber welches Reading?

Viele Grüße und Danke
Rainer

[Beta-User]

Danke für die gute Weiterentwicklung 

Gerne doch!

was muß ich bei useExtWeather angeben? 

Nach jetzigem Stand würde ich das mal so zusammenfassen:
Nichts!

Langform:
Das Attribut useExtWeather ist eigentlich nur für die interessant, die eigenen Code zur Ermittlung des "Werte-Tripples" einbauen wollen.
Für alle anderen ist es eher empfehlenswert, das ganze direkt in der DEF zu integrieren. Dabei gibt es (für PROPLANTA und Weather) zwei Varianten, nämlich das "einfache" und das "erweiterte" Berücksichtigen des Bedeckungsgrades.
In der Regel gehe ich davon aus, dass man das "erweiterte" haben will. Dann gibt man einfach nur den Namen des ext. Wetter-Devices an, das ergäbe konkret was in diese Richtung:

Code Auswählen Erweitern

defmod Twilight Twilight 2.5 MyProplanta

(Namen und Wert geschossen, wer andere Koordinaten angeben will wie in global, muß das natürlich erweitern, und das Attribut _löschen_, das überschreibt nämlich die Angaben in der DEF...).

Für die "einfache" Variante (und die, die kein passendes Device-TYPE haben), ist dann das Reading anzugeben, das einen nummerischen Bedeckungsgrad enthält. Das wäre im Falle eines sich jeweils auf den aktuellen Wert beziehenden userReadings namens "actCC" dann eben:

Code Auswählen Erweitern

defmod Twilight Twilight 2.5 MyProplanta:actCC

Das mit dem "Überschreiben" ist übrigens dafür gedacht, dass man einfach zum Testen für externen Code das Attribut ergänzt, schaut, ob es tut und - wenn nicht - einfach wieder zum DEF-Wert zurückkehren kann...

Hoffe, das ist jetzt etwas klarer?

[Heuberg]

Danke Dir, jetzt sehe ich klar (cloudCover = 0), bin wieder auf dem Zug  .
Seit Mitternacht habe ich auch "cloudCover", "cloudCover_sr" und "cloudCover_ss".

[FunkOdyssey]

Ein paar schnelle Fragen:
- Kann man gar kein Intervall mehr festlegen? Oder macht das keine Sinn mehr ohne Yahoo-Weather?
- Könnte man ansonsten ein set xyz update implementieren?
- Die get-Befehle sind in der Detailansicht nicht sichtbar.

[Beta-User]

Das mit den gettern schaue ich mir an, war mir bisher nicht aufgefallen. Andererseits muß ich zugeben, dass ich (und wohl nicht nur ich) die bisher nicht vermisst hatte, denn die liefern ja auch nur die aktuellen Reading-Werte zurück, und die sieht man ja auch so... (eigentlich macht das ganze get-Verfahren (wohl zwischenzeitlich wegen allgemeinem ReadingsVal() in FHEM) für mich nicht den großen Sinn, aber vielleicht kann mir ja jemand erklären, für was es (außer zur Erhaltung der Kompabilität) gut ist... (Eigentlich wäre das ein Grund, die getter nicht prominenter zu platzieren und den Punkt zu lassen, wie er ist).

Ein Intervall kann man nicht mehr einstellen. Da früher erst die Werte von einem Internetdienst nach intern gepollt wurden, machte das Sinn. Über das NotifyFn-Verfahren dürfte das aber überholt sein. Entweder der Wert wird (extern&triggernd (!)) aktualisiert, dann bekommt Twilight das mit, oder eben nicht, dann sind die Werte auch aktuell. Geringfügige Differenzen kann es geben, wenn sich der Wert nur gering ändert:
- beim "einfachen" cloudCover-Verfahren führt das nur dann zur Aktualisierung, wenn eine Mindestschwelle (6?) überschritten ist;
- beim "erweiterten" forecasting (PROPLANTA und Weather) wird auch aktualisiert, wenn entweder die Schwelle überschritten ist (?) oder mind. eine Stunde um ist (wegen der anderen Werte wollte ich nicht auch noch Vergleiche anstellen) bzw. um Mitternacht (falls die Werte dann nicht völlig veraltet sind, sonst wird ein default verwendet).

Falls da irgendeine gedankliche Lücke sein sollte, bitte melden.
Ausdrücklich nicht unterstützen möchte ich Methoden der nichttriggernden Readingaktualisierung, falls es (noch) Module gibt, die sowas verwenden und direkt in den Hashes rumschreiben... (es sei denn, jemand erklärt mir nachvollziehbar, warum man das tun sollte.)

[Elektrolurch]

Habe heute mal nach einem Update wieder einen Neustart gemacht und folgendes im log gefunden:

Code Auswählen Erweitern


2020.11.14 11:52:24 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 4507.
2020.11.14 11:52:24 1: PERL WARNING: Use of uninitialized value in localtime at ./FHEM/59_Twilight.pm line 1021.
2020.11.14 11:52:24 1: PERL WARNING: Use of uninitialized value in localtime at ./FHEM/59_Twilight.pm line 1022.

Elektrolurch

[Christoph Morrison]

Habe heute mal nach einem Update wieder einen Neustart gemacht und folgendes im log gefunden:

Code Auswählen Erweitern


2020.11.14 11:52:24 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 4507.
2020.11.14 11:52:24 1: PERL WARNING: Use of uninitialized value in localtime at ./FHEM/59_Twilight.pm line 1021.
2020.11.14 11:52:24 1: PERL WARNING: Use of uninitialized value in localtime at ./FHEM/59_Twilight.pm line 1022.

Elektrolurch

Mach mal ein list vom Twilight-Device direkt nach einem Neustart und dann noch mal nach ein paar Minuten, zehn vielleicht.

[Beta-User]

Mach mal ein list vom Twilight-Device direkt nach einem Neustart und dann noch mal nach ein paar Minuten, zehn vielleicht.

+1

Weiter wäre es evtl. hilfreich, stacktrace zu aktivieren. Im Moment bin ich ratlos, ob das uninitialized in ReadingsVal() (#4507) auch (indirekt) aus Twilight kommt und wie die Zusammenhänge ggf. sind.
Weiter würden mich der TYPE vom Wetter-Device und die Systemumgebung interessieren. (Pi ohne HW-Clock?)

[Elektrolurch]

Code Auswählen Erweitern


2020.11.19 12:26:19 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 4507.
2020.11.19 12:26:19 1: stacktrace:
2020.11.19 12:26:19 1:     main::__ANON__                      called by fhem.pl (4507)
2020.11.19 12:26:19 1:     main::ReadingsVal                   called by fhem.pl (4520)
2020.11.19 12:26:19 1:     main::ReadingsNum                   called by ./FHEM/59_Twilight.pm (392)
2020.11.19 12:26:19 1:     FHEM::Twilight::Twilight_Firstrun   called by fhem.pl (3342)
2020.11.19 12:26:19 1:     main::HandleTimeout                 called by fhem.pl (677)
2020.11.19 12:26:19 1: PERL WARNING: Use of uninitialized value in localtime at ./FHEM/59_Twilight.pm line 1021.
2020.11.19 12:26:19 1: stacktrace:
2020.11.19 12:26:19 1:     main::__ANON__                      called by ./FHEM/59_Twilight.pm (1021)
2020.11.19 12:26:19 1:     FHEM::Twilight::getTwilightHours    called by ./FHEM/59_Twilight.pm (1031)
2020.11.19 12:26:19 1:     FHEM::Twilight::getwTYPE_Weather    called by ./FHEM/59_Twilight.pm (257)
2020.11.19 12:26:19 1:     FHEM::Twilight::Twilight_HandleWeatherData called by ./FHEM/59_Twilight.pm (777)
2020.11.19 12:26:19 1:     FHEM::Twilight::Twilight_Midnight   called by ./FHEM/59_Twilight.pm (399)
2020.11.19 12:26:19 1:     FHEM::Twilight::Twilight_Firstrun   called by fhem.pl (3342)
2020.11.19 12:26:19 1:     main::HandleTimeout                 called by fhem.pl (677)
2020.11.19 12:26:19 1: PERL WARNING: Use of uninitialized value in localtime at ./FHEM/59_Twilight.pm line 1022.
2020.11.19 12:26:19 1: stacktrace:
2020.11.19 12:26:19 1:     main::__ANON__                      called by ./FHEM/59_Twilight.pm (1022)
2020.11.19 12:26:19 1:     FHEM::Twilight::getTwilightHours    called by ./FHEM/59_Twilight.pm (1031)
2020.11.19 12:26:19 1:     FHEM::Twilight::getwTYPE_Weather    called by ./FHEM/59_Twilight.pm (257)
2020.11.19 12:26:19 1:     FHEM::Twilight::Twilight_HandleWeatherData called by ./FHEM/59_Twilight.pm (777)
2020.11.19 12:26:19 1:     FHEM::Twilight::Twilight_Midnight   called by ./FHEM/59_Twilight.pm (399)
2020.11.19 12:26:19 1:     FHEM::Twilight::Twilight_Firstrun   called by fhem.pl (3342)
2020.11.19 12:26:19 1:     main::HandleTimeout                 called by fhem.pl (677)


Code Auswählen Erweitern


Internals:
   DEF        48 11 3 Wetter
   FUUID      5c498765-f33f-c8c3-7f31-5af83f7537a5a7e9
   FVERSION   59_Twilight.pm:0.231260/2020-11-09
   INDOOR_HORIZON 3
   NAME       Daemmerung
   NOTIFYDEV  Wetter
   NR         437
   NTFY_ORDER 50-Daemmerung
   STATE      6
   SUNPOS_OFFSET 300
   TYPE       Twilight
   WEATHER_CORRECTION 6
   WEATHER_HORIZON 9
   READINGS:
     2020-11-19 12:26:19   aktEvent        sr_weather
     2020-11-19 12:31:24   azimuth         187.83
     2020-11-19 12:26:19   cloudCover      75
     2020-11-19 00:00:01   cloudCover_sr   63
     2020-11-19 12:26:19   cloudCover_ss   75
     2020-11-19 12:31:24   compasspoint    south
     2019-01-12 07:56:01   condition       28
     2019-01-12 07:56:01   condition_txt   Mostly Cloudy
     2020-11-19 12:31:24   elevation       21.38
     2020-11-19 12:26:19   horizon         9
     2020-11-19 12:26:19   light           6
     2020-11-19 12:26:19   nextEvent       ss_weather
     2020-11-19 12:26:19   nextEventTime   15:18:05
     2020-11-19 12:26:19   sr              07:34:36
     2020-11-19 12:26:19   sr_astro        05:39:03
     2020-11-19 12:26:19   sr_civil        06:54:16
     2020-11-19 12:26:19   sr_indoor       07:55:55
     2020-11-19 12:26:19   sr_naut         06:16:01
     2016-12-03 00:00:01   sr_twilight     undefined
     2020-11-19 12:26:19   sr_weather      08:42:16
     2020-11-19 12:26:19   ss              16:25:44
     2020-11-19 12:26:19   ss_astro        18:21:14
     2020-11-19 12:26:19   ss_civil        17:06:03
     2020-11-19 12:26:19   ss_indoor       16:04:25
     2020-11-19 12:26:19   ss_naut         17:44:16
     2020-11-19 12:26:19   ss_weather      15:18:05
     2020-11-19 12:26:19   state           6
     2020-11-19 12:31:24   twilight        100
     2020-11-19 12:31:24   twilight_weather 61
   TIMER:
     Daemmerung_Midnight:
       HASH       Daemmerung
       MODIFIER   Midnight
       NAME       Daemmerung_Midnight
     Daemmerung_sr:
       HASH       Daemmerung
       MODIFIER   sr
       NAME       Daemmerung_sr
     Daemmerung_sr_astro:
       HASH       Daemmerung
       MODIFIER   sr_astro
       NAME       Daemmerung_sr_astro
     Daemmerung_sr_civil:
       HASH       Daemmerung
       MODIFIER   sr_civil
       NAME       Daemmerung_sr_civil
     Daemmerung_sr_indoor:
       HASH       Daemmerung
       MODIFIER   sr_indoor
       NAME       Daemmerung_sr_indoor
     Daemmerung_sr_naut:
       HASH       Daemmerung
       MODIFIER   sr_naut
       NAME       Daemmerung_sr_naut
     Daemmerung_sr_weather:
       HASH       Daemmerung
       MODIFIER   sr_weather
       NAME       Daemmerung_sr_weather
     Daemmerung_ss:
       HASH       Daemmerung
       MODIFIER   ss
       NAME       Daemmerung_ss
     Daemmerung_ss_astro:
       HASH       Daemmerung
       MODIFIER   ss_astro
       NAME       Daemmerung_ss_astro
     Daemmerung_ss_civil:
       HASH       Daemmerung
       MODIFIER   ss_civil
       NAME       Daemmerung_ss_civil
     Daemmerung_ss_indoor:
       HASH       Daemmerung
       MODIFIER   ss_indoor
       NAME       Daemmerung_ss_indoor
     Daemmerung_ss_naut:
       HASH       Daemmerung
       MODIFIER   ss_naut
       NAME       Daemmerung_ss_naut
     Daemmerung_ss_weather:
       HASH       Daemmerung
       MODIFIER   ss_weather
       NAME       Daemmerung_ss_weather
     Daemmerung_sunpos:
       HASH       Daemmerung
       MODIFIER   sunpos
       NAME       Daemmerung_sunpos
   TW:
     sr:
       DEG        0
       LIGHT      4
       NAME       sr
       NAMENEXT   sr_indoor
       STATE      4
       SWIP       1
       TIME       1605767676.03
     sr_astro:
       DEG        -18
       LIGHT      1
       NAME       sr_astro
       NAMENEXT   sr_naut
       STATE      1
       SWIP       1
       TIME       1605760743
     sr_civil:
       DEG        -6
       LIGHT      3
       NAME       sr_civil
       NAMENEXT   sr
       STATE      3
       SWIP       1
       TIME       1605765256.02
     sr_indoor:
       DEG        3
       LIGHT      5
       NAME       sr_indoor
       NAMENEXT   sr_weather
       STATE      5
       SWIP       1
       TIME       1605768955.04
     sr_naut:
       DEG        -12
       LIGHT      2
       NAME       sr_naut
       NAMENEXT   sr_civil
       STATE      2
       SWIP       1
       TIME       1605762961.01
     sr_weather:
       DEG        9
       LIGHT      6
       NAME       sr_weather
       NAMENEXT   ss_weather
       STATE      6
       SWIP       1
       TIME       1605771736.05
     ss:
       DEG        0
       LIGHT      3
       NAME       ss
       NAMENEXT   ss_civil
       STATE      9
       SWIP       1
       TIME       1605799544.97
     ss_astro:
       DEG        -18
       LIGHT      0
       NAME       ss_astro
       NAMENEXT   sr_astro
       STATE      12
       SWIP       1
       TIME       1605806474
     ss_civil:
       DEG        -6
       LIGHT      2
       NAME       ss_civil
       NAMENEXT   ss_naut
       STATE      10
       SWIP       1
       TIME       1605801963.98
     ss_indoor:
       DEG        3
       LIGHT      4
       NAME       ss_indoor
       NAMENEXT   ss
       STATE      8
       SWIP       1
       TIME       1605798265.96
     ss_naut:
       DEG        -12
       LIGHT      1
       NAME       ss_naut
       NAMENEXT   ss_astro
       STATE      11
       SWIP       1
       TIME       1605804256.99
     ss_weather:
       DEG        9
       LIGHT      5
       NAME       ss_weather
       NAMENEXT   ss_indoor
       STATE      7
       SWIP       1
       TIME       1605795485.95
   helper:
     extWeather:
       Device     Wetter
       regexp     Wetter:cloudCover:.*
       dispatch:
         trigger    cloudCover
Attributes:
   alias      Dämmerung
   event-on-change-reading twilight_weather,elevation,azimuth,condition,light,state,twilight
   verbose    0


Ein odroid 4 Kerne mit 2 GHz, glaube ich.

[Beta-User]

OK, das hilft mir weiter .

Kannst du bitte mal in/zu Zeile 392 (bzw. 393 neu) folgendes testen:

Code Auswählen Erweitern


my $ewr = definded $hash->{helper}{extWeather}{Reading} ? $hash->{helper}{extWeather}{trigger};
$extWeatherVal = ReadingsNum( $name, "cloudCover", ReadingsNum( $hash->{helper}{extWeather}{Device}, $ewr, 0 ) );

[Elektrolurch]

Code Auswählen Erweitern


syntax error at ./FHEM/59_Twilight.pm line 394, near "};"
Global symbol "$ewr" requires explicit package name (did you forget to declare "my $ewr"?) at ./FHEM/59_Twilight.pm line 395.

my $ewr = definded $hash->{helper}{extWeather}{Reading} ? $hash->{helper}{extWeather}{trigger};
$extWeatherVal = ReadingsNum( $name, "cloudCover", ReadingsNum( $hash->{helper}{extWeather}{Device}, $ewr, 0 ) );
#          $extWeatherVal = ReadingsNum( $name, "cloudCover", ReadingsNum( $hash->{helper}{extWeather}{Device}, $hash->{helper}{extWeather}{Reading}, 0 ) );
        readingsSingleUpdate ( $hash, "cloudCover", $extWeatherVal, 0 ) if $extWeatherVal;



[Beta-User]

Mit dem heutigen update sollten die Fehlermeldungen  weg sein, bin aber nicht sicher, ob das an ein paar Stellen ganz optimal ist.

[BroPi]

In #10 stelltest du mal die Frage:

"Welche Funktionsaufrufe aus Twilight werden denn von euch auch in eigenem Code genutzt? "twilight()" habe ich vereinzelt schon gesehen, aber sonst noch Bedarf?"

Ich verwende in einem DOIF folgende Funktionsaufrufe:

Code Auswählen Erweitern

([{twilight("HGW_Twilight_Test","ss_weather","15:00","23:30")}]) (set Rollos_Dummy_Test Runter) DOELSEIF
([{twilight("HGW_Twilight_Test","sr_weather","06:30","09:55")}]) (set Rollos_Dummy_Test Hoch)

Dabei habe ich festgestellt, dass nach einem Funktionsaufruf die Timer für den nächsten Tag im DOIF mit den aktuellen sx_weather gesetzt werden. Twilight müsste aber beim Aufruf von sx_weather den Wert für den nächsten Tag liefern. Im Moment werden aber die Zeiten vom jetzigen Tag genommen.
Ich habe hier mal eine kleine Code-Erweiterung (Proplanta)

Code Auswählen Erweitern

"$fc_day0 = $i < 1 ? $fc_day0 : $fc_day1;"
als Vorschlag eingetragen, die schon ausgetestet ist und zu den richtigen Zeiten schaltet.
Gleichzeitig ist noch eine kleine Anpasung (Schönheitsreperatur) in

Code Auswählen Erweitern

"$ret[$i] = ReadingsNum($extDev,"fc${fc_day1}_cloud00",0)))))));"
eingefügt, die ein Springen der Werte kurz nach Mitternacht verhindert und einen kontinuierlichen Verlauf liefert.

Code Auswählen Erweitern

sub getwTYPE_PROPLANTA {
    my $hash   = shift // return;
   
    my $extDev = $hash->{helper}{extWeather}{Device};
    my @hour  = getTwilightHours($hash);
   
    my $fc_day0 = secondsSinceMidnight( time() ) > 60 ? 0 : 1;
    my $fc_day1 = $fc_day0 + 1;
   
    my @ret;
    for (my $i = 0; $i < 3 ; $i++) {
$fc_day0 = $i < 1 ? $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], fc_day0 $fc_day0,fc_day1 $fc_day1, data $ret[0]-$ret[1]-$ret[2]");
    return @ret;
}

Für mich ist dies jetzt die optimale Lösung.
Damit ist gewährleistet, dass data $ret[0] immer den "aktuellen" und $ret[1]; $ret[2] den "morgigen" cloudCover bekommen. Damit zeigt TwilightWeather den aktuellen Verlauf weiterhin an und sx_weather sind auch korrekt bei Verwendung des DOIFs.
Welchen Einfluß diese Änderung auf andere Readings hat, kann ich nicht beurteilen. Vielleicht müssen auch 2 weitere Parameter sx_weather_tomorrow eingeführt werden?
Ich hoffe nicht zu viel Unruhe in den jetzt doch sehr stabilen Zustand gebracht zu haben

[Beta-User]

OK, also auch in diesem Fall "nur" ein twilight()-Aufruf (die Parameter sind für die Frage nicht relevant, ob man das außerhalb des package-Namespace verfügbar machen will).

Das mit der Glättung werde ich einbauen, falls keine Einwände kommen.

Mit dem "für morgen berechnen" habe ich aber ein paar gedankliche Schwierigkeiten:
- Das verändert auch die trigger-Zeiten am heutigen Tag, wenn ich das richtig interpretiere. Damit wäre es für alle kontraproduktiv, die die trigger-Funktion nutzen.
- Weiter wäre es für die kontraproduktiv, die Twilight mit WDT, RT oder einer anderen Timer-Lösung verwenden, die in "täglich" denken.
(Vermutlich kann man dem DOIF auch eine "täglich"-Denkweise verordnen, indem man ein DOELSIF auf 00:10 Uhr macht und dort einfach nichts tut? Ist aber nur die Vermutung eines bekennenden DOIF-Nichtnutzers...)

Die Alternative wäre, entweder den twilight()-Aufruf zu erweitern, dass man da auch "zeige das für morgen" abfragen kann, aber zum einen ist das mit einiger Sicherheit ein ziemlich komplexes coding (für meine Verhältnisse), und zum anderen müßte man eigentlich sicherstellen, dass die Readings  konsistent zum aktuellen Verhalten sind, es wären dann also zusätzliche erforderlich, und man müßte im aufrufenden Device wissen, ob man jetzt eigentlich heute oder morgen braucht - in der Initialisierung nach einem Neustart oder der Änderung der DEF stellt sich das nämlich ggf. anders dar wie im laufenden Betrieb, oder?

Meine Bitte wäre daher, erst nochmal zu schauen, ob du das DOIF nicht auf anderem Weg dazu bewegen kannst, die richtigen Werte zu verwenden.
Trotzdem muss da wohl noch was in der Doku gemacht werden, denn andere Module, die auch "kontinuierlich" ticken, dürften ähnliche Probleme haben, z.B. AutoShuttersControl.

Falls da jemand Ideen dazu hat: feel free, ich bin nämlich überhaupt nicht sicher, ob ich in den obigen Überlegungen nicht was wesentliches übersehen habe...