Twilight Verständnisprobleme

Begonnen von DerFrickler, 06 Januar 2017, 15:41:30

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: MadMax-FHEM am 18 Januar 2022, 08:03:00
Ist aber nur Symtombekämpfung?
Ja, und die "drittbeste" Variante, um das Problem zu lösen...

@p-body:
Vorab mal: Willkommen im FHEM-Forum :) .

a) Twilight ist seit ca. 2020 nicht mehr direkt vergleichbar mit Twilight 2017, jedenfalls, was die Frage angeht, wie es (meistens) rund um die .*_weather-Readings tickt (hier nicht unmittelbar das Thema).

b) Dein Problem mit dem "at" und dem Perl-Code, der auf Readings zugreift ist ein bekanntes - "at" kennt daher ein Attribut "computeAfterInit".

c) Warum das mit dem notify auf "Twilight.*" nicht klappt, ist auch einfach: Du hast es nicht mit dem Event-Monitor angelegt und händisch auf ein Device verwiesen, das es nicht gibt. Geben würde es anscheinend "VD_Twilight".

Die Varianten b) und c) sind mAn. besser als das INITIALIZED-notify, weil man für b) kein zusätzliches Device braucht, und c) von Vorteil wäre, wenn auf die variableren ".*_weather"-Readings reagiert werden soll - diese Zeiten können sich nämlich im Lauf des Tages ggf. mehrfach ändern, je nachdem, wie das Wetter draußen (gemeldet) wird...
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

p-body

#16
Vielen Dank für die schnellen Antworten!

Ich habe gleich mal die Varianten b + c getestet - und es funktionieren beide.

Zu c) wie von Beta-User vermutet habe ich das falsche Device genutzt.

(klarer Copy & Paste Fehler  >:( )   

Bei c) wird allerdings bei mir immer ein Config-Change gemeldet - das konnte man doch auch noch irgendwie unterdrücken?!?

Twilight ist wie von Beta-User vermutet als "VD_Twilight" definiert:
define VD_Twilight Twilight 49.063447 8.194783 1 AgroWeather

damit sollte dann in meinem Beispiel das Notify z.B. so angelegt werden:
define n_TwilightMessageSZ notify VD_Twilight.*:ss_astro:.*   {fhem('modify abends_SZ_Rollos *{twilight("VD_Twilight","ss_indoor","16:00","22:00")} set SZ_Rollo pct 40')}
 
(nur falls andere Anfänger wie ich auch danach suchen)

Für meinen Anwendungsfall langt vermutlich schon Lösung b), da ich hauptsächlich bei Dämmerung die Rollos herunterfahren möchte.

also ein
attr abends_SZ_Rollos computeAfterInit 1
führt wie beschrieben zu einer Aktualisierung der Zeit zum Herunterfahren des Rollos nach einem Neustart von fhem.

Kann man eigentlich auch "einfach" eine Neuberechung der ATs anstoßen, ohne ein modify mit der kompletten Definition auszulösen? (vermutlich nicht, sonst hättet ihr es wohl erwähnt?!?)



Beta-User

Zitat von: p-body am 18 Januar 2022, 19:34:02
Bei c) wird allerdings bei mir immer ein Config-Change gemeldet - das konnte man doch auch noch irgendwie unterdrücken?!?
...das war eigentlich etwas anders gemeint: Twilight wirft nicht nur Events, wenn die Readings aktualisiert werden, sondern auch jeweils zum "Eintrittszeitpunkt" eines neuen "state" (ss_astro dürfte "12" entsprechen) - damit kann man die Rollläden auch ohne "at" schalten, nur mit notify (bzw. für morgens: watchdog oder verzögert per sleep + Prüfung, da die "Leiter" uU. nur bei einem Neustart komplett durchlaufen wird, und das morgendliche Hochfahren unversehens sonst auch abends stattfinden könnte...)

Für "unveränderliche" Werte wie ss_astro würde ich immer die Timer-Lösung mit b) bevorzugen.
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