DOIF neue Features: Generalisierung, $DEVICE, $EVENT, Attribut notexist

[Per]

Aha, danke.
Aber:

■ dieses Attribut muss beim Empfänger (notify, FileLog, etc) gesetzt werden.

Und gerade bei notify funktionierte es bisher ohne , ich wollte ja auf DOIF umstellen.
Leider kann ich gerade nicht nachschauen, kann DOIF addStateEvent?

[Loredo]

Poste mal list deines Moduls. Aktuelle Version V 0.5 hast du schon?

Habe die 0.5 installiert gehabt und gerade nochmal mit der 0.6 getestet (inkl. shutdown restart). Funktioniert leider nicht.


Ich habe mal das List in eine Textdatei kopiert, falls Zeilenumbrüche ö.ä. relevant werden.

[Damian]

Habe die 0.5 installiert gehabt und gerade nochmal mit der 0.6 getestet (inkl. shutdown restart). Funktioniert leider nicht.


Ich habe mal das List in eine Textdatei kopiert, falls Zeilenumbrüche ö.ä. relevant werden.

Code Auswählen Erweitern

2016-01-28 16:27:30   e_regexp_c1     rr_Julian:locationPresence: absent locationLat: xx.xxx locationLong: xx.xxxx locationAddr: Strasse 1A


Dein Event endet offenbar nicht mit "locationPresence", sondern mit "locationPresence: absent", deswegen kann es mit deiner Definition nicht funktionieren.

Deswegen solltest du eher:

Code Auswählen Erweitern

["^rr_:^locationPresence"]  oder ["^rr_:^locationPresence: absent"]

definieren.

Gruß

Damian

[Damian]

Version 0.8.

$EVENT bzw. $EVENTS wird jetzt mit "timer_<nr>" belegt, wenn der Trigger vom Timer kommt.

[Per]

kann DOIF addStateEvent?

Hat es nicht.
Aber - ich habe es hinbekommen:

Code Auswählen Erweitern

define DoorLog DOIF([".*\.Door$:^open$|^closed$"]) (log $DEVICE $EVENT)
mit attr DoorLog do always (wg. nur einem Zustand).
Ich könnte zwar schwören, dass ich das schon mal probiert habe, aber vllt. hatte ich da auch nen Tippfehler dabei. Oder das "do always" vergessen. Egal, jetzt geht es .

[Damian]

Version 0.9

1) Events werden jetzt in $EVENTS nicht mit Leerzeichen, sondern mit Komma getrennt dargestellt. Damit kann man einzelne Ereignisse eines Triggers besser auseinander halten.

2) Bisherige Angabe für Event-Trigger

Code Auswählen Erweitern

[<Device>:?<Regex für Event>] lässt sich jetzt auch wie folgt angeben 

Code Auswählen Erweitern

[<Device>:"<Regex für Event>"]
Damit wird zum Einen die neue Syntax (Regex in Anführungszeichen) vereinheitlicht zum Anderen ist das Fragezeichen an dieser Stelle immer etwas verwirrend gewesen, da es ja auch ein Fragezeichen für "nicht triggern" vor einem Device gibt. Die bisherige Syntax bleibt natürlich aus Kompatibilitätsgründen bestehen.

Gruß

Damian

[Damian]

Neue Version wurde eingecheckt.

Ab morgen per Update verfügbar.

Gruß

Damian

[Loredo]

Dein Event endet offenbar nicht mit "locationPresence", sondern mit "locationPresence: absent", deswegen kann es mit deiner Definition nicht funktionieren.

Hm, ok. Finde ich etwas verwirrend, dass das Regex auf einen langen state-ähnlichen String angewendet wird. Intuitiv hätte ich eher erwartet, dass pro Event das Regex ausgewertet wird und nicht zunächst aus allen Events ein langer String gebildet wird. Das ist definitiv ein großer Unterschied zu dem wie man ansonsten in FHEM mit Events umgeht. Hat das Performancegründe oder weshalb hast du dich dafür entschieden? Was hat es da mit der Trennung per , im Reading jetzt aufsich?

[Damian]

Hm, ok. Finde ich etwas verwirrend, dass das Regex auf einen langen state-ähnlichen String angewendet wird. Intuitiv hätte ich eher erwartet, dass pro Event das Regex ausgewertet wird und nicht zunächst aus allen Events ein langer String gebildet wird. Das ist definitiv ein großer Unterschied zu dem wie man ansonsten in FHEM mit Events umgeht. Hat das Performancegründe oder weshalb hast du dich dafür entschieden? Was hat es da mit der Trennung per , im Reading jetzt aufsich?

Es wird wie beim Notify jede Eventzeile einzeln ausgewertet. Alle Events eines Triggers werden nur zur Information in einer Zeile dargestellt.

Gruß

Damian

[Loredo]

Sehr gut, dann ist das doch so wie ich zunächst annahm.


Hatte mich zuerst gefragt weshalb ^locationPresence$ als Trigger nicht funktioniert. Mein Denkfehler war dabei, dass ich Reading und Value bei einem Event immer getrennt betrachte und es irgendwie nicht in meinen Schädel geht, dass das zusammen gehört...


Denke nun ist alles klar, danke

[Damian]

Sehr gut, dann ist das doch so wie ich zunächst annahm.


Hatte mich zuerst gefragt weshalb ^locationPresence$ als Trigger nicht funktioniert. Mein Denkfehler war dabei, dass ich Reading und Value bei einem Event immer getrennt betrachte und es irgendwie nicht in meinen Schädel geht, dass das zusammen gehört...


Denke nun ist alles klar, danke

Am besten nimmst du auch die aktuelle Version, die ich gestern eingecheckt habe. Ich habe noch an einigen Sachen gedreht.
Insbesondere heißt das neue Reading für die neue Regex-Syntax: "matched_event...", dort wird auch nur das Event angezeigt, was tatsächlich "gematched" hat.

Was man allerdings wissen sollte:

In einem Punkt unterscheidet sich funktionsbedingt die Vorgehensweise im Vergleich zu Notify. Im DOIF-Modul kann innerhalb eines Triggers höchstens nur eine Eventzeile "zutreffen" und nicht mehr.

Beispiel:

mit

Code Auswählen Erweitern

DOIF ([""]) ({Log 3, "$EVENT"}) wird man nicht alle Events loggen, sondern nur jeweils die erste Eventzeile eines Triggers.

mit

Code Auswählen Erweitern

DOIF ([""]) ({Log 3, "$EVENTS"}) werden dagegen alle Events dargestellt, allerdings pro Trigger alle in einer Zeile mit Komma getrennt.

Gruß

Damian

[Loredo]

Am besten nimmst du auch die aktuelle Version, die ich gestern eingecheckt habe. Ich habe noch an einigen Sachen gedreht.
Insbesondere heißt das neue Reading für die neue Regex-Syntax: "matched_event...", dort wird auch nur das Event angezeigt, was tatsächlich "gematched" hat.

Ja hab ich gesehen. Macht absolut Sinn und ist extrem benutzerfreundlich so 

Was man allerdings wissen sollte:

Ja das sind gute Hinweise. Einer wäre vermutlich noch, dass man nur einen einzigen Regex-Trigger gleichzeitig anwenden kann bzw. dass mehrere Regex-Trigger durch "and" verknüpft keinen Sinn machen, höchstens mit "or". Richtig?

[Damian]

Ja das sind gute Hinweise. Einer wäre vermutlich noch, dass man nur einen einzigen Regex-Trigger gleichzeitig anwenden kann bzw. dass mehrere Regex-Trigger durch "and" verknüpft keinen Sinn machen, höchstens mit "or". Richtig?

ja, im Normalfall ja, es sei denn beide Regex-Angaben finden jeweils einen Treffen innerhalb der Eventzeilen eines Triggers - das wird allerdings normalerweise weniger interessant sein.

[P.A.Trick]

Neue Version wurde eingecheckt.

Ab morgen per Update verfügbar.

Gruß

Damian

Bombe, vielen Dank dafür! Ich glaube nun haben wir alle Funktionen die benötigt werden! Danke Damian!

[Damian]

Bombe, vielen Dank dafür! Ich glaube nun haben wir alle Funktionen die benötigt werden! Danke Damian!

Noch nicht alle

Es sollen noch Datumsangaben hinzukommen z. B.  [2015-10-30 10:00] oder ähnlich.

Gruß

Damian