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
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.
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
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.
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.
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
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!)
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
Kann es vielleicht daran liegen dass ich nichts für <remove-event> definiert habe?
Wobei das ja optional ist.
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.
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
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.
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.
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.
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.
Thx für die Rückmeldung.
Wenn für die anderen monitoring in deinem DOIF auch "get"-Anweisungen drin waren, haben die dann jeweils die "sende mir was"-Anweisungen ausgelöst.
Insgesamt kommt mir die ganze Konstruktion aber weiter sehr kompliziert vor. Aus deinen Codeschnippseln würde ich folgendes ableiten:
- wenn direkt eine Änderung per messenger mitgeteilt werden soll, nimm ein notify (oder ein DOIF, wenn es sein muss), das genau das macht;
- wenn kurz gewartet werden soll (z.B. weil eine slider-Bewegung viele Events feuert, bis der Ziellevel erreicht wird, oder die Rückmeldung vom Gerät abgewartet werden soll): dto., aber mit watchdog;
- wenn du mehrere Devices überwachen willst, und dann eine zusammenfassende Statusmeldung abgesendet werden soll: nimm monitoring, aber definiere dann auch einfach eine errorAdded-Funktion, um die message zu versenden, einen weiteren Eventhandler braucht man dazu eigentlich nicht und kann vermutlich auch gleich das auslösende Device mitliefern.
Ansonsten kannst du auch mal einen Blick auf msgConfig und den Befehl msg iVm. RESIDENTS&Co. werfen. Perl-Code aufzurufen, um Statusmeldungen zu "verpushen" kommt mir überkompliziert vor...