Guten Tag,
ich habe folgendes DOIF
defmod di_desktop_ctrl DOIF ([{sunrise("REAL")}-{sunset("REAL")}]) (set deCONZ_HUEDevice2 off) DOELSEIF ([desktop] eq "on") (set deCONZ_HUEDevice2 on) DOELSEIF ([desktop] eq "off") (set deCONZ_HUEDevice2 on-for-timer 90) DOELSE (set
deCONZ_HUEDevice2 off)
Wenn nun desktop tagsüberauf "on" wechselt geht aber trotzdem die Lampe an. Wenn ich checkall mache geht Sie wieder aus.
D.h. das Ablaufdiagramm hier https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF stimmt nicht, wenn es durch einen Event ausgelöst wird?
Bitte um Erläuterung.
BTW. Der State vom DOIF wechselt nach cmd_2 und nach dem checkall wieder auf cmd_1, da ist keine andere Regel an der Lampe.
Es sind keine Attribute am DOIF gesetzt
Viele Grüße
Tim
In der Einleitung in der Commandref zu DOIF steht:
ZitatSyntax FHEM-Modus:
define <name> DOIF (<Bedingung>) (<Befehle>) DOELSEIF (<Bedingung>) (<Befehle>) DOELSEIF ... DOELSE (<Befehle>)
Die Angaben werden immer von links nach rechts abgearbeitet. Logische Abfragen werden in DOIF/DOELSEIF-Bedingungen vornehmlich mit Hilfe von and/or-Operatoren erstellt. Zu beachten ist, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event das dazughörige Device bzw. die dazugehörige Triggerzeit beinhalten. Kommt ein Device in mehreren Bedingungen vor, so wird immer nur ein Kommando ausgeführt, und zwar das erste, für das die dazugehörige Bedingung in der abgearbeiteten Reihenfolge wahr ist.
Guter Hinweis.
Zeitgleich habe ich einen Workaround eingebaut, weil ich mir sowas schon gedacht habe.
defmod di_desktop_ctrl DOIF ([{sunrise("REAL")}-{sunset("REAL")}] and [desktop] ne "Muss hier stehen") (set deCONZ_HUEDevice2 off) DOELSEIF ([desktop] eq "on") (set deCONZ_HUEDevice2 on) DOELSEIF ([desktop] eq "off") (set deCONZ_HUEDevice2 on-for-timer 90) DOELSE (set deCONZ_HUEDevice2 off)
Damit zwinge ich die Verarbeitung auch beim Event von desktop dahin.
Wieder etwas wertvolles gelernt.
Danke
Das kannst du auch einfacher haben, siehe https://fhem.de/commandref_DE.html#DOIF_checkall
Ich habe ein ähnliches Problem und hoffe, dass das für mich die Lösung ist.
Auch bei mir wurde ein gültiger Zustand weggeschaltet.
Ist es nicht so, dass es bei der Verwendung von Zeitintervallen sehr wahrscheinlich ist, dass man in diese Falle läuft?
Dann wäre es doch hilfreich, die Verwendung des Attributes checkall im Einsteigerleitfaden und in der commandref in Verbindung mit Zeitintervallen zu empfehlen?
Mir hätte es geholfen.
Gruß, Stefan.
Zitat von: buennerbernd am 27 November 2019, 17:31:04
Ich habe ein ähnliches Problem und hoffe, dass das für mich die Lösung ist.
Auch bei mir wurde ein gültiger Zustand weggeschaltet.
Ist es nicht so, dass es bei der Verwendung von Zeitintervallen sehr wahrscheinlich ist, dass man in diese Falle läuft?
Dann wäre es doch hilfreich, die Verwendung des Attributes checkall im Einsteigerleitfaden und in der commandref in Verbindung mit Zeitintervallen zu empfehlen?
Mir hätte es geholfen.
Gruß, Stefan.
Normalerweise braucht man checkall nicht, insb. auch bei Zeitintervallen nicht.
Wenn eine Bedingung unabhängig von einem Device ist, dann sollte sie nicht zum Tragen kommen, ansonsten sollte sie sich mit einer anderen Bedingung mit and zusammenfassen lassen, wo das triggernde Device vorkommt.
Man kann sagen: nach Möglichkeit sollte es in einem DOIF-Device nur eine Bedingung zum off-Schalten und nur eine zum on-Schalten geben und nicht mehrere.
Wenn du einen konkreten Fall hast, dann kannst du ihn hier posten.
Stimmt, ich habe 3 Zweige und mit ein paar Klammern mehr könnte man sie auf 2 Zweige kürzen.
DOIF mach so einen flexiblen Eindruck, dass ich dachte 3 Zweige sind genau richtig für meinen Fall.
Hier mal mein DEF, wo ich dachte, ich hätte alles richtig gemacht:
([Anwesenheit]eq"anwesend" and ([6:00-22:00|Mo Di Mi Do] or [6:00-23:00|MWE] or [7:00-23:00|WE])) (set Heizung1Nachtabsenkung off)
DOELSEIF ([Anwesenheit]eq"auto" and ([6:00-8:00|AT] or [15:00-22:00|Mo Di Mi Do] or [15:00-23:00|MWE] or [7:00-23:00|WE])) (set Heizung1Nachtabsenkung off)
DOELSE (set Heizung1Nachtabsenkung on)
Der 1. Zweig war richtig, doch um 8:00 und 15:00 Uhr wurde der else-Zweig aktiv. Das war nicht auf Anhieb plausibel.
Schwierig, etwas zu sagen, wenn man nicht weiss, was Anwesenheit für ein Status hatte, und wie es sich geändert hat.
Besser wäre ein vollständiges "list" vom Device, wenn Du meinst, es hat "falsch" geschaltet
Seit 7:45 Uhr war Anwesenheit=anwesend
Es war von da an cmd_1 aktiv.
Um 8:00 Uhr hat es auf cmd_3 geschaltet. Ich habe mich gewundert. Mit set checkall war dann wieder cmd_1 aktiv.
Um 15:00 Uhr wieder das Gleiche, cmd_3 und mit set checkall stellte sich wieder wie erwartet cmd_1 ein.
Dann hab ich die Forensuche angeworfen. Ich denke, dass mit dem Attribut checkall mein Problem gelöst ist.
Ich habe auch nicht gesagt, dass es nicht funktioniert, wie in der commandref beschrieben, nur für mich unerwartet.
Zitat von: buennerbernd am 27 November 2019, 20:23:01
Stimmt, ich habe 3 Zweige und mit ein paar Klammern mehr könnte man sie auf 2 Zweige kürzen.
DOIF mach so einen flexiblen Eindruck, dass ich dachte 3 Zweige sind genau richtig für meinen Fall.
Hier mal mein DEF, wo ich dachte, ich hätte alles richtig gemacht:
([Anwesenheit]eq"anwesend" and ([6:00-22:00|Mo Di Mi Do] or [6:00-23:00|MWE] or [7:00-23:00|WE])) (set Heizung1Nachtabsenkung off)
DOELSEIF ([Anwesenheit]eq"auto" and ([6:00-8:00|AT] or [15:00-22:00|Mo Di Mi Do] or [15:00-23:00|MWE] or [7:00-23:00|WE])) (set Heizung1Nachtabsenkung off)
DOELSE (set Heizung1Nachtabsenkung on)
Der 1. Zweig war richtig, doch um 8:00 und 15:00 Uhr wurde der else-Zweig aktiv. Das war nicht auf Anhieb plausibel.
Unabhängig davon, wann du off schalten willst. Die beiden Bedingungen kannst du mit or zu einer Bedingung verknüpfen, damit erreichst du genau zwei Zustände (on/off), die sich gegenseitig ausschließen.