Mit der internen FHEM-Funktion IsDisabled (http://www.fhemwiki.de/wiki/DevelopmentModuleAPI#IsDisabled) und des besonderen Statuswertes inactive lässt sich für Bedingungszweige die Befehlsausführung deaktivieren.
Zusätzlich ist die Nutzung des Attributes disabledForIntervals möglich.
Das Reading state kann über setreading oder über das Attribut cmdState auf inactive gesetzt werden.
Grundsätzlich wird eine Bedingung, die inaktiv werden soll, so formuliert
(<Bedingung> and !IsDisabled("$SELF")) (<Befehle>)
Jede Bedingung, die !(IsDisabled("$SELF") == 3) enthält wird nicht wahr und die Befehle werden nicht ausgeführt, wenn state auf inactive gesetzt ist.
Jede Bedingung die state auf einen anderen Wert als inactive setzt, aktiviert die Bedingungen wieder, die durch !IsDisabled("$SELF") blockiert sind.
Ist das Attribut disabledForIntervals gesetzt, dann wird IsDisabled("$SELF") unabhängig von state wahr und liefert 2 zurück. Daher wird jede Bedingung, die !(IsDisabled("$SELF") == 2) enthält nicht wahr, wenn der Zeitpunkt der Bedingungsprüfung einem Intervall liegt, dass im Attribut disabledForIntervals angegeben ist.
Eine Abfrage des Rückgabewertes von IsDisabled ist nicht notwendig, wenn der Grund für den Deaktivierungszustand keine Rolle spielt.
Das Beispiel kann mit Raw definition importiert werden.
defmod using_inactive_Labor DOIF ([$SELF:mybutton] == 1 and !IsDisabled("$SELF")) ({Log 1, "Befehl 1"})\
DOELSEIF ([$SELF:mybutton] == 2 and !IsDisabled("$SELF")) ({Log 1, "Befehl 2"})\
DOELSEIF ([$SELF:mybutton] == 3 and !IsDisabled("$SELF")) ({Log 1, "Befehl 3"})\
DOELSEIF ([$SELF:mybutton] == 4) ({Log 1, "Befehl 4"})\
DOELSEIF ([00:00]) ({Log 1, "Befehl 5"})\
attr using_inactive_Labor userattr disabledForIntervals
attr using_inactive_Labor alias Nutzung von state inactive und IsDisabled-Funktion
attr using_inactive_Labor cmdState Schritt 1|inactive|Schritt 3| Schritt 4|Schritt 5
attr using_inactive_Labor disabledForIntervals 13:00-14:00
attr using_inactive_Labor do always
attr using_inactive_Labor readingList mybutton
attr using_inactive_Labor room DOIF_Labor
attr using_inactive_Labor setList mybutton:0,1,2,3,4
attr using_inactive_Labor webCmd mybutton
setstate using_inactive_Labor initialized
setstate using_inactive_Labor 2016-12-08 14:30:13 cmd 0
setstate using_inactive_Labor 2016-12-08 14:24:47 mybutton 0
setstate using_inactive_Labor 2016-12-08 14:30:13 state initialized
setstate using_inactive_Labor 2016-12-08 14:30:13 timer_01_c05 09.12.2016 00:00:00
Bedingung 2 setzt state über cmdState auf inactive. Danach werden nur noch Zweig 4 und 5 ausgeführt, dadurch wird inactive zurück gesetzt.
@Damian: Würde dieses Verfahren nicht dafür sprechen, das Attribut disabledForIntervals in die Liste der Modulattribute aufzunehmen?. Dann könnte man sich das Attribut userattr sparen.
Es ist schön, dass es diese Möglichkeit gibt. Das sollten wir im WIKI aufnehmen. Allerdings ist es an bestimmte Bedingungen geknüpft: Zustand des Moduls inactive, Abfrage des eigenen Zustands. Meine Befürchtung ist, wenn man das Attribut offiziell aufnimmt, dann werden viele erwarten, dass es ohne weiteres funktioniert - das ist aber nicht der Fall. Ich gehe eher davon aus, dass 99% der User in ihren DOIF-Definitionen noch nicht mal das Bedürfnis haben den eigenen Status auszuwerten.
Es wird immer nach diesem Attribut gefragt, weil es beim notify verwendet wird. Im DOIF-Modul kann man aber noch viel flexibler mit unterschiedlichen Zeitintervallen in jeder Bedingung hantieren.
Daher würde ich diese Option den Power-DOIF-Usern überlassen, die wissen was sie tun. Und wenn man ohnehin schon so viele Voraussetzungen erfüllen muss, dann kann man auch das userattr setzen. Wenn sich gegen meine Erwartung dieses Verfahren durchsetzen sollte, dann wäre ich auch bereit dieses Attribut aufzunehmen. Aber z. Zt., denke ich, würde es mehr Fragen aufwerfen als Probleme lösen, weil es ohne die oben genannten Voraussetzungen eben nicht funktioniert.
Gruß
Damian
Zur Verwendung von state inactive (http://doif/partielle%20Deaktivierung%20der%20Befehlsausf%C3%BChrung,%20Zur%C3%BCcksetzen%20eines%20Wait-Timers%20mit%20$SELF%20oder%20IsDisabled%20verhindern,%20im%20Vergleich) und disabledForIntervals (http://www.fhemwiki.de/wiki/DOIF/Zeitspanne_im_DOIF_und_disableForIntervals_im_Vergleich) gibt es jetzt etwas im FHEM-Wiki.
Zitat von: Ellert am 09 Dezember 2016, 10:28:53
Zur Verwendung von state inactive (http://doif/partielle%20Deaktivierung%20der%20Befehlsausf%C3%BChrung,%20Zur%C3%BCcksetzen%20eines%20Wait-Timers%20mit%20$SELF%20oder%20IsDisabled%20verhindern,%20im%20Vergleich) und disabledForIntervals (http://www.fhemwiki.de/wiki/DOIF/Zeitspanne_im_DOIF_und_disableForIntervals_im_Vergleich) gibt es jetzt etwas im FHEM-Wiki.
Der Aufbau hat mich etwas irritiert:
Überschrift lautet: DOIF/Zeitspanne im DOIF und disableForIntervals im Vergleich
Dennoch erklärst du zuerst die Alternative disableForIntervals und dann die originäre Funktionalität.
Ich würde passend zur Überschrift (und dem, was ich persönlich den Usern zunächst empfehlen würde, weil es flexibler ist und ohne zusätzliche Attribute auskommt) mit der originären Funktionalität beginnen, und dann die disableForIntervals als Alternative präsentieren. Ich würde noch deutlicher hervorheben, dass es eine Alternative für die
gleiche Funktionalität ist.
Meine Absicht war eher ein unbewerteter Vergleich, bei dem der Anwender sich eine Meinung bildet. Ich habe jetzt das Verbesserungspotential erkannt und genutzt ;)
Zitat von: Ellert am 09 Dezember 2016, 17:32:23
Meine Absicht war eher ein unbewerteter Vergleich, bei dem der Anwender sich eine Meinung bildet. Ich habe jetzt das Verbesserungspotential erkannt und genutzt ;)
Siehst du denn persönlich einen Vorteil bei der Nutzung des disabledForIntervals gegenüber einer einfachen Zeitintervallangabe? Denn mir erschließt sich nicht so richtig ein Vorteil, außer dass es ein bekanntes Atttribut ist, welches auch bei notify verwendet wird.
Nein, ab und zu wurde danach gefragt, das hat mich dazu gebracht nach einer Lösung zu suchen. Wegen der Beschäftigung mit dem Attribut stand es wohl auch deshalb im Vordergrund bei der Erstellung des Artikels. Einen echten Vorteil sehe ich nicht, ausser dass die Benutzung aus anderen Modulen bekannt ist.
Interessanter finde ich die Möglichkeit "state inactive" zu nutzen, das halte ich für etwas einfacher als den "!~"- Operator in Verbindung mit Regex, besonders wenn man die Zahlenvariante mit $cmd verwendet.