at funktioiniert nicht wie erwartet - Bug oder Feature oder falsche Bedienung

[fhem024]

Hallo zusammen,

ich habe einen simplen, relativen, at:

Code Auswählen Erweitern

define Heizung_test at +*00:00:20 \
{\
Log 1, "at started";;\
fhem("set Heizung_test inactive");;\
}
Der soll, nach dem er aktiv (set Heizung_test active) gesetzt wurde, schlicht nach 20 Sekunden anlaufen und wird danach wieder deaktiviert. So zumindest meine Vorstellung und Erwartungshaltung.

Das Verhalten ist jedoch komplett anders. Die Zeit, nach der der at nach activate gestartet wurde, ist rein zufällig und hat mit den definierten 20 s nichts zu tun. War bisher aber immer zwischen 20s und 1s.

Ist das ein Bug oder ein Feature? Zumindest ich verstehe es nicht.

Danke
fhem024

[betateilchen]

Verwende bitte code tags zum Posten von code Zeilen. Danke.

Das beschriebene Verhalten ist völlig normal. Das at wird immer (auch wenn es inaktiv gesetzt ist) alle 20 Sekunden gestartet und prüft dann zuerst, ob es sich aktiv oder inaktiv "verhalten" soll, was den Ausführungsteil betrifft.

Danach wird die nächste Startzeit in 20 Sekunden berechnet und das ganze Spiel beginnt von vorne. Beim setzen von active befindest Du dich also nicht automatisch beim Zeitpunkt 0.

Formuliere doch mal die eigentliche Aufgabe, die Du lösen möchtest, es gibt bestimmt andere Lösungen dafür.

[fhem024]

Hallo betateilchen,
Danke für Deine schnelle Rückmeldung!

Mein use case ist relativ trivial: Es ist das Event x eingetreten (hat ein notify bemerkt). Dann soll exakt 20 s (oder eben nach definierter Zeitspanne y) irgend ein Befehl ausgeführt werden.

[betateilchen]

Dafür brauchst Du doch kein at, zumindest, wenn es um eine FHEM Befehl geht, der ausgeführt werden soll:

Code Auswählen Erweitern

define n_myNotify notify <regex> sleep 20; set lampe on (evtl. braucht es zwei ; nach dem sleep, das kann ich gerade nicht testen)

Alternativ kannst Du auch im notify ein Einmal-at definieren:

Code Auswählen Erweitern

define n_myNotify2 notify <regex> defmod at_once at +00:00:20 set lampe on
Der Vorteil der zweiten Variante: man kann sie problemlos auch mit perl im Ausführungsteil verwenden.

[fhem024]

Hallo betateilchen,

die Variante 2 hatte ich bisher immer genutzt (und nutze sie jetzt auch wieder). Die hatte auch problemlos funktioniert. Ich fand die Variante, einen statischen, relativen at zu haben, der von verschiedenen notify (seriell!) genutzt werden kann, ganz schick. Quasi wie eine Funktion.

Das relative at-Verhalten ist jedenfalls aus meiner Sicht so nicht erwartbar. Nach Deiner Erläuterung, wie das ganze umgesetzt ist, jedoch nachvollziehbar. Ich frage mich, ob man das nicht auch anders umsetzen könnte, so dass das aus meiner Sicht erwartbare Verhalten auch eintritt. Zumindest leuchtet mir nicht ein, warum ein deaktivierter, regelmäßiger at trotzdem starr alle definierte n Zeit angefahren wird. Es funktioniert doch auch, wenn ich ihn neu anlege mit defmod. Für mein Verständnis ist das (re-)aktivieren ähnlich einem defmod - was das Zeithandling angeht. Der nächste Start wird auf akt time + rel time gesetzt. Wie beim defmod auch.

Danke
Gruß
fhem024

[betateilchen]

Die Diskussion über die Bedeutung von set ... inactive bzw. attr ... disable hatten wir hier neulich schonmal.

Das derzeitige Verhalten ist m.E. völlig logisch, wenn man verstanden hat, dass sich das inactive nur darauf bezieht, ob der Ausführungsteil eines at (oder eines anderen devices, das Verhalten bezüglich periodischer Ausführung ist in FHEM in vielen Modulen identisch implementiert) bezieht.

Der Ablauf eines periodischen at ist IMMER - auch wenn inactive oder disabled gesetzt ist - dieser:

• das at wird zur berechneten Zeit aufgeweckt
• es prüft zuerst, ob es aktiv gesetzt ist
  
• ist es aktiv gesetzt, wird der Ausführungsteil ausgeführt
• die nächste Ausführungszeit wird berechnet und das at dafür neu eingeplant
• das at geht wieder schlafen

Das Setzen von inactive oder disable wirkt sich also ausschließlich auf den Punkt 3 aus, sonst auf nicht. Und das ist auch gut so.

[betateilchen]

Bei einem defmod wird das at und sein interner Timer gelöscht und beides neu angelegt.

Das ist ein komplett anderes Verhalten als beim Setzen von active/inactive.

[fhem024]

Hallo betateilchen,

es ist nicht so, dass ich Deine Beschreibung nicht verstehen würde. Das ist kein Thema. Aus meiner Sicht macht dieses aus der Implementierung resultierende Verhalten einfach keinen Sinn und ist auch nicht dokumentiert stand bisher (zumindest konnte ich es nirgendwo rauslesen). Ein aus meiner Sicht unintuitives Verhalten sollte dann auch mit rotem fettem Ausrufezeichen exakt so dokumentiert sein.

Danke
Gruß
fhem024

[fhem024]

Bei einem defmod wird das at und sein interner Timer gelöscht und beides neu angelegt.

Das ist ein komplett anderes Verhalten als beim Setzen von active/inactive.

Mir fällt einfach kein praktischer use case ein, wo das daraus resultierende Verhalten Sinn ergeben könnte. Derjenige, der den at wieder aktiviert kann doch gar nicht wissen, wann er wieder losläuft. Das ist doch dann reiner Zufall.

Danke
Gruß
fhem024

[frank]

moin.

Die Diskussion über die Bedeutung von set ... inactive bzw. attr ... disable hatten wir hier neulich schonmal.

https://forum.fhem.de/index.php?topic=139578.0

Das Setzen von inactive oder disable wirkt sich also ausschließlich auf den Punkt 3 aus, sonst auf nicht. Und das ist auch gut so.

meine aktuelle zählung: 1x "gut so" und 3x "nicht so gut".

Aus meiner Sicht macht dieses aus der Implementierung resultierende Verhalten einfach keinen Sinn und ist auch nicht dokumentiert stand bisher (zumindest konnte ich es nirgendwo rauslesen).

beachte aber: die "offizielle" doku ist immer die commandRef auf englisch.


gruss frank

[betateilchen]

Mir fällt einfach kein praktischer use case ein, wo das daraus resultierende Verhalten Sinn ergeben könnte. Derjenige, der den at wieder aktiviert kann doch gar nicht wissen, wann er wieder losläuft. Das ist doch dann reiner Zufall.

Nein, das muss kein Zufall sein.
Nehmen wir an, ich habe ein at, das eigentlich immer um xx:05 und xx:25 und xx:45 ausgeführt werden soll.

Code Auswählen Erweitern

define at1 at +*00:20:00 {meinCode}
attr at1 alignTime 00:05

Aber - aus welchen Gründen auch immer -  möchte ich nun, dass die Ausführung zwischen 11:00 Uhr und 12:30 Uhr nicht erfolgen soll. Also setze ich das at mittels einer der mehreren zur Verfügung stehenden Möglichkeiten auf inaktiv.

Dann wird um 11:05, 11:25, 11:45, 12:05 und 12:25 Uhr das at zwar aufgeweckt, aber der Ausführungsteil wird nicht abgearbeitet.

Ab 12:45 Uhr findet dann wieder die Ausführung im gewünschten Takt statt - exakt zu der ursprünglich vorgesehenen und gewünschten Zeit, ganz ohne Zufallskomponente.


Für mich ist das aktuelle Verhalten eines at in diesem Fall völlig logisch und nachvollziehbar und genau das Verhalten, das ich auch erwarte.

[fhem024]

@betateilchen
Ja, das ist tatsächlich ein use case, den Du hier beschreibst. Wie Frank sehe ich das aber auch mit dem attr alignTime geregelt. Ohne alignTime erwarte ich, das von mir beschriebene Verhalten.
Ein relativer timer hat für mich immer die Aufgabe, nach einem Startzeitpunkt (egal, ob Anlage oder aktiv-Setzung), exakt nach der definierten Zeit etwas zu tun. Mit alignTime setze ich den ersten Zeitpunkt ab Anlage oder Reaktivierung (wenn der Timer immer zu bestimmten Zeiten wiederholt etwas machen soll).
Es handelt sich also um die zwei grundsätzlichen Funktionalitäten: entweder ein statischer relativer Timer (der Startzeitpunkt wird entweder durch die Anlage des Timers bestimmt oder durch alignTime und ändert sich nie mehr wieder - so habe ich das jetzt zumindest verstanden) oder ein Timer, der sobald er angelegt oder reaktiviert wird, ab genau n Sekunden, Minuten ... nach diesem Zeitpunkt losläuft.

@Frank
Auch in der englischen Commandref ist das Verhalten für mich absolut nicht (klar) erkennbar. Ganz abgesehen davon: mehrere konkurrierende Dokus zu haben und dann im Zweifel zu sagen, Doku x wäre nix Wert (im Sinne von: die ist keine Referenz), ist zumindest fragwürdig. Dann bitte alle nicht relevanten Dokus entfernen. Den Aufwand kann man sich dann sparen.

Danke
Gruß
fhem024

[Damian]

Das Verhalten des at-Moduls war immer schon so, ob man es gut findet oder nicht, eine Änderung ist nicht gewünscht und vermutlich auch nicht gewollt, denn es würde das Verhalten bestehender Definitionen verändern.

Wer es bezüglich disable bzw. inaktiv so haben will, wie hier erwartet, der benutzt ein anderes Modul.