monitoring triggert nicht

Begonnen von dancatt, 29 Juli 2022, 10:24:30

Vorheriges Thema - Nächstes Thema

dancatt

Moin zusammen,

kann mir jemand erklären warum folgendes monitoring nicht triggert? Habe so einige im Einsatz und alle gehen.
Diesen hier bekomme ich nicht hin.

Im Eventlog steht folgendes:

2022-07-29 10:12:59 vitoconnect vitoconnect WW-Haupttemperatur 44
2022-07-29 10:13:57 vitoconnect vitoconnect WW-Haupttemperatur: 44


Log:

2022.07.29 09:59:38 4: monitoring (monitoring_Heizung_Warmwasser) triggered by "vitoconnect WW-Haupttemperatur: 44"
2022.07.29 09:59:38 5: monitoring (monitoring_Heizung_Warmwasser) errorFuncAdd and errorFuncRemove are preset
2022.07.29 09:59:38 2: monitoring (monitoring_Heizung_Warmwasser) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2022.07.29 09:59:38 5: monitoring (monitoring_Heizung_Warmwasser) warningFuncAdd and warningFuncRemove are preset
2022.07.29 10:11:34 4: monitoring (monitoring_Heizung_Warmwasser) triggered by "vitoconnect WW-Haupttemperatur: 45"
2022.07.29 10:11:34 5: monitoring (monitoring_Heizung_Warmwasser) errorFuncAdd and errorFuncRemove are preset
2022.07.29 10:11:34 2: monitoring (monitoring_Heizung_Warmwasser) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2022.07.29 10:11:34 5: monitoring (monitoring_Heizung_Warmwasser) warningFuncAdd and warningFuncRemove are preset
2022.07.29 10:12:41 3: monitoring (monitoring_Heizung_Warmwasser) set monitoring_Heizung_Warmwasser active
2022.07.29 10:12:59 4: monitoring (monitoring_Heizung_Warmwasser) triggered by "vitoconnect WW-Haupttemperatur 44"
2022.07.29 10:12:59 5: monitoring (monitoring_Heizung_Warmwasser) errorFuncAdd and errorFuncRemove are preset
2022.07.29 10:12:59 2: monitoring (monitoring_Heizung_Warmwasser) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2022.07.29 10:12:59 5: monitoring (monitoring_Heizung_Warmwasser) warningFuncAdd and warningFuncRemove are preset
2022.07.29 10:13:57 4: monitoring (monitoring_Heizung_Warmwasser) triggered by "vitoconnect WW-Haupttemperatur: 44"
2022.07.29 10:13:57 5: monitoring (monitoring_Heizung_Warmwasser) errorFuncAdd and errorFuncRemove are preset
2022.07.29 10:13:57 2: monitoring (monitoring_Heizung_Warmwasser) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2022.07.29 10:13:57 5: monitoring (monitoring_Heizung_Warmwasser) warningFuncAdd and warningFuncRemove are preset
2022.07.29 10:14:33 4: monitoring (monitoring_Heizung_Warmwasser) triggered by "global ATTR monitoring_Heizung_Warmwasser errorReturn {
my $wwSollTemp = ReadingsVal("vitoconnect", "WW-Haupttemperatur", 0);
telegramSendMessage("\@test", "Die Warmwasser Solltemperatur wurde angepasst auf: ".$wwSollTemp);
}"
2022.07.29 10:14:33 5: monitoring (monitoring_Heizung_Warmwasser) errorFuncAdd and errorFuncRemove are preset
2022.07.29 10:14:33 2: monitoring (monitoring_Heizung_Warmwasser) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2022.07.29 10:14:33 5: monitoring (monitoring_Heizung_Warmwasser) warningFuncAdd and warningFuncRemove are preset
2022.07.29 10:14:51 3: monitoring (monitoring_Heizung_Warmwasser) set monitoring_Heizung_Warmwasser active



defmod monitoring_Heizung_Warmwasser monitoring vitoconnect:WW-Haupttemperatur:.*
attr monitoring_Heizung_Warmwasser DbLogExclude .*
attr monitoring_Heizung_Warmwasser errorReturn {\
my $wwSollTemp = ReadingsVal("vitoconnect", "WW-Haupttemperatur", 0);;\
telegramSendMessage("\@test", "Die Warmwasser Solltemperatur wurde angepasst auf: ".$wwSollTemp);;\
}
attr monitoring_Heizung_Warmwasser event-on-change-reading .*
attr monitoring_Heizung_Warmwasser group Monitoring
attr monitoring_Heizung_Warmwasser room 9_00_System
attr monitoring_Heizung_Warmwasser verbose 5


Vielen Dank.

Gruß Daniel
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

Beta-User

Welche Version ist das?

Und kannst du ein list einstellen von dem monitoring?

Nach meinem Verständnis sollte eine errorWait-Zeit angegeben werden, bevor der errorReturn-Ausdruck ausgewertet wird; getriggert wird ja anscheinend, sonst würde nichts im log stehen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

dancatt

list:

Internals:
   .FhemMetaInternals 1
   DEF        vitoconnect:WW-Haupttemperatur:.*
   FUUID      62d66150-f33f-cf0a-c2d3-6db73770e36cba8e
   FVERSION   98_monitoring.pm:0.260480/2022-05-16
   NAME       monitoring_Heizung_Warmwasser
   NOTIFYDEV  global,vitoconnect
   NR         438
   NTFY_ORDER 50-monitoring_Heizung_Warmwasser
   STATE      active
   TYPE       monitoring
   .attreocr:
     .*
   .attrminint:
   READINGS:
     2022-07-29 10:14:51   state           active
   hmccu:
Attributes:
   DbLogExclude .*
   errorReturn {
my $wwSollTemp = ReadingsVal("vitoconnect", "WW-Haupttemperatur", 0);
telegramSendMessage("\@test", "Die Warmwasser Solltemperatur wurde angepasst auf: ".$wwSollTemp);
}
   event-on-change-reading .*
   group      Monitoring
   room       9_00_System
   verbose    5


Ein errorwait habe ich bei anderen auch nicht.

Version   0.260480
Release Date   2022-05-16
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

Beta-User

OK, also die aktuelle Version.

Habe jetzt mal eine Trockenübung dazu gemacht: Das Ding läuft an sich m.E. schon los, allerdings dauert es eine ganze Zeit, bis dann der error-Code tatsächlich ausgeführt wird (hier: etwas über 4 Minuten, warum ist mir noch nicht klar). Da bei dir mehr bzw. in kürzeren Abständen Events kommen, gehe ich davon aus, dass der Timer immer wieder resettet wird (was ja auch sinnvoll ist, das Tool ist dazu da, "tote" Devices zu überwachen bzw. eine Art generalisierten watchdog zu haben).

Was willst du eigentlich am Ende erreichen? Wenn es nur um eine simple Benachrichtigung bei Änderung der Temp geht, ist ein notify oder ein watchdog eventuell das bessere Werkzeug.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

dancatt

hmm. ok.
Habe einiges was mir nur Benachrichtigungen sendet. In dem vorliegenden Fall ist im device vitoconnect aber auch das Attribut "event-on-change-reading" gesetzt so dass eigentlich nur bei einer Änderung was kommen sollte.

Dann muss ich mir meine monitoring devices alle nochmal anschauen und eventuell in ein notify/doif überführen.
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

dancatt

Folgendes hätte dann aber auch ein Problem wenn man innerhalb dieser Zeit das Fenster mehr als einmal zu macht:


1_04_GT_Fensterkontakt:closed 1_04_GT_Fensterkontakt:open|tilted
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

Beta-User

Zitat von: dancatt am 29 Juli 2022, 11:57:27
Folgendes hätte dann aber auch ein Problem wenn man innerhalb dieser Zeit das Fenster mehr als einmal zu macht:


1_04_GT_Fensterkontakt:closed 1_04_GT_Fensterkontakt:open|tilted

Da kommt aber dazwischen doch immer wieder ein "offen" Event?
Und die Logik für das Fensterbeispiel in der commandref ist genau anders herum: Wenn länger offen, dann warn/error, wenn geschlossen: remove (alles im Butter)...

(Ich bin auch noch recht neu in dem Thema und habe "nur" den Code jüngst mal renoviert - hoffentlich aber ohne wesentliche Funktionsänderungen herbeizuführen. Von daher kann es durchaus sein, dass ich was übersehe!)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

dancatt

Zitat von: dancatt am 29 Juli 2022, 11:55:52
In dem vorliegenden Fall ist im device vitoconnect aber auch das Attribut "event-on-change-reading" gesetzt so dass eigentlich nur bei einer Änderung was kommen sollte.
Kannst du hierzu auch was sagen? Das Reading WW-Haupttemperatur sollte dann eigentlich nur sehr selten triggern. Also außerhalb dieser 4 Minuten
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

dancatt

Kann es vielleicht daran liegen dass ich nichts für <remove-event> definiert habe?
Wobei das ja optional ist.
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

Beta-User

Zitat von: dancatt am 29 Juli 2022, 12:25:39
Kannst du hierzu auch was sagen? Das Reading WW-Haupttemperatur sollte dann eigentlich nur sehr selten triggern. Also außerhalb dieser 4 Minuten
OK, das mit den 4 Minuten kam wohl daher, dass ich dann erst "get ... error" aufgerufen hatte.

Von alleine tut so ein monitoring "gar nichts", wenn man nicht warn/error-Zeiten angibt, und auch dann triggert es erst mal nur sich selbst, wenn man keine entsprechenden add/remove-Funktionen angibt.

Wenn also deine anderen monitoring sich (vermeintlich) so verhalten, wie das für dich paßt, musst du das m.E. etwas mehr im Detail ansehen, nur die define-Zeile ist definitiv zu wenig.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

dancatt

Folgendes funktioniert auch und hat keine Zeiten definiert und hat auch schon funktioniert. Am 17.05. zum letzten Mal


Internals:
   .FhemMetaInternals 1
   DEF        .*:motorErr:.communicationERR|ValveTight .*:motorErr:.ok
   FUUID      5c640b6f-f33f-cf0a-0615-33bb4e5b768e9700
   FVERSION   98_monitoring.pm:0.260480/2022-05-16
   NAME       monitoring_motorErr
   NR         326
   NTFY_ORDER 50-monitoring_motorErr
   STATE      active
   TYPE       monitoring
   .attreocr:
     .*
   .attrminint:
   READINGS:
     2022-05-17 14:01:43   allCount        0
     2022-05-17 14:01:43   error           
     2022-05-17 14:01:43   errorCount      0
     2022-07-26 17:42:01   state           active
     2019-02-22 12:32:57   warning         
     2019-02-22 12:32:57   warningCount    0
Attributes:
   DbLogExclude .*
   errorReturn {return unless(@errors);
$_ = AttrVal($_, "alias", $_) foreach(@errors);
return("Bei dem Gerät \"$errors[0]\" ist ein Motorproblem.") if(int(@errors) == 1);
@errors = sort {lc($a) cmp lc($b)} @errors;
return(join("\n - ", "Die folgenden ".@errors." Geräten haben ein Motorproblem:", @errors))
}
   event-on-change-reading .*
   group      Monitoring
   room       9_00_System
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

Beta-User

Hmmm, bedeutet?

Es funktioniert jetzt nicht mehr, oder es gab seitdem keine Fehler mehr?

Wenn es eine Änderung der Modulfunktionalität wäre, müßte eigentlich die Version von https://svn.fhem.de/trac/export/25912/trunk/fhem/FHEM/98_monitoring.pm noch so funktionieren, wie du das erwarten würdest.
Wenn es Abweichungen zwischen Erwartung und tatsächlichem Verhalten gibt, müßte ich mir das näher ansehen, aber zum einen wundert es mich dann, dass sich bisher (fast*) niemand gemeldet hat... Fast bedeutet: es gab einen bug-report zu der auf obige Version folgenden Änderung, der dann zu der letzten svn-Version geführt hat.

Nach meinem bisherigen Verständnis war es ursprünglich so, dass monitoring gar keine eigenen Aktionen ausgelöst hat. Dieses Prinzip hat dann eine Durchbrechung erhalten durch die Einführung der errorFuncAdded-etc. Funktionen. Das ist aber bei dir insgesamt nicht gesetzt, von daher sollte das monitoring selbst (ohne die Anfrage von extern auf das "get") eigentlich "nichts" machen...

Aber wie gesagt: Es ist nicht ausgeschlossen, dass ich was übersehe.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

dancatt

monitoring_motorErr hatte seitdem keine Fehler mehr.
Letzte Triggerung war am 17.05. und da hatte ich eine ältere Modulversion.
Ich werde mir nun alle monitoring devices anschauen.
Ich habe die Befürchtung dass die meisten nun nicht mehr gehen.
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

Beta-User

Hmmm, habe jetzt die letzte Version von igami ausgegraben und auf das von dir anscheinend erwartete Verhalten hin getestet: auch da passiert nichts automatisch. Der Code aus dem Attribut wird erst ausgeführt, wenn man ein "get" auslöst.

Vielleicht kann jemand anderes was dazu sagen, der das Modul auch in Gebrauch hat?

PS: für das "motor"-Error-Ding solltest du dir m.E. das "whitelist"-Attribut ansehen. Die Empfehlung wäre, das so zu setzen, das NOTIFYDEF (für die relevanten Geräte) gefüllt wird.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

dancatt

Ok. Hab "monitoring_Heizung_Warmwasser" mal umgebaut


Internals:
   .FhemMetaInternals 1
   DEF        vitoconnect:WW-Haupttemperatur:.*
   FUUID      62d66150-f33f-cf0a-c2d3-6db73770e36cba8e
   FVERSION   98_monitoring.pm:0.259120/2022-04-02
   NAME       monitoring_Heizung_Warmwasser
   NOTIFYDEV  vitoconnect,global
   NR         437
   NTFY_ORDER 50-monitoring_Heizung_Warmwasser
   STATE      error add: vitoconnect
   TYPE       monitoring
   eventCount 2
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   READINGS:
     2022-07-29 14:22:54   allCount        1
     2022-07-29 14:22:54   error           vitoconnect
     2022-07-29 14:22:54   errorCount      1
     2022-07-29 14:22:54   state           error add: vitoconnect
     2022-07-29 14:16:41   warning         
     2022-07-29 14:16:41   warningCount    0
   hmccu:
Attributes:
   DbLogExclude .*
   errorReturn {
return unless(@errors);
$_ = AttrVal($_, "alias", $_) foreach(@errors);
return("Bei dem Gerät \"$errors[0]\" wurde die WW-Haupttemperatur geändert.") if(int(@errors) == 1);
@errors = sort {lc($a) cmp lc($b)} @errors;
return(join("\n - ", "Die folgenden ".@errors." Geräten wurde die WW-Haupttemperatur geändert:", @errors))
}
   errorWait  1
   event-on-change-reading .*
   group      Monitoring
   room       9_00_System
   verbose    5


An anderer Stelle hab ich ein allgemeines DOIF für die monitoring-Dinger. Da habe ich folgendes dazugemacht:

####################################################
##vitoconnect WW-Haupttemperatur
DOELSEIF([monitoring_Heizung_Warmwasser:"error add"])
{
my $n = fhem("get monitoring_Heizung_Warmwasser default");
telegramSendMessage("\@test", $n);
}


Läuft mit der Version 0.259120/2022-04-02 und auch mit 260480/2022-05-16

Schau mir nächste Woche mal alle meine anderen monitoring Devices an.

Danke dir.
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55