Der Push mit Pushover funktioniert einwandfrei, leider wird er 3-4 Mal abgeschickt. Ich denke das liegt aber nicht am Pushover sondern am FHEM bzw. MAX Event.
Warum wird dieses mehrmals ausgelöst? Gibt es eine Möglichkeit das Event nur einmal abzuschicken? Kann man evtl. auf die Auslösezeit zugreifen, um eine Zeitsperre einzurichten?
Hier noch mein Config-Code:
define Tuer_closed notify MAX_073c07 { if ( Value("MAX_073c07") eq "closed") {fhem("set PushService msg 'Titel' 'Wohnungstür wurde geschlossen' '' 0 ''")} }
Wenn das Event öfter ausgelöst wird, obwohl sich der Zustand nicht ändert, könnte dir das Attribut "event-on-change-reading" vielleicht weiter helfen. Ein Event wird so nur noch bei einer Statusänderung ausgelöst.
Vielleicht gibt es aber auch eine Lösung damit dein Pushover nur ein mal gesendet wird. Dann wird auch wirklich das Problem und nicht nur das Symptom bekämpft. Da kann aber vielleicht jemand anderes weiter helfen.
Dein Push wird immer dann ausgeführt, wenn sich irgendwas an Deinem Device ändert. Dein notify ist einfach zu unspezifisch. Du willst doch eigentlich nur dann benachrichtigt werden, wenn ein closed passiert. Somit könntest Du das triggern direkt auf das closed begrenzen:
define Tuer_closed notify MAX_073c07.*:.*closed.*
Super! Vielen Dank an euch beide!
Es funktioniert aber ich habe noch nicht so recht verstanden wo der unterschied zwischen
.*:.*closed.*
und
{ if ( Value("MAX_073c07") eq "closed")
besteht :(
Nach was sollte ich hier mal in der Reference suchen?
Das stündliche Status Event des Fensterkontaktes kann ich damit sicher noch nicht umgehen?
Zitat von: nofear87 am 06 Februar 2014, 13:58:19
Das stündliche Status Event des Fensterkontaktes kann ich damit sicher noch nicht umgehen?
Wenn der Status sich nicht ändert, dann kannst du es über "attr XXX event-on-change-reading state" Events verhindern die den Status nicht verändern.
--> Erst wieder ein Event wenn der Status sich ändert
ZitatEs funktioniert aber ich habe noch nicht so recht verstanden wo der unterschied zwischen
Code: [Auswählen]
.*:.*closed.*
und
Code: [Auswählen]
{ if ( Value("MAX_073c07") eq "closed")
besteht :(
Nach was sollte ich hier mal in der Reference suchen?
Ersteres (siehe Betateilchens code) löst nur aus wenn der status sich auf "closed" ändert. Dein Versuch hat bei jeder Meldung des max (also auch battery oder "ich lebe noch" Meldung) das notify ausgelöst und im notify wird geprüft ob "closed" ist.
Betateilchens Variante ist btw auch gleich effizienter weil das notify nur bei Bedarf ausgelöst wird, das erzeugt auch weniger fhem Rechenlast. Minimal liese sich das nur noch durch
define Tuer_closed notify MAX_073c07:closed (etvl auch so notwendig: "define Tuer_closed notify MAX_073c07:\sclosed") optimieren, dann muss die regex engine noch weniger "denken".
Deine Frage "wo kann ichs nachschlagen": google Dich in regex ein, sind in fhem ein Kernkonzept.
vg
Jörg
Zitat von: siggi85 am 06 Februar 2014, 15:38:36
Wenn der Status sich nicht ändert, dann kannst du es über "attr XXX event-on-change-reading state" Events verhindern die den Status nicht verändern.
--> Erst wieder ein Event wenn der Status sich ändert
Danke! Werde ich mir anschauen, hört sich sinnvoll an!
Zitat von: herrmannj am 06 Februar 2014, 16:15:50
Ersteres (siehe Betateilchens code) löst nur aus wenn der status sich auf "closed" ändert. Dein Versuch hat bei jeder Meldung des max (also auch battery oder "ich lebe noch" Meldung) das notify ausgelöst und im notify wird geprüft ob "closed" ist.
Betateilchens Variante ist btw auch gleich effizienter weil das notify nur bei Bedarf ausgelöst wird, das erzeugt auch weniger fhem Rechenlast. Minimal liese sich das nur noch durch
define Tuer_closed notify MAX_073c07:closed (etvl auch so notwendig: "define Tuer_closed notify MAX_073c07:\sclosed") optimieren, dann muss die regex engine noch weniger "denken".
Deine Frage "wo kann ichs nachschlagen": google Dich in regex ein, sind in fhem ein Kernkonzept.
vg
Jörg
Was genau wird mit den regexp durchsucht? Die Readings?
yes:
devspec state oder devspec reading value je noch Form.
edith:
Wobei "durchsucht" mißverständlich ist / sein kann. Immer wenn ein Event erzeugt wird prüft die regex ob das (device + ...) event zur "seiner" Definition passt.
vg
Jörg
Danke Jörg!
define Balkontuer MAX ShutterContact 073d67
attr Balkontuer room Kueche
attr Balkontuer event-on-change-reading state
define Log_Balkontuer FileLog ./log/Balkontuer-%Y.log Balkontuer
attr Log_Balkontuer logtype text
attr Log_Balkontuer room Kueche
Ist es richtig, dass es reicht wenn ich die markierte Zeile hinzufüge, um stündliche Events zu unterbinden?
Wenn ich die Referenz richtig verstanden habe löst das Event jetzt nur noch aus wenn sich state in den Readings ändert?
Ich frage das ganze dann dennoch weiter mit notify ab?
Readings
battery ok 2014-02-07 19:09:59
onoff 0 2014-02-07 19:09:59
state closed 2014-02-07 19:09:59
Hi,
richtig, wenn Du auch die battery im "Auge" behalten willst musst Du das so abändern:
attr Balkontuer event-on-change-reading battery,state
Dann bekommst Du Events nur bei bei Änderung von battery & state, die Du mit notifies abarbeiten kannst...
MfGroby
Danke, habe ich getestet und es funktioniert wie gewünscht ;-)