Neue Features - $SELF, $self, cmd-Reading, timerevent, selftrigger ...

[Ellert]

addStateEvent funktioniert jetzt. In diesem Zusammenhang ist mir aufgefallen, dass für

Code Auswählen Erweitern

([Test:"^state: "]) (({Log 1, "$DEVICE $EVENTS"})) "do always" erforderlich ist, da ein Event als Status erhalten bleibt und das DOIF nicht auf cmd_2 wechselt, wenn das Ereignis vorbei ist.

Wäre es nicht konsequenter eine Bedingung mit Event, nur zum Zeitpunkt des Events wahr werden zu lassen? Die Eigenart eines Events impliziert eigentlich ein "do always" Verhalten. Dazu wäre dann ein Attribut "do once" passend.

Das Triggern auf Status/Reading wäre dann komplementär zum Triggern auf Events. 

Die Einleitung finde ich sehr verständlich, sie stellt das grundsätzliche Verhalten des DOIF deutlich heraus.

[Damian]

addStateEvent funktioniert jetzt. In diesem Zusammenhang ist mir aufgefallen, dass für

Code Auswählen Erweitern

([Test:"^state: "]) (({Log 1, "$DEVICE $EVENTS"})) "do always" erforderlich ist, da ein Event als Status erhalten bleibt und das DOIF nicht auf cmd_2 wechselt, wenn das Ereignis vorbei ist.

Das verstehe ich nicht. Warum soll ein Event als Status erhalten bleiben? Das Modul verhält sich, wie sonst auch:

Es handelt sich hier um eine Event-Abfrage mit konkreter Deviceangabe. Die Eventabfrage ist nur zum Zeitpunkt des Events wahr und sonst nicht. Damit wird beim Eintreffen des Ereignisses die Regexp ausgewertet, und wenn sie nicht wahr ist dann wechselt der Status auf cmd_2 (ohne do always).

Das ist doch unabhängig davon, ob ich addStateEvent hinzufüge oder nicht.

[Damian]

Schöne Einleitung in der Doku.



Mit der v0.8 habe ich wieder eine Warnung:

Code Auswählen Erweitern

PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/98_DOIF.pm line 1168.

V 0.9

[Ellert]

Das verstehe ich nicht. Warum soll ein Event als Status erhalten bleiben? Das Modul verhält sich, wie sonst auch:

Es handelt sich hier um eine Event-Abfrage mit konkreter Deviceangabe. Die Eventabfrage ist nur zum Zeitpunkt des Events wahr und sonst nicht. Damit wird beim Eintreffen des Ereignisses die Regexp ausgewertet, und wenn sie nicht wahr ist dann wechselt der Status auf cmd_2 (ohne do always).

Das ist doch unabhängig davon, ob ich addStateEvent hinzufüge oder nicht.

Mit "addStateEvent" hat meine Überlegung nichts zu tun.

da ein Event als Status erhalten bleibt

Da habe ich mich unverständlich ausgerückt.

Mir ist bei dem DOIF mit einer Bedingung nur aufgefallen,  dass nicht automatisch in den  cmd_2 gewechselt wird, wenn die Bedingung unwahr wird.
Die Bedingung wird unwahr, sobald das Ereignis beendet ist, die Bedingung wird dann jedoch nicht erneut geprüft.

Bei einem Reading gibt es für jeden Zustandswechsel/-aktualisierung eine Prüfung der Bedingung.

Ein Event stelle ich mir als zwei Zustandswechsel vor, "Event erscheint" und "Event verschwindet".
Deshalb hätte ich einen Statuswechsel des DOIF auf cmd_2 erwartet.

Oder anders formuliert: Wenn eine Bedingung mit Eventangabe nur zum Zeitpunkt des zutreffenden Events wahr ist, müsste sie zu jedem anderen Zeitpunk unwahr sein und das DOIF müsste einen Zustandswechsel nach cmd_2 durchführen, bzw. "do always" implizieren.

Mir kommt dieses Verhalten intuitiver vor, deshalb hatte es erwähnt.

[Damian]

Mit "addStateEvent" hat meine Überlegung nichts zu tun.
Da habe ich mich unverständlich ausgerückt.

Mir ist bei dem DOIF mit einer Bedingung nur aufgefallen,  dass nicht automatisch in den  cmd_2 gewechselt wird, wenn die Bedingung unwahr wird.
Die Bedingung wird unwahr, sobald das Ereignis beendet ist, die Bedingung wird dann jedoch nicht erneut geprüft.

Bei einem Reading gibt es für jeden Zustandswechsel/-aktualisierung eine Prüfung der Bedingung.

Ein Event stelle ich mir als zwei Zustandswechsel vor, "Event erscheint" und "Event verschwindet".
Deshalb hätte ich einen Statuswechsel des DOIF auf cmd_2 erwartet.

Oder anders formuliert: Wenn eine Bedingung mit Eventangabe nur zum Zeitpunkt des zutreffenden Events wahr ist, müsste sie zu jedem anderen Zeitpunk unwahr sein und das DOIF müsste einen Zustandswechsel nach cmd_2 durchführen, bzw. "do always" implizieren.

Mir kommt dieses Verhalten intuitiver vor, deshalb hatte es erwähnt.

OK. Allerdings muss man an der Stelle weiter denken. Was soll dann passieren bei logischen Verknüpfungen, die ja den Schwerpunkt des Moduls ausmachen?

Beispiel:

([dev1:"event"] and [dev2:reading]) (...)

oder

([dev1:"event"] or [dev2:reading]) (...)

würdest du dann als User eine doppelte Triggerung (wahr/unwahr) erwarten, wenn event eintrifft? Damit würden sehr viele Definition sich nicht mehr so verhalten, wie die Benutzer es erwarten. Und es würde gegen den bisher eingehaltenen Grundsatz des Moduls verstoßen: "Eine Bedingung wird nur einmal ausgewertet, wenn ein dazugehöriger Trigger kommt und sonst nicht". Damit würden auch meine Beispiele nicht mehr so funktionieren, wie ich sie in der Commandoref formuliert habe. Z. B. der on-for-timer, der sich gut für einen Bewegungsmelder eignet. Damit dürften auch Befehlssequenzen nicht mehr funktionieren, usw.

Gruß

Damian

[Damian]

V 0.10 Unterstützt jetzt $SELF und cmd-Reading.

Beispiel:

Code Auswählen Erweitern

DOIF ([$SELF:cmd] == 1 and ...) (set ...)


im Reading cmd steht die Nummer des letzten Kommandos 1, 2, 3 usw. oder bei Sequenzen 1.1, 1.2, 1.3 usw., auf die man abfragen kann.

Gruß

Damian

[Ellert]

OK. Allerdings muss man an der Stelle weiter denken. Was soll dann passieren bei logischen Verknüpfungen, die ja den Schwerpunkt des Moduls ausmachen?

Beispiel:

([dev1:"event"] and [dev2:reading]) (...)

oder

([dev1:"event"] or [dev2:reading]) (...)

würdest du dann als User eine doppelte Triggerung (wahr/unwahr) erwarten, wenn event eintrifft? Damit würden sehr viele Definition sich nicht mehr so verhalten, wie die Benutzer es erwarten. Und es würde gegen den bisher eingehaltenen Grundsatz des Moduls verstoßen: "Eine Bedingung wird nur einmal ausgewertet, wenn ein dazugehöriger Trigger kommt und sonst nicht". Damit würden auch meine Beispiele nicht mehr so funktionieren, wie ich sie in der Commandoref formuliert habe. Z. B. der on-for-timer, der sich gut für einen Bewegungsmelder eignet. Damit dürften auch Befehlssequenzen nicht mehr funktionieren, usw.

Gruß

Damian

Ja, ich merke, dass meine Sicht recht eigenwillig ist und in das grundsätzliche Verhalten des DOIF nicht passt.

[Damian]

Ja, ich merke, dass meine Sicht recht eigenwillig ist und in das grundsätzliche Verhalten des DOIF nicht passt.

ja, das Problem ist einfach, dass der Zeitpunkt Event-Verschwindet nicht gleich Event-Erscheint sein kann -> zwei Trigger direkt hintereinander (würde auch einem wait nicht gut tun). Und jeder spätere Zeitpunkt für Event-Verschwindet ist nicht eindeutig definierbar.

Gruß

Damian

[Ellert]

V 0.10 Unterstützt jetzt $SELF und cmd-Reading.

Beispiel:

Code Auswählen Erweitern

DOIF ([$SELF:cmd] == 1 and ...) (set ...)


im Reading cmd steht die Nummer des letzten Kommandos 1, 2, 3 usw. oder bei Sequenzen 1.1, 1.2, 1.3 usw., auf die man abfragen kann.

Gruß

Damian

Gibt es einen besonderen Grund den Punkt zu benutzen und nicht wie bisher den Unterstrich?

In meinen DOIF benutze ich häufiger die Abfrage auf einen Zwischenstatus [di] eq "cmd_x_y", das müsste ich dann ändern in [di] eq "cmd_x.y"

Code Auswählen Erweitern

([du:state:d])
   (({Log 1, "Sequenz 1_1"}))
   (({Log 1, "Sequenz 1_2"}))
DOELSEIF (![du:state:d])
   (({Log 1, "Sequenz 2_1"}))
   (({Log 1, "Sequenz 2_2"}))


und den Attributen:

Code Auswählen Erweitern

wait 0,10:0,10
do always

die vom DOIF erzeugten Events sehen so aus:

2016.04.07 09:48:09 1: Sequenz 1_1
2016.04.07 09:48:09 1: Lauscher di: cmd_nr: 1
2016.04.07 09:48:09 1: Lauscher di: cmd_seqnr: 1
2016.04.07 09:48:09 1: Lauscher di: cmd: 1_1
2016.04.07 09:48:09 1: Lauscher di: cmd_event: du
2016.04.07 09:48:09 1: Lauscher di: cmd_1.1
2016.04.07 09:48:09 1: Lauscher di: wait_timer: 07.04.2016 09:48:19 cmd_1_2 du
2016.04.07 09:48:19 1: Lauscher di: wait_timer: no timer
2016.04.07 09:48:19 1: Sequenz 1_2
2016.04.07 09:48:19 1: Lauscher di: cmd_nr: 1
2016.04.07 09:48:19 1: Lauscher di: cmd_seqnr: 2
2016.04.07 09:48:19 1: Lauscher di: cmd: 1_2
2016.04.07 09:48:19 1: Lauscher di: cmd_event: du
2016.04.07 09:48:19 1: Lauscher di: cmd_1

Das DOIF nimmt einmal für state einen veränderten Zustand cmd_1.1, er war sonst cmd_1_1

Gemäß Deiner Beschreibung hätte ich folgendes erwartet:

2016.04.07 09:48:09 1: Lauscher di: cmd: 1.1
2016.04.07 09:48:09 1: Lauscher di: cmd_1_1

[Per]

im Reading cmd steht die Nummer des letzten Kommandos 1, 2, 3 usw. oder bei Sequenzen 1.1, 1.2, 1.3 usw., auf die man abfragen kann.

Immer, auch wenn cmdState verwendet wird?

[Damian]

Immer, auch wenn cmdState verwendet wird?

Klar, es muss ein Reading sein, auf das man sich immer verlassen kann. Das ist bei cmd_nr, cmd_seqnr, state nicht der Fall. Natürlich kann man mit $SELF auch jeden anderen Reading nutzen. $SELF wird einfach durch den eigenen Devicenamen ersetzt.

[Damian]

Gibt es einen besonderen Grund den Punkt zu benutzen und nicht wie bisher den Unterstrich?

In meinen DOIF benutze ich häufiger die Abfrage auf einen Zwischenstatus [di] eq "cmd_x_y", das müsste ich dann ändern in [di] eq "cmd_x.y"

Code Auswählen Erweitern

([du:state:d])
   (({Log 1, "Sequenz 1_1"}))
   (({Log 1, "Sequenz 1_2"}))
DOELSEIF (![du:state:d])
   (({Log 1, "Sequenz 2_1"}))
   (({Log 1, "Sequenz 2_2"}))


und den Attributen:

Code Auswählen Erweitern

wait 0,10:0,10
do always

die vom DOIF erzeugten Events sehen so aus:

Das DOIF nimmt einmal für state einen veränderten Zustand cmd_1.1, er war sonst cmd_1_1

Gemäß Deiner Beschreibung hätte ich folgendes erwartet:

cmd_1.1 wäre dann ein Fehler. Es muss natürlich cmd_1_1 bleiben.

cmd als Dezimalzahl auszulegen hatte den Hintergrund einfach mit == ohne Anführungszeichen den Zustand abzufragen - ist zwei Zeichen kürzer und für den Einen oder Anderen vielleicht etwas verständlicher als eq usw.

[Damian]

cmd_1.1 wäre dann ein Fehler. Es muss natürlich cmd_1_1 bleiben.

cmd als Dezimalzahl auszulegen hatte den Hintergrund einfach mit == ohne Anführungszeichen den Zustand abzufragen - ist zwei Zeichen kürzer und für den Einen oder Anderen vielleicht etwas verständlicher als eq usw.

Version 0.11

mit cmd 1.1 und state cmd_1_1, wie beschrieben. Doku muss ich noch anpassen.

[Ellert]

Ich habe die Kurzreferenz angepasst auf Grundlage der Version 0.11

[Damian]

Ich habe die Kurzreferenz angepasst auf Grundlage der Version 0.11

DE FHEM/98_DOIF.pm: Unbalanced ul (1, last line ok: 1894)

irgendwo fehlt ein <ul>