Twilight - Maintainership (orphan 2020)

Begonnen von Beta-User, 05 September 2020, 10:06:33

Vorheriges Thema - Nächstes Thema

Beta-User

Danke für die Rückmeldung!

Sieht m.E. ok aus, das log.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

#286
Moin,

hier ist ja lange nix mehr passiert, aber laut "help" ist hier immer noch die richtige Stelle zum Fragen.

Könnte man bei Gelegenheit in der commandref einen Hinweis ergänzen, dass die Funktion twilight() erst ab $init_done zur Verfügung steht sinnvoll genutzt werden kann?

Oder hat es schon jemand irgendwie geschafft, ein at, das mit *{twilight(...)} aufgebaut ist, so zu persistieren, dass es auch nach einem FHEM restart wieder eine sinnvolle Uhrzeit für die Ausführung zeigt?

Die Ursache des Problems ist relativ einfach beschrieben:

  • Bei einem FHEM Start werden zuerst alle define und attr ausgeführt, bevor das stateFile gelesen wird und die readings gesetzt werden.
  • Zum Zeitpunkt des define eines at, das sich auf twilight() verlässt, steht die darin angegebene Kombination aus twilight-device und -reading noch nicht zur Verfügung.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Zitat von: betateilchen am 18 Februar 2025, 19:37:18Oder hat es schon jemand irgendwie geschafft, ein at, das mit *{twilight(...)} aufgebaut ist, so zu persistieren, dass es auch nach einem FHEM restart wieder eine sinnvolle Uhrzeit für die Ausführung zeigt?
Habe in der commandref den Hinweis auf "computeAfterInit" (=> at, dort ein generelles Thema) eingefügt.

Ist das eine befreidigende Lösung für dieses Problem?

Mir ist klar, dass es hier und u.A. vielleicht auch im WeekdayTimer das weitere Problem gibt, dass sich zwischenzeitlich zwischen shutdown und restart die Rahmenbedingungen geändert haben könnten und daher nach dem timer-basierten Abruf der Wetterdaten (bei Twilight) wieder ein anderes Ergebnis geliefert wird - das ist aber nicht grundlegend anders, wenn sich der Wetterbericht zwischendurch aktualisiert.

Dann kann/muss man ggf. die Events verwenden statt at&Co..
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

Zitat von: Beta-User am 19 Februar 2025, 17:57:59Habe in der commandref den Hinweis auf "computeAfterInit" (=> at, dort ein generelles Thema) eingefügt.

Ist das eine befreidigende Lösung für dieses Problem?

Ja, alles gut. Danke für den Schubs, an das Attribut im at selbst hatte ich überhaupt nicht gedacht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!