AT verschwunden trotz "*"

[ralfix]

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.

Code Auswählen Erweitern

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

[Stelaku]

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.

Code Auswählen Erweitern


*{ReadingsVal("astro","CustomTwilightEvening","")} set HM_R_KU pct 0;set HM_R_WZ pct 0


Viele Grüsse

Stephan

[rudolfkoenig]

Oder so:

Code Auswählen Erweitern

*{ReadingsVal("astro","CustomTwilightEvening","")} set HM_R_KU,HM_R_WZ pct 0


[ralfix]

Danke vielmals . Ich probiere es nochmal.
Gruß Ralf

[Wolfgang Hochweller]

Hast du das hinbekommen ?

Meine Definition :

Code Auswählen Erweitern


define Weihnachtslicht1_an at *{ReadingsVal("SonneMond","SunSet","")} set  Weihnachtslicht1 on


am naechsten Tag sind sie weg.

[Wolfgang Hochweller]

Gibt es was neues ?
Beide der oben angegebenen Versionen fuehren zum Misserfolg ( aber erst nach ein paar Tagen !! )

[rudolfkoenig]

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.

[bartman121]

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?

[jhohmann]

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.

[Wolfgang Hochweller]

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,

Code Auswählen Erweitern


*{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.

[rudolfkoenig]

- 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 ...").

- 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.

[Beta-User]

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...

[Wolfgang Hochweller]

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

[rudolfkoenig]

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.

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.

Danke, 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.

[Beta-User]

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. .