Hallo
ich hatte mir einige AT auf Basis ReadingVal definiert, die leider nach einmaliger Ausführung verschwunden sind.
Nach mehreren Versuchen habe ich vorher ein Beispiel list gesichert.
Internals:
CFGFN
COMMAND {
fhem("set HM_R_KU pct 0");
fhem("set HM_R_WZ pct 0");
}
DEF *{ReadingsVal("astro","CustomTwilightEvening",0)} {
fhem("set HM_R_KU pct 0");
fhem("set HM_R_WZ pct 0");
}
FUUID 603d2183-f33f-d1f3-3de8-00ad35245a935bfe
NAME at_CustomTwilightEvening
NR 4442
NTM 17:46:00
PERIODIC yes
RELATIVE no
REP -1
STATE Next: 17:46:00
TIMESPEC {ReadingsVal("astro","CustomTwilightEvening",0)}
TRIGGERTIME 1614703560
TRIGGERTIME_FMT 2021-03-02 17:46:00
TYPE at
READINGS:
2021-03-01 19:00:16 state Next: 17:46:00
Attributes:
room Küche_WZ,Testraum
Wo ist der Fehler? Geht das grundsätzlich? Bin für jegliche Hinweise dankbar.
Gruß Ralf
Hallo ralfix
Bin zwar kein experte auf at und perl. Mache das lieber mit einen DOIF aber ich hab mal ein bisschen rumprobiert und so funktioniert es bei mir.
*{ReadingsVal("astro","CustomTwilightEvening","")} set HM_R_KU pct 0;set HM_R_WZ pct 0
Viele Grüsse
Stephan
Oder so:
*{ReadingsVal("astro","CustomTwilightEvening","")} set HM_R_KU,HM_R_WZ pct 0
Danke vielmals . Ich probiere es nochmal.
Gruß Ralf
Hast du das hinbekommen ?
Meine Definition :
define Weihnachtslicht1_an at *{ReadingsVal("SonneMond","SunSet","")} set Weihnachtslicht1 on
am naechsten Tag sind sie weg.
Gibt es was neues ?
Beide der oben angegebenen Versionen fuehren zum Misserfolg ( aber erst nach ein paar Tagen !! )
Eine periodische at Definition (die mit *, ohne Anzahl) sollte nur durch explizites Loeschen verschwinden, ich habe im Code gerade auch keinen Hinweis fuer was Anderes gefunden.
Allerdings bleibt das at "stehen", wenn bei dem wiederholten Aufruf des perl Ausdrucks irgendetwas zurueckliefert, was nicht als Timespec zu interpretieren ist. Die Fehlermeldung sollte im Log zu finden sein, ich habe das jetzt aber auch im STATE verewigt.
Aber nur Mal für mich zum Verständnis...
Geschaltet werden soll zum Zeitpunkt des Sonnenunterganges?
Müsste nicht eigentlich das Astro-Modul einen Event (vermutlich state) liefern,der die verschiedenen Phasen des Tages liefert?
Dann bräuchte man doch nur auf das entsprechende Event reagieren,also notify?
Bei ReadingsVal sollte möglichst noch ein guter Defaultwert gesetzt werden, falls es mit dem Reading ein Problem gibt.
Und zusätzlich bei dem at das Attribut computeAfterInit auf 1 setzen.
Mir wurden auch schon ats nach einem Neustart von fhem gelöscht, weil das liefernde Device noch nicht initialisiert war und damit das Auslesen nichts sinnvolles liefern konnte.
Meine Beobachtungen sagen etwas anderes :
- Wenn man bei der Definition des at-Kommandos * und ReadingsVal verwendet, ist das at spaeter weg.
- wenn ich bei der Definition statt des ReadingsVal etwa asunset() verwende,
*{asunset()} set Garten1 on
fuehrt das zwar zu einem erfolgreichen at-Kommando, das auch regelmaessig wiederholt wird, aber leider immer zu dem Zeitpunkt des Tages der Definition,
sprich , der Zeitpunkt aendert sich nicht mit dem Stand der Sonne.
Ich habe mich da wohl von der at-Referenz verleiten lassen ....
Werde also ueber ein notify gehen muessen.
Zitat- Wenn man bei der Definition des at-Kommandos * und ReadingsVal verwendet, ist das at spaeter weg.
Das kann nur passieren, wenn das ReadingsVal bei einem FHEM-Neustart oder rereadcfg einen Wert liefert, was nicht als Uhrzeit interpretiert werden kann. Die Meldung sollte im FHEM-Log zu finden sein ("Wrong timespec...." oder "the function ... must return a timespec and not ...").
Zitat- wenn ich bei der Definition statt des ReadingsVal etwa asunset() verwende, [...] fuehrt das zwar zu einem erfolgreichen at-Kommando, das auch regelmaessig wiederholt wird, aber leider immer zu dem Zeitpunkt des Tages der Definition,
Das kommt mir zumindest merkwuerdig vor.
Ich kenne asunset nicht, mein at mit sunset (ohne a) funktioniert seit 10+ Jahren so wie ich das erwarte, ich kann jeden Tag die leicht veraenderte Uhrzeit des Schaltens beobachten, selbst die Zeitumstellung wird beruecksichtigt.
Um das hier beschriebene Problem einzugrenzen wuerde ich die TRIGGERTIME_FMT Internals ein paar Tage lang beobachten, oder "attr myAt verbose 5" setzen und das Log pruefen.
Zitat von: rudolfkoenig am 22 November 2021, 09:45:03
Ich kenne asunset nicht,
Das kommt aus Astro und sollte eigentlich 1:1 genauso funktionieren.
Vermutlich ist hier nach wie vor "computeAfterInit" nicht gesetzt.
@Rudi:
Bei der Gelegenheit würde ich mal Werbung machen wollen für noansi's Anregung, sowas wie eine "InitFn()" zu ermöglichen. Damit könnte "at" ohne das Attribut auskommen, und man müßte Usern nicht ständig den startup-Prozess näher erläutern.
Schön wäre, wenn man das ergänzen könnte um ein "InitFn-Order"-Internal, mit dem man z.B. "at" ganz nach hinten schubsen könnte...
Danke, ich probier das mal mit "computeAfterInit", obwohl es mir nicht so richtig einleuchten will, die Berechnung funktioniert ja.
Im Anhang sieht man nochmal mein Problem, at-Zeiten, danach die korrekten Werte.
Und das sind nicht die Unterschiede von gestern zu heute, das wuerde ich ja vielleicht noch verstehen.
Kurz nach Mitternacht sind die korrekten Werte eingetroffen; selbst wenn das 'at' erst bei der naechsten Ausfuehrung modifiziert wuerde, waeren die Daten doch hoechstens um 1 Tag verkehrt
ZitatBei der Gelegenheit würde ich mal Werbung machen wollen für noansi's Anregung, sowas wie eine "InitFn()" zu ermöglichen. Damit könnte "at" ohne das Attribut auskommen, und man müßte Usern nicht ständig den startup-Prozess näher erläutern.
Ich will das Attribut behalten, weil ich nicht sicher bin, dass bei einer Umstellung keine Nebeneffekte auftreten.
at ist das erste FHEM-Modul mit entsprechend grosser Verbreitung.
InitFn() ist gleichwertig mit InternalTimer(0,...) im DefFn, und wuerde die API nur komplizierter machen, ohne was Neues zu bieten.
Beide haben das Problem, dass die Reihenfolge der Funktionsaufrufe nicht immer optimal ist.
ZitatDanke, ich probier das mal mit "computeAfterInit", obwohl es mir nicht so richtig einleuchten will, die Berechnung funktioniert ja.
Beim FHEM-Start werden erst alle Definitionen (gefolgt von den jeweiligen Attributen) abgearbeitet, und dann die alten Reading- und STATE Werte eingelesen.
at berechnet beim define(!) die naechste Ausfuehrungszeit. Wenn die Zeit dynamisch berechnet wird und diese Berechnung einen nicht als Zeit interpretierbaren Wert zurueckliefert (wie im o.g. Beispiel, ReadingsVal default ""), dann wird at beim rereadcfg / FHEM Neustart nicht angelegt, und beim naechsten save aus fhem.cfg entfernt. Eine Fehlermeldung wird zwar an mehreren Stellen angezeigt, aber das wird gerne uebersehen.
Wenn man fuer die Zeitberechnung im at eine perl Funktion verwendet, muss man sicherstellen, dass:
- die Funktion vor dem at-define zur Verfuegung steht, indem sie aus fhem.pl, aus 99-er Modulen oder aus einem Modul stammt, was vor dem at-definition in fhem.cfg aufgefuehrt ist.
- die Funktion in jedem Fall eine als Zeit interpretierbaren Wert zurueckliefert.
- die Funktion bei Aufruf (aus dem at define oder direkt nach der Initialisierung bei gesetzten computeAfterInit Attribut) den richtigen Wert liefert. Das ist nicht immer selbstverstaendlich, siehe unten.
Konkret fuer diesen Fall
- die ReadingsVal Version mit Astro ist problematisch: Astro aktualisiert die Werte fuer at zu spaet (InternalTimer(gettimeofday()+5, ...)). Mit computeAfterInit koennte die Zeit, genommen aus dem eingelesenen Readingswert trotzdem richtig sein, wenn das FHEM-downtime nicht zu lang war. Auf einem sinnvollen ReadingsVal-default muss man trotzdem achten.
- die asunset() Version muss sicherstellen, dass Astro in fhem.cfg vor dem at definiert ist.
Zitat von: rudolfkoenig am 22 November 2021, 11:51:08
InitFn() ist gleichwertig mit InternalTimer(0,...) im DefFn, und wuerde die API nur komplizierter machen, ohne was Neues zu bieten.
Beide haben das Problem, dass die Reihenfolge der Funktionsaufrufe nicht immer optimal ist.
Genau das stimmt nicht, jedenfalls nicht ganz. Das Problem mit InternalTimer ist, dass die aufgerufene Funktion erst nach dem global:INITIALIZED ausgeführt wird, und man mehr oder weniger keinen Einfluss auf die Reihenfolge der Abarbeitung hat (weniger wie "0" geht halt nicht).
Deswegen war der Vorschlag, das "InitFn()-Modell" um einen Präfix zu ergänzen, mit dem man z.B. sicherstellen kann, dass CUL_HM-InitFn() nach HMLAN-InitFn() ausgeführt wird. Das klappt jetzt zwar in diesen Fällen, weil NotifyFn() mit entsprechendem Präfix genutzt wird, es ist aber völlig unnötig, dass alle zweistufigen Modelle zum einen mit NotifyFn() arbeiten und zum anderen die Präfixes setzen, nur um zu verhindern, dass versehentlich "echter User-Code" vor der vollständigen Initialisierung ausgeführt wird. Auch das "REREADCFG"-Problem wäre dann nicht aufgetreten.
Wenn ich nicht den Eindruck hätte, dass zap genau dasselbe Problem grade versucht, bei HMCCU.* zu lösen, hätte ich den Punkt nicht aufgegriffen, btw. ;) .
Zitatweniger wie "0" geht halt nicht
Und das steht wo genau ? :)
Ich kann InitFn() einbauen, aber nur, damit ich nicht immer wieder erklaeren muss, dass es nicht hilft.
Wenn Astro gettimeofday()+5 fuer die Initialisierung verwendet, dann wird das mit InitFn nicht besser. Um die richtige Reihenfolge zu berechnen, muessten alle Instanzen (und nicht nur die Module) angeben, von welchen Anderen sie abhaengen. Das ist Konfigurations und damit Benutzer abhaengig, und kann nicht ernsthaft von einem Benutzer verlangt werden. Mit etwas "Glueck" darf man auch eine zyklische Abhaengigkeit aufloesen.
Habe dazu jetzt mal was in https://forum.fhem.de/index.php/topic,120603.msg1151891.html#msg1151891 geschrieben. Kann schon sein, dass ich was wichtiges übersehe...
Danke.
Zitat
Beim FHEM-Start werden erst alle Definitionen (gefolgt von den jeweiligen Attributen) abgearbeitet, und dann die alten Reading- und STATE Werte eingelesen.
at berechnet beim define(!) die naechste Ausfuehrungszeit. Wenn die Zeit dynamisch berechnet wird und diese Berechnung einen nicht als Zeit interpretierbaren Wert zurueckliefert (wie im o.g. Beispiel, ReadingsVal default ""), dann wird at beim rereadcfg / FHEM Neustart nicht angelegt, und beim naechsten save aus fhem.cfg entfernt. Eine Fehlermeldung wird zwar an mehreren Stellen angezeigt, aber das wird gerne uebersehen.
Ich glaube, das verstehe ich : Wenn ich also ReadingsVal ohne Default verwende, und auch sonst nichts weiter angebe, verschwindet das at-Kommando moeglicherweise bei einem Neustart.
Ok, passiert mir nicht wieder.
Zitat
Konkret fuer diesen Fall
- die ReadingsVal Version mit Astro ist problematisch: Astro aktualisiert die Werte fuer at zu spaet (InternalTimer(gettimeofday()+5, ...)). Mit computeAfterInit koennte die Zeit, genommen aus dem eingelesenen Readingswert trotzdem richtig sein, wenn das FHEM-downtime nicht zu lang war.
Das verstehe ich wohl auch; die Werte sind dann aber maximal um einen Tag verschoben, es sei denn, 'at' sollte waehrend der Downtime ausgefuehrt werden.
Zitat
- die asunset() Version muss sicherstellen, dass Astro in fhem.cfg vor dem at definiert ist.
Dafuer kann ich sorgen.