Hallo an Alle,
gibt es bei doif die Möglichkeit auf Nachrichten im FHEM log zu triggern?
notify hat ein entsprechendes Attribut ,,readLog".
Daher meine Hoffnung dass das doif als Schweizer Taschenmesser ;-) da auch was bietet und ich das nur in der Fülle der Informationen übersehen habe.
VG und gut Nacht.
Zitat von: thotti70 am 31 März 2019, 22:33:20
Hallo an Alle,
gibt es bei doif die Möglichkeit auf Nachrichten im FHEM log zu triggern?
notify hat ein entsprechendes Attribut ,,readLog".
Daher meine Hoffnung dass das doif als Schweizer Taschenmesser ;-) da auch was bietet und ich das nur in der Fülle der Informationen übersehen habe.
VG und gut Nacht.
Du hast nichts übersehen, das kann DOIF bisher noch nicht.
Die Information für das Triggern auf Logeinträge wird über den FHEM-Server (fhem.pl) bereitgestellt.
Im Hash $logInform{<Gerätename>} wird eine Funktion hinterlegt, die bei einem Logeintrag aufgerufen wird.
In dieser Funktion kann der Benutzer seine Befehle einbauen.
Daher kann die Funktionalität schon jetzt im DOIF genutzt werden.
In dem Beispiel wird im init-Block die Funktion im Hash $::logInform{$SELF} unter dem Namen des DOIF registriert.
Bei einem Logeintrag wird das Reading informed_by_log mit dem Logeintrag beschrieben, hierauf könnte man triggern.
für Raw definition
defmod logTrigger DOIF init {\
$::logInform{$SELF} = sub($$){\
my ($me, $msg) = @_;;\
####################################\
##Perlcode, vom Benutzer festzulegen, z.B. Nachricht schreiben, Reading setzen usw.\
fhem("setreading $SELF informed_by_log +++$me+++***$msg***",1);;\
####################################\
return;;\
}\
}
Wenn das DOIF gelöscht wird, sollte die Funktion aus dem Hash gelöscht werden.
In der Befehlszeile mit {delete $logInform{<Gerätename>}}
Die Idee stammt aus der notify_Attr-Funktion der 91_notify.pm, derzeit ab Zeile 134.
ja, die Stelle habe ich mir gestern auch schon angeschaut. Man könnte die DOIF-Event-Syntax erweitern auf z. B.
[&LOG:"regex"]
da &LOG kein Device sein kann, wäre die Syntax eindeutig. Bei einer Übereinstimmung mit regex ist der Ausdruck wahr, sonst nicht und triggert auch nicht die Bedingung.
Auch die Filteroptionen für Events wären denkbar.
[&LOG:"regex":"<regex filter>":<output>,<default value>]
Damit würde wie bei Events der Ausdruck den gefilterten Wert zurückliefern (bzw. default value) und nicht nur wahr/falsch sein.
Hier mal eine weitere Möglichkeit. Zuerst das universelle logTrigger-Device definieren:
defmod logTrigger DOIF init {\
$::logInform{$SELF} = sub($$) {my ($me, $msg)=@_; fhem"setreading $SELF state $msg" if ($msg =~ ReadingsVal($me,"regex",""))}\
}
Im Reading regex von logTrigger wird die Regex für die zu triggernden Logeinträge festgelegt. Wird eine passende Nachricht gefunden, so wird sie mit einem Event im Status von logTrigger abgelegt. Auf diesen Status kann man dann im eigenen Modul reagieren.
Beispiel:
setreading logTrigger regex set lamp on
Abfrage im eigenen DOIF:
define mydoif DOIF ([logTrigger:state]) (set ....)
Der Vorteil dieser Lösung ist, dass nicht für alle Logeinträge Events produziert werden, sondern nur für die, auf die man triggern will.
Edit: Routine geändert.
Wenn das Beispiel in der Commandref steht, müsste es eigentlich ausreichend sein.
Lässt sich nicht per defmod einfügen. Meldung:
ZitatlogTrigger DOIF: Perlblck: no right bracket: {
$::logInform{logTrigger} = sub($$) {my ($me, $msg)=@_
Unknown command fhem"setreading, try help.
Zitat von: Invers am 24 Oktober 2020, 14:31:33
Lässt sich nicht per defmod einfügen. Meldung:
Du musst die Semikolons doppeln, wenn du nicht im Editor definierst.
Habe ich im Editor (das + in der Oberfäche) eingefügt.
Ich dachte, da muss man das nicht tun. Muss man aber doch. Geht nun. Danke.