Gelöst: DOIF und HTTPMOD

[olwaldi]

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?

Code Auswählen Erweitern

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

Code Auswählen Erweitern

Hka_Bd.bStoerung=([\w\.]+)
Müßte ich etwa einen numerischen Vergleich "! =" verwenden?

Ergebnislos getestet habe ich durch

Code Auswählen Erweitern

trigger Dachs Stoerung:1
Aber den event sieht der Eventlogger als

Code Auswählen Erweitern

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

[Damian]

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.

[olwaldi]

Habe an die Syntax mal ganz anders versucht, trotzdem gibts nach einem trigger-Versuch keine email.

Code Auswählen Erweitern

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.

[olwaldi]

Hier das list DachsAlarm

Code Auswählen Erweitern

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]

[MadMax-FHEM]

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):

Code Auswählen Erweitern


"qx(/etc/ssmtp/RaspiMail.sh "Dachs meldet Stoerung" xxx. yyyy\@gmx.de)"


Weil ich schätze, dass dort nur "root" rumfuhrwerken darf

Gruß, Joachim

[Otto123]

Hi,

notify 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

[olwaldi]

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.

[olwaldi]

Bin wieder zurück beim notify

Code Auswählen Erweitern

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

[olwaldi]

Und jetzt hat das Device Dachs neue Daten ohne Änderung, und es gibt keine email

Also, Problem gelöst durch

Code Auswählen Erweitern

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

[Damian]

Ich denke, du solltest mal die entsprechenden Events aus dem Eventmonitor posten, damit man das vermeintliche Fehlverhalten analysieren kann.

[Otto123]

Da Du einfach nur eine Mail schickst und Dich die Rückmeldung nicht interessiert, könntest Du den Ausführungsteil:

Code Auswählen Erweitern

{
  qx(/etc/ssmtp/RaspiMail.sh "Dachs meldet Stoerung"  xxx. yyyy\@gmx.de);
}komplett durch das ersetzen:

Code Auswählen Erweitern

"/etc/ssmtp/RaspiMail.sh 'Dachs meldet Stoerung'  xxx. yyyy\@gmx.de"

Vorteil: falls mit dem Mailscript was ist, würde FHEM nicht blockieren.