DOIF: alle vier Kombinationen von 2 Zuständen auswerten

[SGi]

Hallo zusammen,

für die Statusanzeige mit 4 möglichen Zuständen (LED rot, gelb, grün, aus) von einem Fenster EG.WC.FK und einem Rollo EG.WC.RL suche ich eine möglichst kompakte Schreibweise und bin mit dem DOIF eigentlich ganz glücklich. Bisher gelöst in der Form:

Code Auswählen Erweitern


define di.EG.05 DOIF ([EG.WC.*:.*]) ()
DOELSEIF ([EG.WC.FK] eq "geschlossen" and [EG.WC.RL] eq "zu")
  (set EG.Status.05 led off)
DOELSEIF ([EG.WC.FK] eq "offen")
  (set EG.Status.05 led red)
DOELSEIF ([EG.WC.FK] eq "geschlossen" and [EG.WC.RL] ne "zu")
  (set EG.Status.05 led green)


Das erste DOIF ist eigentlich überflüssig, da ich damit nur in den Prüf-Block reinspringe, wenn sich bei einem der beiden Komponenten etwas tut (vergleichbar notify), erlaubt mir aber ggfs. später noch komfortabel zeitliche Eingrenzungen etc. einzubauen.  Meine Fragen:

1. geht es noch eleganter, unter der Prämisse, die vier Stati und die damit verbundene Bedingungen möglichst kurz und übersichtlich zu halten ? In diesem Beispiel nutze ich zwar die Kombination (FK offen und RL zu) nicht explizit, aber der Fall wäre ja einfach und gut lesbar einzufügen.

2. das erste Kommando (LED aus) wird in diesr Version nur dann ausgeführt, wenn das WC.FK geschlossen wird und WC.RL schon den Zustand "zu" besitzt, nicht aber, wenn WC.FK geschlossen ist und WC.RL danach erst "zu" erlangt. Warum ist das so, da sich der State von WC.RL doch ändert und der Block demnach von vorne durchlaufen werden und die erste Bedingung zutreffen mußte ?

Sven

[Damian]

Hallo zusammen,

für die Statusanzeige mit 4 möglichen Zuständen (LED rot, gelb, grün, aus) von einem Fenster EG.WC.FK und einem Rollo EG.WC.RL suche ich eine möglichst kompakte Schreibweise und bin mit dem DOIF eigentlich ganz glücklich. Bisher gelöst in der Form:

Code Auswählen Erweitern


define di.EG.05 DOIF ([EG.WC.*:.*]) ()
DOELSEIF ([EG.WC.FK] eq "geschlossen" and [EG.WC.RL] eq "zu")
  (set EG.Status.05 led off)
DOELSEIF ([EG.WC.FK] eq "offen")
  (set EG.Status.05 led red)
DOELSEIF ([EG.WC.FK] eq "geschlossen" and [EG.WC.RL] ne "zu")
  (set EG.Status.05 led green)


Das erste DOIF ist eigentlich überflüssig, da ich damit nur in den Prüf-Block reinspringe, wenn sich bei einem der beiden Komponenten etwas tut (vergleichbar notify), erlaubt mir aber ggfs. später noch komfortabel zeitliche Eingrenzungen etc. einzubauen.  Meine Fragen:

1. geht es noch eleganter, unter der Prämisse, die vier Stati und die damit verbundene Bedingungen möglichst kurz und übersichtlich zu halten ? In diesem Beispiel nutze ich zwar die Kombination (FK offen und RL zu) nicht explizit, aber der Fall wäre ja einfach und gut lesbar einzufügen.

2. das erste Kommando (LED aus) wird in diesr Version nur dann ausgeführt, wenn das WC.FK geschlossen wird und WC.RL schon den Zustand "zu" besitzt, nicht aber, wenn WC.FK geschlossen ist und WC.RL danach erst "zu" erlangt. Warum ist das so, da sich der State von WC.RL doch ändert und der Block demnach von vorne durchlaufen werden und die erste Bedingung zutreffen mußte ?

Sven

Bei DOIF musst du Device-Namen immer konkret angeben, daher wird ([EG.WC.*:.*])  nicht funktionieren.

Überprüft werden nur Bedingung, bei denen das triggernde Device vorkommt:

Die Bedingung  ([EG.WC.FK] eq "geschlossen" and [EG.WC.RL] eq "zu") wird ausgewertet, wenn EG.WC.FK oder EG.WC.RL triggert (ein Event erzeugt), wer zuerst triggert ist egal.

Gruß

Damian

[SGi]

Hallo Damian,

vielen Dank für die schnelle Antwort.

Bei DOIF musst du Device-Namen immer konkret angeben, daher wird ([EG.WC.*:.*])  nicht funktionieren.

Also bei mir funktioniert das sogar super  , wie gesagt scheint aber die Bedingung "zu" bei WC.RL nicht anzukommen. Da aber alle Zustände korrekt angezeigt werden, wenn das Fenster zuletzt eine Statusänderung hat, wird dieser Status ja auch korrekt ausgewertet. Daher werde ich mal forschen, ob vielleicht der Status von .RL keinen (oder einen anderen) Event auslöst, denn das ist das Einzige was nicht geht...

Sven

[Damian]

Hallo Damian,

vielen Dank für die schnelle Antwort.

Also bei mir funktioniert das sogar super 

Sven

Es mag sein, dass  ([EG.WC.*:.*]) in der Definition als Fehler nicht abgefangen wurde, funktionieren wird es dennoch nicht.

Gruß

Damian

[SGi]

Wie gesagt, bis auf die Tatsache, daß .RL anscheinend nicht immer ausgewertet wird, hat das so genau so funktioniert wie ich mir das vorgestellt habe (spätestens immer bei Betätigung des Fensterkontaktes).

Jetzt hab ich noch mit ein paar verschiedenen Konstellationen experimentiert, komme aber zu keinem Ergebnis. Die beiden beteiligten Aktoren in der Form DOIF ([EK.WC.FK:.*] or [EG.WC.RL:.*]) einzubauen geht irgendwie auch nicht. Deshalb noch mal zu meiner zweiten Frage:

Wie würde man das am besten lösen ?  Doch besser als "obersten Trigger" ein einfaches notify, bei dem ich Konstruktionen wie EG.WC.*:.* ja verwenden könnte, und danach IFs/DOIFs ?  Von diesen Konstruktionen gibt es zehn gleichartige Auswertungen, die jeweils vier Zustände haben können.

Merci,

Sven

[Brockmann]

Wie würde man das am besten lösen ?  Doch besser als "obersten Trigger" ein einfaches notify, bei dem ich Konstruktionen wie EG.WC.*:.* ja verwenden könnte, und danach IFs/DOIFs ?  Von diesen Konstruktionen gibt es zehn gleichartige Auswertungen, die jeweils vier Zustände haben können.

Wie Damian schon schrieb, kannst Du bei DOIFs keine Wildcards verwenden, sondern jedes DOIF muss an ein bestimmtes Device geknüpft sein. Wenn Du zehn solcher Konstruktionen hast, bräuchtest Du also 10 DOIFs, was sicherlich nicht Sinn der Sache ist. Aber mit einem notify und IF (oder if) erreichst Du doch diesselbe Funktionalität und würdest nur ein einziges benötigen, da Du im notify ermitteln kannst, welches Device es ausgelöst hat.

[SGi]

Hallo Brockmann, danke für Dein Feedback.

Das ist genau die Frage.  Wenn ich alles über ein notify löse, habe ich zwar nur eine Funktion für 20 Komponenten in Zweiergruppen (10 Fenster und 10 Rollo), muß aber zunächst in der Bedingung nur die 4 Triggerzustände (offen, geschlossen, auf, zu) filtern, die hierfür wichtig sind, und danach doch einen extremen "Auswerte-Schachtelaufwand" betreiben, um dann

a) die richtige LED-Farbe und
b) das richtige Ziel-Device (LED)

zu ermitteln, um dieses dann wieder mit der Farbe zu setzen. Deshalb kam ich auf IF/DOIF, weil man das damit schön überschaubar und pflegeleicht machen kann.
Eine einmal gebaute Konstruktion wie so etwas

Code Auswählen Erweitern

define LED.05 notify EG.WC.*:.* {
  IF ([EG.WC.FK] eq "geschlossen" and [EG.WC.RL] == 0) (set EG.Status.05 led off)
  IF ([EG.WC.FK] eq "offen") (set EG.Status.05 led red)
  IF ([EG.WC.FK] eq "geschlossen" and [EG.WC.RL] != 0) (set EG.Status.05 led green)
}

verstehe ich auch noch in 6 Monaten und kann Bedingungen für die Farbgebung von LED 5 jederzeit universell anpassen, egal welche Funktion die dann haben wird. Dafür brauche ich natürlich für jede LED so einen notify-Block, das ist klar. Aber das will ich ja auch eigentlich wegen der Übersichtlichkeit, es sei denn, es sprechen extreme Performancegründe oder ähnliches dagegen.

FHEM meckert hier übrigens bereits in Zeile 2 einen Syntaxfehler an. Mag IF mehrere Parameter beim "set" nicht ?  (Semikolon, Doppelklammer usw. haben auch nicht geholfen)

[flurin]

Hallo SGi

Beachte den Unterschied IF und if. Siehe Dokumentation.

Guss
flurin

[Damian]

Hallo Brockmann, danke für Dein Feedback.

Das ist genau die Frage.  Wenn ich alles über ein notify löse, habe ich zwar nur eine Funktion für 20 Komponenten in Zweiergruppen (10 Fenster und 10 Rollo), muß aber zunächst in der Bedingung nur die 4 Triggerzustände (offen, geschlossen, auf, zu) filtern, die hierfür wichtig sind, und danach doch einen extremen "Auswerte-Schachtelaufwand" betreiben, um dann

a) die richtige LED-Farbe und
b) das richtige Ziel-Device (LED)

zu ermitteln, um dieses dann wieder mit der Farbe zu setzen. Deshalb kam ich auf IF/DOIF, weil man das damit schön überschaubar und pflegeleicht machen kann.
Eine einmal gebaute Konstruktion wie so etwas

Code Auswählen Erweitern

define LED.05 notify EG.WC.*:.* {
  IF ([EG.WC.FK] eq "geschlossen" and [EG.WC.RL] == 0) (set EG.Status.05 led off)
  IF ([EG.WC.FK] eq "offen") (set EG.Status.05 led red)
  IF ([EG.WC.FK] eq "geschlossen" and [EG.WC.RL] != 0) (set EG.Status.05 led green)
}

verstehe ich auch noch in 6 Monaten und kann Bedingungen für die Farbgebung von LED 5 jederzeit universell anpassen, egal welche Funktion die dann haben wird. Dafür brauche ich natürlich für jede LED so einen notify-Block, das ist klar. Aber das will ich ja auch eigentlich wegen der Übersichtlichkeit, es sei denn, es sprechen extreme Performancegründe oder ähnliches dagegen.

FHEM meckert hier übrigens bereits in Zeile 2 einen Syntaxfehler an. Mag IF mehrere Parameter beim "set" nicht ?  (Semikolon, Doppelklammer usw. haben auch nicht geholfen)

Ob du pro Fenster den obigen Ausdruck schreibst (abgesehen davon, dass es syntaktisch so nicht funktioniert) oder:

Code Auswählen Erweitern

define LED.05 DOIF ([EG.WC.FK] eq "geschlossen" and [EG.WC.RL] == 0)  (set EG.Status.05 led off)
DOELSEIF ([EG.WC.FK] eq "offen") (set EG.Status.05 led red)
DOELSEIF ([EG.WC.FK] eq "geschlossen" and [EG.WC.RL] != 0) (set EG.Status.05 led green)


sehe ich als keinen Vorteil an.

Gruß

Damian