HI! Ich habe mal gelesen das es gehen soll, aber bei mir funktioniert das irgendwie nicht... Hab ich einen Fehler gemacht?
([HM_29B300:battery] eq "low")
(set Telegram message Taster im Flur: "Batterie leer!!!")
DOIF
([TerrassenTuer] eq "dimdown")
(set Telegram message Terrassen Tür "Batterie leer!!!")
Fehlermeldung:
DOIFBatterie DOIF: expected DOELSEIF or DOELSE: DOIF ([TerrassenTuer] eq "dimdown") (set Telegram message Terrassen Tür "Batterie leer!!!")
Zitat von: CommandRef
Syntax FHEM-Modus:
define <name> DOIF (<Bedingung>) (<Befehle>) DOELSEIF (<Bedingung>) (<Befehle>) DOELSEIF ... DOELSE (<Befehle>)
Das ist das massgebliche, egal was Du woanders gelesen zu haben glaubst.
Habs gefunden:
https://forum.fhem.de/index.php/topic,36889.msg291649.html#msg291649 (https://forum.fhem.de/index.php/topic,36889.msg291649.html#msg291649)
Das kam von entwickler... Zählt das nicht mehr?
Damit könnte ich mir sehr viele DOIFS sparen...
Mehrere DOIF-Fälle:
define di DOIF (...) (...)
DOELSEIF (...) (...)
DOELSE (...)
DOIF (...) (...)
DOELSEIF (...) (...)
DOELSE (...)
DOELSEIF und DOELSE beziehen sich immer auf den vorhergehenden DOIF-Fall.
Zitat von: misux am 27 April 2018, 07:25:13
Habs gefunden:
https://forum.fhem.de/index.php/topic,36889.msg291649.html#msg291649 (https://forum.fhem.de/index.php/topic,36889.msg291649.html#msg291649)
Das kam von entwickler... Zählt das nicht mehr?
Damit könnte ich mir sehr viele DOIFS sparen...
Mehrere DOIF-Fälle:
define di DOIF (...) (...)
DOELSEIF (...) (...)
DOELSE (...)
DOIF (...) (...)
DOELSEIF (...) (...)
DOELSE (...)
DOELSEIF und DOELSE beziehen sich immer auf den vorhergehenden DOIF-Fall.
siehe https://wiki.fhem.de/wiki/DOIF#Entwicklungshistorie
Hallo zusammen,
ich habe ein ähnliches Problem und finde den Fehler nicht. Ich bin gerade dabei, mich mehr mit DOIF zu beschäftigen, um das ein oder andere notify abzulösen. Dazu habe ich ein Test dummy erstellt, den ich wie folgt mit DOIF ansteuere
([dev_residents:state] ne "home") (set licht_wohnzimmer_test off)
DOELSEIF ([daytime:lightstate] eq "off") (set licht_wohnzimmer_test off)
DOELSEIF ([dev_HarmonyHub:activity] eq "PowerOff") (set licht_wohnzimmer_test bewegungsmelder on)
DOELSEIF ([PlexKodiConnect_Wohnzimmer:state] eq "playing") (set licht_wohnzimmer_test plexplaying on)
DOELSEIF ([dev_residents:state] ne "gone") (set licht_wohnzimmer_test on)
Hier sind die Readings vom DOIF:
Device dev_residents
cmd 5
cmd_event dev_residents
cmd_nr 5
e_daytime_lightstate off
e_dev_HarmonyHub_activity PowerOff
e_dev_residents_state home
mode enabled
state cmd_5
Wenn ich das richtig verstehe, sollte doch er doch in die 2. Bedingung (cmd 2) gehen, weil die erste Bedingung ([dev_residents:state] ne "home") ja false ist, aber die zweite Bedingung ([daytime:lightstate] eq "off") ist true, genauso wie die 3. Bedingung. Warum springt er also auf die 5. Bedingung?
MFG,
Patrick
Zitat von: Ellert am 27 April 2018, 07:30:04
siehe https://wiki.fhem.de/wiki/DOIF#Entwicklungshistorie
Och nöööö.... Oh mann... und ich wolte eben richtig los legen und das DOIF befüllen.. :'(
Bin mir nicht sicher, aber fehlen da nicht ein paar semikolone oder müssten die dinge zusammengeschrieben sein oder sind es 2 getrennte dinge??
licht_wohnzimmer_test bewegungsmelder
licht_wohnzimmer_test plexplaying
Wenns 2 Teile sind hätte ich sie so gelöst:
(set licht_wohnzimmer_test on) (set bewegungsmelder on)
(set licht_wohnzimmer_test on) (set plexplaying on)
Zitat von: blade-of-fire am 27 April 2018, 07:36:08
Hallo zusammen,
ich habe ein ähnliches Problem und finde den Fehler nicht. Ich bin gerade dabei, mich mehr mit DOIF zu beschäftigen, um das ein oder andere notify abzulösen. Dazu habe ich ein Test dummy erstellt, den ich wie folgt mit DOIF ansteuere
([dev_residents:state] ne "home") (set licht_wohnzimmer_test off)
DOELSEIF ([daytime:lightstate] eq "off") (set licht_wohnzimmer_test off)
DOELSEIF ([dev_HarmonyHub:activity] eq "PowerOff") (set licht_wohnzimmer_test bewegungsmelder on)
DOELSEIF ([PlexKodiConnect_Wohnzimmer:state] eq "playing") (set licht_wohnzimmer_test plexplaying on)
DOELSEIF ([dev_residents:state] ne "gone") (set licht_wohnzimmer_test on)
Hier sind die Readings vom DOIF:
Device dev_residents
cmd 5
cmd_event dev_residents
cmd_nr 5
e_daytime_lightstate off
e_dev_HarmonyHub_activity PowerOff
e_dev_residents_state home
mode enabled
state cmd_5
Wenn ich das richtig verstehe, sollte doch er doch in die 2. Bedingung (cmd 2) gehen, weil die erste Bedingung ([dev_residents:state] ne "home") ja false ist, aber die zweite Bedingung ([daytime:lightstate] eq "off") ist true, genauso wie die 3. Bedingung. Warum springt er also auf die 5. Bedingung?
MFG,
Patrick
Nach meinem Verständnis ist das ja im FHEM-Modus, also werden dort keine Semicolons benötigt, oder?
Zitat
licht_wohnzimmer_test bewegungsmelder
licht_wohnzimmer_test plexplaying
bewegungsmelder und plexplaying sind readings von licht_wohnzimmer_test.
okay, aber wenn bewegungsmelder und plexplaying eigenständige Devices sind warum dann nicht einfach
(set bewegungsmelder on)
(set plexplaying on)
ohne ales andere davor...?
Nix falsch verstehen... Sind bei mir reine Vermutungen weil ich selbst Anfänger bin also kann es sein das ich das komplett falsch verstehe...
So würde ich es testen und müsste auch gehen...
([dev_residents:state] ne "home") (set licht_wohnzimmer_test off)
DOELSEIF ([daytime:lightstate] eq "off") (set licht_wohnzimmer_test off)
DOELSEIF ([dev_HarmonyHub:activity] eq "PowerOff") (set bewegungsmelder on)
DOELSEIF ([PlexKodiConnect_Wohnzimmer:state] eq "playing") (set plexplaying on)
DOELSEIF ([dev_residents:state] ne "gone") (set licht_wohnzimmer_test on)
Man sollte sich nicht so auf die Readings versteifen. Das ist nur ein Test-Dummy, damit ich ich am Dummy sehen kann, welchen Zustand das DOIF liefert. Später sollen damit unterschiedliche Lichtszenarien geschaltet werden.
In dem Fall ist eigentlich egal, was in dem Befehlsteil steht, weil die Bedingung, obwohl sie wahr ist, übersprungen wird.
Aber das ist doch glaube ich das Problem das de da mit drin stehen... Ich glaube deshalb überspringt er die beiden cmds...
Warum sollte das denn ein Problem sein? Solange der Device existiert und erfolgreich gesetzt werden kann. Insofern der Befehl ein Problem verursacht, würde ich einen entsprechenden Log-Eintrag erwarten, im Log stet aber gar nichts dazu.
Hi,
ich interpretiere das Verhalten mal so:
dev_residents erzeugt einen Event und triggert das DOIF Modul. Im Modul wird erstmal nur nach dev_residents geschaut ob damit irgendwelche Bedingungen zutreffen. Der erste Zweig ist false der fünfte true -> fertig.
Ob das so die richtige Begründung ist weiß ich nicht!
Ich würde die Bedingungen einfach genauer definieren. Und eine Entscheidung auf ungleich zu fällen kann immer alle Fälle bedeuten. Eine Entscheidung auf gleich ist genau ein Fall.
Gruß Otto
Aha... Dann vermute ich das dev_residents eine anwesenheitserkennung ist...
Ich habe diese etwas anders gelöst und diese funktioniert wunderbar seit wochen!
ich habe zwei dummys erstellt "DavidHandy" "ChrissiHandy". Diese werden von PRESENCE modul der die Fritzbox überwacht auf present oder absent gesetzt:
Dann hab ich einen dummy "Haus" dieser wird vom DOIF auf present oder absent gesetzt:
([DavidHandy] eq "absent" and [ChrissiHandy] eq "absent") (set Haus absent)
DOELSE
(set Haus present)
Und auf diesen Dummy triggere ich meine Lichtsteuerung/Tabletsteuerung usw... Ich habe eindeutige werte die gesetzt sind .
Beispiel: Mein FTUI Tablet:
([Haus] eq "absent" or [23:00]) (set FHEMTablet off)
DOELSEIF
([Haus] eq "present" and [08:00-23:00]) (set FHEMTablet on)
DOELSEIF
([Tageslicht_indoor] eq "Nacht" and [?FHEMTablet:brightness] eq "80") (set FHEMTablet brightness 40) (set FHEMTablet url http://192.168.1.61:8083/fhem/ftui/index.html)
DOELSEIF
([Tageslicht_indoor] eq "Tag" and [?FHEMTablet:brightness] eq "40") (set FHEMTablet brightness 80) (set FHEMTablet url http://192.168.1.61:8083/fhem/ftui/index_weiss.html)
DOELSEIF
([?DavidFruehschicht] eq "on" and [?Tageslicht_indoor] eq "Nacht" and [?Haus] eq "present" and [04:00-04:30]) (set FHEMTablet on)
DOELSEIF
([?DavidFruehschicht] eq "off" and [?Tageslicht_indoor] eq "Nacht" and [?Haus] eq "present" and [05:00-05:45]) (set FHEMTablet on)
DOELSE
(set FHEMTablet off)
Ist zwar offtopic, aber ich benutze das Modul RESIDENTS, was ein sehr umfassendes Anwesenheitsmodul ist....
Für die Logik des Ablaufs sollte doch egal sein, aus welchem Grund die Bedingung Wahr oder Unwahr ist.
Habe jetzt nochmal getestet. Es ist wo folgt:
Wenn erste Bedingung wahr (dev_residents = "absent") --> cmd 1 !KORREKT!
Wenn ich nun dev_residents auf "home" stelle (--> 1. Bedingung = false), wird cmd 5 eingestellt, was meiner Meinung nach entsprechend der DOELSEIF Abfrage falsch ist.
Wenn ich nun set checkall betätige, wird die richtige Bedingung herangezogen und cmd 2 wird eingestellt.
Hi blade-of-fire,
Damit hast Du meine Theorie bestätigt und die richtige Lösung selbst gefunden. :D
Doku lesen hilft wie so oft:
ZitatBei der Abarbeitung der Bedingungen, werden nur die Bedingungen überprüft, die zum ausgelösten Event das dazughörige Device bzw. die dazugehörige Triggerzeit beinhalten. Mit dem Attribut checkall lässt sich das Verhalten so verändern, dass bei einem Event-Trigger auch Bedingungen geprüft werden, die das triggernde Device nicht beinhalten. Folgende Parameter können angegeben werden:
checkall event Es werden alle Bedingungen geprüft, wenn ein Event-Trigger auslöst.
checkall timer Es werden alle Bedingungen geprüft, wenn ein Timer-Trigger auslöst.
checkall all Es werden grundsätzlich alle Bedingungen geprüft.
Zu beachten ist, dass bei einer wahren Bedingung die dazugehörigen Befehle ausgeführt werden und die Abarbeitung immer beendet wird - es wird also grundsätzlich immer nur ein Befehlszweig ausgeführt und niemals mehrere.
Gruß Otto
Zitat von: blade-of-fire am 27 April 2018, 10:30:58
Für die Logik des Ablaufs sollte doch egal sein, aus welchem Grund die Bedingung Wahr oder Unwahr ist.
So ist das normalerweise bei einer strukturierter Programmierung.
Bei DOIF ist es etwas anders, hier stehen die Trigger im Vordergrund, daher wird nicht jeder Zweig ausgewertet, dieses Verfahren hat sich beim DOIF bewährt, Zitat aus der Commandref:
ZitatZu 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.
Du kannst das Verhalten über das checkall-Attribut verändern. Aber auch dort wird maximal immer nur ein Zweig pro Trigger ausgeführt. Wenn komplette Unabhängigkeit von Ausführungszweigen innerhalb eines DOIF-Moduls gefordert ist, was der strukturierten Programmierung eher entspricht, dann kann ich nur auf DOIF-Perl verweisen: https://fhem.de/commandref_DE.html#DOIF_Perl_Modus
Dort kann man sich nach belieben austoben, Voraussetzung: geringe Perlkenntnisse.
Ja, da hast du Recht, Lesen hilft oftmals weiter :-[
In dem Fall bin ich fälschlicherweise davon ausgegangen, dass die Bedingungen immer komplett durchlaufen werden. Ich hatte das in irgendeinem Forumsbetrag gelesen und nicht angezweifelt.
Durch setzen des Attributs checkall funktioniert es jetzt wie gewollt, ggf werde ich aber dennoch auf die DOIF-Perl Variante umsteigen.
Danke :)