Probleme bei Änderung eines "at" mit einer Perlfunktion als Timespec

[psycho160]

Verwende FHEM mit ConfigDB.

Habe jetzt mal ein "at" mit einer Perlfunktion (Sonnenuntergang aus Twilight Modul) konfiguriert.  Geht soweit alles gut, wenn ich aber FHEM neu starte kommt folgendes:

Code Auswählen Erweitern

Messages collected while initializing FHEM:configDB: the function "twilight("Tageslicht","ss_civil","16:30","17:30")" must return a timespec and not Undefined subroutine &main::twilight called at (eval 80) line 1.

Ich glaube da wird von der ConfigDB schon was geladen bevor alle Funktionen initialisiert sind... Kann das jemand bestätigen bzw. was kann ich dagegen tun?

lg

[psycho160]

Ich habe es jetzt nochmal neu defined und dann ginge es. Auch Neustart geht nun..

Code Auswählen Erweitern

*{{twilight("Tageslicht","ss_civil","16:30","17:30")}} {
if (($month == 11 && $mday > 10) || $month == 12 || ($month == 1 && $mday < 7)){
        fhem("set xmasLight_random_effect on");
        Log 3, "at_xmasLight_evening: LED_Weichnachtsbeleuchtung einschalten.";
        }
}

[Beta-User]

...das war m.E. ein reines Reihenfolge-Problem (du hattest ein vorhandenes at geändert oder die Twilight-Instanz erst danach...?), und die doppelte geschweifte Klammer ist unnötig....

@Rudi: ich erinnere an unsere Diskussion zum Startablauf neulich...

[psycho160]

...das war m.E. ein reines Reihenfolge-Problem (du hattest ein vorhandenes at geändert oder die Twilight-Instanz erst danach...?), und die doppelte geschweifte Klammer ist unnötig....

@Rudi: ich erinnere an unsere Diskussion zum Startablauf neulich...

Ja, genauso war es. das "at" selbst hatte ich schon ca. 1 Jahr. Vor paar Tagen kam dann die geänderte Timespec als Perl-Funktion dazu.

PS: Die doppelten Klammern hat er mir dann beim erneuten anlegen selbst gemacht, dachte zuerst schon das hier das Problem wäre.

[rudolfkoenig]

@Rudi: ich erinnere an unsere Diskussion zum Startablauf neulich...

Und was genau sollte ich machen?

[Beta-User]

...du "wolltest" nichts machen, sondern hattest dann hier https://forum.fhem.de/index.php/topic,120603.msg1188618.html#msg1188618 nachgefragt, wer sowas verwenden würde...

MAn. wäre es immer noch sinnvoll, dass der Maintainer von "at" dazu die Hand heben würde ...

[betateilchen]

Das hat aber alles nichts mit configDB zu tun, das Problem wäre mit fhem.cfg in identischer Weise aufgetreten.

Solche Threadtitel

Fehler bei ConfigDB und ein "at" mit einer Perlfunktion als Timespec

finde ich einfach kontraproduktiv und unschön.

[rudolfkoenig]

MAn. wäre es immer noch sinnvoll, dass der Maintainer von "at" dazu die Hand heben würde ...

Das wuerde aber nur Dich ruhigstellen , nicht aber das hier beschriebene Problem loesen.

Ich weiss nicht, ab wann twilight diese Daten zur Verfuegung stellt, in dem anderen Fall hat Astro 5 Sekunden nach dem FHEM-Startup mit der Berechnung angefangen. Soll at dann 10 Sekunden warten und hoffen, dass Astro bei 5 Sekunden bleibt? Nur nach FHEM-Startup oder immer?

Um das Problem richtig zu loesen braucht man einen Abhaengigkeitsgraph, weiss aber nicht, wer die notwedigen Daten dafuer liefern soll.
In diesem Fall praeferiere ich das Verwenden von Readings zusammen mit dem computeAfterInit Attribut.

[psycho160]

Das hat aber alles nichts mit configDB zu tun, das Problem wäre mit fhem.cfg in identischer Weise aufgetreten.

Solche Threadtitel  finde ich einfach kontraproduktiv und unschön.

Sorry für den Titel, war mir beim Erstellen noch nicht bewusst, dass die Ursache nicht confdb ist. Mit fhem.cfg wäre die Problemlösung aber einfacher - da hätte ich die betroffene Passage einfach weiter nach unten verschoben...

[Beta-User]

Twilight gäbe direkt nach dem Einlesen der statefile eine (zumindest für die gespeicherten Readingwerte) korrekte Antwort, und hier war das "Problem", dass die Funktion noch gar nicht geladen war. Wie "Astro" das macht, weiß ich nicht, gehe aber davon aus, dass auch das nicht blockieren wird, wenn man dessen "offizielle" Funktionen aufruft, sondern halt "genauso falsche" Werte zurückliefert, wenn es noch nicht durch ist mit seinen Berechnungen.

Was den Abhängigkeitsgraph angeht, wäre das zwar wünschenswert, ich hege aber gewisse Zweifel, dass das auf absehbare Zeit irgendwas wird...

Bin immer noch der Meinung, dass an der Stelle "sauberer" halt besser ist wie gar nicht, und sich der Rest schon irgendwann findet, wenn man erst mal eine Basis hat.

Sorry für den Titel, war mir beim Erstellen noch nicht bewusst, dass die Ursache nicht confdb ist. Mit fhem.cfg wäre die Problemlösung aber einfacher - da hätte ich die betroffene Passage einfach weiter nach unten verschoben...

...dann korrigiere bitte den Thread-Titel, und das mit dem Verschieben ist "Murks", das kann man auch mit "delete" und "define" ohne cfg-Geeditiere haben...

[betateilchen]

das kann man auch mit "delete" und "define" ohne cfg-Geeditiere haben...

Wenn man solcher Art Abhängigkeiten in seiner FHEM Installation hat, kann man das sehr elegant in der 99_myUtils.pm lösen, indem man dort ein

Code Auswählen Erweitern

fhem("reload 59_Twilight.pm");

einfügt. Das sorgt dafür, dass das Modul bereits geladen wird, bevor irgendein device angelegt wird, das möglicherweise auf darin enthaltene Funktionen zugreift.

[Beta-User]

ja. Wenn man davon absieht, dass "Tageslicht" damit auch noch nicht definiert ist, ist das eine super-selbsterklärende Lösung für ein Reihenfolgeproblem, das es nicht geben müßte...

[betateilchen]

Das Reihenfolgen-Problem ist so alt wie FHEM selbst.
Es gibt funktionierende Workarounds.

[psycho160]

...dann korrigiere bitte den Thread-Titel, und das mit dem Verschieben ist "Murks", das kann man auch mit "delete" und "define" ohne cfg-Geeditiere haben...

done. lg