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

[Loredo]

Hi Damian,


wollte mich jetzt auch mal versuchen:

Code Auswählen Erweitern


define di_rr_Julian_car2
(
   ["^rr_:^locationPresence$"] eq "absent" and
   [?$DEVICE:location] eq "BMW"
)
(
(msg push @$DEVICE |Parkplatz für [$DEVICE:location]| Das Auto wurde hier geparkt O[{"URLTITLE":"'In Google Maps öffnen'","ACTION":"'comgooglemapsurl://maps.google.com/?q=[$DEVICE:locationLat],[$DEVICE:locationLong]'","RETRY":0,"EXPIRE":0}])
)
DOELSE

attr di_rr_Julian_car2 do always
attr di_rr_Julian_car2 wait 300



Allerdings wird cmd_1 nie ausgelöst.
Im Reading e_regexp_c1 sehe ich aber, dass das passende Event eigentlich vorbeiläuft:

Code Auswählen Erweitern


rr_Julian:locationPresence: absent locationLat: 48.XXX locationLong: 11.XXX locationAddr: Strasse ABC PLZ Stadt location: BMW



Wo liegt denn hier der Fehler?




Gruß
Julian

[Damian]

Code Auswählen Erweitern


define di_rr_Julian_car2
(
   ["^rr_:^locationPresence$"] eq "absent" and
   [?$DEVICE:location] eq "BMW"
)


Event-Abfragen können nur wahr oder falsch sein und liefern keinen Wert eines Events selbst, du meinst wohl eher:

Code Auswählen Erweitern

...["^rr_:^locationPresence: absent"] and    [?$DEVICE:location] eq "BMW" ...


Gruß

Damian

[Damian]

Hallo Damian,

ich habe kleine Änderungen vorgenommen, Basis ist Version 0.5:
Da $device,$event und $events nur in den Bedingungen gültig sind, habe ich sie in der Kurzreferenz unter die Überschrift "Operanden in der Bedingung" verschoben.

Einmal "&" bei "nbsp;" ergänzt, bei der Überschrift "Filtern nach Zahlen".

Das Ende der Kurzreferenz markiert mit "<!-- Ende der Kurzreferenz -->"

Da es kein $EVTPART gibt, würdest Du ein Beispiel für sinnvoll halten, wie man es nachbilden kann?

Code Auswählen Erweitern

((set einDummy {(my @evt = split(" ","$EVENT");; return $evt[<Nummer des Eventparts>])}))

Gruss
Ellert

Ich habe auch noch ein paar Tippfehler gefunden. Zu den Variablen: Was ich noch nicht gesagt habe ist, dass man sie auch innerhalb einer Berechnung innerhalb eines FHEM-Befehls nutzen kann: set bla {($event/2)}, was z. Zt. nicht geht ist, diese Variablen innerhalb von reinen Perlsequenzen (set bla on, {irgendwas in Perl}) zu nutzen, da ich die Auswertung an eine fhem-Routine übergebe.

Die Frage ist ob $EVTPART so eine Bedeutung hat, wie beim notify, da man diese Informationen beim DOIF aussagekräftiger normalerweise als Reading mit [$DEVICE:reading] ansprechen kann. Wenn der Bedarf allerdings beim DOIF nach den $EVTPARTS gegeben sein wird, dann baue ich sie einfach ins Modul ein.

Gruß

Damian

[Ellert]

(set bla on, {irgendwas in Perl})

Ich hatte mit (({Log 1, "$event"})) getestet, ob die Variablen in der Bedingung gültig sind.

Jetzt ist klar, warum das nicht funktionierte.

Unter "Verzögerungen" gibt es einen kleinen Fehler, der ist in irgendeinem Thema aufgefallen:

DOELSE (Bedingung2)

Danke Ellert

[Damian]

Ich hatte mit (({Log 1, "$event"})) getestet, ob die Variablen in der Bedingung gültig sind.

Jetzt ist klar, warum das nicht funktionierte.

Unter "Verzögerungen" gibt es einen kleinen Fehler, der ist in irgendeinem Thema aufgefallen:

DOELSE (Bedingung2)

Danke Ellert

Ob die Variablen eine große Bedeutung haben werden, weiß ich noch nicht. Normalerweise reichen die Platzhalter in Großbuchstaben. Ich hielt es für reizvoll die Variablen in der Bedingung zu haben, weil diese ja in Perl ausgewertet wird und damit hat man alle Möglichkeiten der Abfragen in Perl, auch wenn ich bisher keinen echten Anwendungsfall gefunden habe, der nicht mit den anderen Mitteln möglich wäre - kommt bestimmt noch.

Gruß

Damian

[Loredo]

Event-Abfragen können nur wahr oder falsch sein und liefern keinen Wert eines Events selbst, du meinst wohl eher:

Code Auswählen Erweitern

...["^rr_:^locationPresence: absent"] and    [?$DEVICE:location] eq "BMW" ...

Ok, den Hinweis hab ich nicht berücksichtigt. Danke dafür!


Allerdings funktioniert es so trotzdem nicht, der Trigger wird nicht ausgelöst.

[Damian]

Ok, den Hinweis hab ich nicht berücksichtigt. Danke dafür!


Allerdings funktioniert es so trotzdem nicht, der Trigger wird nicht ausgelöst.

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

Gruß

Damian

[Ralli]

Hallo Damian,

folgendes Test-DOIF führt in Version 0.5 nicht zu dem erwünschten Verhalten:

Code Auswählen Erweitern


define DOIF_lowbat_WS1 DOIF (["WS.:temperature"] < 30) (setreading UEA.Batterie_niedrig $DEVICE low) DOELSEIF (["WS.:temperature"] > 40) (setreading UEA.Batterie_niedrig $DEVICE ok)


Denn der Dummy UEA.Batterie_niedrig bekommt folgendes Reading verpasst:

DOIF_lowbat_WS1 low 2016-01-26 07:10:04

und nicht richtigerweise

WS1 low 2016-01-26 07:10:04

Also wird als $DEVICE nicht das triggernde Device genommen sondern das getriggerte DOIF.

Wobei ich es grundsätzlich gut fände, wenn tatsächlich mit einer weiteren Variable wie $SELF o.ä. der Name des getriggerten DOIF (wie auch $CMD / $CMD_SEQ) mit im Ausführungsteil verwandt werden könnte .

[Damian]

Hallo Damian,

folgendes Test-DOIF führt in Version 0.5 nicht zu dem erwünschten Verhalten:

Code Auswählen Erweitern


define DOIF_lowbat_WS1 DOIF (["WS.:temperature"] < 30) (setreading UEA.Batterie_niedrig $DEVICE low) DOELSEIF (["WS.:temperature"] > 40) (setreading UEA.Batterie_niedrig $DEVICE ok)


Denn der Dummy UEA.Batterie_niedrig bekommt folgendes Reading verpasst:

DOIF_lowbat_WS1 low 2016-01-26 07:10:04

und nicht richtigerweise

WS1 low 2016-01-26 07:10:04

Also wird als $DEVICE nicht das triggernde Device genommen sondern das getriggerte DOIF.

Wobei ich es grundsätzlich gut fände, wenn tatsächlich mit einer weiteren Variable wie $SELF o.ä. der Name des getriggerten DOIF (wie auch $CMD / $CMD_SEQ) mit im Ausführungsteil verwandt werden könnte .

Mit der Angabe "WS.:  triggerst du auf alle Devices die WS beinhalten, du willst aber offensichtich Devices, die mit WS beginnen dann musst du "^WS:   für Device angeben. Das steht auch in der neuen Doku zum Modul.

Gruß

Damian

[Ralli]

Das ist so weit verstanden (gewesen). Ich habe aber nicht bedacht, dass dieses DOIF durch WS im eigenen Namen sich selbst triggern kann. Böse Falle.


Edit:

Klappt trotzdem nicht. Neue Definition:

Code Auswählen Erweitern


define DOIF_lowbat_WS1 DOIF (["^WS.:temperature"] < 30) (setreading UEA.Batterie_niedrig $DEVICE low) DOELSEIF (["^WS.:temperature"] > 40) (setreading UEA.Batterie_niedrig $DEVICE ok)


führt wieder zu gleichem Ergebnis, der Dummy UEA.Batterie_niedrig bekommt folgendes Reading verpasst:

DOIF_lowbat_WS1 low 2016-01-26 13:54:43

Der Event-Monitor brachte Folgendes:

2016-01-26 13:54:33 DOIF DOIF_lowbat_WS1 wait_timer: 26.01.2016 13:54:43 cmd_1 WS3
2016-01-26 13:54:33 CUL_WS WS3 T: 23.0  H: 0
2016-01-26 13:54:33 CUL_WS WS3 temperature: 23.0
2016-01-26 13:54:33 CUL_WS WS3 humidity: 0
2016-01-26 13:54:43 DOIF DOIF_lowbat_WS1 wait_timer: no timer
2016-01-26 13:54:43 dummy UEA.Batterie_niedrig DOIF_lowbat_WS1: low
2016-01-26 13:54:43 DOIF DOIF_lowbat_WS1 cmd_nr: 1
2016-01-26 13:54:43 DOIF DOIF_lowbat_WS1 cmd_event: WS3
2016-01-26 13:54:43 DOIF DOIF_lowbat_WS1 cmd_1

2. Edit:

Problem besteht in Zusammenhang mit dem Attribut wait, z.B. wait 10:0 . Damit ist das reproduzierbar. Lösche ich das Attribut, tritt das erwartete/erwünschte Verhalten ein.

[Ellert]

Also wird als $DEVICE nicht das triggernde Device genommen sondern das getriggerte DOIF.

Wenn eine Regexp ein Gerät und das DOIF matcht, wird das Reading "Device" und "e_regexp_c1" mit dem "falschen" Namen belegt.
$DEVICE ist mit  dem Namen des triggernden Gerätes belegt.

"du" ist ein Dummy der beim Setzen ein Event erzeugt. Ich führe ein "set du x42" aus.

Code Auswählen Erweitern

di DOIF (["^d.$:"]) (({Log 1, "\nDOIF di: DEVICE: $DEVICE, EVENT: $EVENT, EVENTS: $EVENTS"}))

Mit einem notify schreibe ich die Events des DOIF mit

Code Auswählen Erweitern

notify di {Log 1, "notify $NAME: $EVENT"}

Logeintrag:

2016.01.26 14:16:03 1: DOIF di: DEVICE: du, EVENT: x42, EVENTS: x42
2016.01.26 14:16:03 1: notify di: cmd_nr: 1
2016.01.26 14:16:03 1: notify di: cmd_event: du
2016.01.26 14:16:03 1: notify di: cmd_1
2016.01.26 14:16:03 1: notify di: Device: di
2016.01.26 14:16:03 1: notify di: e_regexp_c1: di:cmd_nr: 1 cmd_event: du cmd_1 Device: di

Müsste das Reading "Device" nicht auf "du" gesetzt werden?

[Damian]

Wenn eine Regexp ein Gerät und das DOIF matcht, wird das Reading "Device" und "e_regexp_c1" mit dem "falschen" Namen belegt.
$DEVICE ist mit  dem Namen des triggernden Gerätes belegt.

"du" ist ein Dummy der beim Setzen ein Event erzeugt. Ich führe ein "set du x42" aus.

Code Auswählen Erweitern

di DOIF (["^d.$:"]) (({Log 1, "\nDOIF di: DEVICE: $DEVICE, EVENT: $EVENT, EVENTS: $EVENTS"}))

Mit einem notify schreibe ich die Events des DOIF mit

Code Auswählen Erweitern

notify di {Log 1, "notify $NAME: $EVENT"}

Logeintrag:
Müsste das Reading "Device" nicht auf "du" gesetzt werden?

Das Device- und e_regexp-Reading wird ziemlich am Anfang in der Abarbeitung innerhalb des Moduls gesetzt. Durch die Regex-Angabe triggert sich das Modul selbst. Diese Rekursion wird neuerdings im Modul abgefangen, allerdings sind zu diesem Zeitpunkt die Readings bereits gesetzt.
Ich habe schon vorher überlegt das Reading Device komplett zu entfernen, da es jetzt für die Abfragen $DEVICE gibt.

Ich müsste schauen, ob ich im Modul bereits vor dem Setzen der Readings die Rekursion erkennen kann.

Gruß

Damian

[Damian]

Version 0.6 im ersten Post.

Diverse Korrekturen des Moduls und angepasste Doku.

Edit: In der Version 0.6 hat sich ein Initialisierungsfehler eingeschlichen - ist jetzt mit Version 0.7 behoben.

Gruß

Damian

[Per]

Ich habe schon etliche Schreibweisen probiert, die richtige war aber noch nicht dabei .
Ich habe div. Sensoren (HM) und will NUR den State auswerten (open oder closed), leider funken mir entweder andere Readings dazwischen oder es geht gar nicht:
   

Code Auswählen Erweitern

define DOIF ([".*\.Door$:^state$"] and [?$DEVICE] =~ "^open$|^closed$") (log $DEVICE $EVENT)

Wo ist mein dicker Denkfehler?

[Ellert]

Ich habe schon etliche Schreibweisen probiert, die richtige war aber noch nicht dabei .
Ich habe div. Sensoren (HM) und will NUR den State auswerten (open oder closed), leider funken mir entweder andere Readings dazwischen oder es geht gar nicht:
   

Code Auswählen Erweitern

define DOIF ([".*\.Door$:^state$"] and [?$DEVICE] =~ "^open$|^closed$") (log $DEVICE $EVENT)

Wo ist mein dicker Denkfehler?

Auf "state" kannst Du nicht ohne Weiteres triggern, s. http://fhem.de/commandref_DE.html#addStateEvent