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

[Per]

Ich pack es mal hier mit rein: kann ich $EVENT irgendwie formatieren? Also $EVENT:d geht schon mal nicht.

Und weil ich das Problem öfter habe und immer nur durch Probieren rausbekomme: wie wird zwischen ["device:event"] und ["device:reading"] mit beliebigen Event unterschieden? ["device:reading:"]?

Den Fall, dass ein Reading oder Event "d" haben soll, ist bei mir zumindest bisher nicht vorgekommen. Ich denke, dann muss man irgendwie maskieren. Oder "weiterzählen": ["device:reading:d:"]?

[Damian]

Ich pack es mal hier mit rein: kann ich $EVENT irgendwie formatieren? Also $EVENT:d geht schon mal nicht.

Und weil ich das Problem öfter habe und immer nur durch Probieren rausbekomme: wie wird zwischen ["device:event"] und ["device:reading"] mit beliebigen Event unterschieden? ["device:reading:"]?

Den Fall, dass ein Reading oder Event "d" haben soll, ist bei mir zumindest bisher nicht vorgekommen. Ich denke, dann muss man irgendwie maskieren. Oder "weiterzählen": ["device:reading:d:"]?

Du kannst mit dieser Syntax:

Code Auswählen Erweitern

["regex for trigger":"<regex filter>":<output>,<default value>]

Filter setzen.

Zitat aus der  Commanref:

Wenn kein Filter, wie obigen Beispiel, angegeben wird, so wird intern folgende Regex vorbelegt: "[^\*: (.*)" Damit wird der Wert hinter der Readingangabe genommen. Durch eigene Regex-Filter-Angaben kann man beliebige Teile des Events herausfiltern, ggf. über Output formatieren und in der Bedingung entsprechend auswerten, ohne auf Readings zurückgreifen zu müssen.

:d für Zahlen bei Events ist noch nicht realisiert, der passende Filter könnte so aussehen:

Code Auswählen Erweitern

"[^\:]*: (\d*)"

Das gilt allerdings nur für die DOIF-Bedingung, nicht für den Ausführungsteil.

[Per]

der passende Filter könnte so aussehen:

Code Auswählen Erweitern

"[^\:]*: (\d*)"

Kannst du mich (und bestimmt andere Nicht-Perler) abholen?
Beispiel: ... and $EVENT > 12
wo kommt dann dein Vorschlag rein? Und mit/ohne geschweifte Klammern?

nicht für den Ausführungsteil.

Lohnt da das warten?

[Damian]

Kannst du mich (und bestimmt andere Nicht-Perler) abholen?
Beispiel: ... and $EVENT > 12
wo kommt dann dein Vorschlag rein? Und mit/ohne geschweifte Klammern?
Lohnt da das warten?

z. B.:

Code Auswählen Erweitern

DOIF (["FS":"[^\:]*: (\d*)",0] > 12) (set bla {("$EVENT" =~ "[^\:]*: (\d*)";$1)})


Bei dieser Abfrage sollten keine Zahlen im Reading vorkommen, ansonsten müsste man die Abfrage noch weiter verfeinern.

Im Ausführungsteil wird mit Hilfe des Operators  =~ nach der Zahl per Perl gefiltert.

Edit: Zahlen im Reading sind unkritisch, da erst nach dem Doppelpunkt ausgewertet wird.

[Per]

Code Auswählen Erweitern

(set bla {("$EVENT" =~ "[^\:]*: (\d*)";$1)})

Irgendwie funktionierte nur

Code Auswählen Erweitern

(set bla {("$EVENT" =~ "[^\:]*: (.*)";$1)})
Zum Glück weiss ich nicht warum .

Edit: Zahlen im Reading sind unkritisch, da erst nach dem Doppelpunkt ausgewertet wird.

Du meinst hoffentlich im Reading-Namen.

[Damian]

Irgendwie funktionierte nur

Code Auswählen Erweitern

(set bla {("$EVENT" =~ "[^\:]*: (.*)";$1)})
Zum Glück weiss ich nicht warum .
Du meinst hoffentlich im Reading-Namen.

dann probiere mal:

Code Auswählen Erweitern

(set bla {("$EVENT" =~ "[^\:]*: (-?\d+(\.\d+)?)";$1)})

(-?\d+(\.\d+)?) entspricht dem Filter :d bei Readings.

[Per]

Dann steht der komplette Ausdruck

Code Auswählen Erweitern

"wert: 12" =~ "[^\:]*: (-?\d+(\.\d+)?)"
in "bla". Klammerwert durch .* ersetzt ergibt 12. Ich weiss, dass damit "nur" der Wert vom Readingnamen getrennt wird, würde mir in dem Fall aber erstmal reichen.

[Damian]

Dann steht der komplette Ausdruck

Code Auswählen Erweitern

"wert: 12" =~ "[^\:]*: (-?\d+(\.\d+)?)"
in "bla". Klammerwert durch .* ersetzt ergibt 12. Ich weiss, dass damit "nur" der Wert vom Readingnamen getrennt wird, würde mir in dem Fall aber erstmal reichen.

ohne $1 ist das nachvollziehbar.

Mit

Code Auswählen Erweitern

(set d_test {("bla: 12" =~ "[^\:]*: (.*)";$1)})

wird bei mir d_test mit 12 korrekt belegt.

[Per]

ohne $1 ist das nachvollziehbar.

Keine Angst, dass hatte ich drin. Im Code-Tag hatte ich das Ergebnis stehen.

[Damian]

OK. Jetzt aber:

Code Auswählen Erweitern

(set d_test {("bla: 12" =~ /[^\:]*: (-?\d+(\.\d+)?)/;$1)})

[Per]

Jap, das geht.





Keine Ahnung, warum.

[Damian]

Jap, das geht.





Keine Ahnung, warum.

Das ist halt Perl: \d  in Anführungszeichen ergibt in Perl d statt \d

[Per]

in Anführungszeichen ergibt in Perl ...

BTW: vllt. ist es hilfreich, in der CommandRef zu erwähnen, dass $_ (vllt. auch an anderer Stelle) in doppelten Anführungszeichen verwendet werden sollten. In den Beispielen ist es zwar auch so gemacht, aber z.B.

define di_Fenster DOIF (["^Window:open"]) {foreach (AggrDoIf('@','^windows','state','"open"')) {Log3 "di_Fenster",3,"Das Fenster $_ ist noch offen"}}

werden beide Varianten "bunt" durcheinander gemixt. Einem Perler ist der Grund vllt. ohne weiters erkennbar, mir nicht.

[Ellert]

Ein paar Perlkenntnisse schaden nie 

Variablen in doppelten Anführungszeichen werden aufgelöst, in einfachen Anführungszeichen nicht.

Die Variable $var habe den Wert ABC, dann ergibt

"$var Schütze" --> ABC Schütze
'$var Schütze' --> $var Schütze

Übrigens, reguläre Ausdrücke sind eine Beschreibungssprache für Zeichenkettenmengen, die unabhängig von Perl existiert, s. https://de.wikipedia.org/wiki/Regul%C3%A4rer_Ausdruck

[Per]

Ein paar Perlkenntnisse schaden nie 

Klar , aber immerhin liegt der "DOIF-Interpreter" drüber.

Variablen in doppelten Anführungszeichen werden aufgelöst, in einfachen Anführungszeichen nicht.

Die Variable $var habe den Wert ABC, dann ergibt

"$var Schütze" --> ABC Schütze
'$var Schütze' --> $var Schütze

Ist genau dann ein Problem, wenn:

Code Auswählen Erweitern

DOIF (["FS":"[^\:]*: (\d*)",0] > 12) (set bla {("$EVENT" =~ "[^\:]*: (\d*)";$1)})


doppelte hier nicht gehen, aber einfache oder Slashs eine Fehlermeldung

Code Auswählen Erweitern

DOIF: wrong filter Regex: /[^\:]*
im Editor erzeugen.