DOIF bei Prozentwerten

[hirsch911]

Moin,

vermutlich habe ich gerade einen Pflock im Kopf, aber kann mir einer sagen, wo hier das Problem ist? Das DOIF landet immer in CMD2 (also nix passiert). Auf den Haustürkontakt reagiert es mit CMD2, also ist der Fehler in meinem Kopf oder im Code

DEF   ([eg.flur.haustuer.fk:"off"] and [aussen.haustuer.wert:"100 %"]) (set zentral.eg.ein on)

Wenn der Haustürkontakt auf "off" geht und in dem Moment der Wert von aussen.haustuer.wert 100% ist, dann soll CMD1 ausgeführt werden (manuell gesetzt geht das auch). Das ist der Plan. Im Event Monitor läuft aussen.haustuer.wert so auf:

_20:58:35 aussen.haustuer.wert getG1: 100 %
_20:58:35 aussen.haustuer.wert last-sender: 1/1/6
_20:58:35 aussen.haustuer.wert 100 %

Hat da jmd. eine Idee? 

Gruß

Stephan

[Otto123]

Hallo Stephan,

ich würde vorsichtig sagen: Du triggerst mit zwei Events, dass kann nicht gehen. Zwei Events werden nie gleichzeitig auftreten.
Nimm einen Event als primären Trigger und frage in der Bedingung den zweiten Wert nur ab.

Code Auswählen Erweitern

([eg.flur.haustuer.fk:"off"] and [aussen.haustuer.wert] eq "100 %"])

Gruß Otto

[hirsch911]

Jo! Danke, das meinte ich mit Pflock im Kopf. Zu wenig Kaffee getrunken. Jetzt geht es!

[Otto123]

Ich will mal noch den Teil aus der Doku einwerfen, da steht u.a. genau das drin was ich gesagt habe.

Ereignissteuerung   back

Vergleichende Abfragen werden, wie in Perl gewohnt, mit Operatoren ==, !=, <, <=, >, >= bei Zahlen und mit eq, ne, lt, le, gt, ge, =~, !~ bei Zeichenketten angegeben. Logische Verknüpfungen sollten zwecks Übersichtlichkeit mit and bzw. or vorgenommen werden. Selbstverständlich lassen sich auch alle anderen Perl-Operatoren verwenden, da die Auswertung der Bedingung vom Perl-Interpreter vorgenommen wird. Die Reihenfolge der Auswertung wird, wie in höheren Sprachen üblich, durch runde Klammern beeinflusst. Status werden mit [<devicename>], Readings mit [<devicename>:<readingname>], Internals mit [<devicename>:&<internal>] angegeben.

Anwendungsbeispiel: Einfache Ereignissteuerung mit einmaliger Ausführung beim Zustandswechsel, "remotecontrol" ist hier ein Device, es wird in eckigen Klammern angegeben. Ausgewertet wird der Status des Devices - nicht das Event.

define di_garage DOIF ([remotecontrol] eq "on") (set garage on) DOELSEIF ([remotecontrol] eq "off") (set garage off)

Das Modul wird getriggert, sobald das angegebene Device hier "remotecontrol" ein Event erzeugt. Das geschieht, wenn irgendein Reading oder der Status von "remotecontrol" aktualisiert wird. Ausgewertet wird hier der Zustand des Status von remotecontrol nicht das Event selbst.

...

Eine Alternative zur Auswertung von Status oder Readings ist das Auswerten von Ereignissen (Events) mit Hilfe von regulären Ausdrücken. Der Suchstring wird als regulärer Ausdruck in Anführungszeichen angegeben. Die Syntax lautet: [<devicename>:"<regex>"]

Anwendungsbeispiel: wie oben, jedoch wird hier nur das Ereignis (welches im Eventmonitor erscheint) ausgewertet und nicht der Status von "remotecontrol" wie im vorherigen Beispiel

define di_garage DOIF ([remotecontrol:"on"]) (set garage on) DOELSEIF ([remotecontrol:"off"]) (set garage off)

In diesem Beispiel wird nach dem Vorkommen von "on" innerhalb des Events gesucht. Falls "on" gefunden wird, wird der Ausdruck wahr und der DOIF-Fall wird ausgeführt, ansonsten wird der DOELSEIF-Fall entsprechend ausgewertet. Die Auswertung von reinen Ereignissen bietet sich dann an, wenn ein Modul keinen Status oder Readings benutzt, die man abfragen kann, wie z. B. beim Modul "sequence". Die Angabe von regulären Ausdrücken kann recht komplex werden und würde die Aufzählung aller Möglichkeiten an dieser Stelle den Rahmen sprengen. Weitere Informationen zu regulären Ausdrücken sollten in der Perl-Dokumentation nachgeschlagen werden. Die logische Verknüpfung "and" mehrerer Ereignisse ist nicht sinnvoll, da zu einem Zeitpunkt immer nur ein Ereignis zutreffen kann.

Die alte Syntax [<devicename><regex>] wird aus Kompatibilitätsgründen noch unterstützt, sollte aber nicht mehr benutzt werden.

Sollen Events verschiedener Devices ausgewertet werden, so lässt sich folgende Syntax anwenden: ["<device regex>:<event regex>"]

Ob man das wirklich versteht, wenn man nicht nur das Ergebnis haben will sondern auch drüber nachdenkt ob das Konstrukt optimal mit den Ressourcen um geht?
Also theoretisch hättest Du auch

Code Auswählen Erweitern

([eg.flur.haustuer.fk:"off"] and ["aussen.haustuer.wert:100 %"]) verwenden können?
Und welche Variante ist besser fürs System? Ob die Frage mal einer der DOIF Gurus beantworten kann?
Noch mal der Überblick anhand dieses Beispiel und lesen der Doku:
([eg.flur.haustuer.fk:"off"] and [aussen.haustuer.wert:"100 %"]) kann nicht gehen!
([eg.flur.haustuer.fk:"off"] and [aussen.haustuer.wert] eq "100 %"]) geht, triggert aber zusätzlich bei jeder Änderung von aussen.haustuer.wert ?
([eg.flur.haustuer.fk:"off"] and ["aussen.haustuer.wert:100 %"]) geht laut Doku ? und triggert wenn ein Gerät mit aussen.haustuer.wert im Namen auf irgendetwas mit  100 % geht?

Gruß Otto

[hirsch911]

Also für meinen Fall ist das genau richtig so, wie Du es beschrieben hast. Getriggert wird durch den TK kurz bei der Öffnung der Tür. Dann schauen, ob gerade das Licht bei 100 % ist und wenn alles stimmt, dann CMD1 auslösen.
Das Licht soll nichts triggern und er soll auch nicht prüfen, ob der Zustand des TK gerade off oder on ist während sich der Wert des Lichts ändert. Nur einmal kurz triggern, wenn das TK-Ereignis eintritt.

Gruß

Stephan

[Damian]

Also für meinen Fall ist das genau richtig so, wie Du es beschrieben hast. Getriggert wird durch den TK kurz bei der Öffnung der Tür. Dann schauen, ob gerade das Licht bei 100 % ist und wenn alles stimmt, dann CMD1 auslösen.
Das Licht soll nichts triggern und er soll auch nicht prüfen, ob der Zustand des TK gerade off oder on ist während sich der Wert des Lichts ändert. Nur einmal kurz triggern, wenn das TK-Ereignis eintritt.

Gruß

Stephan

z. B.

Code Auswählen Erweitern

([eg.flur.haustuer.fk:"off"] and [?aussen.haustuer.wert:state:d] == 100)

[Otto123]

@Damian: das hier ist also weiterhin gültig?

Zeitintervalle, Readings und Status ohne Trigger   back

Angaben in eckigen Klammern, die mit einem Fragezeichen beginnen, führen zu keiner Triggerung des Moduls, sie dienen lediglich der Abfrage.

Anwendungsbeispiel: Licht soll zwischen 06:00 und 10:00 angehen, getriggert wird nur durch den Taster nicht um 06:00 bzw. 10:00 Uhr und nicht durch das Device Home

define di_motion DOIF ([?06:00-10:00] and [button] and [?Home] eq "present")(set lamp on-for-timer 600)
attr di_motion do always

und fällt nicht unter die Kategorie

Die alte Syntax [<devicename><regex>] wird aus Kompatibilitätsgründen noch unterstützt, sollte aber nicht mehr benutzt werden.

Wer soll das noch verstehen 
Ist das Fragezeichen nach der eckigen Klammer also etwas generelles? (Erscheint in der Doku ja schon weiter vorne) Müsste das nicht am Anfang mal erklärt werden?

Gruß Otto

[Damian]

@Damian: das hier ist also weiterhin gültig?und fällt nicht unter die KategorieWer soll das noch verstehen 
Ist das Fragezeichen nach der eckigen Klammer also etwas generelles? (Erscheint in der Doku ja schon weiter vorne) Müsste das nicht am Anfang mal erklärt werden?

Gruß Otto

ja,

Der Satz:

"Die alte Syntax [<devicename><regex>] wird aus Kompatibilitätsgründen noch unterstützt, sollte aber nicht mehr benutzt werden."

fliegt bald raus, damit die User sie gar nicht erst kennen.

Die Syntax [?<device>...] müsste separat erklärt werden.

Dann sollte ? in DOIF nur noch "ohne Trigger" bedeuten.