Hallo!
Ich möchte auf die Änderung eines Readings von HTTPMOD reagieren. notify triggert immer, wenn HTTPMOD die readings aktualisiert, also nicht nur bei einer Änderung. Daher verwende ich DOIF. Aber das scheint gar nicht zu triggern (mittels trigger versucht). Was mache ich falsch?
defmod DachsAlarm DOIF {\
if ([Dachs:Stoerung] ne "0") {\
qx(/etc/ssmtp/RaspiMail.sh "Dachs meldet Stoerung" xxxxx.yyyy\@gmx.de)\
}\
}
Die qx-Zeile funktioniert prima. Unklar ist die Bedingung. Stoerung ist ein Reading, das normalerweise auf 0 steht, gematched in HTTPMOD als
Hka_Bd.bStoerung=([\w\.]+)
Müßte ich etwa einen numerischen Vergleich "! =" verwenden?
Ergebnislos getestet habe ich durch
trigger Dachs Stoerung:1
Aber den event sieht der Eventlogger als
2021-10-25 11:31:36 HTTPMOD Dachs Stoerung:1
Aktuell ist DachsAlarm im Zustand initialized, im Device DachsAlarm selber stehen aber ??? bei probabely associated with.
Grüßle, Michael
Du hast ein DOIF im Perlmodus definiert. Dort ändert sich der Status nicht. Den muss der User selbst setzen. Poste ein list von deinem DOIF-Device, dann kann mehr dazu sagen.
Habe an die Syntax mal ganz anders versucht, trotzdem gibts nach einem trigger-Versuch keine email.
defmod DachsAlarm DOIF ([Dachs:Stoerung] !~ m/0/)\
(\
{\
qx(/etc/ssmtp/RaspiMail.sh "Dachs meldet Stoerung" xxx. yyyy\@gmx.de);;\
}\
)
Grüßle, Michael
PS: Der Unterschied zum pwrl-Mode ist mir gerade parallel zu Deinem post aufgefallen, daher meine Änderung.
Hier das list DachsAlarm
Internals:
DEF ([Dachs:Stoerung] !~ m/0/)
(
{
qx(/etc/ssmtp/RaspiMail.sh "Dachs meldet Stoerung" xxxx. yyyyy\@gmx.de);
}
)
FUUID 61766a38-f33f-6dde-c85f-94d88964685881ff
MODEL FHEM
NAME DachsAlarm
NOTIFYDEV Dachs,global
NR 52
NTFY_ORDER 50-DachsAlarm
STATE initialized
TYPE DOIF
VERSION 24905 2021-09-01 18:35:54
READINGS:
2021-10-26 09:41:33 cmd 0
2021-10-26 09:41:33 mode enabled
2021-10-26 09:41:33 state initialized
Regex:
accu:
collect:
cond:
Dachs:
0:
Stoerung ^Dachs$:^Stoerung:
condition:
0 ::ReadingValDoIf($hash,'Dachs','Stoerung') !~ m/0/
do:
0:
0 { qx(/etc/ssmtp/RaspiMail.sh "Dachs meldet Stoerung" xxx. yyy\@gmx.de); }
1:
helper:
DEVFILTER ^global$|^Dachs$
NOTIFYDEV global|Dachs
globalinit 1
last_timer 0
sleeptimer -1
readings:
all Dachs:Stoerung
uiState:
uiTable:
Attributes:/code]
Funktioniert das überhaupt: qx(/etc/ssmtp/RaspiMail.sh "Dachs meldet Stoerung" xxx. yyyy\@gmx.de)
Und zwar auch als User fhem?
Beispielsweise in FHEMWEB-cmd (inkl. Anführungszeichen):
"qx(/etc/ssmtp/RaspiMail.sh "Dachs meldet Stoerung" xxx. yyyy\@gmx.de)"
Weil ich schätze, dass dort nur "root" rumfuhrwerken darf ;)
Gruß, Joachim
Hi,
Zitatnotify triggert immer, wenn HTTPMOD die readings aktualisiert
mal attr ... event-on-change-reading gesetzt?
Wenn dein notify funktioniert wäre das die einfache Lösung.
Gruß Otto
Ja, das funktioniert so in einem notify bzgl. Batterie Checks. Und es hat auch genauso (ohne Semikolon) in einem notify getan, nur eben das notify hat dann 1x pro Stunde reagiert, nicht nur bei Änderung
Da das notify fast funktioniert hat, wäre ich auch damit zufrieden. Wäre da das Attribut event-on-change-reading das richtige? Ich probiers einfach mal aus...
Danke schonmal für die Hilfestellung, Michael
PS: Sorry, wieder ein Überlapp.
Bin wieder zurück beim notify
Internals:
CFGFN
DEF Dachs:Stoerung.[^0].* {
qx(/etc/ssmtp/RaspiMail.sh "Dachs meldet Stoerung" xxx. yyyy\@gmx.de);
}
FUUID 6177b52f-f33f-6dde-9d76-345f79e3f37b2b51
NAME DachsAlarm
NOTIFYDEV Dachs
NR 337
NTFY_ORDER 50-DachsAlarm
REGEXP Dachs:Stoerung.[^0].*
STATE 2021-10-26 10:03:18
TRIGGERTIME 1635235398.53296
TYPE notify
READINGS:
2021-10-26 10:02:47 state active
Attributes:
Und dem Dachs Device habe ich ein event-on-change-reading .* verpaßt. in der Hoffnung, dann nur bei Änderung informiert zu werden.
Ein trigger führt jetzt wieder zu einer email...
Grüßle, Michael
Und jetzt hat das Device Dachs neue Daten ohne Änderung, und es gibt keine email
Also, Problem gelöst durch
define DachsAlarm notify Dachs:Stoerung.[^0].* {
qx(/etc/ssmtp/RaspiMail.sh "Dachs meldet Stoerung" xxx. yyyy\@gmx.de);
}
und das Attribut event-on-change-reading .* am Dachs.
Danke, Michael
Ich denke, du solltest mal die entsprechenden Events aus dem Eventmonitor posten, damit man das vermeintliche Fehlverhalten analysieren kann.
Da Du einfach nur eine Mail schickst und Dich die Rückmeldung nicht interessiert, könntest Du den Ausführungsteil:
{
qx(/etc/ssmtp/RaspiMail.sh "Dachs meldet Stoerung" xxx. yyyy\@gmx.de);
}komplett durch das ersetzen:
"/etc/ssmtp/RaspiMail.sh 'Dachs meldet Stoerung' xxx. yyyy\@gmx.de"
Vorteil: falls mit dem Mailscript was ist, würde FHEM nicht blockieren.