[at] trotz "attr disable 1" werden wiederholende at ständig neu gestartet.

[frank]

hallo rudi,

bug oder feature?

ich habe einige wiederholende at, die disabled sind, da ich sie nur selten zum testen benötige. nun habe ich heute zufällig festgestellt, dass die timer trotzdem alle regelmässig wie definiert gestartet werden.

disabled ist nur der ausführungsteil.
"set inactive" macht das selbe.

erwartet hatte ich eigentlich "vollständiges" nichts tun.

[betateilchen]

Nein, das Verhalten ist völlig normal so - und so gewollt. Es kann ja sein, dass Du zwischenzeitlich das disabled wieder gelöscht hast, dann wird das at beim nächsten errechneten Zeitpunkt wieder wie gewünscht ausgeführt. Das Verhalten ist sehr hilfreich beim automatisierten Ein- und Ausschalten der Reaktion von devices, und nicht nur at verhält sich so, sondern eigentlich alle devices, die das Attribut unterstützen.

Deine Erwartungshaltung ist "falsch".

[frank]

Deine Erwartungshaltung ist "falsch".

meine erwartungshaltung resultiert ja aus der vielzahl an möglichkeiten und deren beschreibung in der commandref.
teilweise wird dort explizit auf "cmd execution" hingewiesen.
bei disable/inactive hingegen ist die rede von device: "Disables the corresponding device".

Das Verhalten ist sehr hilfreich beim automatisierten Ein- und Ausschalten der Reaktion von devices

da ich immer vom neustart des timers beim enable ausgegangen bin, habe ich für diese fälle immer zusätzlich das attribut alignTime benutzt.

da disable/inactive nahezu gleich funktionieren wünsche ich mir, dass beim attribut disable auch der timer "ab-/angeschaltet" wird.
besonders beim fhem start erscheint es mir kontraproduktiv den timer zu starten, wenn das attribut disable gesetzt ist.

[betateilchen]

da ich immer vom neustart des timers beim enable ausgegangen bin, habe ich für diese fälle immer zusätzlich das attribut alignTime benutzt.

Das Eine hat mit dem Anderen aber überhaupt nichts zu tun.

da disable/inactive nahezu gleich funktionieren wünsche ich mir, dass beim attribut disable auch der timer "ab-/angeschaltet" wird.

Auch bei set ... incative wird der Timer nicht abgeschaltet.

Und das "nahezu gleich funktionieren" ist ein Trugschluss - das eine ist ein set Befehl, das Andere ist ein Attribut.

Das Einzige, was den beiden Varianten gemeinsam ist, ist die Tatsache, dass der jeweilige Zustand über die Funktion IsDisabled() in der fhem.pl ermittelt wird. Und zwar für alle in FHEM vorhandenen Module, sofern sie diese Funktion benutzen.

besonders beim fhem start erscheint es mir kontraproduktiv den timer zu starten, wenn das attribut disable gesetzt ist.

Denke bitte einfach mal logisch mit: Beim Start von FHEM wird zuerst das define des at-devices ausgeführt. Zu diesem Zeitpunkt ist noch kein Attribut "disabled" gesetzt und auch noch kein reading "state" mit dem Wert "inactive" vorhanden. Es gibt also zu diesem Zeitpunkt noch gar keine Möglichkeit, das Starten des Timers zu unterbinden.


Mein Wunsch ist, dass am bestehenden Verhalten nichts geändert wird.
Das Verhalten finde ich logisch, sinnvoll und nachvollziehbar.

[Damian]

hallo rudi,

bug oder feature?

ich habe einige wiederholende at, die disabled sind, da ich sie nur selten zum testen benötige. nun habe ich heute zufällig festgestellt, dass die timer trotzdem alle regelmässig wie definiert gestartet werden.

disabled ist nur der ausführungsteil.
"set inactive" macht das selbe.

erwartet hatte ich eigentlich "vollständiges" nichts tun.

Würde ich auch so erwarten. attr disable schaltet komplett die Funktionalität des Devices ab, set inactive unterbindet nur die Ausführung und lässt den Timer in seinem Takt. Da sollte vielleicht der Autor seine Meinung dazu sagen.

[betateilchen]

Da sollte vielleicht der Autor seine Meinung dazu sagen.

Das hat Rudi bereits 2015 in dem Thread getan, der letztlich zur Schaffung der set Befehle (zusätzlich zum lange vorher existierenden Attribut 'disable') führte.

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

Ein unterschiedliches Verhalten bezüglich der Timer oder der Ausführungen war wohl damals schon nicht beabsichtigt. Auch die commandref ist diesbezüglich m.E. eindeutig, die Unterschiede liegen demnach nur darin, wie der Status gespeichert wird. Dort steht zu den set Befehlen:

Code Auswählen Erweitern

- inactive
Inactivates the current device. Note the slight difference to the disable attribute: using set inactive the state is automatically saved to the statefile on shutdown, there is no explicit save necesary.
This command is intended to be used by scripts to temporarily deactivate the at.
The concurrent setting of the disable attribute is not recommended.
- active
Activates the current device (see inactive).

Warum muss man ein Verhalten, das seit 10 Jahren implementiert ist und bisher keinerlei Probleme verursacht hat, nach so langer Zeit plötzlich grundsätzlich in Frage stellen?