Das ganze ist nun ofiziell in FHEM eingecheckt.
Die git repository kann mit
update delete https://raw.githubusercontent.com/Igami/monitoring-fhem/master/controls_monitoring.txt wieder entfernt werden.
Einleitung:
Zitat
Jedes monitoring verfügt über eine warning- und eine error-Liste, welche als Readings gespeichert werden.
Beim auftreden eines definierten add-events wird das Gerät nach einer vorgegeben Zeit erst auf die warning-Liste gesetzt.
Nach einer weiteren vorgegeben Zeit wird das Gerät von der warning-Liste gelöscht und auf die error-Liste gesetzt.
Beim auftreten eines definierten remove-events wird das Gerät von beiden Listen gelöscht und noch laufende Timer abgebrochen.
Hiermit lassen sich auf einfache Weise Sammelmeldungen erstellen und durch zwei Attribute formatiert ausgeben.
Folgende Anwendungen sind möglich und werden unten beschrieben:
geöffnete Fenster
Batterie Warnungen
Activity Monitor
regelmäßige Wartungsarbeiten (z.B. Tischwasserfilter wechseln)
Betriebsstunden abhängige Wartungsarbeiten (z.B. Beamer Filter reinigen oder Räume putzen)
Das monitor sendet selbst keine Benachrichtung, hierfür ist ein notify oder DOIF notwendig, welches auf das Event "<monitoring-name> error add: <name>" reagiert und dann den Rückgabewert von "get <monitoring-name> default" versendet.
Die folgenden beispiel Codes können per "Raw defnition" importiert werden.
Globale, flexible Fenster-/Tür-Offen-Meldungen (ähnlich wie im Forum beschrieben)
defmod Fenster_monitoring monitoring .*:(open|tilted) .*:closed
attr Fenster_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Fenster \"$errors[0]\" ist schon länger geöffnet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Fenster sind schon länger geöffnet:", @errors))\
}
attr Fenster_monitoring errorWait {AttrVal($name, "winOpenTimer", 60*10)}
attr Fenster_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Fenster \"$warnings[0]\" ist seit kurzem geöffnet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Fenster sind seit kurzem geöffnet:", @warnings))\
}
Sobald ein Gerät ein "open" oder "tilded" Event auslöst wird das Gerät auf die warning-Liste gesetzt und es wird ein Timer gestartet nach dessen Ablauf das Gerät von der warning- auf die error-Liste verschoben wird. Die Wartezeit kann für jedes Gerät per userattr "winOpenTimer" festgelegt werden. Der Vorgabewert sind 10 Minuten.
Sobald ein Gerät ein "closed" Event auslöst wird das Gerät von beiden Listen gelöscht und noch laufende Timer werden gestoppt.
Batterieüberwachung
defmod Batterie_monitoring monitoring .*:battery:.low .*:battery:.ok
attr Batterie_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Bei dem Gerät \"$errors[0]\" muss die Batterie gewechselt werden.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten muss die Batterie gewechselt werden:", @errors))\
}
attr Batterie_monitoring errorWait 60*60*24*14
attr Batterie_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Bei dem Gerät \"$warnings[0]\" muss die Batterie demnächst gewechselt werden.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräten muss die Batterie demnächst gewechselt werden:", @warnings))\
}
Sobald ein Gerät ein "battery: low" Event auslöst wird das Gerät auf die warning-Liste gesetzt und es wird ein Timer gestartet nach dessen Ablauf das Gerät von der warning- auf die error-Liste verschoben wird. Die Wartezeit ist auf 14 Tage eingestellt.
Sobald ein Gerät ein "battery: ok" Event auslöst wird das Gerät von beiden Listen gelöscht und noch laufende Timer werden gestoppt.
Activity Monitor
defmod Activity_monitoring monitoring .*:.*
attr Activity_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))\
}
attr Activity_monitoring errorWait 60*60*24
attr Activity_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräten haben sich seit mehr als 12 Stunden nicht mehr gemeldet", @warnings))\
}
attr Activity_monitoring warningWait 60*60*12
Geräte werden erst überwacht, wenn sie mindestens ein Event ausgelöst haben. Sollte das Gerät in 12 Stunden kein weiterer Event auslösen, wird es auf die warning-Liste gesetzt. Sollte das Gerät in 24 Stunden kein weiteres Event auslösen, wird es von der warning- auf die error-Liste verschoben.
regelmäßige Wartungsarbeiten (z.B. Tischwasserfilter wechseln)
defmod Wasserfilter_monitoring monitoring Wasserfilter_DashButton:.*:.short
attr Wasserfilter_monitoring errorReturn {return unless(@errors);;\
return "Der Wasserfilter muss gewechselt werden.";;\
}
attr Wasserfilter_monitoring errorWait 60*60*24*30
attr Wasserfilter_monitoring warningReturn {return unless(@warnings);;\
return "Der Wasserfilter muss demnächst gewechselt werden.";;\
}
attr Wasserfilter_monitoring warningWait 60*60*24*25
Hierbei wird ein DashButton genutzt um FHEM mitzuteilen, dass der Wasserfilter gewechselt wurde. Nach 30 Tagen wird der DashButton auf die error-Liste gesetzt.
regelmäßige Wartungsarbeiten (z.B. Räume putzen)
defmod putzen_DashButton dash_dhcp
attr putzen_DashButton allowed AC:63:BE:2E:19:AF,AC:63:BE:49:23:48,AC:63:BE:49:5E:FD,50:F5:DA:93:2B:EE,AC:63:BE:B2:07:78
attr putzen_DashButton devAlias ac-63-be-2e-19-af:Badezimmer\
ac-63-be-49-23-48:Küche\
ac-63-be-49-5e-fd:Schlafzimmer\
50-f5-da-93-2b-ee:Arbeitszimmer\
ac-63-be-b2-07-78:Wohnzimmer
attr putzen_DashButton event-min-interval .*:5
attr putzen_DashButton port 6767
attr putzen_DashButton userReadings state {return (split(":", @{$hash->{CHANGED}}[0]))[0];;}
attr putzen_DashButton widgetOverride allowed:textField-long devAlias:textField-long
defmod putzen_monitoring monitoring putzen_DashButton:.*:.short
attr putzen_monitoring errorFuncAdd {$event =~ m/^(.+):/;;\
$name = $1;;\
return 1;;\
}
attr putzen_monitoring errorReturn {return unless(@errors);;\
return("Der Raum \"$errors[0]\" muss wieder geputzt werden.") if(int(@errors) == 1);;\
return(join("\n - ", "Die folgenden Räume müssen wieder geputzt werden:", @errors))\
}
attr putzen_monitoring errorWait 60*60*24*7
Hierbei werden mehrere DashButton genutzt um FHEM mitzuteilen, dass die Räume geputzt wurden.
Nach 7 Tagen wird der Raum auf die error-Liste gesetzt.
Der Raum Name ist hierbei jedoch nicht der Geräte-Name, sondern der Readings-Name und wird in dem errorFuncAdd-Attribut geändert.
Betriebsstunden abhängige Wartungsarbeiten (z.B. Beamer Filter reinigen)
defmod BeamerFilter_monitoring monitoring Beamer_HourCounter:pulseTimeOverall BeamerFilter_DashButton:.*:.short
attr BeamerFilter_monitoring userattr errorInterval
attr BeamerFilter_monitoring errorFuncAdd {return 1\
if(ReadingsVal($name, "pulseTimeOverall", 0) >= \
ReadingsVal($name, "pulseTimeService", 0)\
+ (AttrVal($SELF, "errorInterval", 0))\
&& $addMatch\
);;\
return;;\
}
attr BeamerFilter_monitoring errorFuncRemove {return unless($removeMatch);;\
fhem(\
"setreading $name pulseTimeService "\
.ReadingsVal($name, "pulseTimeOverall", 0)\
);;\
return 1;;\
}
attr BeamerFilter_monitoring errorInterval 60*60*200
attr BeamerFilter_monitoring errorReturn {return unless(@errors);;\
return "Der Filter vom Beamer muss gereinigt werden.";;\
}
attr BeamerFilter_monitoring warningFuncAdd {return}
attr BeamerFilter_monitoring warningFuncRemove {return}
Hierbei wird ein HourCounter genutzt um die Betriebsstunden eine Beamer zu erfassen und ein DashButton um FHEM mitzuteilen, dass der Filter gereinigt wurde.
Wurde der Filter länger als 200 Betriebsstunden nicht gereinigt wird das Gerät auf die error-Liste gesetzt. Wurde die Reinigung mit dem DashButton quittiert wird das Gerät von der error-Liste entfernt und der aktuelle Betriebsstunden-Stand in dem HourCounter Gerät gespeichert.
Schon 11 Mal runtergeladen und noch kein Feedback? ;)
12mal... ;)
Ich muß aber zugeben, ich habe es erstmal runtergeladen, um die commandref zu lesen und zu sehen, was das Modul überhaupt macht. Vielleicht solltest Du mal ein Anwendungsbeispiel hier posten.
Zitat von: mahowi am 10 März 2017, 20:48:24
Ich muß aber zugeben, ich habe es erstmal runtergeladen, um die commandref zu lesen und zu sehen, was das Modul überhaupt macht. Vielleicht solltest Du mal ein Anwendungsbeispiel hier posten.
Habe die Anwendugsbeispiele aus der commandref in den ersten Beitrag gepackt.
Hallo igami,
auch ich habe mir das gestern mal geladen und heute Morgen mal eingebaut.
Als erstes Beispiel habe ich direkt die Fensterüberwachung genommen, das hat schon mal einwandfrei geklappt und läuft ohne Fehler.
Wenn ich am Wochenende die Zeit finde, werde ich mal schauen wie ich das verwenden kann und in meine Umgebung einbauen kann. Mir fällt da spontan die Benachrichtigungen per Jabber ein, sobald verschiedene Bedingungen (Anwesenheit, Temperatur,...) gegeben sind. Dazu muss ich mir das aber mal genauer ansehen.
Gruß, Thomas
Zitat von: ThomasMagnum am 11 März 2017, 07:45:10
Mir fällt da spontan die Benachrichtigungen per Jabber ein, sobald verschiedene Bedingungen (Anwesenheit, Temperatur,...) gegeben sind. Dazu muss ich mir das aber mal genauer ansehen.
Ich habe ein DOIF das inetwa so aussieht:
defmod ServiceNotifications_DI DOIF ([16:30-21:00|8]\
&& ( [":^error add:"]\
|| [$SELF:cmd_nr] == 2\
)\
)(\
set TelegramBot message {(fhem("get TYPE=monitoring default"))}\
)\
DOELSEIF\
([":^error add:"])
attr ServiceNotifications_DI cmdState send notifications|notifications pending
attr ServiceNotifications_DI cmdpause 60*15
attr ServiceNotifications_DI do always
attr ServiceNotifications_DI icon time_automatic
attr ServiceNotifications_DI wait 60*15
Trifft ein "error add:" event ein wird 15 Minuten gewartet, dann bekomme ich eine Nachricht mit allen Sammelmeldungen. Passiert das außerhalb des Zeitraums wird es in die Warteschlange gepackt.
Neue Version im ersten Beitrag:
# changelog ###################################################################
# 170311:
# - Fehler in der commandref behoben
# - Versionsnummer eingebaut
# - Logging erweitert
# - Verhalten für Definitionen ohne remove-event mit non-preset Funktionen
# verbessert
# - monitoring_Get verbessert
# 170312: im Forum veroeffentlicht
Es ist auch ein neues Beispiel dazugekommen wie man Readings-Namen anstelle von Geräte-Namen auf die Liste setzen kann. Ich selbst nutze das im zusmamenhang mit dash_dhcp und Unifi da dort ein define mehrere Geräte als Readings beinhaltet.
Gibt es mittlerweile FeedBack? ;D
Hallo igami,
ich hatte ja geschrieben das ich mich nochmal mit einem kleinen Feedback zum Modul melde, das möchte ich hiermit gerne tun.
Wie geschrieben, habe ich das Modul mal testweise in mein FHEM eingebaut und "spiele" mal mit der Fensterbenachrichtigung rum. Über ein kleines DOIF lass ich mir, sobald ein Gerät in den "error" Status gelangt, eine kurze Nachricht per Jabber zusenden. Das klappt bei einem meiner Fenstersensoren (HM) auch, andere hingegen werden zwar in den Status "warning" gesetzt, nicht aber in den Status "error". Selbst wenn ich Verbose auf 5 setze steht zur entsprechenden Zeit nichts im Eventlog.
Da ich allerdings einen "." im Namen habe und hier schon mehrfach gelesen habe das es damit immer wieder mal Probleme gibt vermute ich den Sensor als Ursache. Komisch ist nur, dass der funktinierende Sensor ebenfalls einen "." im Namen hat.
Bei Gelegenheit werde ich die Namensgebung deshalb mal überdenken und ändern.
Ansonsten vielen Dank für das Modul, da steckt in meinen Augen jede Menge an Potential drin.
Gruß, Thomas
Hallo igami,
ich habe es mal ausprobiert und ich muss sagen, dass ich von dem Potenzial was drin steckt begeistert bin.
Ich habe schon Pläne, was ich damit machen werde.
Eine Anregung hätte ich schon: Schön wäre es, wenn der Übergang vom Warning- zum Error-Status (errorWait, warningWait) nicht nur eine Zeitangabe sondern auch EVENT-gesteuert möglich wäre. Z.B. Fenster-auf wird ERROR wenn die Temperatur im Raum unter einen bestimmten Wert fällt. Ideal wäre es, wenn man eine Bedingung wie in DOIF angeben könnte.
Etwa so: attr Fenster_monitoring errorWait ($DEVICE:measured_temp < 16)
Gruß
Dieter
Habe das ganze nun mal auf Github gestellt.
Repository hinzufügen:
update add https://raw.githubusercontent.com/Igami/monitoring-fhem/master/controls_monitoring.txt
danach sollte das Modul per "update" aktualisiert werden.
CHANGED:
- bugfix: 98_monitoring.pm: monitoring_Set, monitoring_modify
Zitat von: ThomasMagnum am 15 März 2017, 09:25:23
Wie geschrieben, habe ich das Modul mal testweise in mein FHEM eingebaut und "spiele" mal mit der Fensterbenachrichtigung rum. Über ein kleines DOIF lass ich mir, sobald ein Gerät in den "error" Status gelangt, eine kurze Nachricht per Jabber zusenden. Das klappt bei einem meiner Fenstersensoren (HM) auch, andere hingegen werden zwar in den Status "warning" gesetzt, nicht aber in den Status "error". Selbst wenn ich Verbose auf 5 setze steht zur entsprechenden Zeit nichts im Eventlog.
Da ich allerdings einen "." im Namen habe und hier schon mehrfach gelesen habe das es damit immer wieder mal Probleme gibt vermute ich den Sensor als Ursache. Komisch ist nur, dass der funktinierende Sensor ebenfalls einen "." im Namen hat.
Es kann sein, dass es mit dem update von heute schon funktioniert. Da war noch ein Fehler drin.
Zitat von: dieter56 am 15 März 2017, 12:29:50
Ich habe schon Pläne, was ich damit machen werde.
An was denkst du denn so?
Zitat von: dieter56 am 15 März 2017, 12:29:50
Eine Anregung hätte ich schon: Schön wäre es, wenn der Übergang vom Warning- zum Error-Status (errorWait, warningWait) nicht nur eine Zeitangabe sondern auch EVENT-gesteuert möglich wäre. Z.B. Fenster-auf wird ERROR wenn die Temperatur im Raum unter einen bestimmten Wert fällt. Ideal wäre es, wenn man eine Bedingung wie in DOIF angeben könnte.
Wie würdest du denn die Zuordnung Fenster/Temperatursensor lösen?
Man könnte es andersrum lösen, man macht ein Monitoring für Temperatursensoren und in der errorFuncAdd prüft man ob im Raum ein Fenster geöffnet ist
defmod temperature_monitoring monitoring .+:temperature:.+
attr temperature_monitoring errorFuncAdd {my $room = AttrVal($name, "room", "Unsorted");;\
$room =~ s/ /./g;;\
$room =~ s/,/|/g;;\
\
return unless(\
ReadingsVal($name, "temperature", 0) <= 16 \
&& devspec2array("room=.*".$room.".*:FILTER=state=(open|tilted)")\
);;\
return 1;;\
}
attr temperature_monitoring errorFuncRemove {my $room = AttrVal($name, "room", "Unsorted");;\
$room =~ s/ /./g;;\
$room =~ s/,/|/g;;\
\
return unless(\
ReadingsVal($name, "temperature", 0) <= 16 \
|| devspec2array("room=.*".$room.".*:FILTER=state=(open|tilted)")\
);;\
return 1;;\
}
Guten Morgen igami,
hab dein Update erst gesehen nachdem ich gestern Abend meine Namen geändert habe, macht aber nichts, da ich das eh bereinigen wollte.
Auf alle Fälle hat nach der Änderung und dem Update auf die neue Version alles so funktioniert wie erwartet - Vielen Dank!
Jetzt schau ich mal was damit alles umgesetzt werden kann. Das erste wird eine Batterieüberwachung sein, dann kommen Wartungsarbeiten rund ums Haus dran. Dank deiner Beispiele ist die dahinter stehende Logik ja sehr gut dokumentiert bzw. nachzuvollziehen.
Gruß, Thomas
Zitat von: ThomasMagnum am 16 März 2017, 08:18:14
hab dein Update erst gesehen nachdem ich gestern Abend meine Namen geändert habe, macht aber nichts, da ich das eh bereinigen wollte.
Auf alle Fälle hat nach der Änderung und dem Update auf die neue Version alles so funktioniert wie erwartet - Vielen Dank!
Also klappt das mit dem update so ja schonmal, da bin ich beruhigt :)
Zitat von: ThomasMagnum am 16 März 2017, 08:18:14
Jetzt schau ich mal was damit alles umgesetzt werden kann. Das erste wird eine Batterieüberwachung sein, dann kommen Wartungsarbeiten rund ums Haus dran. Dank deiner Beispiele ist die dahinter stehende Logik ja sehr gut dokumentiert bzw. nachzuvollziehen.
Ich hoffe ja, dass ich das so universell gehalten habe, dass sich alles damit abdecken lässt. So viele verschiedene Arten gibt es meiner Meinung nach gar nicht.
Eine englische Commandref habe ich nun auch hinzugefügt und die deutsche ist nun auch als deutsche commandref vorhanden.
Gibt es noch weiteres Feedback zum Modul? Besonders interessiert mich ob irgendetwas nicht funktioniert. Ich würde das dann gerne in FHEM einchecken.
Bitte das git repository aus den update Quellen entfernen, das Modul ist nun ofiziell in FHEM eingecheckt.
Hallo igami
grade per zufall gelesen,klingt gut und muss ich mal testen bei Gelegenheit !
danke für die Mühe
kvo1
Hi Igami,
falls du noch Feedback brauchst: Schönes Modul, macht soweit ich das bisher testen konnte, was es soll und erspart viele notifies, dummies, watchdogs und myUtils-Routinen. Eine Kleinigkeit ist mir noch aufgefallen: Wenn ich Geräte auf die blacklist setze, bleiben diese erstmal im errorAdd, warningAdd bzw. error und warning reading stehen... Ich nehme an, sie werden morgen verschwinden, aber schön wäre wenn man die gleich nach setzen des Attributes rauswerfen könnte... Frage hierzu auch noch: Akzeptiert die blacklist <devspecs>? Also: Kann ich bei einem global activity monitor z.B. "TYPE=DOIF" blacklisten? (Nicht, dass ein globaler activity Monitor aus meiner Sicht Sinn machen würde - aber mir ist gerade kein besseres Beispiel eingefallen ;-))
Danke,
Grüße,
Oli
Zitat von: KernSani am 26 März 2017, 23:59:07
Schönes Modul, macht soweit ich das bisher testen konnte, was es soll und erspart viele notifies, dummies, watchdogs und myUtils-Routinen.
Das freut mich, genau dafür war es ja auch gedacht :)
Zitat von: KernSani am 26 März 2017, 23:59:07
Eine Kleinigkeit ist mir noch aufgefallen: Wenn ich Geräte auf die blacklist setze, bleiben diese erstmal im errorAdd, warningAdd bzw. error und warning reading stehen... Ich nehme an, sie werden morgen verschwinden, aber schön wäre wenn man die gleich nach setzen des Attributes rauswerfen könnte... Frage hierzu auch noch: Akzeptiert die blacklist <devspecs>? Also: Kann ich bei einem global activity monitor z.B. "TYPE=DOIF" blacklisten?
bisher akzeptiert blacklist nur eine regex für den Gerätenamen, ich werde mir aber noch mal Gedanken dazu machen, dass man regex oder devspec angeben kann.
Auch dass, die Geräte dann sofort aus der Beobachtung rausgenommen werden sollte nicht so schwer umzusetzten sein
Zitat von: KernSani am 26 März 2017, 23:59:07
(Nicht, dass ein globaler activity Monitor aus meiner Sicht Sinn machen würde - aber mir ist gerade kein besseres Beispiel eingefallen ;-))
Das habe ich auch schon festgestellt, nachdem ich Benachrichtigungen bzgl. ReadingsGroups bekommen habe :D
Momentan wird hier renoviert, aber ich denke, dass ich die Änderungen im Lauf der Woche einchecken kann.
So, ich habe mal das "Batterieüberwachung" - Beispiel aktiviert, werde dann berichten!
Danke nochmal für das Modul !
Zitat von: igami am 27 März 2017, 06:30:56
Momentan wird hier renoviert, aber ich denke, dass ich die Änderungen im Lauf der Woche einchecken kann.
Ach, ist doch schon eingecheckt, man darf ja keinen Krach machen, wenn die anderen Frühstücken :D
Vielleicht baue ich auch noch ein whiteList attribut ein.
Zitat von: kvo1 am 27 März 2017, 08:27:18
So, ich habe mal das "Batterieüberwachung" - Beispiel aktiviert, werde dann berichten!
Hast du das per "Raw definition" gemacht? Falls ja, funktionert das gut?
Falls sich andere Werte als in den Beispielen angegeben als Sinnvoll erweisen bitte bescheid geben, so ausgiebig habe ich das selbst noch nicht getestet ;)
ZitatHast du das per "Raw definition" gemacht? Falls ja, funktionert das gut?
hmmm, wie meinst Du das ?
Zitat von: kvo1 am 27 März 2017, 11:58:39
hmmm, wie meinst Du das ?
Da ist ein Link direkt am Anfang der Beispiele sektion
Zitat
Die folgenden beispiel Codes können per "Raw defnition" importiert werden. (https://wiki.fhem.de/wiki/Import_von_Code_Snippets)
Hallo igami,
ich experimentiere gerade mit deinem Modul allerdings komme ich mit dem blacklist Attribut nicht so ganz klar.
Egal ob ich (bsp. 1)
DOIF notify readingsGroup MQTT_DEVICE:FILTER=NAME=mqtt_speedtest
oder (bsp. 2)
TYPE=DOIF TYPE=notify etc.
auf die blacklist packe, es werden trotzdem DOIF's gelistet die sich seit mehr als 12 bzw. 24h nicht gemeldet haben.
Auch ist mir nicht ganz klar, wie einzelne Devices zusätzlich auf die blacklist zu nehmen sind wenn bereits einige Devices über devspec ausgeschlossen wurden (daher der Versuch mit dem Filter im ersten Beispiel).
Hast Du einen Tipp wie blacklist korrekt zu nutzen ist?
Danke Sven
Zitat von: hoods am 06 April 2017, 16:40:59
ich experimentiere gerade mit deinem Modul allerdings komme ich mit dem blacklist Attribut nicht so ganz klar.
Egal ob ich (bsp. 1)
DOIF notify readingsGroup MQTT_DEVICE:FILTER=NAME=mqtt_speedtest
oder (bsp. 2)
TYPE=DOIF TYPE=notify etc.
auf die blacklist packe, es werden trotzdem DOIF's gelistet die sich seit mehr als 12 bzw. 24h nicht gemeldet haben.
hast du die aktuelle Version? Bitte mal mit "version monitoring" prüfen. Es sollte "98_monitoring.pm 13814 2017-03-27 06:52:13Z igami" sein.
Zitat von: hoods am 06 April 2017, 16:40:59
Auch ist mir nicht ganz klar, wie einzelne Devices zusätzlich auf die blacklist zu nehmen sind wenn bereits einige Devices über devspec ausgeschlossen wurden (daher der Versuch mit dem Filter im ersten Beispiel).
Hast Du einen Tipp wie blacklist korrekt zu nutzen ist?
nehmen wir an es sollen alle DOIF und das device globa ausgeschlossen werden, dann wäre das Attribut so zu befüllen:
TYPE=DOIF global
Ich habe es gerade eben bei mir noch mit dummy probiert und es wird soweit korrekt ausgewertet
Danke für die super schnelle Antwort.
Version -> 98_monitoring.pm 13814 2017-03-27 06:52:13Z igami
1. blacklist aktualisiert:
TYPE=DOIF TYPE=notify TYPE=readingsGroup global hmusb hm
2. set Activity_monitoring clear all
Fehlt noch was? Ich bin gespannt was mir Telegram nachher schickt. Ich melde mich, sobald ich Neuigkeiten habe.
Gruss Sven
Zitat von: hoods am 06 April 2017, 17:37:15
2. set Activity_monitoring clear all
Das sollte unnötig sein. Wenn das blacklist Attribut gesetzt wird werden alle Einträge auf den Listen gelöscht die davon betroffen sind.
Zitat von: igami am 27 März 2017, 08:55:36
Vielleicht baue ich auch noch ein whiteList attribut ein.
gesagt, getan :)
Ab morgen per update verfügbar
Zitat von: igami am 06 April 2017, 17:44:55
Zitat von: hoods am 06 April 2017, 17:37:15
2. set Activity_monitoring clear all
Das sollte unnötig sein. Wenn das blacklist Attribut gesetzt wird werden alle Einträge auf den Listen gelöscht die davon betroffen sind.
Okay, habe grad festgestellt, dass ja die Device die noch wartend in dem Modul stehen nicht gelöscht werden, also ist es doch Sinnvoll
mein monitoring sieht nun übrigens so aus:
defmod Activity_monitoring monitoring .*:.*
attr Activity_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))\
}
attr Activity_monitoring errorWait 60*60*24
attr Activity_monitoring icon it_television
attr Activity_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräten haben sich seit mehr als 12 Stunden nicht mehr gemeldet:", @warnings))\
}
attr Activity_monitoring warningWait 60*60*12
attr Activity_monitoring whitelist i:TYPE=AMAD:FILTER=i:BRIDGE!=1 \
i:TYPE=CUL_HM:FILTER=i:channel_01!=.+:FILTER=a:model!=(ActionDetector|CCU-FHEM) \
i:TYPE=HTTPMOD \
i:TYPE=HUEDevice:FILTER=i:type=.*light.*\
i:TYPE=Nmap\
i:TYPE=PRESENCE\
i:TYPE=PROPLANTA\
i:TYPE=SYSMON\
i:TYPE=TRX_WEATHER\
i:TYPE=Weather\
Wenn ich mir jetzt eine Push Nachricht schicken lassen möchte, dann muss ich das im Attribut errorReturn (Perl Code) machen? Wird die dann nur einmalig verschickt wenn der Fehler neu in die Fehlerliste aufgenommen wird?
Was macht man mit errorFuncAdd? Kannst du das vielleicht kurz an einem Beispiel erklären?
Hintergrund: Ich würde das Ding gern einsetzen, um dein Batterie Beispiel zu nehmen, möchte mir aber nach 1 Woche im Warning Status (switch zu error) eine Push Nachricht schicken lassen. Weiterhin würde ich damit gern die Benachrichtigung für das Blumen giessen umsetzen. Das würde mir diverse Notify und Watchdog Anweisungen ersparen...
Zitat von: mumpitzstuff am 13 April 2017, 15:38:37
Wenn ich mir jetzt eine Push Nachricht schicken lassen möchte, dann muss ich das im Attribut errorReturn (Perl Code) machen? Wird die dann nur einmalig verschickt wenn der Fehler neu in die Fehlerliste aufgenommen wird?
errorReturn ist dafür da um die Nachricht zu formatieren, das Modul selbst sendet nicht, sondern sammelt nur. Ich lasse mir immer eine Nachricht schicken, wenn ich seit 15 Minuten zu hause bin
defmod rr_MichaelPrange_monitoring_notification DOIF ([rr_MichaelPrange:presence] eq "present")(\
set TelegramBot message @12345678 \
{(fhem("get TYPE=monitoring:FILTER=msgPeerId=.*12345678.* default"))}\
\n/heimdall\
)\
DOELSE
attr rr_MichaelPrange_monitoring_notification wait 60*15
Zitat von: mumpitzstuff am 13 April 2017, 15:38:37
Was macht man mit errorFuncAdd? Kannst du das vielleicht kurz an einem Beispiel erklären?
Steht in der commandref ;)
Zitat
errorFuncAdd {<perl code>}
In dieser Funktion stehen die folgende Variablen zur Verfügung:
$name
Name des Event auslösenden Gerätes
$event
Beinhaltet das komplette Event, z.B. measured-temp: 21.7 (Celsius)
$addMatch
Hat den Wert 1, falls das add-event zutrifft
$removeMatch
Hat den Wert 1, falls das remove-event zutrifft
$SELF
Eigenname des monitoring
Gibt die Funktion eine 1 zurück, wird das Gerät, nach der Wartezeit, auf die error-Liste gesetzt.
Wenn das Attribut nicht gesetzt ist wird auf $addMatch geprüft.
Beispiele für die Anwendung stehen ebenfalls in der commandref und zwar "regelmäßige Wartungsarbeiten (z.B. Räume putzen)" und "Betriebsstunden abhängige Wartungsarbeiten (z.B. Beamer Filter reinigen)"
Zitat von: mumpitzstuff am 13 April 2017, 15:38:37
Hintergrund: Ich würde das Ding gern einsetzen, um dein Batterie Beispiel zu nehmen, möchte mir aber nach 1 Woche im Warning Status (switch zu error) eine Push Nachricht schicken lassen. Weiterhin würde ich damit gern die Benachrichtigung für das Blumen giessen umsetzen. Das würde mir diverse Notify und Watchdog Anweisungen ersparen...
Zum senden brauchst du noch einen weiteren helper (notify, DOIF, watchdog, at, ...). Die Wartezeit kannst du ja nach deinen Wünschen anpassen, im Beispiel sind es 14 Tage, du möchtest 7.
Für das Blumen giessen kannst du dich an dem Räume putzen Beispiel orientieren, du musst dich nur entscheiden womit du das gießen quittierst, ich nutze da gerne DashButtons.
Falls du noch Fragen hast einfach schreiben, wenn möglich wo genau du Probleme hast. Ich bemühe mich immer die commandref so verständlich wie möglich zu halten.
Das mit der Funktion stimmt, ist mir in den relativ großen Beispielen irgendwie unter gegangen.
Ich hatte gehofft direkt beim Übergang eines Gerätes entweder von normal nach warning oder von warning nach error eine Art Action hinterlegen könnte. Das Zurücksetzen würde übrigens entweder durch den Wechsel der Batterie bzw. das Gießen der Blumen erfolgen, weil dann die Feuchtigkeit wieder über das WarningLevel steigt. Ich hoffe ich Fine nach Ostern etwas Zeit zum Experimentieren.
@igami:
keine Ahnung ob es ein Problem ist oder ein bereits gelöstes Problem. Ich hatte eine ältere monitoring Version am Laufen und habe gestern ein Device (global activity monitor gelöscht). Heute morgen hatte ich haufenweise folgende Meldung im Log:
2017.04.13 10:59:58 1: ERROR: empty name in readingsBeginUpdate
2017.04.13 10:59:58 1: stacktrace:
2017.04.13 10:59:58 1: main::readingsBeginUpdate called by ./FHEM/98_monitoring.pm (404)
2017.04.13 10:59:58 1: main::monitoring_modify called by fhem.pl (2918)
2017.04.13 10:59:58 1: main::HandleTimeout called by fhem.pl (613)
Nach einem update und shutdown/restart tritt es nicht mehr auf. Ich frage mich nur, ob beim delete irgendwelche internalTimer nicht ordentlich aufgeräumt werden...
Zitat von: mumpitzstuff am 13 April 2017, 23:24:22
Das mit der Funktion stimmt, ist mir in den relativ großen Beispielen irgendwie unter gegangen.
Ich hatte gehofft direkt beim Übergang eines Gerätes entweder von normal nach warning oder von warning nach error eine Art Action hinterlegen könnte. Das Zurücksetzen würde übrigens entweder durch den Wechsel der Batterie bzw. das Gießen der Blumen erfolgen, weil dann die Feuchtigkeit wieder über das WarningLevel steigt. Ich hoffe ich Fine nach Ostern etwas Zeit zum Experimentieren.
Man könnte so eine Funktion einbauen, aber ich finde die Möglichkeiten die DOIF bietet (wait und die Abfrage auf andere Zustände wie presence) besser. Bei uns in der Firma bekommen wir z.B. nur Benachrichtigungen während der Arbeitszeit und auch nur maximal alle Viertelstunde. Das hatte ich hier mal geschrieben:
Zitat von: igami am 11 März 2017, 08:18:33
Ich habe ein DOIF das inetwa so aussieht:
defmod ServiceNotifications_DI DOIF ([16:30-21:00|8]\
&& ( [":^error add:"]\
|| [$SELF:cmd_nr] == 2\
)\
)(\
set TelegramBot message {(fhem("get TYPE=monitoring default"))}\
)\
DOELSEIF\
([":^error add:"])
attr ServiceNotifications_DI cmdState send notifications|notifications pending
attr ServiceNotifications_DI cmdpause 60*15
attr ServiceNotifications_DI do always
attr ServiceNotifications_DI icon time_automatic
attr ServiceNotifications_DI wait 60*15
Trifft ein "error add:" event ein wird 15 Minuten gewartet, dann bekomme ich eine Nachricht mit allen Sammelmeldungen. Passiert das außerhalb des Zeitraums wird es in die Warteschlange gepackt.
Zitat von: KernSani am 14 April 2017, 00:17:56
@igami:
keine Ahnung ob es ein Problem ist oder ein bereits gelöstes Problem. Ich hatte eine ältere monitoring Version am Laufen und habe gestern ein Device (global activity monitor gelöscht). Heute morgen hatte ich haufenweise folgende Meldung im Log:
2017.04.13 10:59:58 1: ERROR: empty name in readingsBeginUpdate
2017.04.13 10:59:58 1: stacktrace:
2017.04.13 10:59:58 1: main::readingsBeginUpdate called by ./FHEM/98_monitoring.pm (404)
2017.04.13 10:59:58 1: main::monitoring_modify called by fhem.pl (2918)
2017.04.13 10:59:58 1: main::HandleTimeout called by fhem.pl (613)
Nach einem update und shutdown/restart tritt es nicht mehr auf. Ich frage mich nur, ob beim delete irgendwelche internalTimer nicht ordentlich aufgeräumt werden...
Tatsächlich werden die Timer nicht gelöscht und die aufgerufene Funktion überprüft auch nicht ob es das monitoring noch gibt. Werde ich bei gelegenheit einbauen.
Hallo igami,
ich habe angeblich 50 Geräte die sich 24h nicht gemeldet haben und 14 Geräte die sich länger als 12h nicht gemeldet haben. Stichproben über zumindest 8 Devices zeigen, dass die Readings aktuell sind. Beispiel Selbstbau-Wassermelder:
Readings:
2017-04-16 22:01:38 Wasseralarm no
2017-04-16 22:01:38 battery ok
2017-04-16 21:02:01 state T: 20.8
2017-04-16 22:00:50 temperature 20.8
2017-04-16 22:01:38 temperature2 -30.9
Für die Definition des Monitors habe ich dein Beispiel genutzt:
defmod Activity_monitoring monitoring .*:.*
attr Activity_monitoring blacklist TYPE=DOIF TYPE=notify TYPE=readingsGroup global hmusb hm
attr Activity_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräte haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))\
}
attr Activity_monitoring errorWait 60*60*24
attr Activity_monitoring room 5_System,99_Labor
attr Activity_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräte haben sich seit mehr als 12 Stunden nicht mehr gemeldet:", @warnings))\
}
attr Activity_monitoring warningWait 60*60*12
Wie kann ich weiter eingrenzen warum die Devices auf der Error und Warning Liste landen?
Desweiteren habe ich in der Error Liste Devices, die kürzlich neu angelegt wurden und direkt danach umbenannt wurden. Ein Beispiel ist DUOFERN_49B111. Dieses Devices gibt es nicht mehr, da es mit rename in Rollo_WZ_L umbenannt wurde. Leider sind beide Devices auf der Error Liste obwohl es das erste Device gar nicht mehr gibt.
Wie kann ich das bereinigen?
Danke & Gruss,
Sven
Zitat von: hoods am 16 April 2017, 22:12:19
Wie kann ich weiter eingrenzen warum die Devices auf der Error und Warning Liste landen?
erzeugen die devices auch events?
Zitat von: hoods am 16 April 2017, 22:12:19
Desweiteren habe ich in der Error Liste Devices, die kürzlich neu angelegt wurden und direkt danach umbenannt wurden. Ein Beispiel ist DUOFERN_49B111. Dieses Devices gibt es nicht mehr, da es mit rename in Rollo_WZ_L umbenannt wurde. Leider sind beide Devices auf der Error Liste obwohl es das erste Device gar nicht mehr gibt.
Wie kann ich das bereinigen?
Einfach mit errorRemove von der Liste nehmen.
Das Beispiel ist irgendwie noch nicht ganz ausgereift. Mittlerweile gibt es auch ein whitelist Attribut: https://forum.fhem.de/index.php/topic,68765.msg617790.html#msg617790
Zitatclear (warning|error|all)
Removes all devices from the specified list and aborts timers for this list. With "all", all devices are removed from both lists and all running timers are aborted.
Werden die internen Timer wirklich gelöscht?
Ich war irritiert, weil drei Stunden nach einem clear all schon wieder Geräte in der Errorliste auftauchten, obwohl das frühestens nach 25 Stunden passieren soll.
Also habe ich mir mal die internen Timer angesehen und da stehen jede Menge Timer von monitoring_modify drin - jedenfalls wesentlich mehr als in den Readings des monitoring-Moduls...
Zitaterzeugen die devices auch events?
Ich denke doch, folgende Parameter sind gesetzt und ich erhalte im Logfile auch entsprechende Einträge.
attr Wasserwaechter_Bad event-min-interval .*:600
attr Wasserwaechter_Bad event-on-change-reading temperature,temperature2,batteryWerde mal mit errorRemove und warningRemove die unerwünschten Devices von den Listen nehmen. Mal schauen ob Sie anschliessend wieder erscheinen.
Gruss Sven
Zitat von: Brockmann am 18 April 2017, 12:20:22
Werden die internen Timer wirklich gelöscht?
Ich war irritiert, weil drei Stunden nach einem clear all schon wieder Geräte in der Errorliste auftauchten, obwohl das frühestens nach 25 Stunden passieren soll.
Also habe ich mir mal die internen Timer angesehen und da stehen jede Menge Timer von monitoring_modify drin - jedenfalls wesentlich mehr als in den Readings des monitoring-Moduls...
Tatsächlich werden die timer nicht gelöscht, sondern nur die Readings. Ich werde mal zusehen, dass ich es diese Woche noch schaffe ein Update für das Modul zu schreiben.
Aber es freut mich, dass das Modul genutzt wird :)
So, Timer werden nun tatsächlich gelöscht und auch beim neustart wiederhergestellt, da fehlte auch noch eine Zeile ::)
Ist gleich mit dem Update um 8 Uhr verfügbar.
Cool. Funktioniert das nach Neustart dann auch bei verwaisten timern? (Habe gerade die Nachricht bekommen, dass global dich seit 24h nicht gemeldet hat ;-))
Beim Neustart werden aus den readings wieder timer gemacht. Liegt der Zeitpunkt in der Vergangenheit wird das gerät sofort auf die Liste gesetzt. Nur dass die timer neu gestartet werden hatte ich vergessen einzubauen.
Wo ich das gerade schreibe fällt mir auf, dass es dadurch dazu kommen kann, dass das Gerät auf beiden listen landet. Das ändere ich noch zu morgen
Hallo igami,
ich bin gerade auf Dein Modul gestoßen und hoffe, dass es hoffentlich das ist was ich gesucht habe ;)
Ich verwende momentan das "inoffizielle" Modul "DeviceMonitor" aus dem contrib-Verzeichnis. Dieses wird leider nicht mehr gepflegt/supportet und ich würde es gern ablösen! Falls Du es nicht kennst, es es überwacht auch Devices aber nur auf "alive" oder "dead", jedoch fügt es diesen Status direkt dem Device hinzu.
Nun meine Frage: kann man das auch mit Deinem "Monitoring"-Modul erreichen? Ist dafür beispielsweise das Attribut "errorFuncAdd" verwendbar? Also wenn ein ein Device sich nach einiger Zeit nicht mehr meldet, dann setze bei dem Device bspw. ein Userreading "Activity" mit dem Wert "dead"?
VG und danke schonmal für Deine Antwort...
Ja, das sollte machbar sein. Ich mache mir heute abend mal Gedanken dazu wie man das erweitern kann.
Soll die Zeit für alle devices gleich sein oder per Attribut einstellbar?
Hi, das klingt super!
Also beim DeviceMonitor läuft das so: Nachdem das Modul installiert ist, kann man bei jedem Device das Attribut "device_timeout" auswählen und einen Wert in Sekunden eintragen. Damit weiß der DeviceMonitor auf welche Geräte er "aufpassen soll" und listet alle überwachten Geräte in seinen Readings auf.
Nach dem erstmaligen Event eines überwachten Devices, setzt der DeviceMonitor dann beim Gerät das Reading "Activity" auf "alive".
Erzeugt das Gerät nicht innerhalb der eingestellten "device_timeout" ein Event, wird "Activity" auf "dead" gesetzt. Die "toten" Geräte werden dann auch noch extra unter dem DeviceMonitor selbst aufgelistet.
VG...
Gucken wir uns dazu mal das Beispiel aus der Commandref an;
Zitat
defmod Activity_monitoring monitoring .*:.*
attr Activity_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))\
}
attr Activity_monitoring errorWait 60*60*24
attr Activity_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräten haben sich seit mehr als 12 Stunden nicht mehr gemeldet:", @warnings))\
}
attr Activity_monitoring warningWait 60*60*12
Geräte werden erst überwacht, wenn sie mindestens ein Event ausgelöst haben. Sollte das Gerät in 12 Stunden kein weiterer Event auslösen, wird es auf die warning-Liste gesetzt. Sollte das Gerät in 24 Stunden kein weiteres Event auslösen, wird es von der warning- auf die error-Liste verschoben.
Dabei ändern wir das errorWait Attribut auf {ReadingsVal($name, "device_timeout", 0)} und ergänzen das monitoring um das Attribut whitelist device_timeout=.+
Um den das Reading Activity auf dead or alive zu setzen wird noch ein notify benötigt.
Zusammengefasst haben wir dann folgendens (ungetestet):
defmod DeviceMonitor monitoring .*:.*
attr DeviceMonitor errorReturn {return unless(@errors);;\
\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
\
return("Das Gerät \"$errors[0]\" scheint nicht mehr aktiv zu sein.")\
if(int(@errors) == 1);;\
\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
\
return(join("\n - ", "Die folgenden ".@errors." Geräten scheinen nicht mehr aktiv zu sein:", @errors))\\
}
attr DeviceMonitor errorWait {AttrVal($name, "device_timeout", 0)}
attr DeviceMonitor whitelist device_timeout=.+
defmod DeviceMonitorSetActivity notify DeviceMonitor:error.(add|remove):..+ {\
$EVENT =~ m/error (add|remove): (.+)/;;\
\
readingsSingleUpdate(\
$defs{$2}, "Activity", $1 eq "add" ? "dead" : "alive", 0\
);;\
\
return;;\
}
Hi und Danke, das scheint schonmal zu klappen!
Ich Versuch das mal weiter zu Stricken.
Wenn ich das in einem DOIF abbilden will, scheitere ich aber momentan noch den DeviceNamen richtig rauszufiltern. Ich bleib dran...
Gesendet von iPhone mit Tapatalk
Was willst du mit dem DOIF machen?
Bei meinem jetzigen DeviceMonitor-Modul setze ich das setzen der Readings und die Benachrichtigungen in einem DOIF-Modul um. Klar kann man es auch mit dem Notify machen. Ich seh es für mich auch als kleine Herausforderung...
Gesendet von iPhone mit Tapatalk
Und woran scheiterst du?
Ich hatte heute nur 15 min Zeit um Dein Notify zu testen und auch mal das DOIF anzupassen. Es scheitert vorerst daran aus dem Event nur den Devicenamen rauszuziehen für die weitereVrrarbeitung im DOIF. Also bspw. In der Pushnachricht nicht "error add Devicename" sondern eben nur "Devicename" zu schicken oder eben um ein Userreading beim entsprechenden Device setzen zu können.
Gesendet von iPhone mit Tapatalk
Also ich nutze auch viel DOIF, aber wenn es nur ein Event gibt auf das ich reagieren will ist meiner Meinung nach notify die bessere Wahl.
Wenn du das mit dem DOIF weiter besprechen möchtes bitte ich dich ein neues Thema dafür zu erstellen, da es ja eigentlich nichts mit dem Monitoring Modul zu tun hat.
Aber wenn du den DeviceMonitor nun mal eine Woche getestet hast und alles funktioniert bitte Bescheid geben, dann packe ich das mit in die CommandRef zu dem Modul.
So, nun mal ein Feedback zum DeviceMonitoring:
Das funktioniert eigentlich ganz wunderbar!
Ich habe mittlerweile das bisher von mir verwendete, aber nicht supportete Modul "98_DeviceMonitor.pm" (aus dem Contrib-Verzeichnis) komplett entfernt und durch das hier beschriebene "98_monitoring" ersetzt!
Der hier weiter oben schon gepostete Code von igami tut was er soll:
Zitat von: igami am 25 April 2017, 21:05:10
Gucken wir uns dazu mal das Beispiel aus der Commandref an;Dabei ändern wir ...
Dazu habe ich noch unter "global" das Userattribut "device_timeout" gesetzt. Damit kann ich nun bei den Devices, die ich überwachen möchte einen Zeitwert hinterlegen, in dem sich das Device gemeldet haben muss, damit es noch als "alive" gilt, ansonsten gilt es als "dead". Diese Info wir beim Reading "Activity" der Devices hinterlegt.
Den Status dieses Readings kann man dann zum Absetzen von Nachrichten mittels DOIF oder notify verwenden.
Dabei sollte man aber beachten, dass für einige Devices (z.B. Homematic) das Reading "Activity" schon gibt und dieses vom Device selbst befüllt wird! Diese Devices bzw. das Reading "Activity" dieser Devices braucht/darf man also nicht über den hier beschriebenen DeviceMonitor ändern. Eigentlich logisch, ich sags aber trotzdem nochmal.
Der Vorteil, wenn man das Reading auch Activity nennt, liegt auf der Hand: Meine Benachrichtigungslogik, die ich schon für meine Homematic-Komponenten habe funktioniert auch direkt mit den vom monitoring-modul überwachten (bei mir Lacrosse-Sensoren)!
Eine Sache ist aber noch nicht ganz "sauber", ich habe Sie für mich aber pragmatisch gelöst: Ein neues Device bekommt das userreading "Activity" erst, wenn es mintestens 1x "dead" gewesen ist. Das liegt daran, dass das notify erst reagiert, wenn ein "error add:" oder "error remove:" vom monitoring-Modul erzeugt wird. Eigentlich wäre es schön, dass es zu Beginn direkt "alive" wäre. Aber nur eigentlich, da es ja mein Ziel ist, erst bei "dead" eine Nachricht zu bekommen. Wenn man trotzdem gleich zu Beginn das Reading "alive" haben möchte (z.B. für eine grüne OK-Anzeige o.ä.), dann kann man im monitoring-Modul die gelisteten Devices manuell kurz auf dead setzen. Dann wird das reading gleich erzeugt.
Aber ich schätze da gibts auch noch bessere Möglichkeiten...
VG...
Zitat von: friesenjung am 02 Mai 2017, 18:09:33
Eine Sache ist aber noch nicht ganz "sauber", ich habe Sie für mich aber pragmatisch gelöst: Ein neues Device bekommt das userreading "Activity" erst, wenn es mintestens 1x "dead" gewesen ist. Das liegt daran, dass das notify erst reagiert, wenn ein "error add:" oder "error remove:" vom monitoring-Modul erzeugt wird. Eigentlich wäre es schön, dass es zu Beginn direkt "alive" wäre. Aber nur eigentlich, da es ja mein Ziel ist, erst bei "dead" eine Nachricht zu bekommen. Wenn man trotzdem gleich zu Beginn das Reading "alive" haben möchte (z.B. für eine grüne OK-Anzeige o.ä.), dann kann man im monitoring-Modul die gelisteten Devices manuell kurz auf dead setzen. Dann wird das reading gleich erzeugt.
Aber ich schätze da gibts auch noch bessere Möglichkeiten...
du kannst ein notify auf "global:ATTR..+device_timeout.+ setzen
Hallo friesenjung,
ZitatDer Vorteil, wenn man das Reading auch Activity nennt, liegt auf der Hand: Meine Benachrichtigungslogik, die ich schon für meine Homematic-Komponenten habe funktioniert auch direkt mit den vom monitoring-modul überwachten (bei mir Lacrosse-Sensoren)!
ist vlt. etwas offtop aber kannst Du die Benachrichtigungslogik mal bitte kurz beschreiben ?
danke
vko1
hi,
ich nutze monitoring auch seit heute und habe unter anderem das Beispiel mit dem Beamerfilter übernommen.
Ich bekomme folgende Fehlermeldung im Log:
Argument "60*60*200" isn't numeric in addition (+) at (eval 425115) line 1.
das ist ja der Wert vom userAttribut errorInterval.
Ich kann den Fehler aber noch nicht ganz nachvollziehen.
Gruß Michael
Zitat von: l2r am 09 Mai 2017, 12:07:23
hi,
ich nutze monitoring auch seit heute und habe unter anderem das Beispiel mit dem Beamerfilter übernommen.
Ich bekomme folgende Fehlermeldung im Log:
Argument "60*60*200" isn't numeric in addition (+) at (eval 425115) line 1.
das ist ja der Wert vom userAttribut errorInterval.
Ich kann den Fehler aber noch nicht ganz nachvollziehen.
Gruß Michael
Vielen Dank fürs testen.
Mach doch mal bitte aus
+ (AttrVal($SELF, "errorInterval", 0))
ein
+ eval(AttrVal($SELF, "errorInterval", 0))
und sag dann ob es funktioniert.
Ich selbst habe so eine Meldung noch gar nicht im Einsatz ::)
Verrrätst du mir noch für welche Anwendung du das einsetzt?
hi,
funktioniert. Die Meldung aus dem Log ist weg.
Ich nutze das Beispiel für meinen Beamer, den ich über meine Harmony schalte. den HourCounter habe ich auf das Power-Reading vom Beamer-Harmony-Device gelegt. Da ich keinen DashButton besitzte habe ich das signalisieren von Reiningen der Filter über einen Dummy angestoßen. Funktioniert auch soweit (der Dummy wird nach dem betätigen direkt wieder auf off gesetzt (siehe das List und dort errorFuncRemove)
Allerdings scheint bei errorFuncRermove noch etwas nicht richtig zu laufen. Zum einen wird das error-Reading nicht geleert und zum anderen wird das Service-Reading nicht im HourCounter vom Beamer gesetzt. Laut meinem Verständnis kann ich aber keinen SyntaxError ausmachen und im Log steht u
Hier noch das List:
Internals:
CFGFN
DEF hc_Beamer:pulseTimeOverall BeamerLampenwechsel:on
NAME mon_BeamerFilter
NR 48009
NTFY_ORDER 50-mon_BeamerFilter
STATE active
TYPE monitoring
Readings:
2017-05-09 12:12:53 error hc_Beamer
2017-05-09 12:17:38 state active
Powermap:
Readingsdesc:
Pm_consumption:
rtype w
Pm_energy:
rtype whr
Attributes:
errorFuncAdd {return 1
if(ReadingsVal($name, "pulseTimeOverall", 0) >=
ReadingsVal($name, "pulseTimeService", 0)
+ eval(AttrVal($SELF, "errorInterval", 0))
&& $addMatch
);
return;
}
errorFuncRemove {return unless($removeMatch);
fhem(
"setreading $name pulseTimeService "
.ReadingsVal($name, "pulseTimeOverall", 0)
);
fhem ("set BeamerLampenwechsel off");
return 1;
}
errorInterval 60*60*200
errorReturn {return unless(@errors);
return "Der Filter vom Beamer muss gereinigt werden.";
}
room FHEM
userattr errorInterval
warningFuncAdd {return}
warningFuncRemove {return}
und das Log bei Verbose 52017.05.09 13:11:47 4: monitoring (mon_BeamerFilter) triggered by "BeamerLampenwechsel on"
2017.05.09 13:11:47 5: monitoring (mon_BeamerFilter) addRegex (hc_Beamer:pulseTimeOverall) and removeRegex (BeamerLampenwechsel:on) are defined
2017.05.09 13:11:47 5: monitoring (mon_BeamerFilter) addRegex (hc_Beamer:pulseTimeOverall) and removeRegex (BeamerLampenwechsel:on) are defined
2017.05.09 13:11:47 5: monitoring (mon_BeamerFilter)
entering monitoring_modify
reading: error
operation: remove
value: BeamerLampenwechsel
at: now
Scheint das $name auf das triggernde Device gesetzt ist und nicht auf das Device im Error
EDIT: nach nochmaligem Lesen der Commandref ja auch richtig!!! dann muss der Code angepasst werden... Sprich es ist aktuell nicht out of the Box (außer man ruft die Funktion manuell auf) möglich, ein Error-Device zurückzusetzen, wenn es nicht selber das auslösende Device ist.
gruß Michael
Zitat von: l2r am 09 Mai 2017, 13:14:00
Scheint das $name auf das triggernde Device gesetzt ist und nicht auf das Device im Error
EDIT: nach nochmaligem Lesen der Commandref ja auch richtig!!! dann muss der Code angepasst werden...
Ja, so ist das auch. hatte es damals nur mit einem dummy getestet ::)
mach daraus doch mal bitte folgendes:
errorFuncRemove {return unless($removeMatch);
fhem ("set $name off");
$name = InternalVal($SELF, "DEF", "") =~ m/([A-Za-z0-9._]+):.*/ ? $1 : $name;
fhem(
"setreading $name pulseTimeService "
.ReadingsVal($name, "pulseTimeOverall", 0)
);
return 1;
}
dadurch sollte $name pasend ersetzt werden.
Wenn alles funktioniert bitte noch ein list posten, dann änderere ich das entsprechend in der commandref ab
hi,
funktioniert!
Internals:
CFGFN
DEF hc_Beamer:pulseTimeOverall BeamerLampenwechsel:on
NAME mon_BeamerFilter
NR 48009
NTFY_ORDER 50-mon_BeamerFilter
STATE error remove: hc_Beamer
TYPE monitoring
Readings:
2017-05-09 13:29:11 error
2017-05-09 13:29:11 state error remove: hc_Beamer
Powermap:
Readingsdesc:
Pm_consumption:
rtype w
Pm_energy:
rtype whr
Attributes:
errorFuncAdd {return 1
if(ReadingsVal($name, "pulseTimeOverall", 0) >=
ReadingsVal($name, "pulseTimeService", 0)
+ eval(AttrVal($SELF, "errorInterval", 0))
&& $addMatch
);
return;
}
errorFuncRemove {return unless($removeMatch);
fhem ("set $name off");
$name = InternalVal($SELF, "DEF", "") =~ m/([A-Za-z0-9._]+):.*/ ? $1 : $name;
fhem(
"setreading $name pulseTimeService "
.ReadingsVal($name, "pulseTimeOverall", 0)
);
return 1;
}
errorInterval 60*60*200
errorReturn {return unless(@errors);
return "Der Filter vom Beamer muss gereinigt werden.";
}
room FHEM
userattr errorInterval
verbose 5
warningFuncAdd {return}
warningFuncRemove {return}
Wenn ich das richtig verstehe werden dann aber für den Fall dass ich beispielsweise 2 Beamer damit überwache und beide im Error-Reading stehen auch beide wieder raus geworfen, oder? Sprich eine Zuordnung vom Auslösenden Device und dem Error-Device ist nicht möglich, oder? (Ist jetzt auch keine Anforderung von mir, ist mir nur gerade in den Sinn gekommen)
Wobei es rein logisch ja auch sinn macht, wenn beide im Error sind auch beide zu reinigen?!
Gruß Michael
Zitat von: l2r am 09 Mai 2017, 13:35:13
Wenn ich das richtig verstehe werden dann aber für den Fall dass ich beispielsweise 2 Beamer damit überwache und beide im Error-Reading stehen auch beide wieder raus geworfen, oder? Sprich eine Zuordnung vom Auslösenden Device und dem Error-Device ist nicht möglich, oder? (Ist jetzt auch keine Anforderung von mir, ist mir nur gerade in den Sinn gekommen)
Man könnte sich überlegen ob man die dummys passend benennt oder eine reinigung über "trigger <hourcounter> service done" oder so bekanntgibt
Zitat von: l2r am 09 Mai 2017, 13:35:13
Wobei es rein logisch ja auch sinn macht, wenn beide im Error sind auch beide zu reinigen?!
Ne, soll ja Betriebsstunden abhängig sein
Zitat von: igami am 09 Mai 2017, 13:38:44
Ne, soll ja Betriebsstunden abhängig sein
Richtig. Wenn sie im Error stehen, dann sollten sie ja auch die nötigen Betriebsstunden zur Reinigung auf dem Buckel haben ;-)
Gruß Michael
Zitat von: l2r am 09 Mai 2017, 13:42:48
Richtig. Wenn sie im Error stehen, dann sollten sie ja auch die nötigen Betriebsstunden zur Reinigung auf dem Buckel haben ;-)
Aber das bedeutet ja nicht, dass man das auch tut :D
wir verstehen uns ;-)
so war nämlich auch mein Gedankengang und daher kam ich auf die Zuordnung 8)
Gruß Michael
Ich wollte jetzt einen Aktivity Monitor einbinden allerdings erzeugt er für viele Geräte ein Warning und Error obwohl ein Update in den Geräten statt findet:
Internals:
DEF .*:.* .*:.*
NAME Activity_monitoring
NR 580
NTFY_ORDER 50-Activity_monitoring
STATE active
TYPE monitoring
Readings:
2017-05-09 13:42:18 error
2017-05-09 13:44:48 errorAdd_ActionDetector 2017-05-10 13:44:48
2017-05-09 13:45:32 errorAdd_AgroWeather 2017-05-10 13:45:32
2017-05-09 13:49:59 errorAdd_HM_BA_Heizung 2017-05-10 13:49:59
2017-05-09 13:49:59 errorAdd_HM_BA_Heizung_Clima 2017-05-10 13:49:59
2017-05-09 13:50:31 errorAdd_HM_KU_Heizung 2017-05-10 13:50:31
2017-05-09 13:50:31 errorAdd_HM_KU_Heizung_Clima 2017-05-10 13:50:31
2017-05-09 13:49:28 errorAdd_HM_KZ_Heizung 2017-05-10 13:49:28
2017-05-09 13:49:28 errorAdd_HM_KZ_Heizung_Clima 2017-05-10 13:49:28
2017-05-09 13:50:15 errorAdd_HM_WZ_Heizung 2017-05-10 13:50:15
2017-05-09 13:50:15 errorAdd_HM_WZ_Heizung_Clima 2017-05-10 13:50:15
2017-05-09 13:48:50 errorAdd_LaCrosse_BA 2017-05-10 13:48:50
2017-05-09 13:48:50 errorAdd_LaCrosse_BK 2017-05-10 13:48:50
2017-05-09 13:48:51 errorAdd_LaCrosse_KU 2017-05-10 13:48:51
2017-05-09 13:48:50 errorAdd_LaCrosse_KZ 2017-05-10 13:48:50
2017-05-09 13:48:52 errorAdd_LaCrosse_SZ 2017-05-10 13:48:52
2017-05-09 13:48:53 errorAdd_LaCrosse_WZ 2017-05-10 13:48:53
2017-05-09 13:50:01 errorAdd_Presence_TV 2017-05-10 13:50:01
2017-05-09 13:44:52 errorAdd_Presence_iMac 2017-05-10 13:44:52
2017-05-09 13:49:09 errorAdd_Sonos 2017-05-10 13:49:09
2017-05-09 13:46:08 errorAdd_Sonos_Balkon 2017-05-10 13:46:08
2017-05-09 13:47:29 errorAdd_Sonos_Kueche 2017-05-10 13:47:29
2017-05-09 13:49:11 errorAdd_Sonos_Wohnzimmer 2017-05-10 13:49:11
2017-05-09 13:44:50 errorAdd_Switch_Licht 2017-05-10 13:44:50
2017-05-09 13:44:50 errorAdd_Tanken_HEM 2017-05-10 13:44:50
2017-05-09 13:44:50 errorAdd_Tanken_HEM_Bensheim 2017-05-10 13:44:50
2017-05-09 13:44:50 errorAdd_Tanken_Rewe 2017-05-10 13:44:50
2017-05-09 13:44:50 errorAdd_Tanken_Shell 2017-05-10 13:44:50
2017-05-09 13:49:09 errorAdd_WEB 2017-05-10 13:49:09
2017-05-09 13:44:48 errorAdd_WifiLight_1 2017-05-10 13:44:48
2017-05-09 13:44:49 errorAdd_abfallkalender 2017-05-10 13:44:49
2017-05-09 13:49:09 errorAdd_global 2017-05-10 13:49:09
2017-05-09 13:45:06 errorAdd_kamera_keno 2017-05-10 13:45:06
2017-05-09 13:50:13 errorAdd_miniCUL433 2017-05-10 13:50:13
2017-05-09 13:50:13 errorAdd_miniCUL433_reconnect 2017-05-10 13:50:13
2017-05-09 13:49:48 errorAdd_mqtt 2017-05-10 13:49:48
2017-05-09 13:44:52 errorAdd_myHmUARTLGW 2017-05-10 13:44:52
2017-05-09 13:50:31 errorAdd_myLaCrosseGateway 2017-05-10 13:50:31
2017-05-09 13:44:50 errorAdd_netatmo_2 2017-05-10 13:44:50
2017-05-09 13:46:19 errorAdd_netatmo_gateway 2017-05-10 13:46:19
2017-05-09 13:50:01 errorAdd_rgr_Home 2017-05-10 13:50:01
2017-05-09 13:50:01 errorAdd_rr_Stefan 2017-05-10 13:50:01
2017-05-09 13:50:01 errorAdd_rr_Tina 2017-05-10 13:50:01
2017-05-09 13:44:50 errorAdd_sonoff0 2017-05-10 13:44:50
2017-05-09 13:44:50 errorAdd_sonoff1 2017-05-10 13:44:50
2017-05-09 13:44:50 errorAdd_sonoff2 2017-05-10 13:44:50
2017-05-09 13:44:50 errorAdd_sonoff3 2017-05-10 13:44:50
2017-05-09 13:44:50 errorAdd_sonoff4 2017-05-10 13:44:50
2017-05-09 13:44:50 errorAdd_sonoff5 2017-05-10 13:44:50
2017-05-09 13:44:50 errorAdd_sonoff6 2017-05-10 13:44:50
2017-05-09 13:44:50 errorAdd_sonoff7 2017-05-10 13:44:50
2017-05-09 13:44:50 errorAdd_sonoff8 2017-05-10 13:44:50
2017-05-09 13:48:41 errorAdd_sysmon 2017-05-10 13:48:41
2017-05-09 13:44:49 errorAdd_update_check 2017-05-10 13:44:49
2017-05-09 13:44:52 errorAdd_vccu 2017-05-10 13:44:52
2017-05-09 13:48:39 state active
2017-05-09 13:42:18 warning
2017-05-09 13:44:48 warningAdd_ActionDetector 2017-05-10 01:44:48
2017-05-09 13:45:32 warningAdd_AgroWeather 2017-05-10 01:45:32
2017-05-09 13:49:59 warningAdd_HM_BA_Heizung 2017-05-10 01:49:59
2017-05-09 13:49:59 warningAdd_HM_BA_Heizung_Clima 2017-05-10 01:49:59
2017-05-09 13:50:31 warningAdd_HM_KU_Heizung 2017-05-10 01:50:31
2017-05-09 13:50:31 warningAdd_HM_KU_Heizung_Clima 2017-05-10 01:50:31
2017-05-09 13:49:28 warningAdd_HM_KZ_Heizung 2017-05-10 01:49:28
2017-05-09 13:49:28 warningAdd_HM_KZ_Heizung_Clima 2017-05-10 01:49:28
2017-05-09 13:50:15 warningAdd_HM_WZ_Heizung 2017-05-10 01:50:15
2017-05-09 13:50:15 warningAdd_HM_WZ_Heizung_Clima 2017-05-10 01:50:15
2017-05-09 13:48:50 warningAdd_LaCrosse_BA 2017-05-10 01:48:50
2017-05-09 13:48:50 warningAdd_LaCrosse_BK 2017-05-10 01:48:50
2017-05-09 13:48:51 warningAdd_LaCrosse_KU 2017-05-10 01:48:51
2017-05-09 13:48:50 warningAdd_LaCrosse_KZ 2017-05-10 01:48:50
2017-05-09 13:48:52 warningAdd_LaCrosse_SZ 2017-05-10 01:48:52
2017-05-09 13:48:53 warningAdd_LaCrosse_WZ 2017-05-10 01:48:53
2017-05-09 13:50:01 warningAdd_Presence_TV 2017-05-10 01:50:01
2017-05-09 13:44:52 warningAdd_Presence_iMac 2017-05-10 01:44:52
2017-05-09 13:49:09 warningAdd_Sonos 2017-05-10 01:49:09
2017-05-09 13:46:08 warningAdd_Sonos_Balkon 2017-05-10 01:46:08
2017-05-09 13:47:29 warningAdd_Sonos_Kueche 2017-05-10 01:47:29
2017-05-09 13:49:11 warningAdd_Sonos_Wohnzimmer 2017-05-10 01:49:11
2017-05-09 13:44:50 warningAdd_Switch_Licht 2017-05-10 01:44:50
2017-05-09 13:44:50 warningAdd_Tanken_HEM 2017-05-10 01:44:50
2017-05-09 13:44:50 warningAdd_Tanken_HEM_Bensheim 2017-05-10 01:44:50
2017-05-09 13:44:50 warningAdd_Tanken_Rewe 2017-05-10 01:44:50
2017-05-09 13:44:50 warningAdd_Tanken_Shell 2017-05-10 01:44:50
2017-05-09 13:49:09 warningAdd_WEB 2017-05-10 01:49:09
2017-05-09 13:44:48 warningAdd_WifiLight_1 2017-05-10 01:44:48
2017-05-09 13:44:49 warningAdd_abfallkalender 2017-05-10 01:44:49
2017-05-09 13:49:09 warningAdd_global 2017-05-10 01:49:09
2017-05-09 13:45:06 warningAdd_kamera_keno 2017-05-10 01:45:06
2017-05-09 13:50:13 warningAdd_miniCUL433 2017-05-10 01:50:13
2017-05-09 13:50:13 warningAdd_miniCUL433_reconnect 2017-05-10 01:50:13
2017-05-09 13:49:48 warningAdd_mqtt 2017-05-10 01:49:48
2017-05-09 13:44:52 warningAdd_myHmUARTLGW 2017-05-10 01:44:52
2017-05-09 13:50:31 warningAdd_myLaCrosseGateway 2017-05-10 01:50:31
2017-05-09 13:44:50 warningAdd_netatmo_2 2017-05-10 01:44:50
2017-05-09 13:46:19 warningAdd_netatmo_gateway 2017-05-10 01:46:19
2017-05-09 13:50:01 warningAdd_rgr_Home 2017-05-10 01:50:01
2017-05-09 13:50:01 warningAdd_rr_Stefan 2017-05-10 01:50:01
2017-05-09 13:50:01 warningAdd_rr_Tina 2017-05-10 01:50:01
2017-05-09 13:44:50 warningAdd_sonoff0 2017-05-10 01:44:50
2017-05-09 13:44:50 warningAdd_sonoff1 2017-05-10 01:44:50
2017-05-09 13:44:50 warningAdd_sonoff2 2017-05-10 01:44:50
2017-05-09 13:44:50 warningAdd_sonoff3 2017-05-10 01:44:50
2017-05-09 13:44:50 warningAdd_sonoff4 2017-05-10 01:44:50
2017-05-09 13:44:50 warningAdd_sonoff5 2017-05-10 01:44:50
2017-05-09 13:44:50 warningAdd_sonoff6 2017-05-10 01:44:50
2017-05-09 13:44:50 warningAdd_sonoff7 2017-05-10 01:44:50
2017-05-09 13:44:50 warningAdd_sonoff8 2017-05-10 01:44:50
2017-05-09 13:48:41 warningAdd_sysmon 2017-05-10 01:48:41
2017-05-09 13:44:49 warningAdd_update_check 2017-05-10 01:44:49
2017-05-09 13:44:52 warningAdd_vccu 2017-05-10 01:44:52
Attributes:
errorReturn {return unless(@errors);
$_ = AttrVal($_, "alias", $_) foreach(@errors);
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);
@errors = sort {lc($a) cmp lc($b)} @errors;
return(join("\n - ", "Die folgenden ".@errors." Geräten haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))
}
errorWait 60*60*24
room System
warningReturn {return unless(@warnings);
$_ = AttrVal($_, "alias", $_) foreach(@warnings);
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@warnings) == 1);
@warnings = sort {lc($a) cmp lc($b)} @warnings;
return(join("\n - ", "Die folgenden ".@warnings." Geräten haben sich seit mehr als 12 Stunden nicht mehr gemeldet:", @warnings))
}
warningWait 60*60*12
Eine Idee, wo der Fehler liegt?
Die Geräte erzeugen auch Events bzw werden Readings geupdatet. Ein Schalten einer Lampe zum Beispiel hilft nicht, damit es aus Error oder Warning verschwindet.
Zitat von: gloob am 09 Mai 2017, 13:52:19
Ich wollte jetzt einen Aktivity Monitor einbinden allerdings erzeugt er für viele Geräte ein Warning und Error obwohl ein Update in den Geräten statt findet:
Die readings geben nur an, wann das Gerät auf die warning/error Liste gesetzt wird. Die Listen selbst sind jedoch leer.
Allerdings wollte ich das Beispiel mal auf DeviceMonitor umabuen. Siehe:
Zitat von: igami am 25 April 2017, 21:05:10
Gucken wir uns dazu mal das Beispiel aus der Commandref an;
Zitat
defmod Activity_monitoring monitoring .*:.*
attr Activity_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))\
}
attr Activity_monitoring errorWait 60*60*24
attr Activity_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräten haben sich seit mehr als 12 Stunden nicht mehr gemeldet:", @warnings))\
}
attr Activity_monitoring warningWait 60*60*12
Geräte werden erst überwacht, wenn sie mindestens ein Event ausgelöst haben. Sollte das Gerät in 12 Stunden kein weiterer Event auslösen, wird es auf die warning-Liste gesetzt. Sollte das Gerät in 24 Stunden kein weiteres Event auslösen, wird es von der warning- auf die error-Liste verschoben.
Dabei ändern wir das errorWait Attribut auf {ReadingsVal($name, "device_timeout", 0)} und ergänzen das monitoring um das Attribut whitelist device_timeout=.+
Um den das Reading Activity auf dead or alive zu setzen wird noch ein notify benötigt.
Zusammengefasst haben wir dann folgendens (ungetestet):
defmod DeviceMonitor monitoring .*:.*
attr DeviceMonitor errorReturn {return unless(@errors);;\
\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
\
return("Das Gerät \"$errors[0]\" scheint nicht mehr aktiv zu sein.")\
if(int(@errors) == 1);;\
\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
\
return(join("\n - ", "Die folgenden ".@errors." Geräten scheinen nicht mehr aktiv zu sein:", @errors))\\
}
attr DeviceMonitor errorWait {AttrVal($name, "device_timeout", 0)}
attr DeviceMonitor whitelist device_timeout=.+
defmod DeviceMonitorSetActivity notify DeviceMonitor:error.(add|remove):..+ {\
$EVENT =~ m/error (add|remove): (.+)/;;\
\
readingsSingleUpdate(\
$defs{$2}, "Activity", $1 eq "add" ? "dead" : "alive", 0\
);;\
\
return;;\
}
Zitat von: l2r am 09 Mai 2017, 13:51:16
wir verstehen uns ;-)
so war nämlich auch mein Gedankengang und daher kam ich auf die Zuordnung 8)
Gruß Michael
Also was wäre nun am sinnvollsten?
Pro Beamer 1 Hourcounter (hc_Beamer) ist klar. Dann noch je Beamer ein reset dummy oder dash button (hc_Beamer_done) und ein notify welches so aussehen könne:
define ntfy_Beamer_done hc_Beamer.*_done:.* {$NAME =~ m/(.+)_done/; fhem("trigger $1 done");}
das monitoring würde dann so aussehen:
define mon_BeamerFilter monitoring hc_Beamer.*:pulseTimeOverall hc_Beamer.*:done
Müsste man mal testen :D
Ich hatte das damals nur mit einem Dummy simuliert und der hieß ja immer gleich ::)
macht für mich nach dem ersten drüber schauen sinn... Werde ich bei Gelegenheit mal testen.
Ich habe aber noch eine andere Frage.
Ist es richtig/gewollt, dass die Geräte aus dem Warning-Reading nicht verschwinden wenn sie in den Error-Status wechseln?
Wenn man mit get default im doif sich die Liste aufrufen möchte, dann bekommt man die Meldung für warning und error... Klar kann man das umstellen auf get error. Aber man möchte das ja auch für die Geräte haben die nur warning haben.
hier das list:
Internals:
CFGFN
DEF .*:(open|tilted) .*:closed
NAME mon_Fenster
NR 46077
NTFY_ORDER 50-mon_Fenster
STATE error remove: di_Michael_SZ_Lueften
TYPE monitoring
Readings:
2017-05-10 12:21:54 error SZ_M_Fenster,sen_RaumFenster1,sen_RaumFenster2
2017-05-10 12:21:54 state error remove: di_Michael_SZ_Lueften
2017-05-10 08:52:49 warning SZ_M_Fenster,sen_RaumFenster1,sen_RaumFenster2
Powermap:
Readingsdesc:
Pm_consumption:
rtype w
Pm_energy:
rtype whr
Attributes:
errorReturn {return unless(@errors);
$_ = AttrVal($_, "alias", $_) foreach(@errors);
return("Das Fenster \"$errors[0]\" ist schon länger geöffnet.") if(int(@errors) == 1);
@errors = sort {lc($a) cmp lc($b)} @errors;
return(join("\n - ", "Die folgenden ".@errors." Fenster sind schon länger geöffnet:", @errors))
}
errorWait {AttrVal($name, "winOpenTimer", 60*10)}
room FHEM
warningReturn {return unless(@warnings);
$_ = AttrVal($_, "alias", $_) foreach(@warnings);
return("Das Fenster \"$warnings[0]\" ist seit kurzem geöffnet.") if(int(@warnings) == 1);
@warnings = sort {lc($a) cmp lc($b)} @warnings;
return(join("\n - ", "Die folgenden ".@warnings." Fenster sind seit kurzem geöffnet:", @warnings))
}
Gruß Michael
Zitat von: l2r am 10 Mai 2017, 12:27:26
Ist es richtig/gewollt, dass die Geräte aus dem Warning-Reading nicht verschwinden wenn sie in den Error-Status wechseln?
Nein, ist nicht gewollt, momentan hängt es damit zusammen, dass bei einem neustart erst error und dann die warnings geprüft werden. Da muss ich mir noch was einfallen lassen.
ich habe vorhin mal ein set clear all gemacht und nach kurzer Zeit sind warning und error wieder mit den gleichen Devices gefüllt.
Dazwischen wurde kein shutdown restart durchgeführt, oder redest du vom internen Neustart der Timer?
Gruß Michael
Zitat von: l2r am 10 Mai 2017, 18:27:35
ich habe vorhin mal ein set clear all gemacht und nach kurzer Zeit sind warning und error wieder mit den gleichen Devices gefüllt.
Dazwischen wurde kein shutdown restart durchgeführt, oder redest du vom internen Neustart der Timer?
Gruß Michael
Nein, es war schon ein fhem neustart gemeint.
Ich gucke mir das noch mal genauer an.
Zitat von: kvo1 am 08 Mai 2017, 08:15:09
Hallo friesenjung,
ist vlt. etwas offtop aber kannst Du die Benachrichtigungslogik mal bitte kurz beschreiben ?
danke
vko1
Hi und sorry für die späte Rückmeldung...
Also eigentlich meinte ich damit nichts besonderes. Nur dieses kleine DOIF
defmod DI_AlarmDeviceStatus DOIF ([":Activity: dead"] and [?$SELF:B_$DEVICE] ne "dead") (set Pushover msg 'Device-Alarm' 'Das Gerät +++ $DEVICE +++ meldet sich nicht mehr!' 'iPhone6s' 0 '', setreading $SELF B_$DEVICE dead)\
DOELSEIF ([":Activity: alive"] and [?$SELF:B_$DEVICE] ne "alive") (setreading $SELF B_$DEVICE alive)
attr DI_AlarmDeviceStatus DbLogExclude .*
attr DI_AlarmDeviceStatus do always
attr DI_AlarmDeviceStatus group Benachrichtigung
attr DI_AlarmDeviceStatus room 9.1_Steuerung
Das reagiert sowohl auf das Activity eines Homematic-Devices, als auch bspw. auf die durch das monitoring-Modul überwachten Lacrosse-Sensoren.
Hoffe das beantwortet Deine Frage...
VG...
Nur so mal als Tipp in die Runde: Das System ist wesentlich wartungsfreundlicher, wenn man in irgendeine der Utils-Dateien einfache Helper-Funktionen einbaut, z.B.
sub BatteryHelper($@){
my ($err,@ew) = @_;
$_ = AttrVal($_, "alias", $_) foreach(@ew);
@ew = sort {lc($a) cmp lc($b)} @ew;
my $ts = ($err)?"":"demnächst ";
return("Bei dem Gerät ".$ew[0]." muss ".$ts."die Batterie gewechselt werden.") if(int(@ew) == 1);
return(join("\n - ", "Bei den folgenden ".@ew." Geräten muss ".$ts."die Batterie gewechselt werden:", @ew));
}
sub ActivityHelper($@){
my ($err,@ew) = @_;
$_ = AttrVal($_, "alias", $_) foreach(@ew);
@ew = sort {lc($a) cmp lc($b)} @ew;
my $ts = ($err)?"60 Minuten":"10 Minuten";
return("Das Gerät ".$ew[0]." hat sich seit ".$ts."nicht mehr gemeldet") if(int(@ew) == 1);
return(join("\n - ", "Die folgenden ".@ew." Geräte haben sich seit ".$ts." nicht mehr gemeldet:", @ew));
}
und dann im Monitoring-device
attr Batterie_monitoring errorReturn {BatteryHelper(1,@errors)}
attr Batterie_monitoring warningReturn {BatteryHelper(0,@warnings)}
setzt.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 13 Mai 2017, 12:07:31
Nur so mal als Tipp in die Runde: Das System ist wesentlich wartungsfreundlicher, wenn man in irgendeine der Utils-Dateien einfache Helper-Funktionen einbaut, z.B.
sub BatteryHelper($@){
my ($err,@ew) = @_;
$_ = AttrVal($_, "alias", $_) foreach(@ew);
@ew = sort {lc($a) cmp lc($b)} @ew;
my $ts = ($err)?"":"demnächst ";
return("Bei dem Gerät ".$ew[0]." muss ".$ts."die Batterie gewechselt werden.") if(int(@ew) == 1);
return(join("\n - ", "Bei den folgenden ".@ew." Geräten muss ".$ts."die Batterie gewechselt werden:", @ew));
}
sub ActivityHelper($@){
my ($err,@ew) = @_;
$_ = AttrVal($_, "alias", $_) foreach(@ew);
@ew = sort {lc($a) cmp lc($b)} @ew;
my $ts = ($err)?"60 Minuten":"10 Minuten";
return("Das Gerät ".$ew[0]." hat sich seit ".$ts."nicht mehr gemeldet") if(int(@ew) == 1);
return(join("\n - ", "Die folgenden ".@ew." Geräte haben sich seit ".$ts." nicht mehr gemeldet:", @ew));
}
und dann im Monitoring-device
attr Batterie_monitoring errorReturn {BatteryHelper(1,@errors)}
attr Batterie_monitoring warningReturn {BatteryHelper(0,@warnings)}
setzt.
LG
pah
Warum ist das Wartungsfreundlicher?
Kontra:
Ich müsste dann wissen in welcher utils datei ich die sub abgespeichert habe und kann diese nicht einfach im device ändern.
Ein Fehler in der utils kann dazu führen, dass sämtliche subs in der utils nicht mehr funktionieren.
Es werden zu beginn alle subs geladen und machen damit das system etwas träger.
Pro:
in der fhem.cfg (in die niemand reinguckt ;)) stehen weniger Zeilen?
Zitat von: igami am 13 Mai 2017, 14:52:01
Warum ist das Wartungsfreundlicher?
Kontra:
Ich müsste dann wissen in welcher utils datei ich die sub abgespeichert habe und kann diese nicht einfach im device ändern.
Ein Fehler in der utils kann dazu führen, dass sämtliche subs in der utils nicht mehr funktionieren.
Es werden zu beginn alle subs geladen und machen damit das system etwas träger.
Pro: - Erhöht die Lesbarkeit am Device
- Evtl. Wiederverwendbarkeit der Subs für mehrere Devices
- Eine zentrale Stelle für die Pflege
Deswegen ist es clever wenn man sich für unterschiedliche Anwendungs-/Themenbereiche eigene 99_xxxUtils.pm Dateien anlegt. Dann weiß man auch einfacher in welcher .pm die jeweilige sub zu suchen/finden ist. Und am besten noch eine 99_TestUtils.pm in der man nur Entwickelt und testet.
Jedenfalls hab ich mir das so eingerichtet.
Die Trägheit durch die "vielen" subs dürfte sich wohl kaum bemerkbar machen, der Code in den Devices (Hashes) belegt ja schließlich auch Speicherplatz.
ZitatEs werden zu beginn alle subs geladen und machen damit das system etwas träger.
Das ist falsch - denn ebenso müssen die Zeilen aus der Konfigurationsdatei geladen werden. Und da diese a.) länger sind und b.) erst durch den Perl-Code für das Interpretieren der Konfigurationsdatei hindurch müssen, ist
IM GEGENTEIL das Ablegen von Code in den Device-Attributen
VIEL langsamer als das Einlesen einer ordentlichen Perl-Datei.
ZitatEin Fehler in der utils kann dazu führen, dass sämtliche subs in der utils nicht mehr funktionieren.
Halb falsch - das stimmt nur für Syntaxfehler, die beim Einlesen des Moduls auffallen. Dem kann man durch eine separate Utils-Datei für ungetesteten Code entgegentreten. Laufzeitfehler in einer sub beeinträchtigen die anderen subs nicht.
ZitatIch müsste dann wissen in welcher utils datei ich die sub abgespeichert habe und kann diese nicht einfach im device ändern.
Erstens kann man so etwas im Namen der subroutine einbauen, Zweitens habe ich so wie Benni mehrere Util-Dateien. Für Plotfunktionen, Zeitfunktionen, Sicherheit, Licht, Heizung und Sonstiges.
Zitat
- Erhöht die Lesbarkeit am Device
- Evtl. Wiederverwendbarkeit der Subs für mehrere Devices
- Eine zentrale Stelle für die Pflege
Eben.
LG
pah
Hi cooles Modul! :)
aber wie pack ich denn hier
attr Activity_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))\
das mit ein:
fhem "set teleBot message " . '@123456789' . " "Die folgenden ".@errors." Geräten haben sich seit mehr als 24 Stunden nicht mehr gemeldet";
Damit ich die Meldung per Telegram bekomme!
LG
Marlen
in ein extra notify /Doif welches dann ausgelöst wird, wann du es möchtest.
Das Modul erkennt die Geräte, die im Error sind und bereitet die Meldung dementsprechend so auf, dass sie komfortabel abgegriffen werden kann.
Das Versenden usw. ist nicht Teil des Moduls
Gruß Michael
Hallo zusammen,
meine batteriebetriebenen Z-Wave Geräte liefern für battery numerische Werte zurück inkl. %-Zeichen, z.B. 67 %
Im Beispiel wird low und ok verwendet, wie kann ich das monitoring definieren, dass z.B. bei < 10 % add-event und z.B. bei > 95 % ein remove-event verwendet wird?
Beste Grüße
Torsten
Zitat von: ToKa am 16 Mai 2017, 21:54:03
meine batteriebetriebenen Z-Wave Geräte liefern für battery numerische Werte zurück inkl. %-Zeichen, z.B. 67 %
Im Beispiel wird low und ok verwendet, wie kann ich das monitoring definieren, dass z.B. bei < 10 % add-event und z.B. bei > 95 % ein remove-event verwendet wird?
Bei errorFuncAdd bzw. errorFuncRemove eine 1 zurück geben wenn ReadingsNum kleiner bzw. größer ist als dein Grenzwert.
Super, vielen Dank - doch so einfach, wenn man alle attribute richtig versteht :-[
Hallo,
ich verstehe das mit den Events noch nicht ganz. Welches Event wird denn vom monitoring getriggert, damit ich per Telegram oder Pushover, etc. darauf reagieren kann und mir das zusenden lassen kann?
Kann da mal jemand ein komplettes Beispiel posten?
Vielen Dank! :)
Zitat von: ToM_ToM am 10 Juli 2017, 14:56:08
ich verstehe das mit den Events noch nicht ganz. Welches Event wird denn vom monitoring getriggert, damit ich per Telegram oder Pushover, etc. darauf reagieren kann und mir das zusenden lassen kann?
Kann da mal jemand ein komplettes Beispiel posten?
Zitat von: Commandref
Das monitor sendet selbst keine Benachrichtung, hierfür ist ein notify oder DOIF notwendig, welches auf das Event "<monitoring-name> error add: <name>" reagiert und dann den Rückgabewert von "get <monitoring-name> default" versendet.
Schon etwas ausführlicher:
defmod ServiceNotifications_DI DOIF ((\
[":^error add:"]\
|| [$SELF:cmd] == 2\
) \
&& (\
(\
[ServiceNotifications_cu:state] eq "ein"\
&& [NRW:state] eq "none"\
) \
|| AttrVal("$DEVICE", "priority", 0) == 1\
) \
)(\
{my $msg = fhem("get TYPE=monitoring default");;\
my $oldMsg = $defs{$SELF}{helper}{oldMsg};;\
\
if($msg && (!$oldMsg || $msg ne $oldMsg)){\
sendEmail("XXX", $msg);;\
\
$defs{$SELF}{helper}{oldMsg} = $msg;;\
}\
\
return;;\
}\
)\
DOELSEIF\
([":^error add:"])
attr ServiceNotifications_DI cmdState send notifications|notifications pending
attr ServiceNotifications_DI cmdpause 60*15
attr ServiceNotifications_DI do always
attr ServiceNotifications_DI wait 60*15
Ich überprüfe immer auf error add:
Umschriben bedeutet der code:
Falls ein Gerät ein "error add:" Event auslöst, oder ich mich im Status zwei Befinde
Und, mein Weekdaytimer eingeschaltet ist und kein Feiertag ist, oder die Benachrichtigung Priorität hat,
warte 15 Minuten ob noch weitere Fehlermeldungen kommen und schicke mir dann eine Nachricht, sofern die Nachricht sich von der vorherigen unterscheidet und nicht leer ist.
Andernfalls falls ein Gerät ein "error add:" Event auslöst, speichere das als Status zwei.
Dieses DOIF nutze ich auf der Arbeit um mich nur während der Arbeitszeit informieren zu lassen. Ich möchte ja nicht zu Hause wissen, dass ich Batterien tauschen muss. Falls aber etwas wichtiges ist, z.B. Klimaanlage im Serverraum ausgefallen werde ich trotzdem benachrichtigt. Dafür habe ich meinen monitoring einer userattr priority spendiert.
Zu Hause mache ich das ganz anders, da lasse ich mir einfach alle Nachrichten schicken, wenn ich 15 Minuten zu hause bin. Und nicht dann, wenn sie auftreten.
Hey, kann man in dem Modul auch irgendwie einen Counter einbauen damit ich ein Reading habe welches mir anzeigt wieviele aktuell auf der Warining Liste sind und wieviele aktuell auf der Error Liste sind?
VG, Thomas
Und es wäre auch cool wenn man statt dem DEVICE Namen, auf den Alias zurückgreifen könnte (evtl. überein Attribut gesteuert).
LG, Thomas
Kann man doch beides über das Attribut errorReturn machen.
Bsp:
{return unless(@errors);
return("Das Thermostat \"".AttrVal(InternalVal($errors[0], "channel_04", $errors[0]), "alias", $errors[0])."\" meldet einen Fehler: ".ReadingsVal($errors[0], "motorErr", ""))
if(int(@errors) == 1);
$_ = AttrVal(InternalVal($_, "channel_04", $_), "alias", $_)."\n Fehler: ".ReadingsVal($_, "motorErr", "") for(@errors);
@errors = sort {lc($a) cmp lc($b)} @errors;
return(join("\n - ", "Die folgenden ".@errors." Thermostate melden einen Fehler:", @errors));
}
ZitatKann man doch beides über das Attribut errorReturn machen.
Ach cool, danke! Das mit dem Alias funktioniert jetzt super.
Nur wie ich mir ein UserReading erzeuge welches die Anzahl der Warnings enthält, habe ich noch nicht ganz herausfinden können.
VG, Thomas
Zitat von: ToM_ToM am 14 Juli 2017, 14:44:29
Nur wie ich mir ein UserReading erzeuge welches die Anzahl der Warnings enthält, habe ich noch nicht ganz herausfinden können.
Ich schreibe das meist in die Nachricht mit rein.
Ein userreading könnte so aussehen:
attr <name> userreadings error_count:error.+ {split(",", ReadingsVal($name, "error", ""))}
ZitatEin userreading könnte so aussehen:
Ach cool. Super danke. Das funktioniert. Auch wenn sich mir nicht ganz erschließt, wie es funktioniert, da du hier mit
ReadingsVal($name, "error", "")ja das Reading
error ausliest, welches es zumindest bei mir, gar nicht gibt. :o
Aber es funktioniert. :)
Dann hast du auch keine Einträge im error ;)
Sobald du welche hast gibt es auch das Reading
Ah.. jetzt funktioniert es.
Der Trick war Strg + F5 für Reload. Der hatte mir zwar die vorhandenen Readings aktualisiert, aber die neuen nicht angezeigt.
Aber jetzt geht's super.
Falls es noch jemand benötigt:
warning_count:warning.+ {split(",", ReadingsVal($name, "warning", ""))},
error_count:error.+ {split(",", ReadingsVal($name, "error", ""))},
all_count:(warning.+|error.+) {split(",", ReadingsVal($name, "warning", "")) + split(",", ReadingsVal($name, "error", ""))}
VG und vielen Dank!, Thomas
Hi,
beschäftige mich gerade mit Battery / Telegram etc. und bin auf dieses Modul gestoßen.
Ist es möglich in dieses Modul ein "Send an xx " bei Warning / Error mit einzubauen (xx= Telegram / E-Mail / Sonos.....) ?
Dies wäre sehr sehr hilftreich.
VG
Darauf habe ich absichtlich verzichtet, da es zu viele Dienste zur Benachrichtigung gibt. Einfach ein notify oder DOIF erstellen welches auf das Event error add bzw. warning add reagiert. Dann lassen sich auch noch weitere Bedingungen einbauen, z.b. Anwesenheit. Leere Batterien interessieren mich nicht, wenn keiner zu Hause ist.
Hey igami,
gibt es auch eine Möglichkeit, Schellenwerte zu überwachen?
Ich habe z.B.: Device "Pflanze" mit dem Reading "bodenfeuchte".
Der Wert reicht von 0% bis 100%.
Nun möchte ich die Pflanze gerne auf die warning-Liste setzen, sobald der Wert unter 20% sinkt.
Wäre sowas möglich?
VG, Thomas
Zitat von: ToM_ToM am 21 August 2017, 07:32:12
Hey igami,
gibt es auch eine Möglichkeit, Schellenwerte zu überwachen?
Ich habe z.B.: Device "Pflanze" mit dem Reading "bodenfeuchte".
Der Wert reicht von 0% bis 100%.
Nun möchte ich die Pflanze gerne auf die warning-Liste setzen, sobald der Wert unter 20% sinkt.
Wäre sowas möglich?
VG, Thomas
Klar geht das.
einfach über regex:
define Pflanze_bodenfeuchte monitoring Pflanze:bodenfeuchte:.1?[0-9] Pflanze:bodenfeuchte:.1?[2-9][0-9]
sofern keine Wartezeiten programmiert werden landet es aber nur auf der error liste.
Hey igami,
super. Aber irgendwie klappt das noch nicht ganz bei mir.
Meine Pflanzen heißen alle Pflanze_01 bis Pflanze_05. Nur bei Pflanze_02 ist moisture = 13. Alle anderen sind zwischen 30 und 60.
Und dennoch schmeißt er mir gleich alle auf die warining Liste. :o
defmod Flower_monitoring monitoring Pflanze_0?[0-9]*:moisture:.1?[0-9] Pflanze_0?[0-9]*:moisture:.1?[2-9][0-9]
attr Flower_monitoring DbLogExclude .*
attr Flower_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Die Pflanze \"$errors[0]\" muss dringend gegossen werden.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Pflanzen müssen dringend gegossen werden:", @errors))\
}
attr Flower_monitoring errorWait 60*60*24*7
attr Flower_monitoring group Monitoring
attr Flower_monitoring room FlowerSens
attr Flower_monitoring userReadings warning_count:warning.+ {split(",", ReadingsVal($name, "warning", ""))}, \
error_count:error.+ {split(",", ReadingsVal($name, "error", ""))}, \
all_count:(warning.+|error.+) {split(",", ReadingsVal($name, "warning", "")) + split(",", ReadingsVal($name, "error", ""))}
attr Flower_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Die Pflanze \"$warnings[0]\" muss demnächst gegossen werden.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Pflanzen müssen demnächst gegossen werden:", @warnings))\
}
Hey igami,
hast du keine Idee mehr für mich? Ich habe noch alles Mögliche hin und her probiert, aber irgendwie interessiert dem Monitoring mein zweiter REGEX nicht.
Nach clear all und FHEM Neustart kommen gleich wieder alle Pflanzen auf die warning Liste.
VG, Thomas
Entschuldige bitte, ich hatte es zwar unterwegs gelesen, dann aber vergessen zu gucken als ich wieder zu Hause war. Ich Stelle das nachher Mal mit einem Dummy nach. Momentan wüsste ich nicht woran es liegt.
Zitat von: ToM_ToM am 24 August 2017, 22:00:47
Hey igami,
hast du keine Idee mehr für mich? Ich habe noch alles Mögliche hin und her probiert, aber irgendwie interessiert dem Monitoring mein zweiter REGEX nicht.
Nach clear all und FHEM Neustart kommen gleich wieder alle Pflanzen auf die warning Liste.
VG, Thomas
Mach mal ein $ hinter die erste Regex, dann sollte es gehen
defmod Flower_monitoring monitoring Pflanze_0?[0-9]*:moisture:.1?[0-9]$ Pflanze_0?[0-9]*:moisture:.([2-9][0-9]|100)
Hey igami,
kein Problem. Super, das war die Lösung. 8)
Jetzt funktioniert es perfekt.
Vielen Dank und ein schönes Wochenende!
VG, Thomas
Geniales Modul! Löst einen Haufen meiner Probleme, die ich bisher nicht angegangen bin weil mir das zu viel Arbeit war! :-)
DANKE!
Zitat von: zweiundzwanzig am 14 November 2017, 18:57:35
Geniales Modul! Löst einen Haufen meiner Probleme, die ich bisher nicht angegangen bin weil mir das zu viel Arbeit war! :-)
DANKE!
Vielen Dank für das Lob :)
Wenn du Fragen oder Anregungen hast immer her damit!
Ich habe mal das Beispiel mit dem Activity Monitoring aus der Hilfe übernommen.
Meine MAX-Thermostate haben Tagesprogramme und sollten mindestens alle 12h irgend etwas von sich aus melden.
Ich schalte aber auch regelmäßig (mindestens alle 2-3 Tage, eher täglich) automatisiert jedes Thermostat z.B. per "set desiredTemperature 15". Dadurch allein entsteht ja auch schon ein event, das so aussieht: "MAX MAX_Thermostat_1 desiredTemperature 15.0" und erst danach kommen die events, die das Thermostat nach der Änderung der Solltemperatur selber sendet.
Dadurch führt also schon das "set desiredTemperature 15" dazu, dass ein Thermostat als "aktiv" gilt und der counter des Monitorings wieder zurückgesetzt wird oder? Wie verhindere ich das?
Zitat von: zweiundzwanzig am 16 November 2017, 23:07:37
Ich habe mal das Beispiel mit dem Activity Monitoring aus der Hilfe übernommen.
Meine MAX-Thermostate haben Tagesprogramme und sollten mindestens alle 12h irgend etwas von sich aus melden.
Ich schalte aber auch regelmäßig (mindestens alle 2-3 Tage, eher täglich) automatisiert jedes Thermostat z.B. per "set desiredTemperature 15". Dadurch allein entsteht ja auch schon ein event, das so aussieht: "MAX MAX_Thermostat_1 desiredTemperature 15.0" und erst danach kommen die events, die das Thermostat nach der Änderung der Solltemperatur selber sendet.
Dadurch führt also schon das "set desiredTemperature 15" dazu, dass ein Thermostat als "aktiv" gilt und der counter des Monitorings wieder zurückgesetzt wird oder? Wie verhindere ich das?
Zuerst einmal: Das Beispiel muss ich noch überarbeiten ::)
Aber nun zu deinem Problem:
Poste mal bitte die Raw definiton von deinem monitoring und den Ausschnitt aus dem Eventmonitor wenn du das set ausführst.
Hallo,
experimentiere gerade mit monitoring herum.
attr FensterMonitoring errorReturn {WindowHelper(1,"test")}
attr FensterMonitoring warningReturn {WindowHelper(1,"test1")}
sub WindowHelper($$) {
Log3(undef, 1, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx");
}
Beim FensterMonitoring werden die geöffneten Fenster hinzugefügt bzw. beim schließen entfernt.
WindowHelper wird aber anscheinend nicht ausgeführt.
Wenn ich WindowHelper über einen AT Job ausführe wird geloggt.
Mache ich einen Denkfehler?
Gruß
Thomas
ZitatMache ich einen Denkfehler?
Poste mal deine gesamte Definition.
Hast du darin ein warningWait oder errorWait definiert?
VG, Thomas
Hallo,
Hier die Definition
defmod FensterMonitoring monitoring .*:(open|tilted) .*:closed
attr FensterMonitoring errorReturn {WindowHelper(1,"test")}
attr FensterMonitoring errorWait {AttrVal($name, "winOpenTimer", 60*5)}
attr FensterMonitoring room monitoring,Test,Unsorted
attr FensterMonitoring warningReturn {WindowHelper(0,"test1");;;;}
Gruß
Thomas
Durch dein errorWait verzögerst du die Ausführung dess errorReturn.
Aber warningReturn sollte eigentlich sofort greifen.
Was passiert wenn du das oben in der Commandline ausführst?
{WindowHelper(0,"test1")}
Passiert dann das was dahinter passieren soll?
Hi,
ja, aus der Befehlszeile wird "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ins log geschrieben.
Gruß
Thomas
Hm... dann bin ich jetzt auch überfragt.
Vielleicht stören die vielen ;;;;;
Ansonsten kann igami vielleicht weiterhelfen.
VG, Thomas
Der return Code wird nur bei einem get ausgeführt, nicht automatisch, wenn ein Device auf eine Liste geschrieben wird.
Morgähn,
wenn ich das jetzt richtig verstanden habe kann aus monitoring keine Aktion ausgelöst werden ( Mail Versand, Telegramm,....).
Es ist immer ein Notify oder DOIF nötig.
Gruß
Thomas
korrekt
Hallo,
hab es endlich zum laufen gebracht ;D
Das Problem waren die Backslashs aus "Raw definition"
blacklist: HM_RT_.*._WindowRec
errorReturn:
{return unless(@errors);
$_ = AttrVal($_, "alias", $_) foreach(@errors);
return("Das Fenster \"$errors[0]\" ist schon länger geöffnet.") if(int(@errors) == 1);
@errors = sort {lc($a) cmp lc($b)} @errors;
return(join("\n - ", "Die folgenden ".@errors." Fenster sind schon länger geöffnet:", @errors))
}
errorWait: {AttrVal($name, "winOpenTimer", 60*15)}
warningReturn:
{return unless(@warnings);
$_ = AttrVal($_, "alias", $_) foreach(@warnings);
return("Das Fenster \"$warnings[0]\" ist seit kurzem geöffnet.") if(int(@warnings) == 1);
@warnings = sort {lc($a) cmp lc($b)} @warnings;
return(join("\n - ", "Die folgenden ".@warnings." Fenster sind seit kurzem geöffnet:", @warnings))
}
Notify WindowOpenError:
FeFensterMonitoring:error.(add):..+ {
my $msg = (fhem("get TYPE=monitoring error"));
{ system "echo '$msg' | mail -s 'FHEM Fenster warnung' xxxxxx\@xxxx.xx" };
"set JabberClient msg xxxxx\@xxxxxx.xx".$msg;
}
Notify WindowOpenWarning:
FensterMonitoring:warning.(add):..+ {
my $msg = (fhem("get TYPE=monitoring error"));
{ system "echo '$msg' | mail -s 'FHEM Fenster warnung' xxxxxx\@xxxx.xx" };
"set JabberClient msg xxxxx\@xxxxxx.xx".$msg;
}
Gruß
Thomas
Moin,
ZitatDefine
define <name> <add-event> [<remove-event>]
Die Syntax für <add-event> und <remove-event> ist die gleiche wie für das Suchmuster von notify (Gerätename oder Gerätename:Event).
Ist nur ein <add-event> definiert wird beim auftreten das Gerät von beiden Listen gelöscht und die Timer für warning und error werden gestartet.
Fehler, oder soll das so in der Commandref? Da fehlt der Aufruf des Moduls im define.
also :
define <name> monitoring <add-event> [<remove-event>]
Interesssantes Modul. Ich hänge mich hier mal rein, da ich mir das am Wochennede mal asnsehen möchte. Danke schon mal im Vorraus für deine Arbeit.
Zitat von: automatisierer am 01 Dezember 2017, 10:22:09
Moin,Fehler, oder soll das so in der Commandref? Da fehlt der Aufruf des Moduls im define.
also :
define <name> monitoring <add-event> [<remove-event>]
Das ist ein Fehler. Werde ich bei Gelegenheit korrigieren, wenn ich auch nochmal die Beispiele anpasse.
Hallo,
ich möchte die desired-temp meiner Homematic Thermostate überwachen und wenn ein Thermostat längere Zeit auf 12.0 Grad ist eine Meldung bekommen.
Ich scheitere aber an der Definition. Über einen RegEx Tester funktioniert die RexEx.
Wenn nun ein Thermostat auf 12.0 Grad gestellt wird, wird das auch vom Monitoring erkannt, aber nach dem das Thermostat wieder die normale Temperatur hat, wird das Gerät nicht wieder aus der Error-Liste gelöscht. Was mache ich falsch?
Hier die definition:
.*:desired-temp:.1?[2].[0]$ .*:desired-temp:.?[0-1|3-9].[0-9]$|.?22.[0-9]$
Grüße
Oliver
ZitatÜber einen RegEx Tester funktioniert die RexEx
Hey, dein zweiter Regex ist nicht so ganz korrekt wenn du tatsächlich immer auf "Nicht 12.0" Grad reagieren möchtest.
Probier mal folgenes:
([1-9][1|3-9]?|[2][1-9])\.[0-9]$VG, Thomas
Zitat von: ToM_ToM am 05 Dezember 2017, 10:51:37
Hey, dein zweiter Regex ist nicht so ganz korrekt wenn du tatsächlich immer auf "Nicht 12.0" Grad reagieren möchtest.
Probier mal folgenes:
([1-9][1|3-9]?|[2][1-9])\.[0-9]$
VG, Thomas
Klappt auch nicht.
Habe es mit einem Dummy und folgender DEF erfolgreich getestet:
.*:desired-temp:.12 .*:desired-temp:.(?!12$).*
Zitat von: igami am 10 Dezember 2017, 18:10:58
Habe es mit einem Dummy und folgender DEF erfolgreich getestet:
.*:desired-temp:.12 .*:desired-temp:.(?!12$).*
Das ist echt seltsam. Es funktioniert tatsächlich mit einem Test-Dummy, aber es reagiert nicht auf Homematic HM-CC-RT-DN bzw. HM-TC-IT-WM-W-EU
hast du bei deinen HM-CC-RT-DN bzw. HM-TC-IT-WM-W-EU eventuell event-on-change-reading auf ein bestimmtes Reading gesetzt? so dass keine entsprechenden Events kommen?
EDIT:
.*:desired-temp:.12.* .*:desired-temp:.(?!12$).*
HT und WT senden:
desired-temp 12.0
Zitat von: automatisierer am 10 Dezember 2017, 20:31:27
HT und WT senden:
desired-temp 12.0
Ohne Doppelpunkt?
Zeig mal bitte einen Auszug aus dem Eventmonitor.
nein, mit :
Climate desired-temp: 20.5
sorry, den hab ich unterschlagen.
mir ging es um das .0 , welches hinter der 12 steht.
Dadurch triggert
desired-temp:.12
dann nicht.
Ja, dann musst du nur noch .0 hinter der 12 ergänzen, dann sollte das funktionieren.
Zitat von: igami am 13 Dezember 2017, 09:09:00
Ja, dann musst du nur noch .0 hinter der 12 ergänzen, dann sollte das funktionieren.
so funktioniert das jetzt:
.*:desired-temp:.12.0 .*:desired-temp:.(?!12.0$).*
Vielen Dank für eure Untersützung!
Hallo allersteits. Vorweg erst mal sehr cooles und hilfreiches Modul.
Ich konnte dadurch eine menge Dummys und Notifys einsparen, stoße aber grade an einige Grenzen (wohl auch aufgrund eingeschränkter Perl Kenntnisse).
Folgender Usecase:
Ich habe im Keller einen Lufttrockner mit Wassertank stehen, der regelmäßig volläuft. Im betreffenden raum messe ich über einen TX29DTH-IT Temperatur und Luftfeuchtigkeit.
Den Energieverbrauch des Lufttrockners wiederum messe ich über eine Zwave Steckose mit Energiemessung.
Das Error-Ereigniss definiere ich derzeit indem ein Notify bei jeder Veränderung der rel. Feuchtigkeit prüft, wie hoch der Stromverbrauch des Trockners ist. Wenn Luftfeuchtigkeit > 55% und Energieverbrauch < 5W, bedeutet das, dass der Trockner nicht anspringt, weil vmtl. voll.
Nun ist mir nicht ganz klar, wie ich das mit dem monitoring Device abbilden soll. In der Def des monitoring moduls kann ich ja nur auf ein Reading prüfen und nicht auf das Ergebnis einer Vergleichsoperation. Meine Verständnis ist, dass dafür errorFuncAdd vorgesehen ist. Allerdings verstehe ich aus den beigefügten Beispielen nicht so recht, wie ich das abbilden müsste. Auf ein vorausgehendes Warning würde ich auch gerne verzichten wollen.
In einem ersten Versuch mit errorFuncAdd scheint diese garnicht anzuziehen. Insofern habe ich den Mechanismus wohl nicht richtig verstanden und bin für hilfreiche Erläuterungen sehr dankbar.
Und so sieht mein Monitoring Device aus:
defmod CheckState_LufttrocknerVoll monitoring KG_(vk|wk)_TF_Klimasensor:humidity.*
attr CheckState_LufttrocknerVoll errorFuncAdd {
my $room = substr($name,3,2);
fhem("setreading CheckState_LufttrocknerVoll TestReading $room");
return 1;
}
attr CheckState_LufttrocknerVoll errorReturn {return unless(@errors) }
attr CheckState_LufttrocknerVoll errorWait 0
attr CheckState_LufttrocknerVoll warningReturn {return unless(@warnings) }
Hilfreiche Erläuterung mache ich morgen mal in Ruhe. Erstmal eine Nachstellung mit dummy:
defmod Lufttrockner dummy
attr Lufttrockner readingList power
attr Lufttrockner room pano
attr Lufttrockner setList power:slider,0,1,100
attr Lufttrockner stateFormat P: power
attr Lufttrockner webCmd power
setstate Lufttrockner P: 20
setstate Lufttrockner 2017-12-15 23:38:56 power 20
defmod TX29DTH dummy
attr TX29DTH readingList humidity
attr TX29DTH room pano
attr TX29DTH setList humidity:slider,0,1,100
attr TX29DTH stateFormat H: humidity
attr TX29DTH webCmd humidity
setstate TX29DTH H: 22
setstate TX29DTH 2017-12-15 23:38:59 humidity 22
defmod CheckState_LufttrocknerVoll monitoring TX29DTH:humidity.*
attr CheckState_LufttrocknerVoll errorFuncAdd {\
return 1 if(ReadingsNum("Lufttrockner", "power", 0) < 5);;\
return;;\
}
attr CheckState_LufttrocknerVoll errorFuncRemove {\
return 1 if(ReadingsNum("Lufttrockner", "power", 0) >= 5);;\
return;;\
}
attr CheckState_LufttrocknerVoll room pano
Nun noch einmal ausführlich und etwas angepasst.
In der DEF wird, wie bei einem notify, das Ereignis angegeben wann geprüft wird. In deinem Fall ist das Luftfeuchtigkeit > 55%.
In dem errrorFuncAdd Attribut kann spezifiziert werden wann das Gerät auf die Error Liste gesetzt wird. In deinem Fall bei Energieverbrauch < 5W.
Nun kann man noch das errorFuncRemove Attribut setzen um das Gerät auch wieder Automatisch entfernen zu lassen.
Durch deine DEF "KG_(vk|wk)_TF_Klimasensor:humidity.*" gehe ich davon aus, dass du mehrere Sensoren und Lufttrockner hast.
Ich habe bei mir nun je zwei dummys angelegt.
Rausgekommen ist dabei folgendes (Raw definition):
defmod KG_vk_Lufttrockner dummy
attr KG_vk_Lufttrockner readingList power
attr KG_vk_Lufttrockner room pano
attr KG_vk_Lufttrockner setList power:slider,0,1,100
attr KG_vk_Lufttrockner stateFormat P: power
attr KG_vk_Lufttrockner webCmd power
defmod KG_vk_TF_Klimasensor dummy
attr KG_vk_TF_Klimasensor readingList humidity
attr KG_vk_TF_Klimasensor room pano
attr KG_vk_TF_Klimasensor setList humidity:slider,0,1,100
attr KG_vk_TF_Klimasensor stateFormat H: humidity
attr KG_vk_TF_Klimasensor webCmd humidity
defmod KG_wk_Lufttrockner dummy
attr KG_wk_Lufttrockner readingList power
attr KG_wk_Lufttrockner room pano
attr KG_wk_Lufttrockner setList power:slider,0,1,100
attr KG_wk_Lufttrockner stateFormat P: power
attr KG_wk_Lufttrockner webCmd power
defmod KG_wk_TF_Klimasensor dummy
attr KG_wk_TF_Klimasensor readingList humidity
attr KG_wk_TF_Klimasensor room pano
attr KG_wk_TF_Klimasensor setList humidity:slider,0,1,100
attr KG_wk_TF_Klimasensor stateFormat H: humidity
attr KG_wk_TF_Klimasensor webCmd humidity
defmod CheckState_LufttrocknerVoll monitoring KG_(vk|wk)_TF_Klimasensor:humidity:.(5[5-9]|[6-9][0-9])
attr CheckState_LufttrocknerVoll errorFuncAdd {\
$name =~ s/TF_Klimasensor/Lufttrockner/;;\
return 1 if(ReadingsNum($name, "power", 0) < 5);;\
return;;\
}
attr CheckState_LufttrocknerVoll errorFuncRemove {\
$name =~ s/TF_Klimasensor/Lufttrockner/;;\
return 1 if(ReadingsNum($name, "power", 0) >= 5);;\
return;;\
}
attr CheckState_LufttrocknerVoll room pano
Da das auslösende Gerät ja der Sensor ist muss in dem errorFuncX Attribut noch der Name auf den Trockner geändert werden. Habe ich hier einfach mal durch suchen und ersetzen gemacht.
Grüße
igami
Großartig, danke für die Hilfestellung.
Das mit dem Umbenennen ist sehr effizient, auch wenn ich in einem Monat sicher nicht mehr weiss, waum das da steht ;-)
In welche Richtung möchtest Du das Modul eigentlich weiterentwickeln, bzw. welcher Anwendungsfall schwebte dir dabei vor?
Hintergrund der Frage ist, dass ich seit einiger Zeit rumbastel wie man Überwachung und Alarmierung der Heimautomation sinnvoll ausgestalten/umsetzen kann.
Meine bisherigen Überlegungen führen aber - je nach Größe der FHEM Installation - zu einer enormen Menge von Dummys, Notifys, Komplexität.
Dein Modul hilft da schon einiges zu konsolidieren. Wenn das den Fokus dieses Threads nicht sprengt, würde ich mich gerne hier mit dir und anderen Interessierten über mögliche Usecases und Implementierungsvarianten austauschen.
Der Ansatz, den ich bisher gedanklich vefolgt hatte war anforderungsseitig:
a1) Überwachung der technischen Komponenten => zB Server/Sensor/Aktor lebt noch
a2) Überwachung von (logischen) Zuständen => zB ist es zu kalt, ist das Fenster zu lange offen, ist der Lufttrockner voll
a3) Erkennen von Fehlerursachen => zB is ist zu kalt, weil das Fenster offen ist oder der heizungsregler ausgestellt ist
a4) Erkennen von unspezifischen Problemen => zB Anzahl von Logeinträgen pro Zeit steigt
Der nächste Schritt wäre die sinnvolle Darstellung und Benachrichtigung von Events (da ich zu Hause keinen Leitstand mit Displaywand voller Dashboards durchgesetzt bekomme).
b1) kontinuierliche Meldung bei Fehlern => zB Rote Lampe leuchtet, Sirene heult, ... solange Fehler andauert
b2) diskrete Benachrichtigung => Aussteuern von Mails/SMS/... mindestens beim Eintreten und Auflösen eines Fehlers, ggf. periodisches wiedererinnern
b3) Eventeskalation => Retest um "Verschlucker" und False-Positives zu erkennen, Wechseln von Warnings zu Critical nach x Retests oder Fehlerdauer, etc.
b4) Komfortfunktionen => Sleep/Mute und Ignore von Alarmen, die man temporär "akzeptieren" möchte
Nach Erkennung und Benachrichtigung von Fehlerzuständen ginge es dann noch an das Lösen des eigentlichen Problemes:
c1) Triggern von Aktionen zur "Selbstheilung" (zB Neustart von FHEM, erneutes Ansprechen von Aktoren,...)
c2) Handlungsempfehlungen ausgeben (zB "Fenster sollte geschlossen werden", Lufttrockner ausleeren")
Ach ja, dass das Ganze auch bis zu einem gewissen Punkt Ehefrauenkompatibel sein muss versteht sich natürlich von selbst ;-)
FHEM bietet jetzt schon diverse Module, die Teilaufgaben hiervon übernehmen können (Alarm, actiondetector, monitoring um einige zu nennen). Andererseits gibt es auch am Markt Tools, die zB auf das Managen von Events (zB Nagios) oder das Darstellen von Zuständen/Dashboards spezialisiert sind (letzteres wird grade durch das recht neue InfluxDB Modul in Kombination mit Grafana recht interessant)
Soll heissen, im Zweifel und mithilfe aller möglichen Module und selbstgebastelter Utils bekommt man sicherlich alles auch innerhalb von FHEM hin. Fraglich ist aber, ob das auch der sinnvollste Weg ist.
Ich denke, da FHEM in den meisten Fällen die Steuerung des SmartHomes übernimmt, wäre hier die Bestimmung von Fehlern aus a2) sinnvoll aufgehoben, vmtl. auch a3). Bei a1) wäre ich mich schon nicht mehr sicher, ob man das nicht besser auslagern sollte, insb. wenn man über FHEM hinaus noch weitere Komponenten (NAS, Router, ...) im Netzwerk stehen hat.
Spätestens bei b1) bis b4) stellt sich die Frage, ob ein System sich selbst überwachen und melden soll, da ein Komplettausfall des Systemes auch die Überwachung selbst betreffen würde. Davon abgesehen wäre die robuste Nachbildung all der Funktionen von bestehender spezialisierter Software recht aufwändig. Fairerweise würde ich aber auch das in b1) beschriebene Leuchten der Roten Lampe durch FHEM lösen, aber vielleicht sinnvollerweise einer getrennten FHEM Installation (wozu hat man üblicherweise unmengen Raspis im Haus ;-)
Ähnlich verhält es sich mit c1) und c2). Ist es die richtige Strategie die Problemlösung vom betroffenen System selbst triggern zu lassen, oder sollte man da eher auf Drittsysteme (zusätzliche FHEM Installation, Jobsteuerung a la Jenkins) zurückgreifen.
Ideen und Meinungen sind herzlich willkommen.
Zitat von: pano am 17 Dezember 2017, 00:22:52
Das mit dem Umbenennen ist sehr effizient, auch wenn ich in einem Monat sicher nicht mehr weiss, waum das da steht ;-)
Kommentare, durch # eingeleitet, sind momentan leider noch nicht möglich, da muss ich noch nach gucken wie ich das umsetzen kann.
Zitat von: pano am 17 Dezember 2017, 00:22:52
In welche Richtung möchtest Du das Modul eigentlich weiterentwickeln, bzw. welcher Anwendungsfall schwebte dir dabei vor?
Die Idee zu dem Modul kommt daher, dass ich eine relativ große FHEM Installation in einer Firma administriert habe.
Irgendwie musste man dann ja überwachen bei welchen Funkaktoren die Batterie nachlässt. Bei den Beispielen die es gab wird immer bei battery: low eine E-Mail verschickt. Dabei bedeutet low ja nicht leer, weiterhin pendelt der Status auch gerne zwischen high und low wenn man sich an der Grenze befindet und ich wollte auch nicht außerhalb der Arbeitszeit eine so unwichtige Nachricht erhalten, dass die Batterie bald leer ist. Daraufhin habe ich monitoring entwickelt. Neben den Batterien gab es dann noch die Filterüberwachung der Klimaanlagen, Fehlermeldungen von APs und anderen Geräten, etc.
Zitat von: pano am 17 Dezember 2017, 00:22:52
Hintergrund der Frage ist, dass ich seit einiger Zeit rumbastel wie man Überwachung und Alarmierung der Heimautomation sinnvoll ausgestalten/umsetzen kann.
Meine bisherigen Überlegungen führen aber - je nach Größe der FHEM Installation - zu einer enormen Menge von Dummys, Notifys, Komplexität.
Dein Modul hilft da schon einiges zu konsolidieren. Wenn das den Fokus dieses Threads nicht sprengt, würde ich mich gerne hier mit dir und anderen Interessierten über mögliche Usecases und Implementierungsvarianten austauschen.
Der Ansatz, den ich bisher gedanklich vefolgt hatte war anforderungsseitig:
a1) Überwachung der technischen Komponenten => zB Server/Sensor/Aktor lebt noch
a2) Überwachung von (logischen) Zuständen => zB ist es zu kalt, ist das Fenster zu lange offen, ist der Lufttrockner voll
a3) Erkennen von Fehlerursachen => zB is ist zu kalt, weil das Fenster offen ist oder der heizungsregler ausgestellt ist
a4) Erkennen von unspezifischen Problemen => zB Anzahl von Logeinträgen pro Zeit steigt
Die Fällte a1, a2 und a4 sollten sich durch monitoring abbilden lassen.
Die ganzen Benachrichtigunen b sind bewusst nicht in monitoring implementiert, das es viel zu viele verschiedene Möglichkeiten gibt. Auf der Arbeit habe ich noch ein userattr priority eingebaut. Fällt die Klimaanlage im Serverraum aus bekomme ich sofort eine Benachrichtigung, ansonsten bekomme ich nur Benachrichtigungen während der Arbeitszeit. Das ganze ist mit einem DOIF gelöst.
Zitat von: pano am 17 Dezember 2017, 00:22:52
Der nächste Schritt wäre die sinnvolle Darstellung und Benachrichtigung von Events (da ich zu Hause keinen Leitstand mit Displaywand voller Dashboards durchgesetzt bekomme).
b1) kontinuierliche Meldung bei Fehlern => zB Rote Lampe leuchtet, Sirene heult, ... solange Fehler andauert
b2) diskrete Benachrichtigung => Aussteuern von Mails/SMS/... mindestens beim Eintreten und Auflösen eines Fehlers, ggf. periodisches wiedererinnern
b3) Eventeskalation => Retest um "Verschlucker" und False-Positives zu erkennen, Wechseln von Warnings zu Critical nach x Retests oder Fehlerdauer, etc.
b4) Komfortfunktionen => Sleep/Mute und Ignore von Alarmen, die man temporär "akzeptieren" möchte
Zu Hause habe ich das userattr executor welches ich mit Residents verknüpft habe um die "Aufgaben" an bestimmte Personen zu verteilen. Die Benachrichtigung erfolgt über Telegram. Die Benachrichtigung wird dabei 15 Minuten nach dem man nach hause kommt automatisch versendet. Alternativ kann sie manuell abgerufen werden.
Zitat von: pano am 17 Dezember 2017, 00:22:52
Nach Erkennung und Benachrichtigung von Fehlerzuständen ginge es dann noch an das Lösen des eigentlichen Problemes:
c1) Triggern von Aktionen zur "Selbstheilung" (zB Neustart von FHEM, erneutes Ansprechen von Aktoren,...)
c2) Handlungsempfehlungen ausgeben (zB "Fenster sollte geschlossen werden", Lufttrockner ausleeren")
Hier ist es ähnlich wie bei b. Es ist von Fall zu Fall unterschiedlich was die richtige Vorgehensweise ist. C2 lässt sich durch das Attribut errorReturn umsetzen, dies dient dazu die Nachricht zu formatieren. So bekommt man nicht nur die Namen der Geräte mit niedrigen Batteriestand sondern eine Nachricht in der Form:
Zitat
Bei den folgenden 3 Geräten muss die Batterie gewechselt werden:
- Arbeitszimmer: Fenster links
- Wohnzimmer: Heizung
- Flur: Bewegungsmelder
Zitat von: pano am 17 Dezember 2017, 00:22:52
Ach ja, dass das Ganze auch bis zu einem gewissen Punkt Ehefrauenkompatibel sein muss versteht sich natürlich von selbst ;-)
Das liegt in deiner Hand. Ich habe diverse DashButtons in der Wohnung verteilt. Wurde der Wasserfilter gewechselt: drücken. Das klappt wunderbar. Ich wurde nur gebeten noch bald ausstehende Aufgaben auch mit anzugeben, wie "In 3 Tagen muss der Wasserfilter gewechselt werden". Das lässt sich ja durch die warning Liste managen.
Zitat von: pano am 17 Dezember 2017, 00:22:52
FHEM bietet jetzt schon diverse Module, die Teilaufgaben hiervon übernehmen können (Alarm, actiondetector, monitoring um einige zu nennen). Andererseits gibt es auch am Markt Tools, die zB auf das Managen von Events (zB Nagios) oder das Darstellen von Zuständen/Dashboards spezialisiert sind (letzteres wird grade durch das recht neue InfluxDB Modul in Kombination mit Grafana recht interessant)
Soll heissen, im Zweifel und mithilfe aller möglichen Module und selbstgebastelter Utils bekommt man sicherlich alles auch innerhalb von FHEM hin. Fraglich ist aber, ob das auch der sinnvollste Weg ist.
Ich denke, da FHEM in den meisten Fällen die Steuerung des SmartHomes übernimmt, wäre hier die Bestimmung von Fehlern aus a2) sinnvoll aufgehoben, vmtl. auch a3). Bei a1) wäre ich mich schon nicht mehr sicher, ob man das nicht besser auslagern sollte, insb. wenn man über FHEM hinaus noch weitere Komponenten (NAS, Router, ...) im Netzwerk stehen hat.
Spätestens bei b1) bis b4) stellt sich die Frage, ob ein System sich selbst überwachen und melden soll, da ein Komplettausfall des Systemes auch die Überwachung selbst betreffen würde. Davon abgesehen wäre die robuste Nachbildung all der Funktionen von bestehender spezialisierter Software recht aufwändig. Fairerweise würde ich aber auch das in b1) beschriebene Leuchten der Roten Lampe durch FHEM lösen, aber vielleicht sinnvollerweise einer getrennten FHEM Installation (wozu hat man üblicherweise unmengen Raspis im Haus ;-)
Ähnlich verhält es sich mit c1) und c2). Ist es die richtige Strategie die Problemlösung vom betroffenen System selbst triggern zu lassen, oder sollte man da eher auf Drittsysteme (zusätzliche FHEM Installation, Jobsteuerung a la Jenkins) zurückgreifen.
Zu a1: da kommt es darauf an ob FHEM das sicher überwachen kann. Geräte ohne Rückkanal lassen sich schlecht überwachen. Beim Server ist die Frage was man überwachen will: Stromverbrauch, Temperatur, erreichbarkeit per Ping, Stauts von Diensten, etc.
Wie heißt es doch so schön? Quis custodiet ipsos custodes? zu deutsch: Wer überwacht die Wächter? Sie überwachen sich gegenseitig. FHEM die NAS und die NAS FHEM.
Zitat von: pano am 17 Dezember 2017, 00:22:52
Ideen und Meinungen sind herzlich willkommen.
Ich bin auch für jedes Brainstorming offen. Wenn du noch weitere Anwendungsfälle hast immer her damit!
Ich selbst nutze monitoring als Aufgabensteuerung für:
- den Abfallkalender (Morgen wird XX abgeholt)
- den Wechsel der Bettwäsche (im Sommer ein anderes Intervall als im Winter, Bestätigung über einen DashButton)
- das Entkalken des Duschkopfs (Bestätigung über einen DashButton)
- den Wechsel des Wasserfilters (Bestätigung über einen DashButton)
- die Überwachung von Batterieständen
- das Ablesen von Strom-, Wasser- und Wärmemengenzählern (Eingabe über Telegram)
- den Wechsel der Zahnbürste (Bestätigung über einen DashButton)
- das Umschalten der Heizung zwischen Sommer- und Winterbetrieb
Weiterhin noch als Statusanzeige für geöffnete Fenster. Beim zubett gehen bekomme ich eine Nachricht und kann noch fix das Fenster im Bad schließen, damit es am nächsten Morgen nicht so kalt ist :D
Meiner Meinung nach ist FHEM eine gute Backend Software. Als Frontend gibt es dann Tablet UI oder Telegram, sofern benötigt.
Ich freue mich auch immer, wenn user einen Wiki Beitrag zu Modulen schreiben. Ich selbst bin nur leider nicht so Wortgewand und habe auch Angst, dass der Beitrag dann auf einem alten Stand bleibt (wie die Commandref zu monitoring auch schon :-[) und falsche Informationen sind schlimmer als gar keine.
Hallo igami.
Zuerst mal zu meinen Usecases.
meine Alarmierungen (wobei ich noch nicht weiss, welche davon ich mit Monitoring umsetzen werde):
- Fenster offen länger als x Minuten
- Fenster nicht mehr geöffnet seit x Stunden
- Raumtemperatur unter x Grad
- Fenster offen bei Taupunkt Innen > Taupunkt Aussen
- Waschmaschine / Waschtrockner Fertig (via Energieabfall an Energiemesssteckdose)
- Luftentfeuchter voll
- Jeelink-Temperatursensoren noch am Leben (gelegentlich muss der Jeelink mal reopened werden)
Darüber hinaus betreibe ich drei weitere Raspis für
- Anwesenheitserkennung (PiZero im Flur bei der Schlüsselablage, Schlüssel mit GTags ausgerüstet)
- Auslesen gaszähler und Stromzähler (per reed, bzw. Infrarotschnittstelle)
- Pi3 mit RaspiCam und Python/OpenCV-Scripten zum Ablesen des Betriebsmodus meiner Uralt-Heizungsanlage (via eines 7-Segment Display)
Alle drei stellen gelegentlich mal den Dienst ein und bedürfen eines "gegentretens"
Nun ein paar Anmerkungen/Vorschläge zum monitoring-Device als solchen.
a1) Status des monitoring Devices
In meinem aktuellen Setup habe ich spasseshalber 6 monitoring-Devices erzeugt (Fenster offen, Haustür offen, Garage offen, Lufttrockner voll, Raumtemperatur niedrig, Raumfeuchte hoch).
Unschön finde ich, dass man auf der Oberfläche (im State) nicht sieht, ob grade ein Fehler vorliegt (insb. wenn ein monitoring Device mehrere Geräte überwacht). Stattdessen sieht man welches Event als letztes ausgesteuert wurde. Das wiederum könnte interessant sein, da aber hier ein Zeitstempel fehlt hilft das nur bedingt.
Eine bessere State-Darstellung fände ich also zB "x Errors | y Warnings".
Alternativ und analog zu heute "warning remove: <ein device> (um hh:mm)". Noch cooler wäre "Fehler bei <ein device> seit xy Stunden" (wobei ich allerdings nicht sicher bin, ob man in einem State einen sich periodisch verändernden Text hinterlegen sollte)
a2) Wechsel von Warning zu Error nach x Retrys
Derzeit basiert der Wechsel von einem in den anderen Status lediglich auf einer Fehlerdauer (attr errorWait). Gut wäre es, wenn es auch die Möglichkeit gäbe eine Anzahl von aufeinanderfolgenden Warning-Events zu hinterlegen nach denen in Error gewechselt wird. Zeitbasiert lässt sich das ansonsten nur "schätzungsweise" abbilden wenn mann Annahmen triift, wie oft eine Messung sich wiederholen könnte.
Zitat von: pano am 17 Dezember 2017, 23:47:02
a1) Status des monitoring Devices
In meinem aktuellen Setup habe ich spasseshalber 6 monitoring-Devices erzeugt (Fenster offen, Haustür offen, Garage offen, Lufttrockner voll, Raumtemperatur niedrig, Raumfeuchte hoch).
Unschön finde ich, dass man auf der Oberfläche (im State) nicht sieht, ob grade ein Fehler vorliegt (insb. wenn ein monitoring Device mehrere Geräte überwacht). Stattdessen sieht man welches Event als letztes ausgesteuert wurde. Das wiederum könnte interessant sein, da aber hier ein Zeitstempel fehlt hilft das nur bedingt.
Eine bessere State-Darstellung fände ich also zB "x Errors | y Warnings".
Alternativ und analog zu heute "warning remove: <ein device> (um hh:mm)". Noch cooler wäre "Fehler bei <ein device> seit xy Stunden" (wobei ich allerdings nicht sicher bin, ob man in einem State einen sich periodisch verändernden Text hinterlegen sollte)
Das soll doch bitte jeder so handhaben wie er möchte. Ich persönlich habe eine in den myUtils eine sub für stateFormat
sub monitoring_stateFormat($) {
my ($SELF) = @_;
my $ret = fhem("get $SELF all");
if($ret){
$ret =~ s/\n/<br>/g;
return('<div style="text-align: left">' . $ret . '</div>' );
}
return("keine Meldungen");
}
Zitat von: pano am 17 Dezember 2017, 23:47:02
a2) Wechsel von Warning zu Error nach x Retrys
Derzeit basiert der Wechsel von einem in den anderen Status lediglich auf einer Fehlerdauer (attr errorWait). Gut wäre es, wenn es auch die Möglichkeit gäbe eine Anzahl von aufeinanderfolgenden Warning-Events zu hinterlegen nach denen in Error gewechselt wird. Zeitbasiert lässt sich das ansonsten nur "schätzungsweise" abbilden wenn mann Annahmen triift, wie oft eine Messung sich wiederholen könnte.
Da muss ich nächstes Jahr mal drüber nachdenken. Da ich bei fast allen Geräten event-on-change-reading verwende ergibt sich bei mir der Anwendungsfall mit wiederholenden Events nicht.
ZitatDa muss ich nächstes Jahr mal drüber nachdenken. Da ich bei fast allen Geräten event-on-change-reading verwende ergibt sich bei mir der Anwendungsfall mit wiederholenden Events nicht.
Das wäre bei MAX Thermostaten sehr interessant, die irgendwann anfangen "Battery low" Events zu machen aber immer wieder nochmal zu "Battery ok" zurückspringen bis dann irgendwann Ende ist.
Zitat von: zweiundzwanzig am 24 Dezember 2017, 10:15:56
Das wäre bei MAX Thermostaten sehr interessant, die irgendwann anfangen "Battery low" Events zu machen aber immer wieder nochmal zu "Battery ok" zurückspringen bis dann irgendwann Ende ist.
Das ist bei HomeMatic auch so, deswegen lasse ich mich auch erst benachrichtigen, wenn die low Meldung zwei Wochen ansteht, da low ja auch nicht leer bedeutet ;)
Hallo igami, ich beobachte seit einigen Monaten immer wieder dass die Geräte nicht auf die Error-Liste verschoben, sondern kopiert werden.
Könntest du bitte mal einen Blick auf meine Konfiguration werfen? Evtl. übersehe ich ja einfach nur einen Fehler.
defmod Flower_monitoring monitoring Pflanze_0?[0-9]*:moisture:.(1?[0-9])$ Pflanze_0?[0-9]*:moisture:.(1?[2-9][0-9])
attr Flower_monitoring DbLogExclude .*
attr Flower_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Bei dem Gerät \"$errors[0]\" muss die Batterie gewechselt werden.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Bei folgenden ".@errors." Geräten muss die Batterie gewechselt werden:", @errors))\
}
attr Flower_monitoring errorWait 60*60*24*7
attr Flower_monitoring group Monitoring
attr Flower_monitoring room FlowerSens
attr Flower_monitoring userReadings warning_count:warning.+ {split(",", ReadingsVal($name, "warning", ""))}, \
error_count:error.+ {split(",", ReadingsVal($name, "error", ""))}, \
all_count:(warning.+|error.+) {split(",", ReadingsVal($name, "warning", "")) + split(",", ReadingsVal($name, "error", ""))}
attr Flower_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Bei dem Gerät \"$warnings[0]\" muss die Batterie demnächst gewechselt werden.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Bei folgenden ".@warnings." Geräten muss die Batterie demnächst gewechselt werden:", @warnings))\
}
setstate Flower_monitoring active
setstate Flower_monitoring 2017-12-28 21:00:10 all_count 7
setstate Flower_monitoring 2017-12-28 20:59:26 error Pflanze_03,Pflanze_04,Pflanze_06
setstate Flower_monitoring 2017-12-22 23:27:33 errorAdd_Pflanze_02 2017-12-29 23:27:33
setstate Flower_monitoring 2017-12-28 20:59:26 error_count 3
Vielen Dank!
VG, Thomas
Hallo
Ich glaube das hier was passendes gefunden habe für mich. Und zwar ich habe eine Alte Wanduhr vergesse sie manchmal aufzuziehen. Doof aber nicht tragisch. Ich würde gerne über meine Tablet Ui seite einen Button bekommen. reicht das wenn ich den dashbutton dann einfach mit einem Dummy austausche?? und benötige ich noch weitere module?
Und vielleicht könnte mir ja einer helfen.
Bin nicht sehr gut im umgang mit fhem.
danke schon mal.
Und schon mal einen guten Rutsch. ;)
Zitat von: ToM_ToM am 29 Dezember 2017, 20:20:41
Hallo igami, ich beobachte seit einigen Monaten immer wieder dass die Geräte nicht auf die Error-Liste verschoben, sondern kopiert werden.
Sieht soweit gut aus, nur dass die Nachricht ja irgendwas mit gießen und nicht mit Batterien sein sollte ;)
Das von dir beschriebene Verhalten kann auftreten, wenn nach einem Neustart geprüft wird ob in der Vergangenheit ein Gerät auf eine Liste gesetzt werden muss. Falls es auf beide gesetzt werden muss landet es auch auf beiden.
Startest du dein FHEM häufiger neu?
Zitat von: Wasserwerk33 am 30 Dezember 2017, 12:55:02
Hallo
Ich glaube das hier was passendes gefunden habe für mich. Und zwar ich habe eine Alte Wanduhr vergesse sie manchmal aufzuziehen. Doof aber nicht tragisch. Ich würde gerne über meine Tablet Ui seite einen Button bekommen. reicht das wenn ich den dashbutton dann einfach mit einem Dummy austausche?? und benötige ich noch weitere module?
Und vielleicht könnte mir ja einer helfen.
Bin nicht sehr gut im umgang mit fhem.
danke schon mal.
Und schon mal einen guten Rutsch. ;)
Ja, der Austausch reicht. Versuch es bitte erst mal selbst, wenn es dann noch nicht funktioniert helfe ich dir gerne.
Guten Rutsch!
igami
Danke werde es probieren. Aber die Antwort das es mit diesem Modul klappt hilft mir schon mal weiter
Danke
ZitatStartest du dein FHEM häufiger neu?
Hey igami, frohes und gesundes Neues erst mal! :) Das mit den Batterien stimmt. War mir gar nicht aufgefallen da ich die Nachricht nicht weiter verwende, sondern nur die Counter. :D
Ja, ich starte FHEM des Öfteren neu, da ich ja immer wieder an meinem System irgendwas rumbastel. Speichert er nicht die aktuellen Zustände und stellt diese nach dem Neustart einfach nur wieder her?
VG, Thomas
Zitat von: ToM_ToM am 01 Januar 2018, 20:13:39
Ja, ich starte FHEM des Öfteren neu, da ich ja immer wieder an meinem System irgendwas rumbastel. Speichert er nicht die aktuellen Zustände und stellt diese nach dem Neustart einfach nur wieder her?
Hmm, ich sehe grade, dass meine Vermutung auf dich nicht zutreffen kann, da du kein warningWait verwendest.
Muss ich mir doch noch mal genau ansehen.
Ich bin letzte Tage auf das Modul gestoßen und war begeistert das es sowas gibt, da ich schon länger nach so einer eirlegende Wollmilchsau gesucht habe.
Ich verstehe da leider nicht alles und hoffe auf Hilfe hier im Thread.
defmod Activity_monitoring monitoring .*:.*
attr Activity_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))\
}
attr Activity_monitoring errorWait 60*60*24
attr Activity_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräten haben sich seit mehr als 12 Stunden nicht mehr gemeldet:", @warnings))\
}
attr Activity_monitoring warningWait 60*60*12
Irgendwie verstehe ich das return(...) nicht.
Wo taucht diese Meldung auf wenn die Bedingung erfüllt ist? Ich habe es mal mit der Fensterüberwachung testen können, sehe aber nirgendwo die Meldung.
Was mich dann auch zu der Frage führt wie ich ein DOIF/NOTIFY da aufsetzen kann um mir mit pushover eine Nachricht zukommen zu lassen.
Danke für die Hilfe. (Habe übrigens den gesamten Thread durchgelesen, aber für mich keine schlüssige Antwort gefunden)
Zitat von: Soc am 12 Februar 2018, 12:24:31
Ich bin letzte Tage auf das Modul gestoßen und war begeistert das es sowas gibt, da ich schon länger nach so einer eirlegende Wollmilchsau gesucht habe.
Ich verstehe da leider nicht alles und hoffe auf Hilfe hier im Thread.
defmod Activity_monitoring monitoring .*:.*
attr Activity_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))\
}
attr Activity_monitoring errorWait 60*60*24
attr Activity_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräten haben sich seit mehr als 12 Stunden nicht mehr gemeldet:", @warnings))\
}
attr Activity_monitoring warningWait 60*60*12
Irgendwie verstehe ich das return(...) nicht.
Wo taucht diese Meldung auf wenn die Bedingung erfüllt ist? Ich habe es mal mit der Fensterüberwachung testen können, sehe aber nirgendwo die Meldung.
Was mich dann auch zu der Frage führt wie ich ein DOIF/NOTIFY da aufsetzen kann um mir mit pushover eine Nachricht zukommen zu lassen.
Danke für die Hilfe. (Habe übrigens den gesamten Thread durchgelesen, aber für mich keine schlüssige Antwort gefunden)
In Antwort #5 hat igami ein DOIF dazu gepostet.
VG Sebastian
Gesendet von iPad mit Tapatalk
Zitat von: Soc am 12 Februar 2018, 12:24:31
Wo taucht diese Meldung auf wenn die Bedingung erfüllt ist?
gar nicht, die lässt sich nur per get abholen
ZitatHmm, ich sehe grade, dass meine Vermutung auf dich nicht zutreffen kann, da du kein warningWait verwendest.
Muss ich mir doch noch mal genau ansehen.
Hey igami, bist du schon dazu gekommen? :)
Zitat von: ToM_ToM am 13 Februar 2018, 12:47:18
Hey igami, bist du schon dazu gekommen? :)
Ehrlich gesagt habe ich das vergessen :-[
Also gut, dass du mich noch mal daran erinnerst.
Hi igami,
echt ein super Modul. Genau das hat mir noch gefehlt.
Ich hätte auch noch einen Wunsch :P
Ich würde gerne auch den Raum, in dem das gemeldete Gerät ist, in die Meldung mit aufnehmen.
Wäre das möglich?
Würde damit gerne einen Feueralarm melden. Da ist der Raum nicht so unerheblich ;)
Gruß,
Stephan
Hallo Stephan,
wir haben dich auf den letzten Treffen schon vermisst!
In den return Attributen kannst du den Text so formatieren wie du möchtest. Ich verwende nur alias da mir das für eine eindeutige Zuordnung ausreicht. Du kannst natürlich auch noch weitere Attribute auslesen, dies würde ich dann aber eher in eine sub in die myUtils packen.
Wenn du nicht weiter kommst schreib einfach mal den Text auf den du erwartest, dann bekommen wir das schon hin.
Grüße
Michael
ZitatIch würde gerne auch den Raum, in dem das gemeldete Gerät ist, in die Meldung mit aufnehmen.
Das finde ich auch ziemlich interessant :)
Hallo..
Ich versuche schon seit Stunden den <remove Event> so zu definieren, dass auch ein "attr <ueberwachtes device> disable 1" das entsprechende Device aus der Error und Warning Liste entfernt.
Sowas wie:
defmod mon_device monitoring device_.*:presence:.*absent device_.*:(presence.*present)|(disable.*)
nur leider funktioniert das nicht (weder so noch in den 100 Varianten die ich versucht habe ;)
Wenn ich beim blacklist Attribut ein
device_.*:FILTER=disable=
einbaue dann werden zwar devices die bereits disabled sind ignoriert und aus der Liste gelöscht, jedoch nur beim attribut setzen, danach (dynamisch) nicht mehr, d.h. wenn das disable später gesetzt wird...
kann mir da jemand helfen?
Zitat von: clumsy am 08 März 2018, 23:21:56
kann mir da jemand helfen?
Ich weiß wie es funktioniert, die Umsetzung ist aber mit etwas Mühe verbunden:
Guck mal in deinen Event monitor, wenn du das disable Attribut setzt. Dann wird dir auffallen, dass das Event vom global device ausgeht und inetwa so lautet: "global ATTR <name> disable 1".
Folglich muss das monitoring auch auf global horchen.
Dann muss das ganze in der
errorFuncRemove noch auf das eigentliche device gemappt werden.
Für meine DashButtons sieht das so aus:
{
($name) = ($event =~ m/^(.+):/g);
return 1;
}
Hier kommt nun die Mühe, die Syntax so anzupassen, dass es funktioniert.
Danke erstmal für den Tip, werd mir das mal genauer ansehen...
Müsste das aber eigentlich nicht im Modul selbst abgehandelt werden? Ich weiss nur dass andere Module (z.b. structure) "korrekt" darauf reagieren, d.h. das entsprechende Device aus der Struktur entfernen, resp. nicht mehr beachten für den Status.
Ist nur als Anregung gemeint, nicht als Kritik! Das monitoring Modul sonst ist (für meine Zwecke) super! Habs leider erst diese Woche entdeckt als ich meine Variante der Geräteüberwachung umbauen/erweitern wollte..
komm nicht weiter... ich schaffs schon nicht einen removeEvent zu definieren welcher auf das disable reagiert, egal ob global oder im device...
wenn ich das device mit attr ... disable 1 deaktiviere erhalte ich im monitor:
ESPEasy wemos_mini_11_nfx disabled
Global global ATTR wemos_mini_11_nfx disable 1
also generiert das device selbst einen event beim disable... nur wie kriege ich den korrekt in die definition?
im removeEvent habe ich im moment:
wemos_.*:(presence.*present|disabled)
schonmal danke im voraus...
nachtrag:
wenn ich zusätzlich ein notify mache mit:
defmod not_wemos_disabled notify wemos_.*:disabled set mon_wemos_presence errorRemove $NAME
dann wird das bei einem disable korrekt ausgeführt und löscht das device aus der error Liste....
ZitatHmm, ich sehe grade, dass meine Vermutung auf dich nicht zutreffen kann, da du kein warningWait verwendest.
Muss ich mir doch noch mal genau ansehen.
Hi igami, konntest du schon etwas wegen meines Pflanzenmonitor herausfinden (Warning wird auf Error kopiert statt verschoben)?
Anbei nochmal der Code:
defmod Flower_monitoring monitoring Pflanze_0?[0-9]*:moisture:.(1?[0-9])$ Pflanze_0?[0-9]*:moisture:.(1?[2-9][0-9])
attr Flower_monitoring DbLogExclude .*
attr Flower_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Die Pflanze \"$errors[0]\" ist sehr durstig und vertrocknet bald.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Pflanzen sind sehr durstig und vertrocknen bald: ", @errors))\
}
attr Flower_monitoring errorWait 60*60*24*7
attr Flower_monitoring group Monitoring
attr Flower_monitoring room FlowerSens
attr Flower_monitoring userReadings warning_count:warning.+ {split(",", ReadingsVal($name, "warning", ""))}, \
error_count:error.+ {split(",", ReadingsVal($name, "error", ""))}, \
all_count:(warning.+|error.+) {split(",", ReadingsVal($name, "warning", "")) + split(",", ReadingsVal($name, "error", ""))}
attr Flower_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Die Pflanze \"$warnings[0]\" bekommt langsam Durst und müsste mal gegossen werden.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Pflanzen bekommen langsam Durst und müssten mal gegossen werden: ", @warnings))\
}
VG, Thomas
Hallo Tolles Modul ! Habs auch gleichmal eingebunden (Die Zwei Vorschläge Monitoring und Batterie) :-)
Eins hab ich mir noch für Lanpings eingerichtet presence absent/present funktioniert alles Tutti!
Nun eine kleine Frage könnte mir jemand Helfen beim erstellen einer Temperaturüberwachung?
Ich habe im ganzen Haus Sensoren und möchte nun diese auf ungewöhnliche Temperaturen Überwachen.
Also wenn die Temperatur kleiner als 5 (Frostwächter) oder Größer als 50 (Brandalarm) ist...
Vielleicht mit Abstufungen ... Warnung ab 45°C Error ab 50°C und umgekehrt Warnung ab 10°C und Error ab 5°C
Natürlich inkl. Meldung per Push und Lichtan in einem Raum usw...
wie bekomme ich das hin...
Habe mich nun schon lange nicht mehr gemeldet, aber dieses Wochenende setze ich mich da mal wieder dran!
Super modul! Ein tolles Ostenest hab ich da gefunden :)
Kann man das Reading warning oder error mit Umbruch darstellen anstelle von , ?
Ich setze das Modul noch nicht ein, meine Frage gibt es in dem Modul ein reading was einfach nur zählt, z.B. Batterieüberwachung 1 Gerät das es eine 1 anzeigt oder 2 Geräte eben eine 2..?
Hi igami,
danke für das Modul. Ich bin gerade dabei mein System damit auszustatten.
Dabei habe ich mir für meine Bequemlichkeit das Modul etwas angepasst:
Ich habe mir ein globales "userAttr" geschaffen: "ActivityTimeout".
Wenn ich jetzt an einem Device dieses Attribut auch setze, soll der dafür zuständige Aktivitätsmonitor dieses Device entsprechend überwachen.
Dafür ist es notwendig, dass man beim Definieren des Monitors nicht nur eine AddRegex angeben kann, sondern auch eine DevSpec für das Device.
Ich habe das (zunächst mal nur für den AddRegex-Teil) relativ schlank eingebaut (ab Zeile 279):
my ($addRegex, $removeRegex) = split(/[\s]+/, InternalVal($SELF, "DEF", ""));
# Hier wird der Device-Teil als DevSpec verarbeitet, und um transparent weitermachen zu können, wird der "alte" $addRegex auf den aktuellen Event-Devicenamen gesetzt
my ($device, $tail) = split(/:/, $addRegex);
return unless(exists {map { $_ => 1 } devspec2array($device)}->{$name});
$addRegex = $name.':'.$tail;
# Hier braucht dann kein Ausstieg für das Device gemacht werden...
return unless(
$removeRegex && $removeRegex =~ m/^$name:/
|| $events
);
Des weiteren habe ich natürlich das Attribut "errorWait" (und auch "warningWait") wie folgt gesetzt:
{ eval(AttrVal($name, 'ActivityTimeout', '24*60*60')) }
Des Weiteren natürlich die von dir schon beschriebenen Attribute und Activity-Notify am Monitor...
Das wars. Jetzt brauche ich nur noch an jedem gewünschten Device das Attribut setzen, und der Monitor überwacht es...
Für meine einfache Lösung reichte es mir, dass die DevSpec momentan keine Doppelpunkte enthalten kann (da es der Trenner zum Reading/Event ist).
Wenn man das offiziell übernimmt, müsste man das vielleicht noch eruieren und entsprechend erweitern...
Vielleicht kannst du es ja in die offizielle Version bringen...
EDIT: Hier noch die Definition des Monitor-Devices:
defmod global_Monitoring_DeviceActivity monitoring ActivityTimeout=.+:.*
Grüße
Reinerlein
Hi igami,
hach, wenn man einmal anfängt :)
Ich habe noch etwas hinzugefügt, was die Perfomance massiv steigern dürfte.
Im Define (bei Zeile 84):
my ($device, $tail) = split(/:/, $re[0]);
$hash->{NOTIFYDEV} = $device;
Außerdem muss ich mir nochmal die Notify-Funktion anschauen. Ich habe z.B. in meinem Activity-Reading-Setzen-Notify den Aufruf für readingsSingleUpdate mit Trigger auf 1 aufgerufen, damit ich auch auf die Änderung des Reading "Activity" reagieren kann, bzw. dieses Reading in einer Readingsgroup auf der Oberfläche auch per longpoll aktualisiert wird.
Leider ist das natürlich eine Reaktion vom überwachten Device, womit es wieder von der error-Liste heruntergenommen wird :(
Irgendwie muss dieses indirekte Event auch noch unterbunden werden, nur weiß ich noch nicht wie... Vielleicht indem man dieses Reading-Setzen direkt ins Modul verbaut, und damit weiß, dass nicht darauf zu reagieren ist.
Alternativ könnte man natürlich auch den Regex entsprechend anpassen... Wobei ich mich mit diesen Negationen immer sehr schwer tue.
Ein einfaches
(?!Activity)
oder
^(?!Activity)$
Grüße
Reinerlein
https://stackoverflow.com/questions/406230/regular-expression-to-match-a-line-that-doesnt-contain-a-word (https://stackoverflow.com/questions/406230/regular-expression-to-match-a-line-that-doesnt-contain-a-word)
Hi,
habe es doch noch herausgefunden:
^(?!Activity$)
Bei meiner obigen Definition also:
ActivityTimeout=.+:^(?!Activity$)
Grüße
Reinerlein
Hi igami,
für das Activity-Reading hätte ich jetzt eine Lösung.
Man muss ein neues Attribut einführen, mit dem man dann direkt ein Event blacklisten kann.
Ich hatte es bei mir einfach mal "blacklistRegex" genannt.
Dieses habe ich dann in der Eventverarbeitung als zusätzlichen Überspringer eingebaut:
my $blacklistRegex = AttrVal($SELF, 'blacklistRegex', '');
foreach my $event (@{$events}){
next unless($event);
# Hier das neue Attribut prüfen, um einzelne Readings/Events ausschließen zu können...
next if ($event =~ m/$blacklistRegex/);
^Activity:
Wenn man das ganze mal schön umsetzt, dann müsste man vermutlich auch wieder über ein entsprechendes Whitelisting-Attribut nachdenken.
Das wird hier jetzt aber nicht benötigt...
Wie sieht es denn überhaupt aus?
Bist du denn bereit solche Änderungen in die offizielle Version zu übernehmen?
Danke schon mal...
Grüße
Reinerlein
Hallo,
ich benutze FHEM jetzt schon ein Jahr auf meinem RPi3 und dieses Forum hat mir bei vielen Fragen immer sehr geholfen. Danke dafür. Da mir FHEM immer noch sehr viel Spaß macht und hier um ein feedback gebeten wird, schreibe ich heute meinen ersten Beitrag.
Ich finde das Monitoring-Modul echt klasse! Mir ist nur aufgefallen, dass obwohl ich das Attribut verbose auf 2 eingestellt habe, noch immer 3er Meldungen (jedes get) im Logfile landen. Ein FHEM-Update habe ich gestern gemacht, ist aber immer noch so.
Des weiteren würde ich mir für dieses Modul noch ein Attribut für wenn "nichts auf den Listen" ist wünschen, damit kein leeres return entsteht (PERL WARNING: Use of uninitialized value...). Kann aber auch sein, das man so etwas auch in die Attribute warningReturn und errorReturn integrieren kann, die habe ich nämlich noch nicht so ganz verstanden. Ich frage jetzt immer erst die Readings error und warning auf ne "" ab bevor ich ein get mache.
Liebe Grüße
Ich bemerke grad, dass ich mich schon länger nicht um das Modul gekümmert habe :-[
Das versuche ich mal heue Nachmittag aufzuarbeiten!
Zitat von: mar3d@RPi3 am 08 Juni 2018, 22:39:21
Ich finde das Monitoring-Modul echt klasse!
Vielen Dank für das Lob :)
Zitat von: mar3d@RPi3 am 08 Juni 2018, 22:39:21
Ich finde das Monitoring-Modul echt klasse! Mir ist nur aufgefallen, dass obwohl ich das Attribut verbose auf 2 eingestellt habe, noch immer 3er Meldungen (jedes get) im Logfile landen. Ein FHEM-Update habe ich gestern gemacht, ist aber immer noch so.
Poste doch bitte mal die Betreffende Logzeile. Vom Modul selbst wird nur ein "clear" und fehlerhafte Konfiguration bei verbose 2 ins Log geschrieben.
Zitat von: mar3d@RPi3 am 08 Juni 2018, 22:39:21
Des weiteren würde ich mir für dieses Modul noch ein Attribut für wenn "nichts auf den Listen" ist wünschen, damit kein leeres return entsteht (PERL WARNING: Use of uninitialized value...). Kann aber auch sein, das man so etwas auch in die Attribute warningReturn und errorReturn integrieren kann, die habe ich nämlich noch nicht so ganz verstanden. Ich frage jetzt immer erst die Readings error und warning auf ne "" ab bevor ich ein get mache.
Das lässt sich tatsächlich mit den Return Attributen umsetzen.
In den Beispielen steht oft die Zeile
return unless(@errors);
in dem errorReturn Attribut. Diese bedeutet, dass nichts zurückgegeben wird, wenn es keien Fehler gibt. Du kannst aber auch einen Text zurück geben:
return("keine Einträge vorhanden") unless(@errors);
Danke für die Hilfe.
Hier einer der Logeinträge:
2018.06.08 22:07:35.058 3: get Kontakt_monitoring error : Die folgenden 2 Fenster/Türen sind schon länger geöffnet:
- Badezimmerfenster
- Terrassentür
Zitat von: mar3d@RPi3 am 09 Juni 2018, 19:11:00
Danke für die Hilfe.
Hier einer der Logeinträge:
2018.06.08 22:07:35.058 3: get Kontakt_monitoring error : Die folgenden 2 Fenster/Türen sind schon länger geöffnet:
- Badezimmerfenster
- Terrassentür
Ich vermute du machst das über
{fhem("get Kontakt_monitoring error")}
Dass es dann geloggt wird ist normal. Siehe dazu in der commandref den Abschnitt Perl specials (http://commandref.fhem.de/#perl)
Zitat
To use FHEM commands from the perl expression, use the function fhem(), which takes a string argument, this string will be evaluated as a FHEM command:
{ fhem "set light on" }
define n1 notify piri:on { fhem "set light on" }
Note: if this function returns a value, it will also be logged into the global FHEM log. Use 1 as a second argument to disable this logging, this makes sense when obtainig some values via FHEM "get...".
Ja, du hast recht, das ist es. Da habe ich auch noch gar nicht alles gelesen. UNENDLICHE WEITEN... XD
Vielen Danke!
Zitat von: raiderxxl am 23 März 2018, 12:42:43
Hallo Tolles Modul ! Habs auch gleichmal eingebunden (Die Zwei Vorschläge Monitoring und Batterie) :-)
Eins hab ich mir noch für Lanpings eingerichtet presence absent/present funktioniert alles Tutti!
Nun eine kleine Frage könnte mir jemand Helfen beim erstellen einer Temperaturüberwachung?
Ich habe im ganzen Haus Sensoren und möchte nun diese auf ungewöhnliche Temperaturen Überwachen.
Also wenn die Temperatur kleiner als 5 (Frostwächter) oder Größer als 50 (Brandalarm) ist...
Vielleicht mit Abstufungen ... Warnung ab 45°C Error ab 50°C und umgekehrt Warnung ab 10°C und Error ab 5°C
Natürlich inkl. Meldung per Push und Lichtan in einem Raum usw...
wie bekomme ich das hin...
Hier ein Beispiel für den Frostwächter:
defmod Frostwa.chter monitoring .+:temperature:..+
attr Frostwa.chter errorFuncAdd {\
return 1\
if($event =~ m/temperature: (.+)/ && $1 < 5);;\
return;;\
}
attr Frostwa.chter errorFuncRemove {\
return 1\
if($event =~ m/temperature: (.+)/ && $1 >= 5);;\
return;;\
}
Der Brandwächter kann dann Analog gebaut werden. Zur Abstufung müssen noch die Attribute warningFuncAdd und warningFuncRemove mit den jeweils anderen Werten gepflegt werden.
Eine implementiertung mit Meldung werde ich dir nicht bauen. Ich überlege aber schon seit längerem ob ich nicht als FHEM Dienstleister anfangen soll 8)
Zitat von: choetzu am 30 März 2018, 23:08:10
Kann man das Reading warning oder error mit Umbruch darstellen anstelle von , ?
Das Reading selbst nicht, aber bei warining-/errorReturn kann man das ja so formatieren wie man es mag. In den Beispielen wird auch alles mit einem Zeilenumbruch dargestellt.
Zitat von: moonsorrox am 31 März 2018, 14:12:22
Ich setze das Modul noch nicht ein, meine Frage gibt es in dem Modul ein reading was einfach nur zählt, z.B. Batterieüberwachung 1 Gerät das es eine 1 anzeigt oder 2 Geräte eben eine 2..?
Ab morgen im Update gibt es dann die Readings errorCount und warningCount.
Zitat von: Reinerlein am 05 April 2018, 15:36:15
Dafür ist es notwendig, dass man beim Definieren des Monitors nicht nur eine AddRegex angeben kann, sondern auch eine DevSpec für das Device.
Ist bereits möglich mit dem Attribut whitelist.
Zitat von: Reinerlein am 05 April 2018, 15:36:15
Des weiteren habe ich natürlich das Attribut "errorWait" (und auch "warningWait") wie folgt gesetzt:
{ eval(AttrVal($name, 'ActivityTimeout', '24*60*60')) }
eval ist an der Stelle nicht notwendig, das es sowieso schon vom Modul gemacht wird. Schadet aber auch nicht.
Zitat von: Reinerlein am 05 April 2018, 15:36:15
EDIT: Hier noch die Definition des Monitor-Devices:
Müsste dann abegewandelt werden zu:
defmod global_Monitoring_DeviceActivity monitoring .*:.*
attr global_Monitoring_DeviceActivity whitelist ActivityTimeout=.+
Zitat von: Reinerlein am 05 April 2018, 20:09:58
Ich habe noch etwas hinzugefügt, was die Perfomance massiv steigern dürfte.
Im Define (bei Zeile 84):
my ($device, $tail) = split(/:/, $re[0]);
$hash->{NOTIFYDEV} = $device;
Werde ich mir noch anschauen wie ich das umsetzen kann.
Zitat von: Reinerlein am 05 April 2018, 20:09:58
Außerdem muss ich mir nochmal die Notify-Funktion anschauen. Ich habe z.B. in meinem Activity-Reading-Setzen-Notify den Aufruf für readingsSingleUpdate mit Trigger auf 1 aufgerufen, damit ich auch auf die Änderung des Reading "Activity" reagieren kann, bzw. dieses Reading in einer Readingsgroup auf der Oberfläche auch per longpoll aktualisiert wird.
Leider ist das natürlich eine Reaktion vom überwachten Device, womit es wieder von der error-Liste heruntergenommen wird :(
Irgendwie muss dieses indirekte Event auch noch unterbunden werden, nur weiß ich noch nicht wie... Vielleicht indem man dieses Reading-Setzen direkt ins Modul verbaut, und damit weiß, dass nicht darauf zu reagieren ist.
Alternativ könnte man natürlich auch den Regex entsprechend anpassen... Wobei ich mich mit diesen Negationen immer sehr schwer tue.
Das sieht dann leider etwas kryptisch aus, aber folgendes sollte funktionieren:
defmod global_Monitoring_DeviceActivity monitoring ^[^:]+:(?!Activity).+$
Also bis auf das NOTIFYDEV alles schon möglich ;)
Ich werde gleich noch das Beispiel in der commandref überarbeiten und dann zu morgen einchecken.
Das ganze monitoring sollte dann wie folgt aussehen:
defmod global_Monitoring_DeviceActivity monitoring ^[^:]+:(?!Activity).+$
attr global_Monitoring_DeviceActivity errorWait AttrVal($name, "ActivityTimeout", 60*60*6)
attr global_Monitoring_DeviceActivity whitelist ActivityTimeout=.+
Zitat von: igami am 09 Juni 2018, 21:41:13
Also bis auf das NOTIFYDEV alles schon möglich ;)
Habe ich jetzt auch noch fix eingebaut. Es wird das whitelist Attribut verwendet, falls vorhanden, ansonsten die DEF.
ZitatAb morgen im Update gibt es dann die Readings errorCount und warningCount
Oh da kann ich ja dann meine userReadings entfernen. 8) Ich habe zusätzlich noch einen Gesamtzähler integriert.
warning_count:warning.+ {split(",", ReadingsVal($name, "warning", ""))},
error_count:error.+ {split(",", ReadingsVal($name, "error", ""))},
all_count:(warning.+|error.+) {split(",", ReadingsVal($name, "warning", "")) + split(",", ReadingsVal($name, "error", ""))}
VG, Thomas
Zitat von: ToM_ToM am 16 März 2018, 17:28:45
Hi igami, konntest du schon etwas wegen meines Pflanzenmonitor herausfinden (Warning wird auf Error kopiert statt verschoben)?
Ich habe nun eine Überprüfung eingebaut, dass das Reading nur auf eine Liste gesetzt werden kann, wenn es noch nicht auf der error Liste steht. Da gab es noch ein Problem bei der Abarbeitung, wenn die FuncAdd Attribute genutzt werden.
Zitat von: ToM_ToM am 10 Juni 2018, 00:02:08
Oh da kann ich ja dann meine userReadings entfernen. 8) Ich habe zusätzlich noch einen Gesamtzähler integriert.
Habe das mal als allCount eingebaut.
Ab morgen im Updaten.
Hallo igami auch ich möchte dir danken für deine tolle arbeit, sollte man viel öfter machen.
Setzte auch schon mehrere Devices deines Moduls ein und wollte mich jetzt mal an den Activity Monitor wagen.
Möchte aber nicht inkludieren sondern lieber exkludieren, wann vergisst ja doch mal ein neu angelegtes Device auf die liste zu setzten, dies ist ja mit der blacklist möglich.
Könntest du mir bitte einen Tipp geben wie ich nur Devices auf die Liste setzte die kein einziges Reading besitzen welches jünger als 24 ist.
Manche Readings mancher Devices werden so selten aktualisiert das dein Modul, laut meiner Regex aus der Commandref, denkt die Devices wären Tod obwohl sie mindestens ein Reading innerhalb der Zeit geschrieben haben. Hoffe du verstehst mein Kauderwelsch.
Gruß Christian
Zitat von: mrbreil am 10 Juni 2018, 20:37:14
Manche Readings mancher Devices werden so selten aktualisiert das dein Modul, laut meiner Regex aus der Commandref, denkt die Devices wären Tod obwohl sie mindestens ein Reading innerhalb der Zeit geschrieben haben.
Es geht ja nicht um Readings sondern um Events. Wenn das event durch event-on-... Attribute eingeschränkt wird kann monitoring das nicht erkennen. Also das bitte noch mal überprüfen.
Habe es so definiert.
defmod Activity_monitoring monitoring .*:.*
attr Activity_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))\
}
attr Activity_monitoring errorWait 60*60*24
attr Activity_monitoring room System
attr Activity_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräten haben sich seit mehr als 12 Stunden nicht mehr gemeldet:", @warnings))\
}
attr Activity_monitoring warningWait 60*60*12
Nehmen wir z.B. ein AMAD Device ohne jedes event-on-.. Attribut.
Nach einem "set Activity_monitoring clear all" landet dieses und jedes weitere Device welches ein Event erzeugt sofort auf der Warning und Error Liste.
Wo ist mein Denkfehler?
Gruß Christian
Zitat von: mrbreil am 11 Juni 2018, 11:13:49
Nehmen wir z.B. ein AMAD Device ohne jedes event-on-.. Attribut.
Nach einem "set Activity_monitoring clear all" landet dieses und jedes weitere Device welches ein Event erzeugt sofort auf der Warning und Error Liste.
Wo ist mein Denkfehler?
Das kann ich dir leider nicht sagen. Habe es gerade per copy & paste in mein FHEM übernommen und bei den Devices wird gewartet:
setstate Activity_monitoring 2018-06-11 17:38:21 errorAdd_global 2018-06-12 17:38:21
setstate Activity_monitoring 2018-06-11 17:38:21 warningAdd_global 2018-06-12 05:38:21
Gibt es irgendwelche Hinweise im Log (ggf. mit verbose 5)?
Hey igami,
kurzes Feedback zu meinen Pflanzenmonitor. Habe es nun ein paar Tage beobachtet und getestet. Es läuft jetzt seit dem Update wie es soll. :)
Vielen Dank!
Wie sieht denn der Pflanzenmonitor aus? Würde mich interessieren...
Meine Pflanzen heißen alle Pflanze_01 bis Pflanze_08. Den korrekten Pflanzennamen zur Unterscheidung vergebe ich über den Alias.
Das ist mein alter Pflanzenmonitor um den es hier ging, der Alarm schlägt sobald die Pflanze eine Bodenfeuchte von weniger als 10% erreicht.
defmod Flower_monitoring monitoring Pflanze_0?[0-9]*:moisture:.(1?[0-9])$ Pflanze_0?[0-9]*:moisture:.1?([2-9][0-9]|00)
attr Flower_monitoring DbLogExclude .*
attr Flower_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Die Pflanze \"$errors[0]\" ist sehr durstig und vertrocknet bald.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Pflanzen sind sehr durstig und vertrocknen bald: ", @errors))\
}
attr Flower_monitoring errorWait 60*60*24*7
attr Flower_monitoring group Monitoring
attr Flower_monitoring room FlowerSens
attr Flower_monitoring userReadings warning_count:warning.+ {split(",", ReadingsVal($name, "warning", ""))}, \
error_count:error.+ {split(",", ReadingsVal($name, "error", ""))}, \
all_count:(warning.+|error.+) {split(",", ReadingsVal($name, "warning", "")) + split(",", ReadingsVal($name, "error", ""))}
attr Flower_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Die Pflanze \"$warnings[0]\" bekommt langsam Durst und müsste mal gegossen werden.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Pflanzen bekommen langsam Durst und müssten mal gegossen werden: ", @warnings))\
}
Den habe ich jedoch heute geringfügig umgebaut, da die Pflanzen ja durchaus unterschiedliche Bodenfeuchten benötigen.
So sind die Pflanzen definiert:
defmod Pflanze_07 XiaomiBTLESens XX:XX:XX:XX:XX:XX
attr Pflanze_07 alias Gasteria
attr Pflanze_07 disabledForIntervals 21:00-24:00 00:00-06:00
attr Pflanze_07 interval 3600
attr Pflanze_07 maxFertility 1000
attr Pflanze_07 maxLux 30000
attr Pflanze_07 maxMoisture 50
attr Pflanze_07 maxTemp 35
attr Pflanze_07 minFertility 300
attr Pflanze_07 minLux 3500
attr Pflanze_07 minMoisture 7
attr Pflanze_07 minTemp 5
attr Pflanze_07 model flowerSens
attr Pflanze_07 room FlowerSens
attr Pflanze_07 userReadings moistureFeeling:moisture.* {\
if (ReadingsVal($name, "moisture", -1) < AttrVal($name, "minMoisture", 0)) {\
return "too dry";;\
}\
elsif (ReadingsVal($name, "moisture", -1) > AttrVal($name, "maxMoisture", 100)) {\
return "too wet";;\
}\
else {\
return "good";;\
}\
}
Hier der neue Monitor:
defmod Flower_monitoring monitoring Pflanze_0?[0-9]*:moistureFeeling:.(too.dry|too.wet)$ Pflanze_0?[0-9]*:moistureFeeling:.(good)
attr Flower_monitoring DbLogExclude .*
attr Flower_monitoring errorReturn {return unless(@errors);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
my $tooDryCount = 0;;\
my $tooDryFlowers = "";;\
my $tooWetCount = 0;;\
my $tooWetFlowers = "";;\
foreach(@errors) {\
my $alias = AttrVal($_, "alias", $_);;\
if (ReadingsVal($_,"moistureFeeling", "good") eq "too dry") {\
$tooDryCount += 1;;\
$tooDryFlowers += $alias +", ";;\
}\
elsif (ReadingsVal($_,"moistureFeeling", "good") eq "too wet") {\
$tooWetCount += 1;;\
$tooWetFlowers += $alias +", ";;\
}\
}\
\
my $returnText = "";;\
if ($tooDryCount == 1) {\
$returnText = $returnText . "Die Pflanze " . substr($tooDryFlowers, 0, length($tooDryFlowers)-2) . " ist schon völlig verdurstet und braucht dringend Wasser. ";;\
}\
elsif ($tooDryCount > 1) {\
$returnText = $returnText . "Die folgenden " . $tooDryCount . " Pflanzen sind schon völlig vertrocknet und brauchen dringend Wasser: " . $tooDryFlowers . ". ";;\
}\
if ($tooWetCount == 1) {\
$returnText = $returnText . "Die Pflanze " . substr($tooDryFlowers, 0, length($tooDryFlowers)-2) . " steht immer noch viel zu nass und droht schon zu faulen.";;\
}\
elsif ($tooWetCount > 1) {\
$returnText = $returnText . "Die folgenden " . $tooWetCount . " Pflanzen stehen immer noch viel zu nass und drohen zu faulen: " . $tooWetFlowers . ". ";;\
}\
return $returnText;;\
}
attr Flower_monitoring errorWait 60*60*24*7
attr Flower_monitoring group Monitoring
attr Flower_monitoring room FlowerSens
attr Flower_monitoring warningReturn {return unless(@warnings);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
my $tooDryCount = 0;;\
my $tooDryFlowers = "";;\
my $tooWetCount = 0;;\
my $tooWetFlowers = "";;\
foreach(@warnings) {\
my $alias = AttrVal($_, "alias", $_);;\
if (ReadingsVal($_,"moistureFeeling", "good") eq "too dry") {\
$tooDryCount += 1;;\
$tooDryFlowers .= $alias .", ";;\
}\
elsif (ReadingsVal($_,"moistureFeeling", "good") eq "too wet") {\
$tooWetCount += 1;;\
$tooWetFlowers .= $alias .", ";;\
}\
}\
\
my $returnText = "";;\
if ($tooDryCount == 1) {\
$returnText = $returnText . "Die Pflanze " . substr($tooDryFlowers, 0, length($tooDryFlowers)-2) . " bekommt langsam Durst und müsste mal gegossen werden. ";;\
}\
elsif ($tooDryCount > 1) {\
$returnText = $returnText . "Die folgenden " . $tooDryCount . " Pflanzen bekommen langsam Durst und müssten mal gegossen werden: " . $tooDryFlowers . ". ";;\
}\
if ($tooWetCount == 1) {\
$returnText = $returnText . "Die Pflanze " . substr($tooDryFlowers, 0, length($tooDryFlowers)-2) . " steht viel zu nass.";;\
}\
elsif ($tooWetCount > 1) {\
$returnText = $returnText . "Die folgenden " . $tooWetCount . " Pflanzen stehen viel zu nass: " . $tooWetFlowers . ". ";;\
}\
return $returnText;;\
}
Der Neue meldet aktuell auch "zu trocken" wenn die Pflanzen eig. zu feucht sind. Für dieses Thema muss ich mir noch was einfallen lassen wie ich das abbilde.
Der Monitor mit korrekter Unterscheidung zwischen zu trocken und zu nass. Allerdings nur von mir eben zusammengeschrieben und aktuell noch ungetestet.
Vielen Dank!
Hallo und schönen Abend,
vielleicht kann mir ja jemand weiterhelfen. Hab das Modul jetzt auch als Ersatz für das 98_DeviceMonitor eingesetzt und funktioniert auch soweit gut. Ist wie folgt konfiguriert:
define DeviceMonitor monitoring .*:.*
attr DeviceMonitor errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" scheint nicht mehr aktiv zu sein.")\
if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten scheinen nicht mehr aktiv zu sein:", @errors))\
}
attr DeviceMonitor errorWait {AttrVal($name, "device_timeout", 0)}
attr DeviceMonitor whitelist device_timeout=.+
define ny_DeviceMonitor notify DeviceMonitor:error.(add|remove):..+ {\
$EVENT =~ m/error (add|remove): (.+)/;;\
readingsSingleUpdate(\
$defs{$2}, "Activity", $1 eq "add" ? "dead" : "alive", 0);;\
return;;\
}
define di_AlarmDeviceStatus DOIF ([":Activity: dead"] and [08:00-22:00])\
(set Telegram message @411***976 ❗️ Das Gerät +++ $DEVICE +++ meldet sich nicht mehr)\
DOELSEIF ([":Activity: alive"] and [08:00-22:00])\
(set Telegram message @411***976 ✔ Das Gerät +++ $DEVICE +++ meldet sich wieder)
attr di_AlarmDeviceStatus do always
Habe das DOIF aus folgendem Post benutzt:
Zitat von: friesenjung am 12 Mai 2017, 22:20:32
Hi und sorry für die späte Rückmeldung...
Also eigentlich meinte ich damit nichts besonderes. Nur dieses kleine DOIF
defmod DI_AlarmDeviceStatus DOIF ([":Activity: dead"] and [?$SELF:B_$DEVICE] ne "dead") (set Pushover msg 'Device-Alarm' 'Das Gerät +++ $DEVICE +++ meldet sich nicht mehr!' 'iPhone6s' 0 '', setreading $SELF B_$DEVICE dead)\
DOELSEIF ([":Activity: alive"] and [?$SELF:B_$DEVICE] ne "alive") (setreading $SELF B_$DEVICE alive)
attr DI_AlarmDeviceStatus DbLogExclude .*
attr DI_AlarmDeviceStatus do always
attr DI_AlarmDeviceStatus group Benachrichtigung
attr DI_AlarmDeviceStatus room 9.1_Steuerung
Das reagiert sowohl auf das Activity eines Homematic-Devices, als auch bspw. auf die durch das monitoring-Modul überwachten Lacrosse-Sensoren.
Hoffe das beantwortet Deine Frage...
VG...
Habe aber das Problem das nur alive-Nachrichten geschickt werden, die dead-Nachrichten funktionieren nicht. Das notify funktioniert auch und trägt den Activity-Status am Device auch richtig ein. Jetzt meine Frage kann es sein das der dead-Eintrag nicht triggert? Hab mittlerweile keine Ahnung mehr wo das Problem liegen sollte, vielleicht hat ja von euch noch jemand eine Idee.
Gruß
Markus
Zitat von: meier81 am 21 Juli 2018, 22:00:04
Jetzt meine Frage kann es sein das der dead-Eintrag nicht triggert?
Deine Vermutung ist richtig, das setzen des Activity Readings löst kein Event aus.
Ist es möglich das notify so umzubauen das das setzen und rücksetzen des Activity readings einen event auslöst? Falls nicht was müsste ich denn beim doif ändern?
Gruß Markus
Ja, das ist möglich, dann würde es aber wieder auf alive springen, da das Gerät ja wieder ein Event sendet :D
Es gilt also das monitoring umzubauen, sodass es nicht auf Activity reagiert.
Ich hatte damit schon angefangen:
defmod global_Monitoring_DeviceActivity monitoring ^[^:]+:(?!Activity).+$
attr global_Monitoring_DeviceActivity errorWait AttrVal($name, "ActivityTimeout", 60*60*6)
attr global_Monitoring_DeviceActivity whitelist ActivityTimeout=.+
Na dann sag ich doch mercy für die Hilfe, werde schauen ob ich das heute morgen noch eingebaut und getestet bekomme, bin dann nämlich mal 2 Tage weg.
Ich sag auch jeden Fall Bescheid was als Ergebnis rauskam.
Gruß
Markusd
Beim notify müsste dann nur noch die 0 durch eine 1 ersetzt werden.
So kam heute mal zum testen deiner Änderung:
Zitat von: igami am 22 Juli 2018, 07:48:27
Ich hatte damit schon angefangen:
defmod global_Monitoring_DeviceActivity monitoring ^[^:]+:(?!Activity).+$
attr global_Monitoring_DeviceActivity errorWait AttrVal($name, "ActivityTimeout", 60*60*6)
attr global_Monitoring_DeviceActivity whitelist ActivityTimeout=.+
muß leider berichten das nach der Änderung jetzt gar nichts mehr passiert, habe zum testen bei einem neuen Fühler die Überwachungszeit gesetzt und es wird kein errorAdd-Eintrag im monitoring-Modul hinzugefügt. Habe im notify auch die 0 gegen eine 1 getauscht, ist ja aber erstmal nicht relevant bei dem Problem.
Hier mal meine COnfig zur Sicherheit:
define DeviceMonitor monitoring ^[^:]+:(?!Activity).+$
attr DeviceMonitor errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" scheint nicht mehr aktiv zu sein.")\
if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten scheinen nicht mehr aktiv zu sein:", @errors))\
}
attr DeviceMonitor errorWait {AttrVal($name, "device_timeout", 0)}
attr DeviceMonitor whitelist device_timeout=.+
Hast du noch eine Idee wo da der Fehler steckt? Bei dem regex Ausdruck hört bei mir nämlich der Horizont auf (leider). Ich glaube damit muß ich mich aber mal auseinandersetzen in Zukunft das ich das auch mal verstehe.
Hallo igami,
da scheint sich ein Bug in deinem Modul eingeschlichen zu haben.
Meinen Fehler habe ich hier beschrieben:
https://forum.fhem.de/index.php/topic,89546.0.html#top (https://forum.fhem.de/index.php/topic,89546.0.html#top)
und folgenden Hinweis erhalten:
ZitatDas Modul 98_monitoring.pm setzt NOTIFYDEV selbst, und erzeugt dabei einen falschen Regexp.
Der empfohlene Weg ist die vom FHEM Framework bereitgestellte notifyRegexpChanged Funktion zu verwenden.
Könntest du dir das bitte mal anschauen?
VG, Thomas
Zitat von: ToM_ToM am 27 Juli 2018, 12:28:26
Könntest du dir das bitte mal anschauen?
Mache ich am Sonntag mal.
Hi igami,
hab heute nochmal stundenlang probiert, leider ohne Erfolg, immer mit dem Ergebnis wie ich es hier schon geschildert habe:
Zitat von: meier81 am 25 Juli 2018, 22:56:28
So kam heute mal zum testen deiner Änderung:
muß leider berichten das nach der Änderung jetzt gar nichts mehr passiert, habe zum testen bei einem neuen Fühler die Überwachungszeit gesetzt und es wird kein errorAdd-Eintrag im monitoring-Modul hinzugefügt. Habe im notify auch die 0 gegen eine 1 getauscht, ist ja aber erstmal nicht relevant bei dem Problem.
Hier mal meine COnfig zur Sicherheit:
define DeviceMonitor monitoring ^[^:]+:(?!Activity).+$
attr DeviceMonitor errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" scheint nicht mehr aktiv zu sein.")\
if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten scheinen nicht mehr aktiv zu sein:", @errors))\
}
attr DeviceMonitor errorWait {AttrVal($name, "device_timeout", 0)}
attr DeviceMonitor whitelist device_timeout=.+
Hast du noch eine Idee wo da der Fehler steckt? Bei dem regex Ausdruck hört bei mir nämlich der Horizont auf (leider). Ich glaube damit muß ich mich aber mal auseinandersetzen in Zukunft das ich das auch mal verstehe.
Hast du noch einen Rat für mich was ich da noch anpassen müsste?
Danke dir mal, Gruß Markus
Zitat von: meier81 am 28 Juli 2018, 00:20:38
Hast du noch einen Rat für mich was ich da noch anpassen müsste?
Was bekommst du bei "list device_timeout=.+" ?
Zitat von: ToM_ToM am 27 Juli 2018, 12:28:26
Könntest du dir das bitte mal anschauen?
Zum testen mal bitte Zeile 486 durch folgenden Code ersetzen:
notifyRegexpChanged($hash, $NOTIFYDEV);
Hallo igami,
habe das getestet. Leider immer noch das gleiche Problem.
Es tritt auch nur bei den Devices auf bei denen der Regex mit .* beginnt.
z.B.: bei sowas:
defmod Batterie_monitoring monitoring (.*:battery:.low|.*LOWBAT:.yes|.*LOWBAT:.true) (.*:battery:.ok|.*LOWBAT:.no|.*LOWBAT:.false)
VG, Thomas
Hi igami,
ich habe es jetzt nochmal in Ruhe getestet. Die Anpassung hat doch funtktioniert. Da hatte ich wohl vorhin irgendwas übersehen.
Vielen Dank! :)
Zitat von: ToM_ToM am 29 Juli 2018, 20:02:50
ich habe es jetzt nochmal in Ruhe getestet. Die Anpassung hat doch funtktioniert. Da hatte ich wohl vorhin irgendwas übersehen.
Dann werde ich es nächste Woche selbst noch mal testen und dann einchecken. Ich erinnere mich, dass ich bei der Entwicklung irgendwelche Probleme mit notifyRegexpChanged hatte. Nur weiß ich nicht mehr genau welche :-[
Hallo igami,
hat etwas gedauert, war ein paar Tage unterwegs. Hie die Antwort auf deine Frage
Zitat von: igami am 29 Juli 2018, 09:42:00
Was bekommst du bei "list device_timeout=.+" ?
Der Befehl bringt mir die Aufstellung meiner Devices die das Attribut Device_timeout haben, also alle meine Fühler:
Fuehler_Arbeitszimmer
Fuehler_Aussen
Fuehler_Bad
Fuehler_Dachgeschoss
Fuehler_Elias
Fuehler_Kueche
Fuehler_Schlafzimmer
Fuehler_Wohnzimmer
Gruß Markus
Hab zudem folgenden Fehler im Log:
1: devspec2array ^[^: Unmatched [ in regex; marked by <-- HERE in m/^(^[ <-- HERE ^)$/ at fhem.pl line 1288.
Denke das der rexex-Ausdruck einen Fehler enthält, habe anbei mal einen Screenshot des Moduls gemacht.
Aktualisier mal bitte das whitelist Attribut, dann sollte in dem INTERNAL NOTIFYDEV auch was anders stehen.
Hi igami,
danke für den Tipp, das brachte den entscheidenen Erfolg. Das Problem ist nur das das ganze einen Neustart nicht übersteht, nach dem Neustart steht nämlich wieder im NOTIFYDEV ^[^
Gibt es eine Möglichkeit das ganze dauerhaft zu speichern, ist blöd wenn das nach jedem Neustart verschwindet.
Zitat von: meier81 am 02 August 2018, 21:21:19
Gibt es eine Möglichkeit das ganze dauerhaft zu speichern, ist blöd wenn das nach jedem Neustart verschwindet.
Muss ich fixen und das schaffe ich eventuell morgen, sodass es dann am Sonntag per update verfügbar ist.
Okay, dann warte ich mal und schaue wenn das Update da ist. Ich gebe dir nochmal Rückmeldung ob es dann funktioniert.
Hallo zusammen,
ich habe vor kurzem dieses tolle Modul in Betrieb genommen - als Ablösung für eigenes Gebastel aus Dummys und DOIFs - und monitore damit schon eine ganze Menge - herzlichen Dank!
Bei einem Anwendungszweck ist mir allerdings ein Problem aufgefallen. Ich nutze es, um festzustellen, ob meine lePresenced-Services noch laufen:
defmod system.monitoring.lepresenced monitoring (tag\..*):.*rssi_.*
attr system.monitoring.lepresenced errorFuncAdd {$event =~ m/^rssi_(.+):/;;\
$name = $1;;\
return 1;;\
}
attr system.monitoring.lepresenced errorWait 20*60
attr system.monitoring.lepresenced warningWait 10*60
Hiermit überwache ich analog zum dash_dhcp-Beispiel, ob von einem presence-Device die Readings, die mit rssi_.* beginnen, regelmäßig aktualisiert werden (ein Bluetooth-Dongle was immer zu Hause ist und immer von allen lepresenced-Installationen empfangen können werden sollte).
Dabei "entgehen" dem Monitoring aber offenbar immer wieder events. Das betreffende presence-Device sieht so aus (Auszug):
defmod tag.alwaysathome PRESENCE lan-bluetooth AC:DC:AC:DC:AC:DC 192.168.178.60:5222
attr tag.alwaysathome DbLogExclude rssi.* event-min-interval rssi_.*:60
attr tag.alwaysathome event-min-interval rssi_.*:60
attr tag.alwaysathome event-on-change-reading state
attr tag.alwaysathome event-on-update-reading rssi_.*
setstate tag.alwaysathome 2018-08-15 14:32:16 rssi_Bad-Oben -83
setstate tag.alwaysathome 2018-08-15 14:32:16 rssi_Flur -85
setstate tag.alwaysathome 2018-08-15 14:32:16 rssi_Kinderzimmer -79
setstate tag.alwaysathome 2018-08-15 14:32:16 rssi_Küche -82
setstate tag.alwaysathome 2018-08-15 14:32:16 rssi_Schlafzimmer -82
setstate tag.alwaysathome 2018-08-15 14:32:16 rssi_Wohnzimmer -53
setstate tag.alwaysathome 2018-08-15 14:32:16 state present
Im Eventmonitor sehe ich z.B. die Events für "rssi_Flur" minütlich kommen, aber das Monitoring ignoriert die. So werden error_adds etc. für einige Readings wie Flur erst gar nicht automatisch angelegt (für ein paar andere aber schon!) und andere gehen, obwohl die Events regelmäßig kommen, nach anfänglichem aktualisieren der error-add-Zeit für 1-2 Stunden irgendwann trotzdem auf error, obwohl die Events unverändert kommen. Das ganz ist ziemlich zufällig und betrifft immer wieder andere Events.
Igami, hast du ne Idee, woran das liegen könnte?
Hallo igami,
Zitat von: igami am 03 August 2018, 16:37:02
Muss ich fixen und das schaffe ich eventuell morgen, sodass es dann am Sonntag per update verfügbar ist.
du bist noch nicht dazugekommen das zu fixen?
Gruß Markus
OK ich habe glaube ich das Problem mit den Fehlenden Events durch verbose 5 eingrenzen können: Die fehlenden Events kommen beim monitoring-Device nicht an. Vermutlich, weil sie durch das Presence-Device alle auf einmal ausgelöst werden. Auszug aus dem Event-Monitor:
2018-08-16 10:19:28.556 PRESENCE tag.alwaysathome rssi_Bad-Oben: -80
2018-08-16 10:19:28.556 PRESENCE tag.alwaysathome rssi_Flur: -85
2018-08-16 10:19:28.556 PRESENCE tag.alwaysathome rssi_Kinderzimmer: -77
2018-08-16 10:19:28.556 PRESENCE tag.alwaysathome rssi_Küche: -81
2018-08-16 10:19:28.556 PRESENCE tag.alwaysathome rssi_Schlafzimmer: -81
2018-08-16 10:19:28.556 PRESENCE tag.alwaysathome rssi_Wohnzimmer: -54
Das Log vom monitoring-device zeigt dann genau einen Trigger nur für das erste von diesen Events, die anderen fehlen:
2018.08.16 10:19:28.504 4: monitoring (test.monitoring) triggered by "tag.alwaysathome rssi_Bad-Oben: -80"
2018.08.16 10:19:28.504 5: monitoring (test.monitoring) only addRegex is defined
2018.08.16 10:19:28.506 5: monitoring (test.monitoring)
entering monitoring_modify
reading: error
operation: remove
value: Bad-Oben
at: now
2018.08.16 10:19:28.552 5: monitoring (test.monitoring)
entering monitoring_modify
reading: error
operation: add
value: Bad-Oben
at: 2018-08-16 10:21:28
Scheint so, als ob FHEM dem Modul Events "unterschlägt", nach meinem Verständnis muss es an dieser Zeile bzw. der Funktion deviceEvents liegen:
my $events = deviceEvents($dev_hash, AttrVal($SELF, "addStateEvent", 0));
So und nun bin ich mit meinem Latein am Ende :-D
OK der funktionierende Workaround liegt darin, event-min-interval in Verbindung mit event-on-update-reading für das event-auslösende Device nicht mehr zu benutzen. Das ist offenbar eine durch FHEM "nicht vorgesehene" Kombination, die ich aber schon des öfteren eingesetzt habe, ohne die Probleme zu bemerken ;)
ZitatZum testen mal bitte Zeile 486 durch folgenden Code ersetzen:
Hi igami, könntest du das bitte fix übernehmen? Bei mir läuft es seit der Umstellung fehlerfrei.
VG, Thomas
Zitat von: ToM_ToM am 18 August 2018, 12:29:15
Hi igami, könntest du das bitte fix übernehmen? Bei mir läuft es seit der Umstellung fehlerfrei.
Habe ich gerade gemacht, eventuell landet es dann gleich noch im Update.
Zu den anderen Sachen bin ich noch nicht gekommen.
Ich habe ein Komma vergessen, dadurch ist das Modul unbrauchbar! Bitte heute nicht updaten!
Erstmal vielen Dank für dieses Modul, das ich in den letzten Monaten irgendwie immer übersehen habe.
Den Beispielen folgend habe ich es gestern für meine MAX-Batterien sowie als Aktivitätsmonitor erfolgreich in Betrieb genommen. Nun möchte ich es zur Überwachung der CPU-Temperaturen meiner per SYSMON in FHEM verfügbaren RaspberryPis einsetzen.
Ab 60 Grad soll der Raspi vorest auf die Liste. Und wenn er ein paar Stunden dort bleibt, als Fehler erfasst werden. Habe ich die Doku richtig verstanden, dann müsste der erste Teil ab 60 den Listeneintrag machen und der zweite bei 0-59 den Eintrag runternehmen. Events werden erzeugt. Bei UserReading habe ich in SYSMON cpu_temp auf measuredTemp übertragen (verwende ich einheitlich bei allen Devices mit Temperaturlieferung).
Die Definition sieht so aus:
DEF sysmon.*:measuredTemp:.([6-9][0-9]|[1-9][0-9][0-9])$ sysmon.*:measuredTemp:.([0-9]|[0-5][0-9])
NAME monitoring.rpi.temperaturen
NOTIFYDEV sysmon.*,sysmon.*
NR 20665
NTFY_ORDER 50-monitoring.rpi.temperaturen
STATE 0 Fehler | 0 Warnungen
TYPE monitoring
.attraggr:
.attrminint:
Helper:
DBLOG:
allCount:
DbLog:
TIME 1534680113.51513
VALUE 1
error:
DbLog:
TIME 1534680113.51513
VALUE sysmon.blomesprinkler
errorCount:
DbLog:
TIME 1534680113.51513
VALUE 1
state:
DbLog:
TIME 1534680113.51513
VALUE error add
READINGS:
2018-08-19 14:01:53 allCount 1
2018-08-19 14:06:25 error
2018-08-19 14:06:25 errorCount 0
2018-08-19 14:10:58 state active
2018-08-19 14:06:25 warning
2018-08-19 14:06:25 warningCount 0
powerMap:
readingsDesc:
pM_consumption:
rtype w
pM_energy:
rtype whr
Attributes:
group Monitoring
room IT-Systeme,System
stateFormat errorCount Fehler | warningCount Warnungen
Ich habe gerade einen RPI, der über 60 Grad ist. Warum erscheint er nicht auf der Liste? Ist meine Regex doch falsch?
Gruß
Christian
Zitat von: cbl am 19 August 2018, 14:24:18
Ich habe gerade einen RPI, der über 60 Grad ist. Warum erscheint er nicht auf der Liste? Ist meine Regex doch falsch?
So auf die Schnelle kann ich nichts finden was nicht passt.
Für meinen Tiefkühler habe ich ein ähnliches monitoring und habe mir für den Granzwert ein userattr angelegt. So muss ich mich nicht mit der regex rumärgern wenn ich den Wert ändere
defmod Ku.che.._Ku.hlschrank_Gefrierfach_.U.berwachung monitoring Ku.che.._Ku.hlschrank_Gefrierfach_.Thermometer:temperature:..+
attr Ku.che.._Ku.hlschrank_Gefrierfach_.U.berwachung userattr desired threshold
attr Ku.che.._Ku.hlschrank_Gefrierfach_.U.berwachung desired -17
attr Ku.che.._Ku.hlschrank_Gefrierfach_.U.berwachung errorFuncAdd {\
return 1\
if(ReadingsVal($name, "temperature", 0) >= AttrVal($SELF, "desired", 0));;\
return;;\
}
attr Ku.che.._Ku.hlschrank_Gefrierfach_.U.berwachung errorFuncRemove {\
return 1\
if(ReadingsVal($name, "temperature", 0) <= AttrVal($SELF, "desired", 0) - AttrVal($SELF, "threshold", 0));;\
return;;\
}
attr Ku.che.._Ku.hlschrank_Gefrierfach_.U.berwachung threshold 1
Danke für die schnelle Antwort. Deine Lösung ist viel komfortabler umstellbar als das Regex-Basteln. Damit funktioniert es nun.
Hallo Leute
Ja ich weiß es gehört hier nicht hin. Aber ich habe mir dieses Modul installiert. Es liegt schon lange auf Fhem nur nicht weiter dazu gekommen.
Habe kein dashbutton genommen sondern einen Dummy auf meinem Tablet hätte ich gerne .
Hat jemand eine Hilfestellung für mich was ich in meinem Dummy eintragen muss?
Den das aus Wiki verstehe ich nicht so ganze.
so sieht meine Monitoring aus.
Internals:
CFGFN
DEF Kaffeemaschine_dummy:.*:
NAME Kaffemaschine_monitoring
NOTIFYDEV Kaffeemaschine_dummy
NR 45985
NTFY_ORDER 50-Kaffemaschine_monitoring
STATE active
TYPE monitoring
READINGS:
2018-08-19 18:09:11 state active
Attributes:
errorReturn {return unless(@errors);
return "Die Kaffeemaschine muss sauber gemacht werden.";
}
errorWait 60*60*24*14
room Experiment
warningReturn {return unless(@warnings);
return "Die Kaffeemaschine muss demnächst sauber gemacht werden.";
}
warningWait 60*60*24*10
Das wäre super. Danke schon mal im vorraus
Zitat von: Wasserwerk33 am 19 August 2018, 18:18:09
Hallo Leute
Ja ich weiß es gehört hier nicht hin. Aber ich habe mir dieses Modul installiert. Es liegt schon lange auf Fhem nur nicht weiter dazu gekommen.
Habe kein dashbutton genommen sondern einen Dummy auf meinem Tablet hätte ich gerne .
Hat jemand eine Hilfestellung für mich was ich in meinem Dummy eintragen muss?
Den das aus Wiki verstehe ich nicht so ganze.
so sieht meine Monitoring aus.
Internals:
CFGFN
DEF Kaffeemaschine_dummy:.*:
NAME Kaffemaschine_monitoring
NOTIFYDEV Kaffeemaschine_dummy
NR 45985
NTFY_ORDER 50-Kaffemaschine_monitoring
STATE active
TYPE monitoring
READINGS:
2018-08-19 18:09:11 state active
Attributes:
errorReturn {return unless(@errors);
return "Die Kaffeemaschine muss sauber gemacht werden.";
}
errorWait 60*60*24*14
room Experiment
warningReturn {return unless(@warnings);
return "Die Kaffeemaschine muss demnächst sauber gemacht werden.";
}
warningWait 60*60*24*10
Das wäre super. Danke schon mal im vorraus
Mach einfach den : am Ende der DEF weg und dann ist es egal was du in deinen Dummy einträgst. Jedes mal wenn der ein Event sendet wird das monitoring dann ausgelöst.
Danke
Habe trotzdem ein Problem ich kann nicht gut perl.
habe versucht mir ein notify anzulegen. Aber komme da nicht weiter. Welche angaben muss ich treffen damit ich dieses dann auch sehe?
Ich würde die errormeldungen gerne nachher auf meinem Tablet sehen. Also nicht zusenden.
Also wenn ich das monitoring ja richtig verstanden habe. schaut er auf meinen Dummy wann er das letzte mal betätigt wurde. Ist so doch richtig oder??
Und das notify soll das monitoring dann auslesen. Aber was muss ich da eintragen??
Zitat von: meier81 am 02 August 2018, 21:21:19
Hi igami,
danke für den Tipp, das brachte den entscheidenen Erfolg. Das Problem ist nur das das ganze einen Neustart nicht übersteht, nach dem Neustart steht nämlich wieder im NOTIFYDEV ^[^
Gibt es eine Möglichkeit das ganze dauerhaft zu speichern, ist blöd wenn das nach jedem Neustart verschwindet.
Hallo igami, habe gesehen beim Update gestern ist der Bug behoben, nach einem Neustart alles weiterhin einwandfrei.
Mercy nochmal. Gruß Markus
Benutze dieses tolle Modul zur Überwachung meiner T/F-Kontakte und schicke eine Meldung per notify mit Trigger allCount via Telegram, sobald alle geschlossen (allCount==0) sind. Nun bekomme ist diese Meldung voreilig, falls nur ein Kontakt offen ist und ein Übergang von warning nach error stattfindet.
Der Grund ist wohl: erst wird warning entfernt (allCount: 0) dann bei error hinzugefügt (allCount: 1)
Hat jemand eine Idee, wie ich so etwas vermeiden kann.
TFK_monitoring:allCount:.*
{if (ReadingsVal("TFK_monitoring","allCount",0) == 0) {fhem("set Telegram msg alle TFK geschlossen")}}
2018-08-27 13:09:20 monitoring TFK_monitoring warning: TFK_Bad
2018-08-27 13:09:20 monitoring TFK_monitoring warningCount: 1
2018-08-27 13:09:20 monitoring TFK_monitoring allCount: 1
2018-08-27 13:10:20 monitoring TFK_monitoring warning remove: TFK_Bad
2018-08-27 13:10:20 monitoring TFK_monitoring warning:
2018-08-27 13:10:20 monitoring TFK_monitoring warningCount: 0
2018-08-27 13:10:20 monitoring TFK_monitoring allCount: 0
2018-08-27 13:10:20 monitoring TFK_monitoring error add: TFK_Bad
2018-08-27 13:10:20 monitoring TFK_monitoring error: TFK_Bad
2018-08-27 13:10:20 monitoring TFK_monitoring errorCount: 1
2018-08-27 13:10:20 monitoring TFK_monitoring allCount: 1
ZitatHat jemand eine Idee, wie ich so etwas vermeiden kann.
Du könntest einen watchdog draufsetzen und erst dann deine Telegram-Nachricht senden sobald allCount länger als ein paar Sekunden auf 0 steht.
Zitat von: jkriegl am 27 August 2018, 13:35:01
Hat jemand eine Idee, wie ich so etwas vermeiden kann.
event-min-interval wäre eine Möglichkeit, aber wahrscheinlich sollte ich das mal korrigieren.
Zitat von: igami am 27 August 2018, 21:18:19
event-min-interval wäre eine Möglichkeit, aber wahrscheinlich sollte ich das mal korrigieren.
Ist mit dem Update von morgen behoben.
Danke, ging pfeilschnell und klappt wunderbar.
Hallo igami,
Zuerst mal Danke für das vielseitige und flexible Modul.
Spart mir jede Menge notify's .
Könntest Du bei Gelegenheit evtl. noch ein ,,setInactiveFunc" Attribut einbauen?
Danke
Zitat von: Muk.s am 15 September 2018, 22:37:51
Könntest Du bei Gelegenheit evtl. noch ein ,,setInactiveFunc" Attribut einbauen?
Neue Version im Anhang, bitte testen. Wird bei "set inactive", "attr disable 1" und "delete" ausgeführt.
Das war fix :)
Teste es die Tage und melde mich
Kurze Rückmeldung:
Bei "set xxx Inactive" funktioniert das neue Attribut, bei "attr disable 1" leider nicht. Außerdem reagiert das modul nicht richtig auf "attr disable 0", der state bleibt auf "disabled" selbst wenn ich das Attribut lösche. "Delete" habe ich noch nicht getestet
Schaue ich mir nächst Woche noch mal an.
Glaube der Fehler liegt hier:
elsif($attribute eq "disable"){
if($cmd eq "set" and $value == 1){
monitoring_setActive($hash);
}
else{
monitoring_setInactive($hash);
readingsSingleUpdate($hash, "state", "disabled", 0);
Log3($SELF, 3, "$hash->{TYPE} ($SELF) attr $SELF disabled");
}
}
Hiermit funktioniert's:
elsif($attribute eq "disable"){
if($cmd eq "set" and $value == 0){
monitoring_setActive($hash);
}
else{
monitoring_setInactive($hash);
readingsSingleUpdate($hash, "state", "disabled", 1);
Log3($SELF, 3, "$hash->{TYPE} ($SELF) attr $SELF disabled");
}
}
Ein kleines Problem gibt es noch: Wenn ,,disable" 1 ist und gelöscht wird, bleibt state trotzdem auf disabled.
Hallo igami,
habe Dein Modul in meinem FHEM eingerichtet (erste Tests erfolgreich) und möchte eine entsprechende Errormeldung an meine Emailadresse senden.
mit dieser (DOIF) DEF möchte ich das versuchen :
([16:30-21:00|8]&&[":^error add:"]|[$SELF:cmd_nr] == 2)
(set TelegramBot message ({DebianMail('hp.abele@t-online.de','Monitoring Nachricht')}))
DOELSEIF ([":^error add:"])
bin aber nicht sicher ob dann die entsprechenden Gerätenahmen in das Email geschrieben werden ?
Würdest Du einen Oldie unterstützen ?
LG Peter
Zitat von: Peter aus Calw am 18 November 2018, 19:14:44
Würdest Du einen Oldie unterstützen ?
Selbstverständlich! Aber nur in der Form Hilfe zur Selbsthilfe ;)
Erstmal was generelles: and wird vor or ausgewertet, ist wie Punkt vor Strich beim Rechnen. Ich vermute, dass du die Emails nicht in dem beabsichtigten Zeitraum bekommst.
Ich benutze selbst keinen E-Mail versand mehr in Telegram, aber ich kann nicht erkennen an welcher Stelle die Fehlermeldungen übergeben werden.
Die bekommst du z.B. mit "get TYPE=monitoring error"
Hi,
Tolles Modul bin durch einen Hinweis hiergelandet (weil ich einen Aktivitätsmonitor bei mir aktivieren/selbst schreiben wollte) und hab das Modul ohne gröbere Schwierigkeiten zum Laufen gebracht für Batterie und Aktivität (gut letzteres muss ich noch ein wenig testen ...)
Frage:
- Gibt es eine einfache Möglichkeit in einer ReadingsGroup die Batterien bzw. Aktivitäten darzustellen mit (ok, warning, error) in Zusammenarbeit mit dem Monitoring-Modul.
- Vielleicht hab ich auch etwas überlesen (zugegeben ich hab nicht alle 16 Seiten dieses Threads verfolgt und es ist heute schon etwas später :-) )
- Mit ReadingsGroup fühl ich mich noch nicht 100%ig sicher
Danke!
Ich hab das so:
defmod rg_battery readingsGroup .*:battery
attr rg_battery DbLogExclude .*
attr rg_battery alias Batteriestatus
attr rg_battery group Batteriestatus
attr rg_battery mapping %ALIAS
attr rg_battery noheading 1
attr rg_battery notime 1
attr rg_battery room FHEM->Systemstatus
attr rg_battery sortDevices 1
attr rg_battery valueIcon {'battery.ok' => 'measure_battery_100@green', 'battery.low' => 'measure_battery_0@red'}
Grüßle
Pascal
Zitat von: Cyber1000 am 26 November 2018, 00:52:21
Tolles Modul bin durch einen Hinweis hiergelandet (weil ich einen Aktivitätsmonitor bei mir aktivieren/selbst schreiben wollte) und hab das Modul ohne gröbere Schwierigkeiten zum Laufen gebracht für Batterie und Aktivität (gut letzteres muss ich noch ein wenig testen ...)
letzteres ist auch gar nicht so leicht, bitte teilen, wenn du eine brauchbare Lösung hast
Zitat von: Cyber1000 am 26 November 2018, 00:52:21
Frage:
- Gibt es eine einfache Möglichkeit in einer ReadingsGroup die Batterien bzw. Aktivitäten darzustellen mit (ok, warning, error) in Zusammenarbeit mit dem Monitoring-Modul.
- Vielleicht hab ich auch etwas überlesen (zugegeben ich hab nicht alle 16 Seiten dieses Threads verfolgt und es ist heute schon etwas später :-) )
- Mit ReadingsGroup fühl ich mich noch nicht 100%ig sicher
Das ist eher eine readingsGroup Frage wie sich Kommagetrennte Listen hübsch darstellen lassen. Ich kann dir da nicht weiter helfen da ich kein readingsGroup nutze.
ZitatGibt es eine einfache Möglichkeit in einer ReadingsGroup die Batterien bzw. Aktivitäten darzustellen mit (ok, warning, error) in Zusammenarbeit mit dem Monitoring-Modul.
Hi Cyber1000,
hier mal wie ich das gelöst habe. Vielleicht hilft dir das.
defmod Batterieuebersicht readingsGroup <Device>,<Batteriestatus>,<Batterielevel>,<Activity> .*:battery,batteryLevel,Activity\
attr Batterieuebersicht DbLogExclude .*
attr Batterieuebersicht mapping %ALIAS %ROOM
attr Batterieuebersicht room Allgemein
attr Batterieuebersicht valueColumn { battery => 1,batteryLevel => 2, Activity => 3 }
attr Batterieuebersicht valueFormat { if (defined $VALUE) {return $VALUE;;;;} else { return 'none';;;;} }
attr Batterieuebersicht valueIcon {'battery.ok' => 'batterie@green', 'battery.low' => 'batterie@red'}
Hi,
Danke für eure Antworten, muss ich wohl am Wochenende noch ein wenig testen und herumspielen mit den readingsgroups.
Zum Modul selbst:
- Da kann man wirklich viel damit machen, hab mir jetzt auch noch eine Temperaturüberwachung darauf aufgebaut (Einzelne Temperatursensoren haben Ober- und Untergrenze als userattr definiert, das Modul setzt dann einen error bei Verlassen des Bereichs)
- Die Aktivitäten hab ich schon mal so halb getestet, aber ich muss das nochmal nur mit Dummy-Geräten und kürzerer Zeit testen. Irgendwie kams mir so vor, als ob die Meldungen nicht nach 12/24h da sind, sondern verzögert, einmal kamen sie erst nach einem Neustart von fhem. Muss allerdings sagen ich hatte eine 1 Jahr alte Installation von fhem drauf, die ich erst jetzt upgedatet hab. Ansonsten halt einige Sachen blacklisten müssen, notifies die ich abgespeichert hab und dann eben nach 12 Stunden nicht wieder geändert hab, wollten sich auch wieder melden.
- Wenn ich was brauchbares stabiles hab stell ichs gern unter Codeschnipsel oder ins wiki.
- Ein simples notify oder DOIF als Beispiel für den Nachrichtenversand wär ganz nett in der commandref direkt beim Modul oder im Wiki gewesen. Das hab ich hier ein wenig vermisst (und wie gesagt alle 16 Seiten hab ich mir nicht durchgelesen).
Ansonsten tolles Modul!
Zitat von: Cyber1000 am 28 November 2018, 21:31:41
- Ein simples notify oder DOIF als Beispiel für den Nachrichtenversand wär ganz nett in der commandref direkt beim Modul oder im Wiki gewesen. Das hab ich hier ein wenig vermisst (und wie gesagt alle 16 Seiten hab ich mir nicht durchgelesen).
Ich behaupte, dass es das simple notify/DOIF nicht gitb. Das fängt schon bei der Art der Übermittlung an: msg Befehl, TelegramBot, Jabber, Whatsapp, E-Mail, Pushbullet, MQTT, ... . Weiterhin sollten Benachrichtigungen auch intelligent sein (z.B. Interessiert mich ein Batteriewechsel mitten in der Nacht nicht). Daher habe ich mich in der Commandref auf diese Passage festgelegt:
Zitat
Das monitor sendet selbst keine Benachrichtung, hierfür ist ein notify oder DOIF notwendig, welches auf das Event "<monitoring-name> error add: <name>" reagiert und dann den Rückgabewert von "get <monitoring-name> default" versendet.
Beim msgDialog Modul wird der wiki Artikel von der Community geschrieben und ich lese den dan bei größeren Änderungen quer. Das können wir für monitoring auch gerne so machen :)
ZitatIch behaupte, dass es das simple notify/DOIF nicht gitb.
Naja meins sieht zum Beispiel jetzt so aus:
m_activity:(warning|error).add:..+ {
my $message=fhem("get m_activity default",1);
sendMessage('Aktivitätswarnung', $message);
}
Und sendmessage verwendet mehr oder weniger den TelegramBot (und Kodi zu bestimmten Zeiten). Durch ein einfaches sendmessage, das ich überall verwende, ist im Endeffekt auch der Bot egal, ich kann ihn auch jederzeit zentral auswechseln. Die Uhrzeiten von Batteriewarnungen können ruhig auch in der Nacht kommen, das Handy hab ich (fast) nie im Schlafzimmer. Aber gut jeder hat da andere Vorlieben, sonst würden vermutlich viele hier ein vorgefertigtes System nehmen und sich nicht selber eines nach eigenen Wünschen zurechtbasteln ;D
Und vermutlich wars damals wie ich ein paar Zeilen Code zusammenbasteln wollte schon etwas zu spät (hust, kurz nach 0:00 und nach einem langen Arbeitstag), aber so ein paar "Anwendungsbeispiele" wären schon manchmal hilfreich.
ZitatBeim msgDialog Modul wird der wiki Artikel von der Community geschrieben
Ja vermutlich wäre ein wiki-Artikel dafür der bessere Ort als ein commandref-Eintrag, da sollte wohl wirklich nur das wesentliche stehn.
Ich hätte da noch eine Frage das Modul betreffend, ich wollte/will das als Aktivitätsmonitor verwenden, nur waren mir am Anfang die Meldungen dann schon zu viel (teilweise für dummydevices, die sich nicht ständig melden - ich wasche auch nicht alle 12/24h Wäsche), deshalb habe ich kurzfristig das Monitoring auf inactive gesetzt und mal viele meiner devices neu benannt, ausgemistet, korrigiert; hab mit fhem vor gut einem Jahr angefangen und war mit dem naming dann teilweise doch inkonsequent, sodass ich in der blacklist sehr viele Geräte direkt eintragen hätte müssen.
Jetzt hab ich das Monitoring wieder aktiviert (set m_activity active), alles bereinigt (set m_acitivity clear all), es landen aber jetzt sehr wenige warningAdd_ oder errorAdd_ in den readings.
defmod m_activity monitoring .*:.*
attr m_activity blacklist global eventTypes initialUsbCheck KODI n_.* d_.* m_.* l_.* w_.* st_.* virtual_switch_.* Benachrichtigung_.* Info_.* Dongle_.* Hauptnode_.*
attr m_activity errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräte haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))\
}
attr m_activity errorWait 60*60*24
attr m_activity warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräte haben sich seit mehr als 12 Stunden nicht mehr gemeldet", @warnings))\
}
attr m_activity warningWait 60*60*12
Im Eventmonitoring hab ich aber nach wie vor Events die so aussehen:
2018-12-12 21:13:38 ZWave Steckdose_Geschirrspueler Power: 0.4 W
Ich wüsste jetzt nicht, wie ich mit obiger blacklist "Steckdose_Geschirrspueler" weggefiltert haben sollte
Eine Idee was hier passiert sein könnte?
Nachtrag:
- Blacklist gelöscht
- gewartet bis die Readings (errorAdd, warningAdd) da waren, die kamen dann auf einmal wieder durch Meldung der Geräte
- blacklist wieder 1:1 reingeschrieben
- dadurch sind die unerwünschten errorAdds und warningAdds rausgefallen
Jetzt scheint wieder alles zu funktionieren, set inactive/set active und clear all dürfte irgendwie das monitoring beschädigen, vielleicht hätte ich das clear all nicht machen dürfen.
Nachtrag vom Nachtrag:
Die blacklist entfernt zwar die gewünschten errorAdd, warningAdd, aber events kommen anschließend auch nicht mehr rein (für keines der Geräte). Kann es sein, dass die blacklist keine regexp verträgt:
Zitatattr m_activity blacklist global eventTypes initialUsbCheck KODI n_.* d_.* m_.* l_.* w_.* st_.* virtual_switch_.* Benachrichtigung_.* Info_.* Dongle_.* Hauptnode_.*
ok ich setze meinen Monolog fort :-) , ich lass die blacklist jetzt ganz weg und mach das über einen negative Lookahead regex.
Also statt mein monitoring auf .*:.* reagieren zu lassen sieht mein DEF jetzt so aus:
(?!global|eventTypes|initialUsbCheck|KODI|n_|d_|m_|l_|w_|st_|virtual_switch_|Benachrichtigung_|Info_|Dongle_|Hauptnode_|dev_|Sensor_LP).*:.*
Es wird somit auf alle Devices, die mit global oder n_ oder d_ oder ... beginnen, nicht mehr reagiert.
Vielleicht kann noch jemand das seltsame Verhalten mit blacklist erklären/verifizieren, ansonsten funktioniert das mal gut für mich.
Hallo zusammen,
das Modul ist echt super, allerdings hab ich Probleme bei der Benachrichtgung.
Ich bekomme die Fehlereldung: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 223) line 1.
Ich hab einen Rückspülfilter angelegt mit einem Dashbutton (die Zeit hab ich absichtlich zum Test auf 20, bzw. 30 Sekunden eingestellt). Das zurücksetzen klappt super, es kommt nur keine Nachricht von dem DOIF im Telegram an. Der Bot funktioniert aber bei anderen Benachrichtigungen.
Anbei meine Config:
define d_Rueckspuelfilter dash_dhcp
attr d_Rueckspuelfilter allowed 18:74:2E:77:7C:29
attr d_Rueckspuelfilter devAlias 18-74-2E-77-7C-29:DashRueckspuelfilter
attr d_Rueckspuelfilter port 6767
define Wasserfilter_monitoring monitoring d_Rueckspuelfilter:.*:.short
attr Wasserfilter_monitoring errorReturn {return unless(@errors);;\
return "Der Wasserfilter muss gewechselt werden.";;\
}
attr Wasserfilter_monitoring errorWait 30
attr Wasserfilter_monitoring warningReturn {return unless(@warnings);;\
return "Der Wasserfilter muss demnächst gewechselt werden.";;\
}
attr Wasserfilter_monitoring warningWait 20
define ServiceNotifications_DI DOIF ([12:35-12:38|8]\
&& ( [":^error add:"]\
|| [$SELF:cmd_nr] == 2\
)\
)(\
set Schokos__Bot message {(fhem("get TYPE=monitoring default"))}\
)\
DOELSEIF\
([":^error add:"])
attr ServiceNotifications_DI cmdState send notifications|notifications pending
attr ServiceNotifications_DI cmdpause 60*15
attr ServiceNotifications_DI do always
attr ServiceNotifications_DI icon time_automatic
attr ServiceNotifications_DI wait 60*15
evtl. hat ja jemand eine Idee
Code bitte in code-tags (# Button über dem Eingabefeld) posten.
Ich sehe aber nichts was den Fehler verursachen sollte. Ist [$SELF:cmd_nr] zu dem Prüfzeitpunkt definiert oder kommt daher vielleicht das ""?
Wenn ich das manuell definieren muss, ist es das wohl nicht. Ich hab leider auch nicht wirklich verstanden, für was das steht...
Zitat von: Schoko am 17 Januar 2019, 22:10:45
Wenn ich das manuell definieren muss, ist es das wohl nicht. Ich hab leider auch nicht wirklich verstanden, für was das steht...
Jetzt weiß ich wieder warum mir der code so bekannt vorkommt, war ursprünglich mal von mir und hat auch funktioniert.
Der besagt, dass in dem von dir gewählten Zeitraum eine Nachricht verschickt wird, wenn ein error add auftritt oder außerhalb des Zeitraums aufgetreten ist. Durch die Attribute wird das dann noch zusätzlich entprellt.
Der Code funktioniert soweit. Wenn du dabei weitere Hilfe benötigst bitte im DOIF Unterforum fragen.
Woher deine Fehlermeldung kommt kann ich dir aber nicht beantworten.
Vielen Dank für Deinen Tipp, dann versuch ich es mal im DOIF Bereich
Hallo,
kann ich das Monitoring Modul zur Überwachung von Türenkontakten (CUL-FHTTKs und HM) verwenden. Ich würde gerne erkennen, wenn der Zustand von Open nach Closed und von Closed nach Open geht. Und das für alle Türen. Da ich das Ergebnis als Sensor für eine Alarmanlage nutzen möchte, brauche ich eine direkte Reaktion.
Zitat von: UweUwe am 24 Januar 2019, 13:09:46
Hallo,
kann ich das Monitoring Modul zur Überwachung von Türenkontakten (CUL-FHTTKs und HM) verwenden. Ich würde gerne erkennen, wenn der Zustand von Open nach Closed und von Closed nach Open geht. Und das für alle Türen. Da ich das Ergebnis als Sensor für eine Alarmanlage nutzen möchte, brauche ich eine direkte Reaktion.
Dafür ist das monitoring Modul nicht geeignet. Die direkte Reaktion bekommst du doch als Event.
Sehr schönes Modul, dass ich bisher noch gar nicht entdeckt hatte. :)
Nur eine kurze Frage dazu:
Wozu gibt es die Variablen $addMatch und $removeMatch z.B. in errorFuncAdd errorFuncRemove?
Muss ich in errorFuncAdd z.B. immer überprüfen ob $addMatch 1 ist?
Oder aus welchem Grund könnte errorFuncAdd aufgerufen werden, ohne dass $addMatch 1 ist?
Ich verstehe die CommandRef so, dass errorFuncAdd immer aufgerufen wird wenn ein Gerät in die Error-Liste aufgenommen werden soll.
Außerdem, dass $addMatch immer auf 1 ist wenn ein Gerät in die Error-Liste aufgenommen werden soll.
Klingt irgendwie doppelt gemoppelt, liegt aber sicher eher daran, dass ich irgendwas nicht verstanden habe. ;)
Und ich wiederhole mal einen Wunsch der schon ein paarmal geäußert wurde und an sich auch ganz gut durch äußere DOIFs / Notifies zu lösen ist.
Aber teilweise wäre es eben doch eleganter dies direkt im Modul lösen zu können:
Es geht darum noch einen Handler/Callback zu haben wenn ein Gerät in die Warning/Error Liste aufgenommen wird.
Ich hab dazu auch ein paar Beispiele warum das durchaus Sinn machen kann.
Es geht dabei nicht darum, sich in diesem Handler einfacher Benachrichtigungen zu schicken, da bin ich auf deiner Seite, dass sowas besser extra in einer Logik abgehandelt gehört.
Ich schreibe bisher aber bei mehreren Überwachungen, die ich gern auf dein Modul umschreiben würde, Werte zurück ins betroffene Gerät.
Man muss sich das dann etwa wie beim Statistics Modul vorstellen.
Mein bisheriges Monitoring liest und überwacht Readings/Events aus einem Gerät und schreibt dann Resultate wieder als Readings ins Gerät zurück um die Infos für das Gerät alle an einem Fleck zu haben.
Z.B. schreibe ich aktuell bei meiner Fensterüberwachung in jedes Fensterkontakt-Device ein Reading "warnLevel" zurück.
Der ist 0 wenn das Fenster zu bzw. erst kurz geöffnet ist, 1 wenn das Fenster langsam mal wieder zugemacht werden könnte (entspricht "warning" aus deinem Modul) und 2 wenn es höchste Eisenbahn wird (wäre dann "error").
Dies ist zum Beispiel hilfreich für die Visualisierung. Ist der warnLevel 1 oder 2 kann ich das Fenster-Icon in der UI sehr einfach in einer anderen Farbe oder mit einem anderen Icon darstellen.
Bei der aktuellen Umsetzung im Modul müsste ich dazu (sofern ich das bis jetzt verstanden habe) das warning und error Reading des monitoring devices parsen um zu sehen, ob der aktuelle Kontakt auf der Liste ist.
Man könnte das z.B. angelehnt an die *FuncAdd Funktionen dann *FuncAdded nennen.
Dann könnte man das z.B. so lösen:
define WindowMonitoring monitoring .*:open .*:closed
Attribut warningFuncAdded:
{ fhem("setreading $name warnLevel 1"); }
Attribut errorFuncAdded:
{ fhem("setreading $name warnLevel 2"); }
Attribut warningFuncRemove:
{
fhem("setreading $name warnLevel 0");
return 1;
}
Attribut errorFuncRemove:
{
fhem("setreading $name warnLevel 0");
return 1;
}
Im Prinzip stehen die Infos die du brauchst doch im state. Da sollte es jeweils ein einzelnes Event pro Gerät geben.
Kurz, weil mobil
Zitat von: Thyraz am 25 Januar 2019, 09:00:21
Wozu gibt es die Variablen $addMatch und $removeMatch z.B. in errorFuncAdd errorFuncRemove?
Muss ich in errorFuncAdd z.B. immer überprüfen ob $addMatch 1 ist?
Oder aus welchem Grund könnte errorFuncAdd aufgerufen werden, ohne dass $addMatch 1 ist?
Ich verstehe die CommandRef so, dass errorFuncAdd immer aufgerufen wird wenn ein Gerät in die Error-Liste aufgenommen werden soll.
Außerdem, dass $addMatch immer auf 1 ist wenn ein Gerät in die Error-Liste aufgenommen werden soll.
Klingt irgendwie doppelt gemoppelt, liegt aber sicher eher daran, dass ich irgendwas nicht verstanden habe. ;)
Wenn du die FuncAdd/Remove Attribute verwendest werden beiden geprüft, also auch errorFuncRemove, wenn ein Event zum $addMatch passt.
Das habe ich so gehalten, damit für spezielle Fälle auch mehrere Devspecs angegeben werden könnne.
Zitat von: Thyraz am 25 Januar 2019, 13:21:08
Es geht darum noch einen Handler/Callback zu haben wenn ein Gerät in die Warning/Error Liste aufgenommen wird.
bitte testen
https://github.com/Igami/FHEM-monitoring/blob/development/FHEM/98_monitoring.pm
Danke für die schnelle Umsetzung. :)
Hier ist glaub noch ein Fehler drin:
my $listFuncAdded = AttrVal($SELF, $list."FuncAdded", "");
$listFuncAdd = $listFuncAdd =~ /^\{.*\}$/s ? eval($listFuncAdd) : fhem($listFuncAdd);
müsste das in der zweiten Zeile einfach überall Added statt Add heißen?
Grüße,
Tobias
Zitat von: Thyraz am 26 Januar 2019, 17:54:49
Danke für die schnelle Umsetzung. :)
Hier ist glaub noch ein Fehler drin:
my $listFuncAdded = AttrVal($SELF, $list."FuncAdded", "");
$listFuncAdd = $listFuncAdd =~ /^\{.*\}$/s ? eval($listFuncAdd) : fhem($listFuncAdd);
müsste das in der zweiten Zeile einfach überall Added statt Add heißen?
Grüße,
Tobias
Ja, müsste es. Habs korrigiert. Bitte testen.
Ok, funktioniert soweit.
Vielen Dank dir. :)
2 Änderungen musste ich noch machen, damit mein Beispiel von der letzte Seite klappt:
- $name ist an der Stelle nicht definiert
- Der Code der Add Handler wir auch bei Remove ausgeführt, schätze @change ist in der return unless Abfrage wahr
So läuft es bei mir, kann auf die Schnelle nicht sagen ob das doch noch irgendwelche Seiteneffekte hat, werde das die Tage mal beobachten:
if ($operation eq "add") {
my $name = $value;
my $listFuncAdded = AttrVal($SELF, $list."FuncAdded", "");
$listFuncAdded = $listFuncAdded =~ /^\{.*\}$/s ? eval($listFuncAdded) : fhem($listFuncAdded);
}
Zitat von: Thyraz am 26 Januar 2019, 22:45:22
Ok, funktioniert soweit.
Vielen Dank dir. :)
2 Änderungen musste ich noch machen, damit mein Beispiel von der letzte Seite klappt:
- $name ist an der Stelle nicht definiert
- Der Code der Add Handler wir auch bei Remove ausgeführt, schätze @change ist in der return unless Abfrage wahr
So läuft es bei mir, kann auf die Schnelle nicht sagen ob das doch noch irgendwelche Seiteneffekte hat, werde das die Tage mal beobachten:
if ($operation eq "add") {
my $name = $value;
my $listFuncAdded = AttrVal($SELF, $list."FuncAdded", "");
$listFuncAdded = $listFuncAdded =~ /^\{.*\}$/s ? eval($listFuncAdded) : fhem($listFuncAdded);
}
Ich bin zwar grad erst dabei mit GitHub warm zu werden, nehme aber auch jetzt schon gerne PullRequests ;)
Ich schaue, dass ich es die nächsten 1-2 Tage nochmal genauer teste mit ein paar weiteren Dingen die ich auf das Monitoring Modul umstellen will.
Wenn das so zu passen scheint stell ich den PullRequest.
Ok, hab nen Pull-Request gestellt. :)
Danke erstmal für das Modul. Das erleicherte die Überwachung sehr.
Allerdings verstehe ich (anscheinend) nicht ganz die Funktion. Was genau wird denn durch das Modul überwacht? Irgendein Reading oder ein bestimmtes (z.B. state)?
Ich habe mehrere LaCrosse-Sensoren, die regelmäßig verschiedene Werte übermitteln (begrenzt durch event-on...).
Wenn ich von dem Reading Temperature ausgehe (Übermittlung am Beispielsensor alle 5 Minuten bei anderen sogar alle 60 Sekunden sollte doch normalerweise keiner der Sensoren unter warning oder
error auftauchen.
Bei der Momentaufnahem sind aber alle Sensoren als "auffällig" geführt, obwohl (einige) Readings aktuell sind. (2ter Screenshot wurde ein paar Minuten später gemacht!)
Zitat von: hmtec99 am 29 Januar 2019, 18:02:03
Allerdings verstehe ich (anscheinend) nicht ganz die Funktion. Was genau wird denn durch das Modul überwacht? Irgendein Reading oder ein bestimmtes (z.B. state)?
Ich habe mehrere LaCrosse-Sensoren, die regelmäßig verschiedene Werte übermitteln (begrenzt durch event-on...).
Es werden nur Events überwacht. Eventuelle werden bei dir keine Events erzeugt, weil es keine Änderung gibt?
Moin,
erstmal tolles Modul muss ich sagen.
Nun zu meiner Frage:
ist es möglich in den Attributen errorReturn und warningReturn dei Variable $name (Name des Event auslösenden Gerätes) mit zu unterstützen?
Vielen Dank.
Gruß Daniel
Zitat von: igami am 27 Januar 2019, 10:18:07
Ich bin zwar grad erst dabei mit GitHub warm zu werden, nehme aber auch jetzt schon gerne PullRequests ;)
Nachdem ich gestern unbedacht FHEM upgedated hab und plötzlich die Fenster-Offen Warnungen nicht mehr kamen,
hab ich das Modul erstmal aus dem Update rausgenommen.
Kannst du hier kurz Bescheid geben (falls du drandenkst) wenn du die neuen Features ins SVN übernimmst?
Hab übrigens jetzt mehrere Monitoring Devices damit im Einsatz, auch Dinge wie die Fenster-Warnungen die mehrmals täglich anschlagen.
Läuft einwandfrei. :)
Zitat von: Thyraz am 05 März 2019, 09:49:19
Kannst du hier kurz Bescheid geben (falls du drandenkst) wenn du die neuen Features ins SVN übernimmst?
Das habe ich doch glatt vergessen...
werde nachher noch die Commandref anpassen und das dann zu morgen einspielen
Super, vielen Dank. :)
Hallo,
lässt sich mein Post von hier
https://forum.fhem.de/index.php/topic,68765.msg905462.html#msg905462
(https://forum.fhem.de/index.php/topic,68765.msg905462.html#msg905462)
auch in einer zukünftigen Version umsetzen?
Vielen Dank.
Gruß Daniel
Zitat von: dancatt am 13 Februar 2019, 07:48:54
ist es möglich in den Attributen errorReturn und warningReturn dei Variable $name (Name des Event auslösenden Gerätes) mit zu unterstützen?
Die Funktion wird manuell aufgerufen, da gibt es kein $name. Es werden alle Geräte auf der Liste als Array (@warnings und @errors) bereitgestellt.
Was hast du für einen konkreten Anwendungsfall?
Moin,
habe folgendes Monitoring Device für die Überwachung der gemessenen Temperatur:
Internals:
DEF ([0123]).([0-9][0-9]).([A-Z][A-Z0-9])(.2)?.(Heizungsthermostat_Clima):measured-temp:..+
FUUID 5c5ac78f-f33f-cf0a-0c13-bb3c1aa4b08b30d7
NAME monitoring_measuredTemp
NR 395
NTFY_ORDER 50-monitoring_measuredTemp
STATE active
TYPE monitoring
.attraggr:
.attrminint:
READINGS:
2019-02-28 07:17:26 allCount 0
2019-02-28 07:17:26 error
2019-02-28 07:17:26 errorCount 0
2019-03-03 08:11:23 state active
2019-02-13 08:16:34 warning
2019-02-13 08:16:34 warningCount 0
Attributes:
DbLogExclude .*
default_measured-temp 26
errorFuncAdd {
return 1 if(ReadingsVal($name, "measured-temp", 0) >= AttrVal($name, "monitoring_measured-temp", AttrVal($SELF, "default_measured-temp", 0)));
return;
}
errorFuncRemove {
return 1 if(ReadingsVal($name, "measured-temp", 0) <= AttrVal($name, "monitoring_measured-temp", AttrVal($SELF, "default_measured-temp", 0)) - AttrVal($SELF, "threshold", 0));
return;
}
errorReturn {
return unless(@errors);
$_ = AttrVal($_, "alias", $_) foreach(@errors);
##my $measuredTemp = AttrVal($name, "monitoring_measured-temp", AttrVal($SELF, "default_measured-temp", 0));
my $measuredTemp = AttrVal($SELF, "default_measured-temp", 0);
return("Das Thermostat \"$errors[0]\" misst eine Temperatur >= ".$measuredTemp." Grad.") if(int(@errors) == 1);
@errors = sort {lc($a) cmp lc($b)} @errors;
return(join("\n - ", "Die folgenden ".@errors." Thermostate messen eine Temperatur >= ".$measuredTemp." Grad:", @errors))
}
group Monitoring
room 9_09_Einstellungen
threshold 1
userattr default_measured-temp threshold
Nun würde ich im Attribut errorReturn gerne die auskommentierte Zeile rein nehmen statt die darauffolgende. Dann hätte ich die Möglichkeit in jedem Device den Defaultwert zu überschreiben.
Eventuell gibt es ja auch eine Alternative die ich nicht sehe.
Wie soll deine Sammelmedlung denn genau aussehen?
Die folgenden 3 Thermostate messen eine Temperatur >= 12 Grad
- Thermostat 1
- Thermostat 2
- Thermostat 3
Es müsste doch eher so sein:
Die folgenden 3 Thermostate messen eine Temperatur im Grenzbereich:
- Thermostat 1 >= 12 Grad
- Thermostat 2 >= 10 Grad
- Thermostat 3 >= 13 Grad
Für den zweiten Fall geht da mit dem folgenen errorReturn (ungetestet):
errorReturn {
return unless(@errors);
my $default_measured-temp = AttrVal($SELF, "default_measured-temp", 0);
return("Das Thermostat ".AttrVal($errors[0], "alias", $errors[0])." misst eine Temperatur >= ".AttrVal($errors[0], "monitoring_measured-temp", $default_measured-temp)." Grad.") if(int(@errors) == 1);
$_ = AttrVal($_, "alias", $_)." >= ".AttrVal($_, "monitoring_measured-temp", $default_measured-temp)." Grad" foreach(@errors);
@errors = sort {lc($a) cmp lc($b)} @errors;
return(join("\n - ", "Die folgenden ".@errors." Thermostate messen eine Temperatur im Grenzbereich:", @errors))
}
Vielen Dank. Schau ich mir nächste Woche mal an.
Aktuell habe ich keine Möglichkeit dazu.
Passt alles. Prima. Vielen dank für die Unterstützung.
Auf die Idee hätte ich auch selbst kommen können.
Guten Abend,
ich bin zu Blöd, wie kann ich den Batteriestatus aller meiner HM-Thermostate überwachen und auch ausgeben -> per Pushover im Fehlerfall (25%)?
Irgendwie bekomme ich das nicht implementiert, kann mir da mal einer kurz helfen.
Danke und einen schönen Abend
Simon
Zitat von: SimonHipp am 23 April 2019, 22:41:00
ich bin zu Blöd, wie kann ich den Batteriestatus aller meiner HM-Thermostate überwachen und auch ausgeben -> per Pushover im Fehlerfall (25%)?
Irgendwie bekomme ich das nicht implementiert, kann mir da mal einer kurz helfen.
Ein list vom device bitte.
Anbei mal meine aktuelle übersicht.
Irgendwas scheint er ja zu prüfen, und auch anzuzeigen, aber wie kann ich das jetzt in eine Pushnachricht wandeln und abschicken?
steh da irgendwie auf dem schlauch!
Was meinst du mit "List vom Device"???
Zitat von: SimonHipp am 24 April 2019, 22:03:12
Anbei mal meine aktuelle übersicht.
Irgendwas scheint er ja zu prüfen, und auch anzuzeigen, aber wie kann ich das jetzt in eine Pushnachricht wandeln und abschicken?
steh da irgendwie auf dem schlauch!
Siehe commandref:
Zitat
Das monitor sendet selbst keine Benachrichtung, hierfür ist ein notify oder DOIF notwendig, welches auf das Event "<monitoring-name> error add: <name>" reagiert und dann den Rückgabewert von "get <monitoring-name> default" versendet.
Hilft dir das weiter?
Zitat von: SimonHipp am 24 April 2019, 22:03:12
Was meinst du mit "List vom Device"???
https://commandref.fhem.de/commandref_DE.html#list
Zitat von: igami am 25 April 2019, 06:18:20
Siehe commandref:Hilft dir das weiter?
https://commandref.fhem.de/commandref_DE.html#list
Leider nicht wirklich, hab es jetzt versucht direkt einzubinden:
{return unless(@warnings);
$_ = AttrVal($_, "alias", $_) foreach(@warnings);
return("Bei dem Gerät \"$warnings[0]\" muss die Batterie demnächst gewechselt werden.") if(int(@warnings) == 1);
@warnings = sort {lc($a) cmp lc($b)} @warnings;
return(join("\n - ", "Die folgenden ".@warnings." Geräten muss die Batterie demnächst gewechselt werden:", @warnings))
set pushmsg msg 'fhem' 'Bei dem Gerät \"$warnings[0]\" muss die Batterie demnächst gewechselt werden. - $EVENT' '' 0 ''
}Jedoch ohne Erfolg, hmmmm
Du brauchst ein anderes device welches die Nachricht verschickt. monitoring sammelt nur ;)
Versuch es mal hiermit:
defmod alarm notify .*:error.add:.+ set pushmsg msg {(fhem("get $NAME default"))}
Hallo Igami, ein tolles Modul.
Auf Seite 6 wird eine Pflanzenüberwachung diskutiert und gelöst. Ich finde diese Lösung allerdings für mich nicht ganz optimal.
Ich habe 8 Pflanzensensoren von Xiaomi
Topfsensor1, Topfsensor2,.......
Anbei ein List, ein Raw und ein Auszug aus einen Logfile eines Sensors
Internals:
BTMAC C4:7C:8D:6A:35:29
DEF C4:7C:8D:6A:35:29
FUUID 5ccc7533-f33f-486f-3766-ecbf7a2880f8af89
INTERVAL 600
NAME TopfSensor7
NOTIFYDEV global,TopfSensor7
NR 532
NTFY_ORDER 50-TopfSensor7
STATE B%:99, C°:14.4, Lux:6555, Dünger:71, Wasser:12 (2019-05-04 11:19:40)
TYPE XiaomiBTLESens
VERSION 2.4.7
loglevel 4
READINGS:
2019-05-04 11:07:28 batteryPercent 99
2019-05-04 11:07:28 batteryState ok
2019-05-04 11:19:40 fertility 71
2019-05-04 11:07:28 firmware 3.1.9
2019-05-04 09:53:19 lastGattError Transport endpoint is not connected (107)
2019-05-04 11:19:40 lux 6555
2019-05-04 11:19:40 moisture 12
2019-05-04 11:19:40 state active
2019-05-04 11:19:40 temperature 14.4
helper:
CallBattery 0
CallSensDataCounter 0
updateTimeCallBattery 1556960848.72804
updateTimestampCallBattery 2019-05-04 11:07:28
Attributes:
alias 01_Süd_Terasse_Mi_Re_TS7
comment sudo hcitool lescan um MacAdresse zu finden
attr TopfSensor7 event-min-interval moisture:1200
event-min-interval moisture:1200
event-on-change-reading .*
group 20_1MicroKlimaSensoren
icon sani_irrigation
interval 600
minMoisture 15
model flowerSens
room XiaomiBTLESens
stateFormat B%:[$name:batteryPercent], C°:[$name:temperature], Lux:[$name:lux], Dünger:[$name:fertility], Wasser:[$name:moisture] ([$name:moisture:t])
defmod TopfSensor1 XiaomiBTLESens C4:7C:8D:65:EC:6E
attr TopfSensor1 alias 06_Süd_Palme_Mi_TS1
attr TopfSensor1 event-min-interval moisture:1200
attr TopfSensor1 event-on-change-reading .*
attr TopfSensor1 group 20_1MicroKlimaSensoren
attr TopfSensor1 icon sani_irrigation
attr TopfSensor1 interval 600
attr TopfSensor1 minFertility 50
attr TopfSensor1 minMoisture 60
attr TopfSensor1 minTemp 5
attr TopfSensor1 model flowerSens
attr TopfSensor1 room XiaomiBTLESens
attr TopfSensor1 stateFormat B%:[$name:batteryPercent], C°:[$name:temperature], Lux:[$name:lux], Dünger:[$name:fertility], Wasser:[$name:moisture] ([$name:moisture:t])
2019-05-04_11:07:03 TopfSensor1 moisture: 56
2019-05-04_11:07:03 TopfSensor1 lux: 53122
2019-05-04_11:07:03 TopfSensor1 fertility: 781
2019-05-04_11:07:03 TopfSensor1 active
2019-05-04_11:07:03 TopfSensor1 minFertility ok
2019-05-04_11:07:03 TopfSensor1 minMoisture low
2019-05-04_11:07:03 TopfSensor1 minTemp ok
2019-05-04_11:09:20 TopfSensor1 write sensor data
2019-05-04_11:09:26 TopfSensor1 read sensor data
2019-05-04_11:09:26 TopfSensor1 fertility: 780
2019-05-04_11:09:26 TopfSensor1 lux: 22790
2019-05-04_11:09:26 TopfSensor1 temperature: 22.5
2019-05-04_11:09:26 TopfSensor1 active
2019-05-04_11:09:26 TopfSensor1 minFertility ok
2019-05-04_11:09:26 TopfSensor1 minMoisture low
2019-05-04_11:09:26 TopfSensor1 minTemp ok
2019-05-04_11:18:09 TopfSensor1 write sensor data
2019-05-04_11:18:11 TopfSensor1 read sensor data
2019-05-04_11:18:11 TopfSensor1 lux: 3248
2019-05-04_11:18:11 TopfSensor1 fertility: 815
2019-05-04_11:18:11 TopfSensor1 temperature: 21.6
2019-05-04_11:18:11 TopfSensor1 active
2019-05-04_11:18:11 TopfSensor1 minFertility ok
2019-05-04_11:18:11 TopfSensor1 minMoisture low
2019-05-04_11:18:11 TopfSensor1 minTemp ok
Nun meine Frage:
Man kann pro Sensor ein Attribut (attr TopfSensor1 minMoisture 20) vergeben, der eine Min Schwelle definiert, im Log wird dann ok oder low "ausgewertet", erscheint aber nicht als Reading.
Ich bitte um Entschuldigung, falls ich mich fachlich nicht so gut ausdrücken kann, ich bin Amateur, hoffe aber meine Fragen und Informationen gut genug gestellt zu haben.
Ziel ist pro Sensor individuelle Grenzen festzulegen.
Kann man sowas mit diesen Modul machen, wenn ja, hast Du ein Beispiel für mich?
Vielen Dank im voraus.
Zitat von: Razor am 04 Mai 2019, 11:42:54
Man kann pro Sensor ein Attribut (attr TopfSensor1 minMoisture 20) vergeben, der eine Min Schwelle definiert, im Log wird dann ok oder low "ausgewertet", erscheint aber nicht als Reading.
[...]
Kann man sowas mit diesen Modul machen, wenn ja, hast Du ein Beispiel für mich?
Da für minMoisture Events erzeugt werden kannst du einfach darauf reagieren (das Modul guckt nicht auf Readings):
define XiaomiminMoisture monitoring .*:minMoisture:.low .*:minMoisture:.ok
Sollte das nicht funktionieren lässt sich das auch noch etwas umständlicher umsetzten (mit errorFuncAdd).
Vielen Dank für die schnelle Hilfe, es funktioniert nicht.
Hier ein Auszug der Events
2019-05-05 09:33:39 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 09:33:41 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 09:33:41 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 09:33:41 XiaomiBTLESens TopfSensor1 fertility: 524
2019-05-05 09:33:41 XiaomiBTLESens TopfSensor1 lux: 4451
2019-05-05 09:33:41 XiaomiBTLESens TopfSensor1 temperature: 20
2019-05-05 09:33:41 XiaomiBTLESens TopfSensor1 active
2019-05-05 09:33:41 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 09:33:41 XiaomiBTLESens TopfSensor1 minMoisture low
2019-05-05 09:33:41 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 09:39:00 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 09:39:02 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 09:39:02 XiaomiBTLESens TopfSensor1 lux: 4684
2019-05-05 09:39:02 XiaomiBTLESens TopfSensor1 temperature: 20.2
2019-05-05 09:39:02 XiaomiBTLESens TopfSensor1 fertility: 520
2019-05-05 09:39:02 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 09:39:02 XiaomiBTLESens TopfSensor1 active
2019-05-05 09:39:02 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 09:39:02 XiaomiBTLESens TopfSensor1 minMoisture low
2019-05-05 09:39:02 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 batteryState: ok
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 batteryPercent: 64
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 firmware: 3.1.8
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 active
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 temperature: 20.1
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 lux: 4802
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 fertility: 528
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 active
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 minMoisture low
2019-05-05 09:39:51 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 09:43:43 Global global ATTR TopfSensor1 minMoisture 10
2019-05-05 09:45:20 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 09:45:24 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 09:45:24 XiaomiBTLESens TopfSensor1 temperature: 20.2
2019-05-05 09:45:24 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 09:45:24 XiaomiBTLESens TopfSensor1 lux: 5303
2019-05-05 09:45:24 XiaomiBTLESens TopfSensor1 fertility: 517
2019-05-05 09:45:24 XiaomiBTLESens TopfSensor1 active
2019-05-05 09:45:24 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 09:45:24 XiaomiBTLESens TopfSensor1 minMoisture ok
2019-05-05 09:45:24 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 09:46:35 Global global ATTR TopfSensor1 minMoisture 50
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 firmware: 3.1.8
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 batteryState: ok
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 batteryPercent: 80
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 active
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 temperature: 19.9
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 fertility: 522
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 lux: 5691
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 active
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 minMoisture low
2019-05-05 09:48:48 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 09:50:53 Global global ATTR TopfSensor1 minMoisture 42
2019-05-05 09:52:41 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 09:52:43 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 09:52:43 XiaomiBTLESens TopfSensor1 lux: 5948
2019-05-05 09:52:43 XiaomiBTLESens TopfSensor1 fertility: 526
2019-05-05 09:52:43 XiaomiBTLESens TopfSensor1 temperature: 20.1
2019-05-05 09:52:43 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 09:52:43 XiaomiBTLESens TopfSensor1 active
2019-05-05 09:52:43 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 09:52:43 XiaomiBTLESens TopfSensor1 minMoisture ok
2019-05-05 09:52:43 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 09:58:48 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 09:58:52 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 09:58:52 XiaomiBTLESens TopfSensor1 temperature: 20.3
2019-05-05 09:58:52 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 09:58:52 XiaomiBTLESens TopfSensor1 lux: 7282
2019-05-05 09:58:52 XiaomiBTLESens TopfSensor1 fertility: 521
2019-05-05 09:58:52 XiaomiBTLESens TopfSensor1 active
2019-05-05 09:58:52 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 09:58:52 XiaomiBTLESens TopfSensor1 minMoisture ok
2019-05-05 09:58:52 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 10:01:49 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 10:01:52 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 10:01:52 XiaomiBTLESens TopfSensor1 lux: 4897
2019-05-05 10:01:52 XiaomiBTLESens TopfSensor1 fertility: 522
2019-05-05 10:01:52 XiaomiBTLESens TopfSensor1 temperature: 20.5
2019-05-05 10:01:52 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 10:01:52 XiaomiBTLESens TopfSensor1 active
2019-05-05 10:01:52 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 10:01:52 XiaomiBTLESens TopfSensor1 minMoisture ok
2019-05-05 10:01:52 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 10:07:37 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 10:07:43 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 10:07:43 XiaomiBTLESens TopfSensor1 lux: 8097
2019-05-05 10:07:43 XiaomiBTLESens TopfSensor1 fertility: 525
2019-05-05 10:07:43 XiaomiBTLESens TopfSensor1 temperature: 20.5
2019-05-05 10:07:43 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 10:07:43 XiaomiBTLESens TopfSensor1 active
2019-05-05 10:07:43 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 10:07:43 XiaomiBTLESens TopfSensor1 minMoisture ok
2019-05-05 10:07:43 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 10:11:08 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 10:11:11 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 10:11:11 XiaomiBTLESens TopfSensor1 temperature: 20.7
2019-05-05 10:11:11 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 10:11:11 XiaomiBTLESens TopfSensor1 lux: 29490
2019-05-05 10:11:11 XiaomiBTLESens TopfSensor1 fertility: 521
2019-05-05 10:11:11 XiaomiBTLESens TopfSensor1 active
2019-05-05 10:11:11 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 10:11:11 XiaomiBTLESens TopfSensor1 minMoisture ok
2019-05-05 10:11:11 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 10:13:33 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 10:13:35 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 10:13:35 XiaomiBTLESens TopfSensor1 fertility: 518
2019-05-05 10:13:35 XiaomiBTLESens TopfSensor1 lux: 6455
2019-05-05 10:13:35 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 10:13:35 XiaomiBTLESens TopfSensor1 temperature: 20.7
2019-05-05 10:13:35 XiaomiBTLESens TopfSensor1 active
2019-05-05 10:13:35 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 10:13:35 XiaomiBTLESens TopfSensor1 minMoisture ok
2019-05-05 10:13:35 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 10:19:50 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 10:19:52 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 10:19:52 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 10:19:52 XiaomiBTLESens TopfSensor1 temperature: 20.6
2019-05-05 10:19:52 XiaomiBTLESens TopfSensor1 fertility: 518
2019-05-05 10:19:52 XiaomiBTLESens TopfSensor1 lux: 7696
2019-05-05 10:19:52 XiaomiBTLESens TopfSensor1 active
2019-05-05 10:19:52 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 10:19:52 XiaomiBTLESens TopfSensor1 minMoisture ok
2019-05-05 10:19:52 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 10:55:28 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 10:55:31 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 10:55:31 XiaomiBTLESens TopfSensor1 fertility: 522
2019-05-05 10:55:31 XiaomiBTLESens TopfSensor1 lux: 9752
2019-05-05 10:55:31 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 10:55:31 XiaomiBTLESens TopfSensor1 temperature: 20.8
2019-05-05 10:55:31 XiaomiBTLESens TopfSensor1 active
2019-05-05 10:55:31 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 10:55:31 XiaomiBTLESens TopfSensor1 minMoisture ok
2019-05-05 10:55:31 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 11:02:07 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 11:02:09 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 11:02:09 XiaomiBTLESens TopfSensor1 fertility: 515
2019-05-05 11:02:09 XiaomiBTLESens TopfSensor1 lux: 10148
2019-05-05 11:02:09 XiaomiBTLESens TopfSensor1 moisture: 43
2019-05-05 11:02:09 XiaomiBTLESens TopfSensor1 temperature: 21.6
2019-05-05 11:02:09 XiaomiBTLESens TopfSensor1 active
2019-05-05 11:02:09 XiaomiBTLESens TopfSensor1 minFertility ok
2019-05-05 11:02:09 XiaomiBTLESens TopfSensor1 minMoisture ok
2019-05-05 11:02:09 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 11:07:28 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 11:07:31 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 11:07:31 XiaomiBTLESens TopfSensor1 moisture: 1
2019-05-05 11:07:31 XiaomiBTLESens TopfSensor1 temperature: 23
2019-05-05 11:07:31 XiaomiBTLESens TopfSensor1 fertility: 0
2019-05-05 11:07:31 XiaomiBTLESens TopfSensor1 lux: 42005
2019-05-05 11:07:31 XiaomiBTLESens TopfSensor1 active
2019-05-05 11:07:31 XiaomiBTLESens TopfSensor1 minFertility low
2019-05-05 11:07:31 XiaomiBTLESens TopfSensor1 minMoisture low
2019-05-05 11:07:31 XiaomiBTLESens TopfSensor1 minTemp ok
2019-05-05 11:08:37 XiaomiBTLESens TopfSensor1 write sensor data
2019-05-05 11:08:43 XiaomiBTLESens TopfSensor1 read sensor data
2019-05-05 11:08:43 XiaomiBTLESens TopfSensor1 temperature: 23.3
2019-05-05 11:08:43 XiaomiBTLESens TopfSensor1 moisture: 1
2019-05-05 11:08:43 XiaomiBTLESens TopfSensor1 lux: 41457
2019-05-05 11:08:43 XiaomiBTLESens TopfSensor1 fertility: 0
2019-05-05 11:08:43 XiaomiBTLESens TopfSensor1 active
2019-05-05 11:08:43 XiaomiBTLESens TopfSensor1 minFertility low
2019-05-05 11:08:43 XiaomiBTLESens TopfSensor1 minMoisture low
2019-05-05 11:08:43 XiaomiBTLESens TopfSensor1 minTemp ok
Zitat von: Razor am 05 Mai 2019, 11:10:12
Vielen Dank für die schnelle Hilfe, es funktioniert nicht.
Ach, ich bin ja auch doof ::)
Die Doppelpunkte hinter minMoisture wären ja nur bei Readings da...
Versuch es doch mal ohne
define XiaomiminMoisture monitoring .*:minMoisture.low .*:minMoisture.ok
XiaomiminMoisture
error add: TopfSensor1 :) :) :) :) :) :) :) :) :) :) :)
Vielen lieben Dank
Ein kleiner Schritt für dich, für mich ein riesiger ;D
Hallo und guten Abend,
habe eben in meinem Log gesehen das ich seit 2 Tagen die folgende Meldung immer 2mal gleichzeitig jede Minuite im Log habe:
2019.06.06 03:52:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:52:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:53:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:53:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:54:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:54:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:55:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:55:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:56:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:56:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:57:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:57:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:58:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:58:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:59:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 03:59:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 04:00:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 04:00:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 04:01:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 04:01:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 04:02:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
2019.06.06 04:02:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
Hat da jemand einen Tipp wo ich da mal nachschauen könnte?
Gruß Markus
Guten Morgen,
bin schonmal etwas weiter gekommen, die Meldung kam nachdem ich die Module RESIDENTS und ROOMMATE angelegt habe, ist da etwas bekannt das die Module untereinander eventuell Probleme machen bzw. kann das Verhalten von euch jemand bestätigen?
Gruß
Markuss
Hallo zusammen,
ich setzte das Monitoring für ein paar Funktionen ein, z.B. für die überwachung von Fensterkontakten. Da geht das auch problemlos. Aber bei lang laufenden Monitorings, über 30 Tage, bzw. 3 Monate setzt er weder Warning noch Errormeldungen...
Anbei der Code einer der Funkitonen
defmod Filterkanne_monitoring monitoring dash_Filterkanne:.*:.short
attr Filterkanne_monitoring errorReturn {return unless(@errors);;\
return "Die Filterkanne muss gereinigt werden.";;\
}
attr Filterkanne_monitoring errorWait 30*24*60*60
attr Filterkanne_monitoring room Logik
attr Filterkanne_monitoring warningReturn {return unless(@warnings);;\
return "Die Filterkanne muss demnächst gereinigt werden.";;\
}
attr Filterkanne_monitoring warningWait 28*24*60*60
setstate Filterkanne_monitoring error remove: dash_Filterkanne
setstate Filterkanne_monitoring 2019-03-14 09:34:02 allCount 0
setstate Filterkanne_monitoring 2019-03-14 09:34:02 error
setstate Filterkanne_monitoring 2019-05-05 08:26:58 errorAdd_dash_Filterkanne 2019-06-04 08:26:58
setstate Filterkanne_monitoring 2019-03-14 09:34:02 errorCount 0
setstate Filterkanne_monitoring 2019-03-14 09:34:02 state error remove: dash_Filterkanne
setstate Filterkanne_monitoring 2019-03-10 21:21:23 warning
setstate Filterkanne_monitoring 2019-05-05 08:26:58 warningAdd_dash_Filterkanne 2019-06-02 08:26:58
setstate Filterkanne_monitoring 2019-03-10 21:21:23 warningCount 0
Vielleicht sieht ja von Euch jemand einen Fehler...
Er hätte ja am 2.6. eine Warnung und am 4.6. einen Error setzen müssen...
Setze ich die Zeit warningwait auf 60 und errorwait auf 120 funktioniert es... echt seltsam...
Danke schon mal
Gruß
Schoko
Zitat von: meier81 am 07 Juni 2019, 22:01:23
2019.06.06 03:52:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
Hat da jemand einen Tipp wo ich da mal nachschauen könnte?
Du musst das Attribut errorWait vergeben.
Zitat von: Schoko am 08 Juni 2019, 14:40:13
Aber bei lang laufenden Monitorings, über 30 Tage, bzw. 3 Monate setzt er weder Warning noch Errormeldungen...
Das monitoring ist soweit fehlerfrei. Ich habe das gleiche Problem bei mir auch schon festgestellt und kann mir nicht erklären woran es liegt. Diese Ausnahmen fange ich mit einem at ab:
defmod set_monitoring_activ at *03:00 set TYPE=monitoring:FILTER=state!=inactive active
Nicht schön, aber funktioniert ::)
Zitat von: igami am 09 Juni 2019, 09:32:03
Du musst das Attribut errorWait vergeben.
Hallo und guten Abend,
das Attribut habe ich schon die ganze Zeit vergeben, hier mal ein List meines Devices:
Internals:
DEF ^[^:]+:(?!Activity).+$
FUUID 5c457742-f33f-c2d2-f71e-e03ff57941d32d0f
FVERSION 98_monitoring.pm:0.188010/2019-03-06
NAME DeviceMonitor
NR 100
NTFY_ORDER 50-DeviceMonitor
STATE active
TYPE monitoring
READINGS:
2019-05-12 07:15:22 allCount 0
2019-05-12 07:15:22 error
2019-06-10 20:51:55 errorAdd_Fuehler_Arbeitszimmer 2019-06-11 02:51:55
2019-06-10 21:10:24 errorAdd_Fuehler_Bad 2019-06-11 03:10:24
2019-06-10 21:09:04 errorAdd_Fuehler_Dachgeschoss 2019-06-11 03:09:04
2019-06-10 20:40:26 errorAdd_Fuehler_Elias 2019-06-11 02:40:26
2019-06-10 21:08:58 errorAdd_Fuehler_Keller 2019-06-11 03:08:58
2019-06-10 21:11:14 errorAdd_Fuehler_Kueche 2019-06-11 03:11:14
2019-06-10 20:57:15 errorAdd_Fuehler_Schlafzimmer 2019-06-11 02:57:15
2019-06-10 20:39:09 errorAdd_Fuehler_Wohnzimmer 2019-06-11 02:39:09
2019-05-12 07:15:22 errorCount 0
2019-06-07 22:12:35 state active
2019-04-25 20:37:22 warning
2019-04-25 20:37:22 warningCount 0
Attributes:
errorWait AttrVal($name, "device_timeout", 0)
whitelist device_timeout=.+
Konnte es eben wieder reproduzieren, hatte die Tage die ROOMMATE und RESIDENTS-Devices gelöscht, seitdem keine Probleme, jetzt wieder neu angelegt und schon gehen die Fehler im Log wieder los. Habe einen Moment gewartet und dann wieder die Devices gelöscht, jetzt ist wieder Ruhe im Log.
Hast du noch eine Idee was ich da machen könnte?
Gruß Markus
Ich würde vermuten, dass device_timeout als 0 zurück gegeben wird, dann kommt auch der Fehler.
Okay, als Info noch ich habe den Devices ROOMMATE und RESIDENTS das Attribut device_timeout nicht gesetzt, ich will diese ja nicht überwachen.
Kannst du das Problem bei dir nachstellen, habe bei mir das Device ROOMMATE angelegt, Attribute alle Standard gelassen und den Status noch auf "Zuhause" gestellt, und schon fangen die Einträge im Log an.
Gruß Markus
Moin moin,
ich wollte nur Bescheid geben das ich mein Problem
2019.06.06 03:52:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
lösen konnte, ich hatte als Raumfühler den ich mit monitoring überwache "Fuehler_Elias" als Definition gehabt und beim ROOMMATE hatte ich die Definition einfach nur "Elias" genannt. Anscheinend ist dem Attribut im monitoring-Device
errorWait AttrVal($name, "device_timeout", 0)
der Anfang des Device-Namens egal und er bringt deswegen die Meldung. Ist aber kein Problem, habe das ROOMMATE-Device umbenannt in "rr_Elias", jetzt läuft´s prima.
Gruß
Markus
trotzdem merkwürdig, aber dann hake ich das erstmal als "erledigt" ab
Hallo igami,
die warnings und errors werden als Komma-separierte Einträge in die entsprechenden Readings geschrieben.
Gibt es eine Möglichkeit statt der Komma-Separierung einen Zeilenumbruch als Trenner zu nutzen, so dass die ausgeworfenen Devices untereinander angezeigt werden können?
Falls ich das selbst (als User) umsetzen kann, dann benötige ich deine Unterstützung.
Viele Grüße Gisbert
Zitat von: Gisbert am 21 Juli 2019, 09:38:19
Falls ich das selbst (als User) umsetzen kann, dann benötige ich deine Unterstützung.
Für die menschen lesbare Form gibt es das Attribut errorReturn bzw. warningReturn. Beispiele zur Nutzung finden sich in der Commandref und hier im Thread. Falls du dennoch schwierigkeiten bei der Umsetzung hast melde dich noch mal. Falls du es alleine hinbekommst teile deine Lösung hier mit anderen.
Zitat von: igami am 23 Juli 2019, 20:12:29
Für die menschen lesbare Form gibt es das Attribut errorReturn bzw. warningReturn. Beispiele zur Nutzung finden sich in der Commandref und hier im Thread. Falls du dennoch schwierigkeiten bei der Umsetzung hast melde dich noch mal. Falls du es alleine hinbekommst teile deine Lösung hier mit anderen.
Hallo igami,
ich hab's leider nur halb hinbekommen, im Endeffekt also nicht.
Ich hab zwar eine Zeile im Modul entdeckt, die zum gewünschten Effekt führt, aber das Entfernen der error und warning Einträge funktioniert dann nicht mehr automatisch,
siehe auch hier:https://forum.fhem.de/index.php/topic,102580.msg963779.html#msg963779 (https://forum.fhem.de/index.php/topic,102580.msg963779.html#msg963779)
Entschuldige, dass ich einen 2. Thread aufgemacht habe, ich konnte mich an diesen nicht mehr erinnern. Entweder ist es altersbedingt und normal, oder ich muss mir Gedanken machen :-\
Die Atrribute errorReturn und warningReturn habe ich in diesem Thread durchforstet, und auch die commandref, leider ohne dass ich daraus eine Vorlage für mein Vorhaben ableiten konnte.
"get <device> error" liefert eine Liste in einem neuen Fenster.
Ich hätte gerne ein Reading, welches als Trennzeichen statt eines Kommas ein Komma+Leerzeichen enthält.
Viele Grüße Gisbert
Hallo igami,
jetzt verstehe dein pädagogisches Konzept ;): Hilfe durch Selbsthilfe !!
Durch Suchen mit den Stichworten "split fhem" bin ich auf diesen Beitrag von dir gestoßen, der mich zur Lösung geführt hat:
https://forum.fhem.de/index.php/topic,58059.msg494877.html#msg494877 (https://forum.fhem.de/index.php/topic,58059.msg494877.html#msg494877)
{my $ret = AttrVal(...); $ret =~ s/<suchen>/<ersetzen>/g; return $ret}
In meinem konkreten Fall lautet das Attribut für ein userReading, bei dem aus dem Reading "error" durch einen Zeilenumbruch [Edit: statt eines Kommas] ein userReading erstellt wird, wie folgt:
attr device userReadings myFehler {my $ret = ReadingsVal("device","error","");; $ret =~ s/,/\n/g;; return $ret}
Den anderen Beitrag in der gleichen Sache markiere ich dann noch als gelöst.
Viele Grüße Gisbert
Ich hab mal eine Frage, ich habe mir die Fensterüberwachung angelegt, der Count funktioniert auch wunderbar.
Habe aber ein kleines Problem: Möchte gerne Fenster, Türen und Tore voneinander trennen. Kann man das mit dem Monitoring machen ? Momentan werden ja alle auf dem selben Count gezählt. Könnte ich hier mehrere monitoring Devices anlegen, aber dort irgendwie Filtern ? Nur Türen, nur Fenster usw ? Dazu müsst ich die Devices umbenennen, oder in dem Monitoring Device die Namen der Sensoren eintragen, die er überwachen soll ?
Wie stelle ich das am besten an ?
EDIT::
Ich glaub ich hab's selber hinbekommen. Hab das nun übe das attr Blacklist gelöst, scheint zu klappen, es werden die Sensoren die drin stehen, mal nicht zum Count gezählt. Dann kann ich zwei weitere Monitoring Devices anlegen und umbenennen, den Text anpassen, fertig.
Nun sollte ich das ganze nur noch auf meine Hauptseite bekommen, das über dem Icon dann die Anzahl offener Fenster angezeigt wird und vllt noch den Text dazu.
Das wäre mein Icon über das ich dann zur Detailseite gelange.
<td>
<div data-type="pagebutton"
data-url="#content_Kontakte.html"
data-load="#content_Kontakte"
data-off-background-color="transparent"
data-off-color="#0088CC"
data-on-background-color="transparent"
data-on-color="#0088CC"
data-active-pattern=".*#content_Kontakte.html"
data-device="Tuer_Ueberwachung"
data-get="allCount"
data-states='["0","1","2","3","4"]'
data-icons='["oa-fts_door","oa-fts_door_open blink warn","oa-fts_door_open blink warn","oa-fts_door_open blink warn","oa-fts_door_open blink warn",]'
data-colors='["red","green"]'
class="tall">
</div>
Wie müsste ich das ergänzen ?
Hallo igami,
nach einem Fhem update und Neustart von Fhem, bekomme ich in meiner Monitorliste Devices als error angezeigt, deren Reading aber eindeutig regelmäßig neu geschrieben werden. Diese dürften dann weder in der warning- noch in der error-Liste auftauchen, was sie aber mir unerklärlicherwise in 2 Fällen tun.
warningWait steht auf 3600 und errorWait auf 7200; der Neustart von Fhem war vor etwa 4 Stunden.
Die beiden Devices <mySIGNALduino> und <mySignalESPHelicalAntenna> sind online und per ping erreichbar, und das überwachte Reading wird regelmäßig neu geschrieben. Die anderen 3 Devices sind tatsächlich offline; bei denen kann ich nachvollziehen, dass sie auf der error-Liste landen.
Ein list meines monitor-Devices:
Internals:
CFGFN ./FHEM/Monitoring.cfg
DEF .*:Zeitstempel.*
FUUID 5c9399d1-f33f-e986-c49d-65266b4f197d5acc
NAME mymonitoring
NR 668
NTFY_ORDER 50-mymonitoring
STATE <i>Fehler</i>:<br><span style='color:#FF0000'>RollladenSchlafzimmerFelix<br>SonoffPow5373<br>myHmUARTLGW1<br>mySIGNALduino<br>mySignalESPHelicalAntenna</span>
TYPE monitoring
READINGS:
2019-08-24 15:46:14 allCount 5
2019-08-24 14:45:29 error RollladenSchlafzimmerFelix,SonoffPow5373,myHmUARTLGW1,mySIGNALduino,mySignalESPHelicalAntenna
2019-08-24 16:31:10 errorAdd_AVIAXpress.Leverkusen 2019-08-24 18:31:10
2019-08-24 16:34:59 errorAdd_Buienradar 2019-08-24 18:34:59
2019-08-24 16:15:37 errorAdd_CO2Germany 2019-08-24 18:15:37
2019-08-24 16:31:48 errorAdd_D.Haushaltsraum 2019-08-24 18:31:48
2019-08-24 16:00:05 errorAdd_DWD.Wetter.Leverkusen 2019-08-24 18:00:05
2019-08-24 16:37:48 errorAdd_ESP8266.Klingelerkennung 2019-08-24 18:37:48
2019-08-24 16:33:13 errorAdd_Ethereum 2019-08-24 18:33:13
2019-08-24 16:36:02 errorAdd_Garage 2019-08-24 18:36:02
2019-08-24 15:59:35 errorAdd_Garagentor.Kontakt 2019-08-24 17:59:35
2019-08-24 16:37:52 errorAdd_HMLAN1 2019-08-24 18:37:52
2019-08-24 16:36:36 errorAdd_Haushaltsraum.Ventilator 2019-08-24 18:36:36
2019-08-24 16:37:33 errorAdd_Heizung 2019-08-24 18:37:33
2019-08-24 16:36:09 errorAdd_HeizungResist 2019-08-24 18:36:09
2019-08-24 16:32:20 errorAdd_Jet.Koeln.Berg.Gladbacher.Str 2019-08-24 18:32:20
2019-08-24 16:33:30 errorAdd_Jet.Koeln.Worringen 2019-08-24 18:33:30
2019-08-24 16:35:20 errorAdd_Klingel 2019-08-24 18:35:20
2019-08-24 16:36:43 errorAdd_Lichtstaerke 2019-08-24 18:36:43
2019-08-24 15:46:15 errorAdd_Luftqualitaet 2019-08-24 17:46:15
2019-08-24 16:37:20 errorAdd_MyBroker 2019-08-24 18:37:20
2019-08-24 16:34:40 errorAdd_PM.Koeln.Liebigstr 2019-08-24 18:34:40
2019-08-24 16:33:16 errorAdd_RollladenSchlafzimmerGisbert 2019-08-24 18:33:16
2019-08-24 16:37:53 errorAdd_RollladenWohnzimmerSued 2019-08-24 18:37:53
2019-08-24 16:33:48 errorAdd_RollladenWohnzimmerTerrasse 2019-08-24 18:33:48
2019-08-24 16:37:54 errorAdd_RollladenWohnzimmerWest 2019-08-24 18:37:54
2019-08-24 16:37:58 errorAdd_SpitzbodenVent 2019-08-24 18:37:58
2019-08-24 16:35:50 errorAdd_Star.Duennwald 2019-08-24 18:35:50
2019-08-24 16:33:05 errorAdd_Stellantriebe.EG 2019-08-24 18:33:05
2019-08-24 16:36:40 errorAdd_Stellantriebe.OG 2019-08-24 18:36:40
2019-08-24 16:37:58 errorAdd_Temp.EG 2019-08-24 18:37:58
2019-08-24 16:36:42 errorAdd_Temp.OG 2019-08-24 18:36:42
2019-08-24 15:59:55 errorAdd_WH3080 2019-08-24 17:59:55
2019-08-24 16:35:55 errorAdd_Wetter.Proplanta 2019-08-24 18:35:55
2019-08-24 16:36:06 errorAdd_bft.Lev.WillyBrandtRing 2019-08-24 18:36:06
2019-08-24 15:45:23 errorAdd_myAstro 2019-08-24 17:45:23
2019-08-24 16:30:07 errorAdd_myBlitzer 2019-08-24 18:30:07
2019-08-24 16:35:12 errorAdd_myTwilight 2019-08-24 18:35:12
2019-08-24 16:36:16 errorAdd_myUniFi 2019-08-24 18:36:16
2019-08-24 16:27:01 errorAdd_netatmo_D70_ee_50_00_ea_7e 2019-08-24 18:27:01
2019-08-24 16:37:02 errorAdd_netatmo_D70_ee_50_02_46_0a 2019-08-24 18:37:02
2019-08-24 16:37:02 errorAdd_netatmo_D70_ee_50_16_12_08 2019-08-24 18:37:02
2019-08-24 16:37:02 errorAdd_netatmo_D70_ee_50_2c_ba_5e 2019-08-24 18:37:02
2019-08-24 14:45:29 errorCount 5
2019-08-24 16:37:58 myerror RollladenSchlafzimmerFelix<br>SonoffPow5373<br>myHmUARTLGW1<br>mySIGNALduino<br>mySignalESPHelicalAntenna
2019-08-24 16:37:58 mywarning
2019-08-24 15:46:14 state warning remove: Luftqualitaet
2019-08-24 15:46:14 warning
2019-08-24 16:31:10 warningAdd_AVIAXpress.Leverkusen 2019-08-24 17:31:10
2019-08-24 16:34:59 warningAdd_Buienradar 2019-08-24 17:34:59
2019-08-24 16:15:37 warningAdd_CO2Germany 2019-08-24 17:15:37
2019-08-24 16:31:48 warningAdd_D.Haushaltsraum 2019-08-24 17:31:48
2019-08-24 16:00:05 warningAdd_DWD.Wetter.Leverkusen 2019-08-24 17:00:05
2019-08-24 16:37:48 warningAdd_ESP8266.Klingelerkennung 2019-08-24 17:37:48
2019-08-24 16:33:13 warningAdd_Ethereum 2019-08-24 17:33:13
2019-08-24 16:36:02 warningAdd_Garage 2019-08-24 17:36:02
2019-08-24 15:59:35 warningAdd_Garagentor.Kontakt 2019-08-24 16:59:35
2019-08-24 16:37:52 warningAdd_HMLAN1 2019-08-24 17:37:52
2019-08-24 16:36:36 warningAdd_Haushaltsraum.Ventilator 2019-08-24 17:36:36
2019-08-24 16:37:33 warningAdd_Heizung 2019-08-24 17:37:33
2019-08-24 16:36:09 warningAdd_HeizungResist 2019-08-24 17:36:09
2019-08-24 16:32:20 warningAdd_Jet.Koeln.Berg.Gladbacher.Str 2019-08-24 17:32:20
2019-08-24 16:33:30 warningAdd_Jet.Koeln.Worringen 2019-08-24 17:33:30
2019-08-24 16:35:20 warningAdd_Klingel 2019-08-24 17:35:20
2019-08-24 16:36:43 warningAdd_Lichtstaerke 2019-08-24 17:36:43
2019-08-24 15:46:15 warningAdd_Luftqualitaet 2019-08-24 16:46:15
2019-08-24 16:37:20 warningAdd_MyBroker 2019-08-24 17:37:20
2019-08-24 16:34:40 warningAdd_PM.Koeln.Liebigstr 2019-08-24 17:34:40
2019-08-24 16:33:16 warningAdd_RollladenSchlafzimmerGisbert 2019-08-24 17:33:16
2019-08-24 16:37:53 warningAdd_RollladenWohnzimmerSued 2019-08-24 17:37:53
2019-08-24 16:33:48 warningAdd_RollladenWohnzimmerTerrasse 2019-08-24 17:33:48
2019-08-24 16:37:54 warningAdd_RollladenWohnzimmerWest 2019-08-24 17:37:54
2019-08-24 16:37:58 warningAdd_SpitzbodenVent 2019-08-24 17:37:58
2019-08-24 16:35:50 warningAdd_Star.Duennwald 2019-08-24 17:35:50
2019-08-24 16:33:05 warningAdd_Stellantriebe.EG 2019-08-24 17:33:05
2019-08-24 16:36:40 warningAdd_Stellantriebe.OG 2019-08-24 17:36:40
2019-08-24 16:37:58 warningAdd_Temp.EG 2019-08-24 17:37:58
2019-08-24 16:36:42 warningAdd_Temp.OG 2019-08-24 17:36:42
2019-08-24 15:59:55 warningAdd_WH3080 2019-08-24 16:59:55
2019-08-24 16:35:55 warningAdd_Wetter.Proplanta 2019-08-24 17:35:55
2019-08-24 16:36:06 warningAdd_bft.Lev.WillyBrandtRing 2019-08-24 17:36:06
2019-08-24 15:45:23 warningAdd_myAstro 2019-08-24 16:45:23
2019-08-24 16:30:07 warningAdd_myBlitzer 2019-08-24 17:30:07
2019-08-24 16:35:12 warningAdd_myTwilight 2019-08-24 17:35:12
2019-08-24 16:36:16 warningAdd_myUniFi 2019-08-24 17:36:16
2019-08-24 16:27:01 warningAdd_netatmo_D70_ee_50_00_ea_7e 2019-08-24 17:27:01
2019-08-24 16:37:02 warningAdd_netatmo_D70_ee_50_02_46_0a 2019-08-24 17:37:02
2019-08-24 16:37:02 warningAdd_netatmo_D70_ee_50_16_12_08 2019-08-24 17:37:02
2019-08-24 16:37:02 warningAdd_netatmo_D70_ee_50_2c_ba_5e 2019-08-24 17:37:02
2019-08-24 15:46:14 warningCount 0
helper:
bm:
monitoring_Get:
cnt 6
dmx -1000
dtot 0
dtotcnt 0
mTS 24.08. 16:24:44
max 0.000926971435546875
tot 0.00209712982177734
mAr:
HASH(0x55630b228538)
mymonitoring
all
monitoring_Notify:
cnt 17011
dmx -1000
dtot 0
dtotcnt 0
mTS 24.08. 14:46:14
max 0.0231859683990479
tot 47.158837556839
mAr:
HASH(0x55630b228538)
HASH(0x55630a255278)
monitoring_Set:
cnt 16
dmx -1000
dtot 0
dtotcnt 0
mTS 24.08. 16:24:05
max 0.000257015228271484
tot 0.00199413299560547
mAr:
HASH(0x55630b228538)
mymonitoring
?
Attributes:
alias monitor
blacklist Wassermelder
errorReturn {return unless(@errors);
$_ = AttrVal($_, "alias", $_) foreach(@errors);
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 2 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);
@errors = sort {lc($a) cmp lc($b)} @errors;
return(join("\n - ", "Die folgenden ".@errors." Geräte haben sich seit mehr als 2 Stunden nicht mehr gemeldet:", @errors))
}
errorWait 7200
icon security
room CUL_HM,Heizung,Rollladen,Weather
stateFormat {if (ReadingsVal('mymonitoring','warningCount','') > 0 and ReadingsVal('mymonitoring','errorCount','') > 0)
{"<i>Warnung</i>:<br><span style='color:#2e5e87'>".(ReadingsVal('mymonitoring','mywarning',''))."</span><br>
<i>Fehler</i>:<br><span style='color:#FF0000'>".(ReadingsVal('mymonitoring','myerror',''))."</span>"}
elsif (ReadingsVal('mymonitoring','warningCount','') > 0)
{"<i>Warnung</i>:<br><span style='color:#2e5e87'>".(ReadingsVal('mymonitoring','mywarning',''))."</span>"}
elsif (ReadingsVal('mymonitoring','errorCount','') > 0)
{"<i>Fehler</i>:<br><span style='color:#FF0000'>".(ReadingsVal('mymonitoring','myerror',''))."</span>"}}
userReadings myerror {my $ret = ReadingsVal("mymonitoring","error",""); $ret =~ s/,/<br>/g; return $ret},
mywarning {my $ret = ReadingsVal("mymonitoring","warning",""); $ret =~ s/,/<br>/g; return $ret}
warningReturn {return unless(@warnings);
$_ = AttrVal($_, "alias", $_) foreach(@warnings);
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 1 Stunde nicht mehr gemeldet.") if(int(@warnings) == 1);
@warnings = sort {lc($a) cmp lc($b)} @warnings;
return(join("\n - ", "Die folgenden ".@warnings." Geräte haben sich seit mehr als 1 Stunde nicht mehr gemeldet:", @warnings))
}
warningWait 3600
Viele Grüße Gisbert
Zitat von: Gisbert am 24 August 2019, 16:41:30
[...]
deren Reading aber eindeutig regelmäßig neu geschrieben werden
[...]
Bitte prüfen ob auch events erzeugt werden.
Zitat von: igami am 29 August 2019, 06:06:39
Bitte prüfen ob auch events erzeugt werden.
Mittlerweile existiert das Problem anscheinend nicht mehr bei mir, nachdem ich die entsprechenden Einträge per remove entfernt habe.
Dies verleitet mich zur Frage, ob nach dem remove diese Devices für immer entfernt sind oder ob sie bei erneutem Eintreten der Bedingungen dann wieder im monitoring device auftauchen.
Viele Grüße Gisbert
@igami
Könntest du vllt auch mir weiterhelfen ? Das Modul scheint zu funktionieren. Es registriert wenn die Tür offen ist und auch wieder wenn sie geschlossen ist. Wie bekomme ich das jetzt in meinen Pagebutton mit eingebaut, das er die Anzahl offener Türen anzeigt und das Icon bei offener Tür sich ändert ?
Ich hänge immer noch bei der Visualisierung fest. Ich bekomme das mit dem Reading einfach nicht hin, das er mir die Anzahl offener in einem roten Kreis über dem Fenster Icon anzeigt. Das Modul selber funktioniert wunderbar.mir fehlt es nur am Verständis, diese Infos nun visuell um zu setzen.
Hallo zusammen,
ich möchte das Modul zur Batterieüberwachung nutzen, da ich mit meiner jetzigen Sofortabfrage im wieder "Frühalarme" vom MAX-System erhalte.
Ich habe das Beispiel zur Batterieüberwachung entsprechend eingebunden. Um das ganze zu Testen habe ich das errorWait auf 6 Sekunden gesetzt. Darauf einen Eintrag mit warningAdd erstellt. Soweit wird der Testeintrag übernommen. Nun erwarte ich, dass es nach 6 Sekunden in die error-Liste kommt. Aber es passiert nichts.
Habe ich bei der Funktion etwas falsch verstanden oder liegt hier irgendwo noch ein Bug drin?
define Batterie_monitoring monitoring .*:battery:.low .*:battery:.ok
setuuid Batterie_monitoring 5d87673e-f33f-3c90-5947-3717cea30e3d1b2e
attr Batterie_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Bei dem Gerät \"$errors[0]\" muss die Batterie gewechselt werden.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten muss die Batterie gewechselt werden:", @errors))\
}
attr Batterie_monitoring errorWait 6
attr Batterie_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Bei dem Gerät \"$warnings[0]\" muss die Batterie demnächst gewechselt werden.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräten muss die Batterie demnächst gewechselt werden:", @warnings))\
}
Kurzes Update: Hatte heute morgen einen richtigen Batteriealarm. Also scheint es zu funktionieren. Die Frage ist nur warum es beim testen mittels warnigadd nicht funktioniert. Kann mich da jemand aufklären?
Ich brauche Hilfe bei der Erstellung des Whitelist-Attributs. Hier im Forum finde ich einmal die Schreibweise mit "i:" vorangesetzt: https://forum.fhem.de/index.php/topic,68765.msg617790.html#msg617790
Und ansonsten ganz normale (scheinbar reguläre) Ausdrücke.
Ich will meine batteriebetriebenen Geräte auf Aktivität überprüfen.
Im DEF habe ich (aus der CommandRef)
.*:.*
Im Whitelist-Attribut:
TYPE=CUL_HM:Activity
TYPE=ZWave:batteryPercent
TYPE=CUL_HM:[Bb]attery
Nur leider habe ich im Log dann folgendes:
global, unknown Event ATTR Activity_monitoring whitelist TYPE=CUL_HM:Activity
TYPE=ZWave:batteryPercent
TYPE=CUL_HM:[Bb]attery
Kann mir jemand einen Tipp geben? Danke.
Wenn jemand eine bessere Idee hat, dann bin ich offen für Anregungen. :-)
Ich will alle physischen Geräte überwachen. Keine DOIFs, Readingsgroups usw.
Zitat von: FunkOdyssey am 22 Oktober 2019, 16:58:42
Hier im Forum finde ich einmal die Schreibweise mit "i:" vorangesetzt
Damit wird nur in INTERNALS gesucht
Zitat von: FunkOdyssey am 22 Oktober 2019, 16:58:42
Nur leider habe ich im Log dann folgendes:
global, unknown Event ATTR Activity_monitoring whitelist TYPE=CUL_HM:Activity
TYPE=ZWave:batteryPercent
TYPE=CUL_HM:[Bb]attery
Wie hast du das Attribut denn eingegeben?
Ist es ein Eintrag aus dem Log oder aus dem Eventmonitor?
Ich habe die ganz normal per Tastatur eingegeben. :-)
Kannst du bitte die RawDefinition (https://wiki.fhem.de/wiki/Import_von_Code_Snippets) von deinem monitoring hier posten? Würde es gerne bei mir testen.
Das hat sich erledigt. Ich habe den Ausdruck falsch verstanden und habe mich an meiner readingsGroups-Syntax orientiert.
So ist es richtig:
i:TYPE=CUL_HM:FILTER=battery=.+
i:TYPE=ZWave:FILTER=batteryPercent=.+
i:TYPE=CUL_HM:FILTER=Activity=.+
Aber: Mein Ansatz könnte unsinnig sein bei den batteriebetriebenen Geräten, die gar nicht zyklisch senden wie z.B. Homematic Wandtaster.
Ich werde muss mir mehr Gedanken darüber machen.
Für Homematic hätte ich ansonsten auch den ActionDetector im Einsatz.
Ich habe gegenwärtig das Fenster-Offen Monitoring wie in den Beispielen im Einsatz. Funktioniert einwandfrei.
Frage: kann ich noch eine weitere Bedingung (Außentemperatur <=5 Grad) mit aufnehmen zu dem die Meldung erst passieren soll?
Wenn ja wie mache ich das?
Zitat von: Nogga am 17 November 2019, 23:12:59
Wenn ja wie mache ich das?
Da musst du dir etwas mit dem Attribut
errorFuncAdd zusammenbauen. Wenn du fertig bist bitte teilen, dann nehme ich das mit in die Beispiele auf :)
Hallo,
ich habe mich mit dem Modul noch nicht richtig beschäftigt, hätte aber einen etwas anderen Anforderungsfall:
Ein Device wechselt manchmal von "connected" auf "disconnected" und das im Sekundentakt.
Leider habe ich noch nicht rausgefunden, warum das passiert.
Im Endeffekt muss ich das Device neu booten, dann funktioniert es wieder für ein paar Tage.
Ist es möglich mit dem Monitoring-Modul zu erkennen, ob innerhalb von x Minuten z.B. 3 Wechsel beim Status "state" von "connected" auf "disconnected" und wieder zurück wechselt?
Wenn, dann soll das Device "disabled" werden und mir mit Telegram eine Nachricht geschickt werden.
Ist es möglich, dass mit dem Modul zu machen?
Danke im Voraus
lg, Gerhard
So pauschal fällt mir keine Lösung mit monitoring dafür ein. Mit dem Modul Sequence lässt sich das jedoch umsetzen.
geht auch mit einem MSwitch - das kann es erkennen , da bekommst du es mit einem Device hin und brauchst nicht nochzusätzlich einen Eventhandler.
gruss Byte09
Hallo zusammen,
ich möchte überwachen ob meine batteriebetriebenen mqtt geräte alle aktiv und erreichbar sind.
Dazu habe ich auf Basis der modulbeispiele ein activity monitoring mit folgender raw Definition eingerichtet
defmod mon_Activity monitoring .*:.*
attr mon_Activity errorReturn {\
return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 6 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten haben sich seit mehr als 6 Stunden nicht mehr gemeldet:", @errors));;\
}
attr mon_Activity errorWait 60*60*6
attr mon_Activity group Monitoring
attr mon_Activity room Conditions
attr mon_Activity whitelist i:TYPE=MQTT2_DEVICE
setstate mon_Activity clear all
setstate mon_Activity 2020-03-23 07:19:50 allCount 4
setstate mon_Activity 2020-03-23 08:01:37 error
setstate mon_Activity 2020-03-23 18:14:44 errorAdd_BU_Fenster 2020-03-24 00:14:44
setstate mon_Activity 2020-03-23 18:19:50 errorAdd_BZ_Climate 2020-03-24 00:19:50
setstate mon_Activity 2020-03-23 18:14:00 errorAdd_BZ_Fenster 2020-03-24 00:14:00
setstate mon_Activity 2020-03-23 18:37:36 errorAdd_EG_GangLicht_Motion 2020-03-24 00:37:36
setstate mon_Activity 2020-03-23 18:36:08 errorAdd_GH_Lichterkette 2020-03-24 00:36:08
setstate mon_Activity 2020-03-23 18:31:53 errorAdd_GaszaehlerKontakt 2020-03-24 00:31:53
setstate mon_Activity 2020-03-23 18:21:41 errorAdd_HZ_Climate 2020-03-24 00:21:41
setstate mon_Activity 2020-03-23 18:35:22 errorAdd_KG_GangLicht_Motion 2020-03-24 00:35:22
setstate mon_Activity 2020-03-23 18:26:03 errorAdd_KL_Climate 2020-03-24 00:26:03
setstate mon_Activity 2020-03-23 18:35:31 errorAdd_KL_Fenster 2020-03-24 00:35:31
setstate mon_Activity 2020-03-23 18:24:18 errorAdd_KZ_Climate 2020-03-24 00:24:18
setstate mon_Activity 2020-03-23 18:19:44 errorAdd_OG_GangLicht 2020-03-24 00:19:44
setstate mon_Activity 2020-03-23 18:19:44 errorAdd_OG_GangLicht_Motion 2020-03-24 00:19:44
setstate mon_Activity 2020-03-23 18:17:29 errorAdd_SZ_Climate 2020-03-24 00:17:29
setstate mon_Activity 2020-03-23 18:11:12 errorAdd_SZ_Fenster 2020-03-24 00:11:12
setstate mon_Activity 2020-03-23 18:20:08 errorAdd_SZ_SchrankLicht 2020-03-24 00:20:08
setstate mon_Activity 2020-03-23 18:20:08 errorAdd_SZ_SchrankLicht_Motion 2020-03-24 00:20:08
setstate mon_Activity 2020-03-23 18:35:15 errorAdd_WK_BodenLicht 2020-03-24 00:35:15
setstate mon_Activity 2020-03-23 18:37:53 errorAdd_WK_Climate 2020-03-24 00:37:53
setstate mon_Activity 2020-03-23 18:28:12 errorAdd_WK_Cube 2020-03-24 00:28:12
setstate mon_Activity 2020-03-23 17:52:28 errorAdd_WK_Fenster 2020-03-23 23:52:28
setstate mon_Activity 2020-03-23 18:21:30 errorAdd_WZ_Climate 2020-03-24 00:21:30
setstate mon_Activity 2020-03-23 08:01:37 errorCount 0
setstate mon_Activity 2020-03-23 08:01:37 state clear all
setstate mon_Activity 2020-03-23 08:01:37 warning
setstate mon_Activity 2020-03-23 08:01:37 warningCount 0
Das Problem ist das auch Geräte überwacht werden die nicht dem type, wie in dem whilelist Attribute definiert, entsprechen.
Nämlich shelly devices. Ich habe dann versucht explizit über die Blacklist nochmal die shelly raus zu bekommen, aber das zeigt auch keine Wirkung.
Hier das shelly define als Beispiel
defmod SZ_SchrankLicht Shelly 192.168.188.102
attr SZ_SchrankLicht userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr SZ_SchrankLicht group Beleuchtung
attr SZ_SchrankLicht icon scene_dressing_room
attr SZ_SchrankLicht model shelly1
attr SZ_SchrankLicht room Schlafzimmer
setstate SZ_SchrankLicht off
setstate SZ_SchrankLicht 2019-01-15 18:59:55 cloud disabled
setstate SZ_SchrankLicht 2020-03-21 11:04:28 firmware v1.6.1(update needed to v1.6.2)
setstate SZ_SchrankLicht 2020-03-22 22:12:32 network <html>connected to <a href="http://192.168.188.102">192.168.188.102</a></html>
setstate SZ_SchrankLicht 2020-03-23 18:20:08 relay off
setstate SZ_SchrankLicht 2020-03-23 18:20:08 state off
Weiß wer was ich falsch gemacht habe?
Hallo igami,
kurze Anmerkung zum Reading "allCount": Kann es sein, dass dieses bei einem "set clear " nicht aktualisiert wird. "set clear all" funktioniert, "errorCount" und "warningCount" werden entsprechend auf "0" gesetzt, "allCount" bleibt auf dem alten Wert. Erst wenn wieder eines der Readings "errorCount" oder "warningCount" sich ändert, wird auch "allCount" wieder korrekt gesetzt.
Nicht tragisch, und leider zu wenig in Perl bewandert, um eine Lösung vorzuschlagen. Vielleicht aber beim nächsten Update einen Blick wert.
Ansonsten: Super Modul, habe es für verschiedene Aufgaben schätzen gelernt.
Gruß Thorsten
Hallo zusammen,
beschäftige mich auch gerade mal wieder mit dem Montoring der Batterien meiner Ventile (z-wave). Die liefern leider sehr spät erst ein "low". Es gibt noch die beiden Werte "battery" z.B. 10 % und batteryPercent z.B. 10.
Wie müsste ich denn die Definition machen, dass bei 10 (10 %) Warning und bei 5 (5 %) Error ausgelöst wird? Geht das überhaupt?
Beste Grüße
Torsten
Zitat von: ToKa am 26 März 2020, 19:31:29
Hallo zusammen,
beschäftige mich auch gerade mal wieder mit dem Montoring der Batterien meiner Ventile (z-wave). Die liefern leider sehr spät erst ein "low". Es gibt noch die beiden Werte "battery" z.B. 10 % und batteryPercent z.B. 10.
Wie müsste ich denn die Definition machen, dass bei 10 (10 %) Warning und bei 5 (5 %) Error ausgelöst wird? Geht das überhaupt?
Beste Grüße
Torsten
Ich habe es wie folgt gelöst
defmod mon_BatterieLow monitoring .*:battery:.*
attr mon_BatterieLow errorFuncAdd {\
return 1 if(ReadingsVal($name, "battery", "high") eq "low" || ReadingsNum($name, "battery", 100) <= 20);;\
return;;\
}
attr mon_BatterieLow errorFuncRemove {\
return 1 if(ReadingsVal($name, "battery", "high") ne "low" && ReadingsNum($name, "battery", 100) > 20);;\
return;;\
}
attr mon_BatterieLow errorReturn {\
return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Bei dem Gerät \"$errors[0]\" muss die Batterie gewechselt werden.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten muss die Batterie gewechselt werden:", @errors));;\
}
attr mon_BatterieLow errorWait 60*60*6
Hallo igami,
ich habe noch eine weitere Frage zu monitoring:
Ich versuche, mittels "whitelist model=HM-CC-RT-DN:FILTER=lastMsg=..*" alle HM-Ventiltriebe zu überwachen. Ein "list model=HM-CC-RT-DN:FILTER=lastMsg=..*" liefert auch genau die Geräte zurück, die ich suche:
HZ.Bad.Heizungsthermostat
HZ.K.Heizungsthermostat
HZ.KiJM.Heizungsthermostat
HZ.KiL.Heizungsthermostat
HZ.KiS.Heizungsthermostat
HZ.SZ.Heizungsthermostat
In den "waringAdd/errorAdd"-Readings tauchen auch nur genau diese Geräte auf. Allerdings hat mein Monitoring 29 Fehler:
ActionDetector,HMLAN1,HZ.WZ.Ventiltrieb1,HZ.WZ.Ventiltrieb2,HZ.WZ.Wandthermostat,HZ.WZ.Wandthermostat_Weather,L.KiL.LED_Bett_Device,S.Bad.Fenster,S.K.Fenster_rechts,S.KiJM.Fenster_rechts,S.KiL.Fenster_rechts,S.KiS.Fenster_rechts,S.SZ.Fenster_links,S_virt.Bad,S_virt.Bad.Temp,S_virt.K,S_virt.K.Temp,S_virt.KiJM,S_virt.KiJM.Temp,S_virt.KiL,S_virt.KiL.Temp,S_virt.KiS,S_virt.KiS.Temp,S_virt.SZ,S_virt.SZ.Temp,dblog,dblog_hz,gassistant,vccu
Was mache ich falsch?
Das komplette list des monitoring:
Internals:
DEF .*
FUUID 5e6defca-f33f-4189-e987-f6c538a3144e3e01
NAME monitoring.ActivityHM
NR 301
NTFY_ORDER 50-monitoring.ActivityHM
STATE 0 warnings - 29 errors
TYPE monitoring
Helper:
DBLOG:
allCount:
dblog:
TIME 1586438332.65689
VALUE 29
error:
dblog:
TIME 1586438332.65689
VALUE ActionDetector,HMLAN1,HZ.WZ.Ventiltrieb1,HZ.WZ.Ventiltrieb2,HZ.WZ.Wandthermostat,HZ.WZ.Wandthermostat_Weather,L.KiL.LED_Bett_Device,S.Bad.Fenster,S.K.Fenster_rechts,S.KiJM.Fenster_rechts,S.KiL.Fenster_rechts,S.KiS.Fenster_rechts,S.SZ.Fenster_links,S_virt.Bad,S_virt.Bad.Temp,S_virt.K,S_virt.K.Temp,S_virt.KiJM,S_virt.KiJM.Temp,S_virt.KiL,S_virt.KiL.Temp,S_virt.KiS,S_virt.KiS.Temp,S_virt.SZ,S_virt.SZ.Temp,dblog,dblog_hz,gassistant,vccu
errorCount:
dblog:
TIME 1586438332.65689
VALUE 29
state:
dblog:
TIME 1586438332.65689
VALUE error add
warning:
dblog:
TIME 1586438332.63563
VALUE
warningCount:
dblog:
TIME 1586438332.63563
VALUE 0
READINGS:
2020-04-09 15:18:52 allCount 29
2020-04-09 15:18:52 error ActionDetector,HMLAN1,HZ.WZ.Ventiltrieb1,HZ.WZ.Ventiltrieb2,HZ.WZ.Wandthermostat,HZ.WZ.Wandthermostat_Weather,L.KiL.LED_Bett_Device,S.Bad.Fenster,S.K.Fenster_rechts,S.KiJM.Fenster_rechts,S.KiL.Fenster_rechts,S.KiS.Fenster_rechts,S.SZ.Fenster_links,S_virt.Bad,S_virt.Bad.Temp,S_virt.K,S_virt.K.Temp,S_virt.KiJM,S_virt.KiJM.Temp,S_virt.KiL,S_virt.KiL.Temp,S_virt.KiS,S_virt.KiS.Temp,S_virt.SZ,S_virt.SZ.Temp,dblog,dblog_hz,gassistant,vccu
2020-04-10 16:12:52 errorAdd_HZ.Bad.Heizungsthermostat 2020-04-10 18:12:52
2020-04-10 16:11:40 errorAdd_HZ.K.Heizungsthermostat 2020-04-10 18:11:40
2020-04-10 16:11:25 errorAdd_HZ.KiJM.Heizungsthermostat 2020-04-10 18:11:25
2020-04-10 16:11:08 errorAdd_HZ.KiL.Heizungsthermostat 2020-04-10 18:11:08
2020-04-10 16:11:55 errorAdd_HZ.KiS.Heizungsthermostat 2020-04-10 18:11:55
2020-04-10 16:12:02 errorAdd_HZ.SZ.Heizungsthermostat 2020-04-10 18:12:02
2020-04-09 15:18:52 errorCount 29
2020-04-09 15:18:52 state error add: HZ.WZ.Wandthermostat_Weather
2020-04-09 15:18:52 warning
2020-04-10 16:12:52 warningAdd_HZ.Bad.Heizungsthermostat 2020-04-10 17:12:52
2020-04-10 16:11:40 warningAdd_HZ.K.Heizungsthermostat 2020-04-10 17:11:40
2020-04-10 16:11:25 warningAdd_HZ.KiJM.Heizungsthermostat 2020-04-10 17:11:25
2020-04-10 16:11:08 warningAdd_HZ.KiL.Heizungsthermostat 2020-04-10 17:11:08
2020-04-10 16:11:55 warningAdd_HZ.KiS.Heizungsthermostat 2020-04-10 17:11:55
2020-04-10 16:12:02 warningAdd_HZ.SZ.Heizungsthermostat 2020-04-10 17:12:02
2020-04-09 15:18:52 warningCount 0
Attributes:
errorReturn {return unless(@errors);
$_ = AttrVal($_, "alias", $_) foreach(@errors);
return("Das folgende Gerät hat sich seit längerem nicht mehr gemeldet (Error):\\n - $errors[0]") if(int(@errors) == 1);
@errors = sort {lc($a) cmp lc($b)} @errors;
return(join("\\n - ", "Die folgenden ".@errors." Geräten haben sich seit längerem nicht mehr gemeldet (Error):", @errors));
}
errorWait 2*60*60
room System->Monitoring
stateFormat warningCount warnings - errorCount errors
warningReturn {return unless(@warnings);;
$_ = AttrVal($_, "alias", $_) foreach(@warnings);
return("Das folgende Gerät ist derzeit on hold (Warnung):\\n - $warnings[0]") if(int(@warnings) == 1);
@warnings = sort {lc($a) cmp lc($b)} @warnings;
return(join("\\n - ", "Die folgenden ".@warnings." Geräte sind derzeit on Hold (Warnung):", @warnings));
}
warningWait 1*60*60
whitelist model=HM-CC-RT-DN:FILTER=lastMsg=..*
Gruß Thorsten
Hi
whitelist {<perl code>}
Durch Leerzeichen getrennte Liste von devspecs die erlaubt sind werden.
Wenn das Attribut gesetzt wird werden alle Geräte die nicht durch die devspecs definiert sind von beiden Listen gelöscht.
Meine whitelist beinhaltet
gassistant speedtest sysmon sysmon_dockerup twilight
Obwohl global nicht enthalten ist, erhalte ich Warnungen, und Error.
state
warning add: global
2020-05-12 01:34:29
Ich beobachte das schon eine Weile. Um irgend welche Timer im Hintergrund auszuschließen haben ich das Device auch schon gelöscht und per RAW-Import wieder angelegt. List s. u.
Irgend eine Idee? Danke!
Internals:
CFGFN
DEF .*:.*
FUUID 5eb93844-f33f-eb0d-4a59-3cb0d92efc59c707
NAME mn_ActivityMonitoring24h
NR 454819
NTFY_ORDER 50-mn_ActivityMonitoring24h
STATE Warning: global
Error:
TYPE monitoring
READINGS:
2020-05-12 01:34:29 allCount 1
2020-05-11 13:34:29 errorAdd_global 2020-05-12 13:34:29
2020-05-12 11:55:25 errorAdd_speedtest 2020-05-13 11:55:25
2020-05-12 11:38:45 errorAdd_twilight 2020-05-13 11:38:45
2020-05-12 01:34:29 state warning add: global
2020-05-12 01:34:29 warning global
2020-05-12 11:55:25 warningAdd_speedtest 2020-05-12 23:55:25
2020-05-12 11:38:45 warningAdd_twilight 2020-05-12 23:38:45
2020-05-12 01:34:29 warningCount 1
Attributes:
DbLogExclude .*
DbLogInclude none
alias mn_ActivityMonitoring24h
errorWait 60*60*24
event-on-change-reading state
group Monitoring
room Server
stateFormat {"Warning: " . ReadingsVal($name,"warning","") . "\nError: " . ReadingsVal($name,"error","") }
warningWait 60*60*12
whitelist gassistant speedtest sysmon sysmon_dockerup twilight
Zitat von: kadettilac89 am 12 Mai 2020, 12:08:25
Irgend eine Idee? Danke!
Auf die Schnelle nicht. Das Modul soll demnächst auch noch ein refactoring bekommen, da es aus meiner Anfangszeit stammt als ich noch weniger Ahnung hatte.
Nur momentan kann ich mir leider nicht die Zeit dafür nehmen.
Zitat von: igami am 12 Mai 2020, 16:12:31
Auf die Schnelle nicht. Das Modul soll demnächst auch noch ein refactoring bekommen, da es aus meiner Anfangszeit stammt als ich noch weniger Ahnung hatte.
Nur momentan kann ich mir leider nicht die Zeit dafür nehmen.
OK, trotzdem danke ... es gibt ein paar warning/error-remove functions ... muss mir die mal ansehen, damit kicke ich dann global raus und schau mal welche noch daher kommen ...
Ich habe die Vermutung, dass es daran liegt, dass global ein sehr spezielles device ist. In der Raw definition davon steht zum Beispiel kein "define/defmod".
Teste bitte ob es hilft global im blacklist-Attribut einzutragen.
Zitat von: igami am 13 Mai 2020, 06:18:58
Ich habe die Vermutung, dass es daran liegt, dass global ein sehr spezielles device ist. In der Raw definition davon steht zum Beispiel kein "define/defmod".
Teste bitte ob es hilft global im blacklist-Attribut einzutragen.
Ich habe es mal gesetzt, bis jetzt ist global noch nicht aufgenommen. Sieht bis jetzt gut aus. Danke
Ich habe einen kleinen Fehler in der commandref gefunden.
<code>
define <name> mointoring <add-event> [<remove-event>]
</code>
Zeilen 1117-1119
Das soll bestimmt "monitoring" heißen und nicht "mointoring" :P
Zitat von: Altrec am 09 Juni 2020, 15:53:16
Ich habe einen kleinen Fehler in der commandref gefunden.
Danke, habs korrigiert.
Super! :)
Hallo zusammen,
habe auch mal eine Frage: Ich möchte mit dem Monitoring-Modul gerne sowohl eine Aktivitäts-Überwachung als auch eine Batterie-Überwachung machen. Beide Fälle sind MQTT-Geräte, allerdings habe ich nicht für jedes Gerät ein eigenes Device.
Konkret:
Im Fall der Aktivitätsüberwachung soll nur das Gerät standorte, hierunter aber die beiden Readings helligkeit und helligkeitssensor unabhängig überwacht werden.
Ähnlich bei der Batterieüberwachung: Hier gibt es nur das Gerät interfhem und Readings für die verschiedenen Batteriestände als Zahl.
Die Beispiele beziehen sich ja alle auf unterschiedliche Devices.
Was wäre denn hier das optimale Vorgehen? Oder kann ich das so nicht mit dem monitoring Modul umsetzen?
Gruß Rainer
Hallo Rainer,
ich nutze das Modul monitoring in der Weise, dass ich bei den zu überwachenden Devices ein userReadings "Zeitstempel" definiert habe, welches sich entsprechend aktualisiert, solange das Device lebt.
Meine Definition für das monitoring-Device lautet deshalb:
defmod mymonitoring monitoring .*:Zeitstempel.*Die commabdref sagt:
ZitatDefine
define <name> monitoring <add-event> [<remove-event>]
The syntax for <add-event> and <remove-event> is the same as the pattern for notify (device-name or device-name:event).
Demzufolge müsste dann auch eine Suche nach mehreren Suchmustern funktionieren:
.*:(Suchmuster1|Suchmuster2|...)
Wie oben beschrieben, habe ich das für mich anders gelöst.
Viele Grüße und viel Erfolg
Gisbert
Zitat von: dora71 am 20 August 2020, 18:08:44
Die Beispiele beziehen sich ja alle auf unterschiedliche Devices.
Du kannst dich an dem Beispiel "regelmäßige Wartungsarbeiten (z.B. Räume putzen)" in der commandref orientieren. Da wird auch die variable $name geändert weil es nur ein device in FHEM gibt aber mehrere Einträge im monitoring erscheinen sollen.
Zum besseren Verständnis bitte ein list von deinem device posten.
Hallo igami, danke für die schnelle Rückmeldung.
Hier die (relevanten Teile) von list:
1. Für die Aktivitätsüberwachung:
Internals:
FUUID 5ec55aa2-f33f-1942-a276-xxxxxxxxxxx
IODev myBroker
NAME standorte
NR 804
STATE 1255 lx, 1024 LDR
TYPE MQTT_DEVICE
READINGS:
2020-08-21 10:27:26 helligkeit 1024
2020-08-21 10:27:26 helligkeitssensor 1255
2. Für die Batterieüberwachung:
Internals:
FUUID 5f119eba-f33f-1942-6a01-xxxxxxxxxxxxxxx
IODev myBroker
NAME interfhem
NR 826
STATE ???
TYPE MQTT_DEVICE
OLDREADINGS:
READINGS:
2020-08-20 22:10:04 samsungtvstate absent
2020-08-20 13:15:28 shellyw1 {"event":"SS","event_cnt":1}
2020-08-20 13:15:29 shellyw1_event SS
2020-08-20 13:15:29 shellyw1_event_cnt 1
2020-08-20 13:15:28 shellyw1batterie 53
2020-08-20 20:33:26 shellyw5wz {"event":"L","event_cnt":1}
2020-08-20 20:33:26 shellyw5wz_event L
2020-08-20 20:33:26 shellyw5wz_event_cnt 1
2020-08-20 20:33:26 shellyw5wzbatterie 66
2020-08-19 11:37:33 sonospresence disappeared
2020-08-20 22:10:04 transmission-state incoming publish received
Alle weiteren Readings / Sets beziehen sich auf MQTT und sollten für diese Funktion hier nicht relevant sein.
Nach Deinem Vorschlag mit der commandref sieht meine Definition für den Aktivitätsmonitor jetzt wie folgt aus:
defmod Activity_monitoring_Luxsensor monitoring standorte:helligkeit.*:.*
attr Activity_monitoring_Luxsensor errorFuncAdd {$event =~ m/^(.+):/;;\
$name = $1;;\
return 1;;\
}
attr Activity_monitoring_Luxsensor errorReturn {return unless(@errors);;\
return("Der Sensor \"$errors[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
return(join("\n - ", "Die folgenden Sensoren haben sich seit mehr als 12 Stunden nicht mehr gemeldet:", @errors))\
}
attr Activity_monitoring_Luxsensor errorWait 60*60*12
attr Activity_monitoring_Luxsensor room Internals
attr Activity_monitoring_Luxsensor warningFuncAdd {$event =~ m/^(.+):/;;\
$name = $1;;\
return 1;;\
}
attr Activity_monitoring_Luxsensor warningReturn {return unless(@warnings);;\
return("Der Sensor \"$warnings[0]\" hat sich seit mehr als 1 Stunde nicht mehr gemeldet.") if(int(@warnings) == 1);;\
return(join("\n - ", "Die folgenden Sensoren haben sich seit mehr als 1 Stunde nicht mehr gemeldet", @warnings))\
}
attr Activity_monitoring_Luxsensor warningWait 60*60
Würde das so passen?
An der Batteriewarnung arbeite ich noch :-[
Gruß Rainer
Zitat von: dora71 am 21 August 2020, 10:49:41
Nach Deinem Vorschlag mit der commandref sieht meine Definition für den Aktivitätsmonitor jetzt wie folgt aus:
[...]
Würde das so passen?
Sollte passen.
errorFuncAdd und warningFuncAdd brauchst du nicht, da es hier nur ein physikalischen Gerät im FHEM device gibt.
Hallo igami,
du hattest folgendes Thema erst mal als erledigt abgehakt. Ich hab das Modul gestern bei mir eingerichtet und hab das Problem jetzt leider auch. Da ich sehr viele Geräte habe wäre die Suche nach dem fast gleichen Namen etwas schwierig. Evnt. kannst du ja noch mal schauen, warum bei $Name nicht auf 100% geprüft wird sondern nur ob DeviceName in Name enthalten ist (so hab ich es von meier81 jedenfalls verstanden).
Evnt. kann man damit auch einen Bug für zukünftige Modul-Nutzer lösen:-)
Zitat von: meier81 am 15 Juni 2019, 07:46:03
Moin moin,
ich wollte nur Bescheid geben das ich mein Problem
2019.06.06 03:52:46 2: monitoring (DeviceMonitor) set "errorWait" while "errorFuncAdd" and "errorFuncRemove" are same
lösen konnte, ich hatte als Raumfühler den ich mit monitoring überwache "Fuehler_Elias" als Definition gehabt und beim ROOMMATE hatte ich die Definition einfach nur "Elias" genannt. Anscheinend ist dem Attribut im monitoring-Device
errorWait AttrVal($name, "device_timeout", 0)
der Anfang des Device-Namens egal und er bringt deswegen die Meldung. Ist aber kein Problem, habe das ROOMMATE-Device umbenannt in "rr_Elias", jetzt läuft´s prima.
Gruß
Markus
Hallo habe eine Frage zu der Whitelist, wie gebe ich das ein?
ich möchte ein paar Netzwerkgeräte auf aktivität überwachen
attr Activity_monitoring whitelist securityHaustuer:status\
ECL310:Warmwasser
so ist das whitelist definiert habe es auch schon getestet mit Leerzeichen statt dem zeilenumbruch usw.
Irgendwie übernimmt er immer nur den ersten der in der Whitelist steht.
Es sind beides "normale" READINGS also keine internals
das ganze RAW sieht so aus
defmod Activity_monitoring monitoring .*:.*
attr Activity_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))\
}
attr Activity_monitoring errorWait 60*5
attr Activity_monitoring room Status
attr Activity_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräten haben sich seit mehr als 12 Stunden nicht mehr gemeldet", @warnings))\
}
attr Activity_monitoring warningWait 60
attr Activity_monitoring whitelist comfoconnect:Abluftventilatorvolumen\
ECL310:Warmwasser\
securityHaustuer:status
setstate Activity_monitoring warning add: securityHaustuer
setstate Activity_monitoring 2020-09-18 09:56:53 allCount 1
setstate Activity_monitoring 2020-09-18 09:59:44 errorAdd_ECL310 2020-09-18 10:04:44
setstate Activity_monitoring 2020-09-18 09:55:53 errorAdd_securityHaustuer 2020-09-18 10:00:53
setstate Activity_monitoring 2020-09-18 09:56:53 state warning add: securityHaustuer
setstate Activity_monitoring 2020-09-18 09:56:53 warning securityHaustuer
setstate Activity_monitoring 2020-09-18 09:59:44 warningAdd_ECL310 2020-09-18 10:00:44
setstate Activity_monitoring 2020-09-18 09:56:53 warningCount 1
hat wer eine tipp wie man das korrekt eingibt?
Hmmm irgendwie ist es komisch nach einen Neustart hat es funktioniert, es wurden alle 3 Devices ständig aktualisiert.
Dann habe ich ein weiteres Device in die whitelist gegeben, und nun funktioniert immer nur das erste Device in der whitelist.
Stellte ich die whitelist um das das letzte Device nun vorne steht, dann geht nur dieses.
niemand eine idee?
Kennt jemand ein anderes Modul das ich testen kann?
Hätte es nun mal auch so getestet:
KEin Eintrag in der Whitelist dafür im Def
Zitatdefmod Activity_monitoring monitoring (can_EG_1:alive.*|comfoconnect:Abluftventilatorvolumen.*|securityHaustuer:status.*|ECL310:Warmwasser.*)
wenn ich das gleiche Def bei einem notify verwende dann geht das ohne Probleme.
Zitatdefmod n_test notify (can_EG_1:alive.*|comfoconnect:Abluftventilatorvolumen.*|securityHaustuer:status.*|ECL310:Warmwasser.*) {Log 1, "Das Device $NAME hat ausgeloest, der Event sah so aus: $EVENT"}
[edit]Also es ist definitiv so, gerade 3 mal getestet.
Nach einem neustart von FHEM funktioniert die Whitelist, so wie sie soll.
Gehe ich nun auf die Whitelist und übernehme genau das gleiche also keine Änderung, dann funktioniert nur mehr der erste Eintrag in der whitelist.
keiner eine idee?
Hat das Modul irgendwer produktiv in Verwendung?
Zitat von: sn0000py am 23 September 2020, 15:49:25
keiner eine idee?
Hat das Modul irgendwer produktiv in Verwendung?
Ich benutze das Modul erfolgreich seit längerem. Ich kann leider nichts zu deiner Konfiguration sagen, aber ich hänge gerne meine Definition an, vielleicht kannst du etwas davon gebrauchen.
defmod mymonitoring monitoring .*:Zeitstempel.*
attr mymonitoring alias monitor
attr mymonitoring blacklist Wassermelder Radiation Lufdaten
attr mymonitoring comment Zeilenumbruch statt Komma-separierte Liste (userReadings):\
https://forum.fhem.de/index.php/topic,68765.msg964742.html#msg964742\
Durch Suchen mit den Stichworten "split fhem" bin ich auf diesen Beitrag von dir gestoßen, der mich zur Lösung geführt hat:\
https://forum.fhem.de/index.php/topic,58059.msg494877.html#msg494877\
{my $ret = AttrVal(...);; $ret =~ s/<suchen>/<ersetzen>/g;; return $ret}\
Im stateFormat werden Begriffe in "" mit einem Punkt (.) mit Perlausdrücken verknüpft.
attr mymonitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 2 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräte haben sich seit mehr als 2 Stunden nicht mehr gemeldet:", @errors))\
}
attr mymonitoring errorWait 7200
attr mymonitoring icon security
attr mymonitoring room CUL_HM,Heizung,Rollladen,Weather
attr mymonitoring stateFormat {if (ReadingsVal($name,'warningCount','') > 0 and ReadingsVal($name,'errorCount','') > 0)\
{"<i>Warnung</i>:<br><span style='color:#2e5e87'>".(ReadingsVal($name,'mywarning',''))."</span><br>\
<i>Fehler</i>:<br><span style='color:#FF0000'>".(ReadingsVal($name,'myerror',''))."</span>"} \
elsif (ReadingsVal($name,'warningCount','') > 0)\
{"<i>Warnung</i>:<br><span style='color:#2e5e87'>".(ReadingsVal($name,'mywarning',''))."</span>"} \
elsif (ReadingsVal($name,'errorCount','') > 0)\
{"<i>Fehler</i>:<br><span style='color:#FF0000'>".(ReadingsVal($name,'myerror',''))."</span>"}}
attr mymonitoring userReadings myerror {my $ret = ReadingsVal($name,'error','');; $ret =~ s/,/<br>/g;; return $ret}, \
mywarning {my $ret = ReadingsVal($name,'warning','');; $ret =~ s/,/<br>/g;; return $ret}
attr mymonitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 1 Stunde nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräte haben sich seit mehr als 1 Stunde nicht mehr gemeldet:", @warnings))\
}
attr mymonitoring warningWait 3600Viele Grüße Gisbert
Zitatdefmod Activity_monitoring monitoring *.:*.
Ich kann mich irren aber müsste es nicht .*:.* heißen?
Des weiteren steht in der CommandRef:
Zitatwhitelist {<perl code>}
Durch Leerzeichen getrennte Liste von devspecs die erlaubt sind werden.
Wenn das Attribut gesetzt wird werden alle Geräte die nicht durch die devspecs definiert sind von beiden Listen gelöscht.
Also Leerzeichengetrennt; keine Zeilenumbrüche.
Vielleicht auch mal mit reinen Devspecs ohne Readings probieren.
Gruß
Wolle
ok danke mal für die Rückmeldungen
das mit dem *.:*. war ein Tippfehler, der nur kurz drinnen war richtig ist natürlich .*:.*
das ganz komische ist das er immer nur den ersten Eintrag in der Whitelist verwendet und da ist es egal ob ich mit Leerzeichen oder mit Zeilenumbrüchen eingebe.
Nach einem Neustart vom FHEM funktioniert es immer kurz, bis ich dann wieder mal was ändere, dann geht nur mehr der erste
Also ich verwende nur blacklist. Sieht bei mir so aus:
.*_RK R_.* global Rollladen_alle Alarm_.* Eingang_.*
Damit funktioniert es bei mir dauerhaft tadellos.
Vielleicht irgendein Bug im Attribut whitelist?
ja vermute ich auch, hab mir den code angeschaut, nur leider sehe ich nur Bahnhof :O
Also ich habe in meinem Testsystem mal folgendes konfiguriert:
defmod Activity_monitoring monitoring .*:.*
attr Activity_monitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 24 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräten haben sich seit mehr als 24 Stunden nicht mehr gemeldet:", @errors))\
}
attr Activity_monitoring errorWait 60*60*24
attr Activity_monitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 12 Stunden nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräten haben sich seit mehr als 12 Stunden nicht mehr gemeldet:", @warnings))\
}
attr Activity_monitoring warningWait 60*60*0.1
attr Activity_monitoring whitelist HMIPW_Fenstereingang_Modul:state HMIPW_Rollladenaktor_3_Modul:state HMIPW_Schaltaktor_Modul:state F_UG_Gaestezimmer:state
setstate Activity_monitoring warning add: HMIPW_Rollladenaktor_3_Modul
setstate Activity_monitoring 2020-09-24 15:53:07 allCount 2
setstate Activity_monitoring 2020-09-24 15:32:02 error
setstate Activity_monitoring 2020-09-24 15:46:45 errorAdd_F_UG_Gaestezimmer 2020-09-25 15:46:45
setstate Activity_monitoring 2020-09-24 15:50:46 errorAdd_HMIPW_Fenstereingang_Modul 2020-09-25 15:50:46
setstate Activity_monitoring 2020-09-24 15:47:07 errorAdd_HMIPW_Rollladenaktor_3_Modul 2020-09-25 15:47:07
setstate Activity_monitoring 2020-09-24 15:32:02 errorCount 0
setstate Activity_monitoring 2020-09-24 15:53:07 state warning add: HMIPW_Rollladenaktor_3_Modul
setstate Activity_monitoring 2020-09-24 15:53:07 warning F_UG_Gaestezimmer,HMIPW_Rollladenaktor_3_Modul
setstate Activity_monitoring 2020-09-24 15:50:46 warningAdd_HMIPW_Fenstereingang_Modul 2020-09-24 15:56:46
setstate Activity_monitoring 2020-09-24 15:53:07 warningCount 2Funktioniert einwandfrei. Auch mit whitelist läuft alles wie es soll.
Hast du folgenden Passus aus der CommandRef berücksichtigt?
ZitatGeräte werden erst überwacht, wenn sie mindestens ein Event ausgelöst haben.
Ich habe in diesem Test bei den überwachten Geräten manuell ein Update ausgelöst so dass sie Events generiert haben und dann hat es 6 Minuten gedauert bis sie auf die Warning-Liste gesetzt wurden. Ein Device hat trotz manuellem Update keine Events produziert und dieses Device ist auch nicht auf die Warnin-Liste gestzt worden, weil das Monitoring-Modul dieses Device deshalb gar nicht überwacht.
Ja die Devices die ich hier habe, die senden alle 10 sekunden bis maximal 60 sekunden ein Alive Ping.
Und bei mir funktioniert immer der erste in der Whitelist also den ich vorne stehen habe, der wird aus der error und warning liste gelöscht die anderen 3 kommen in die warning/Error liste rein.
Stelle ich die whitelist wieder um dann wechselt das.
Starte ich FHEM neu, dann kommen alle 4 aus der Liste raus, bis ich wieder was ändere, dann falle alle bis auf den ersten wieder in die warning liste rein.
Aber in deinem Fall ist ja komischer weise auch nur der erste aktiv die anderen 2 sind schon in der warning Liste - zufall oder gleiches Verhalten wie bei mir?
Zitat von: sn0000py am 24 September 2020, 16:04:57
Aber in deinem Fall ist ja komischer weise auch nur der erste aktiv die anderen 2 sind schon in der warning Liste - zufall oder gleiches Verhalten wie bei mir?
Ich versteh dich grade nicht so wirklich.
In der Whitelist sind diese Devices:
- HMIPW_Fenstereingang_Modul
- HMIPW_Rollladenaktor_3_Modul
- HMIPW_Schaltaktor_Modul
- F_UG_Gaestezimmer
F_UG_Gaestezimmer HMIPW_Rollladenaktor_3_Modul haben ein Event gesendet und werden deshalb überwacht. Da sie danach 6 Minuten kein Event mehr gesendet haben landen sie auf der Warning-Liste
HMIPW_Fenstereingang_Modul hat ein Event gesendet und wird deshalb überwacht. Da es aber innerhalb der 6 Minuten ein weiteres Event gesendet hat landet es nicht auf der Warning-Liste.
HMIPW_Schaltaktor_Modul hat bislang überhaupt kein Event gesendet (auch das initiale nicht) und wird deshalb vom Modul überhaupt nicht überwacht.
Okay bei mir senden alle 4 devices events, aber nur das erste wird aktualisiert, deswegen sieht es bei mir gleich aus wie bei dir (nur das eben die anderen 3 devices Events generieren aber ignoriert werden)
Hallo,
Ich frage das reading "error" in einem DOIF ab zwecks email benachrichtigung.
Das funktioniert wunderbar, nur nach Stromausfall sind anscheinend alle überwachten Geräte im error-reading vorhanden. ich bekommen dann zig mails....
Weiss jemand warum dad so ist
Lg Gerald
Ich beschäftige mich mit dem Modul weil ich eine regelmäßige Erinnerung fürs Blumen gießen erstellen möchte, die ich dann per PushMSG auf meine Handys verteilen lassen will. Dazu habe ich mir das Beispiel "regelmäßige Wartungsarbeiten (z.B. Tischwasserfilter wechseln)" angeschaut.
Nun will ich keine extra Hardware nutzen und würde daher lieber in meinem FTUI einen Button einbauten, der das gießen als erledigt markiert.
Soweit ich das verstehe, müsste ich dann einen Dummy erstellen, dessen state über diesen Button gesetzt wird. Richtig?
Oder hat jemand eine bessere Idee wie es ohne Dummy geht?
Moin zusammen,
Ich verzweile gerade an dem DoIf :-(
Ich habe mich an diesem hier Orientiert:
Zitat von: igami am 11 März 2017, 08:18:33
Ich habe ein DOIF das inetwa so aussieht:
defmod ServiceNotifications_DI DOIF ([16:30-21:00|8]\
&& ( [":^error add:"]\
|| [$SELF:cmd_nr] == 2\
)\
)(\
set TelegramBot message {(fhem("get TYPE=monitoring default"))}\
)\
DOELSEIF\
([":^error add:"])
attr ServiceNotifications_DI cmdState send notifications|notifications pending
attr ServiceNotifications_DI cmdpause 60*15
attr ServiceNotifications_DI do always
attr ServiceNotifications_DI icon time_automatic
attr ServiceNotifications_DI wait 60*15
Trifft ein "error add:" event ein wird 15 Minuten gewartet, dann bekomme ich eine Nachricht mit allen Sammelmeldungen. Passiert das außerhalb des Zeitraums wird es in die Warteschlange gepackt.
Leider bekomme Ich keine Meldung. Ich habe es mal von Error add auf Warning add geänder, aber leider auch keine Meldung. Hat jemand evtl. die Muse um mir zu helfen. Ich finde so ein Monitoring super Klasse, da Ich leider schon mehr als 1 x die Batterien vom Heizkörper leer hatte und Ich ein glühendes Zimmer vorfand, da die Thermostate sich immer nur ausschalten wenn das Ventil gerade voll geöffnet ist
VG
Ralf
Hallo!
Ich habe versucht das Attribut "blacklist" im monitoring Modul zu nutzen und stolpere darüber, dass die Devspecs zu viel ausfiltern. Das ganze lässt sich leicht reproduzieren.
Gebe ich z.B. "x_test_dummy_x" in der Blacklist an, dann werden auch Events des Device "test_dummy" ausgefiltert. Das ist doch vermutlich ein Bug und nicht so gedacht oder?
Gruß
Michael
Zitat von: mdescher am 29 November 2022, 15:02:07
Gebe ich z.B. "x_test_dummy_x" in der Blacklist an, dann werden auch Events des Device "test_dummy" ausgefiltert. Das ist doch vermutlich ein Bug und nicht so gedacht oder?
Neuer support-Thread für das Modul wäre hier zu finden (siehe MAINTAINER.txt): https://forum.fhem.de/index.php/topic,126515.0.html.
Soweit erkennbar, war das schon immer so, ich würde es aber auch als bug ansehen...
Kannst du zum Testen bitte mal #325 so ändern:
return if @blacklist && grep { m{\A${name}\z}x } @blacklist;(in #332 gibt es dann zumindest auf den ersten Blick nochmal was vergleichbares).
Feedback bitte möglichst im neuen Thread.
Guten Abend zusammen,
funktioniert das Monitoring-Modul auch dann, wenn ein Device den Wert 0 erhält?
Ich möchte mit dem monitoring-Modul zählen,
- wie viele Rollläden offen (state 100) sind
- und mit einem zweiten Modul zählen, wie wiele Rollläden geschlossen (state 0) sind.
Hierzu habe ich zwei Monitoring-Devices erstellt. (Ich kann nicht durch die Gesamtanzahl der Rollläden minus Anzahl der offenen Rollläden auf die Anzahl der geschlossenen Rollläden schließen, da es auch Zwischenstände gibt.)
Nun zu meinem Problem. Meine Rolladen Devices werden bei allen beliebigen Werten in die warning/error Liste aufgenommen bzw. aus ihr gelöscht - ABER NICHT, wenn der Wert 0 ist.
Zum Testen habe ich ein einfaches Dummy erstellt,
define r11 dummy
attr r11 userattr rolllaeden rolllaeden_map structexclude
attr r11 room TestRollladen
# FUUID 65a64e2f-f33f-3989-0701-4cd43d71d97947e2
# NAME r11
# NR 266
# STATE 0
# TYPE dummy
# eventCount 33
# READINGS:
# 2024-02-05 21:22:12 state 0
#
setstate r11 0
setstate r11 2024-02-05 21:22:12 state 0
roll_zu soll die geschlossenen Läden zählen. Die Aufnahme in die Warning Liste bei r11=0 funktioniert nicht. Löschen funktioniert bei jedem beliebigen Wert !=0.
define roll_zu monitoring r11:0|r12:0|r13:0 r11:.*|r12:.*|r13:.*
attr roll_zu errorWait 5
attr roll_zu room TestRollladen
# CFGFN
# DEF r11:0|r12:0|r13:0 r11:.*|r12:.*|r13:.*
# FUUID 65c12fba-f33f-3989-edce-ea8961d0ebd547de
# NAME roll_zu
# NOTIFYDEV r12,r11,global,r13
# NR 302
# NTFY_ORDER 50-roll_zu
# STATE active
# TYPE monitoring
# eventCount 16
# READINGS:
# 2024-02-05 21:20:41 allCount 0
# 2024-02-05 21:20:41 error
# 2024-02-05 21:20:41 errorCount 0
# 2024-02-05 21:21:07 state active
# 2024-02-05 21:19:55 warning
# 2024-02-05 21:19:55 warningCount 0
#
setstate roll_zu active
setstate roll_zu 2024-02-05 21:20:41 allCount 0
setstate roll_zu 2024-02-05 21:20:41 error
setstate roll_zu 2024-02-05 21:20:41 errorCount 0
setstate roll_zu 2024-02-05 21:21:07 state active
setstate roll_zu 2024-02-05 21:19:55 warning
setstate roll_zu 2024-02-05 21:19:55 warningCount 0
roll_offen soll die geschlossenen Läden zählen. Die Aufnahme in die Warning Liste bei r11=100 funktioniert, Löschen funktioniert bei jeden Wert von r11, aber nicht bei r11=0
define roll_offen monitoring r11:100|r12:100|r13:100 r11:.*|r12:.*|r13:.*
attr roll_offen errorWait 5
attr roll_offen room TestRollladen
# DEF r11:100|r12:100|r13:100 r11:.*|r12:.*|r13:.*
# FUUID 65c107a1-f33f-3989-83a2-d68c271edae6eb47
# NAME roll_offen
# NOTIFYDEV r13,r11,global,r12
# NR 301
# NTFY_ORDER 50-roll_offen
# STATE error add: r11
# TYPE monitoring
# eventCount 62
# READINGS:
# 2024-02-05 21:22:10 allCount 1
# 2024-02-05 21:22:10 error r11
# 2024-02-05 21:22:10 errorCount 1
# 2024-02-05 21:22:10 state error add: r11
# 2024-02-05 21:22:09 warning
# 2024-02-05 21:22:09 warningCount 0
#
setstate roll_offen error add: r11
setstate roll_offen 2024-02-05 21:22:10 allCount 1
setstate roll_offen 2024-02-05 21:22:10 error r11
setstate roll_offen 2024-02-05 21:22:10 errorCount 1
setstate roll_offen 2024-02-05 21:22:10 state error add: r11
setstate roll_offen 2024-02-05 21:22:09 warning
setstate roll_offen 2024-02-05 21:22:09 warningCount 0
Hat jemand eine Idee für mich?
Vielen Dank und viele Grüße
Zitat von: Beta-User am 29 November 2022, 15:21:58Neuer support-Thread für das Modul wäre hier zu finden (siehe MAINTAINER.txt): https://forum.fhem.de/index.php/topic,126515.0.html..
[...]
Feedback bitte möglichst im neuen Thread.
Gilt immer noch...
Eigentlich sind das keine Zahlenvergleiche, die monitoring da macht, sondern reine regex-Operationen. Von daher sollte das schon klappen, ich habe aber grade kein geeignetes Testsystem, um das nachzustellen.
Im anderen Thread dann bitte noch ausführen, wie du den state setzt, es gibt bei deinem dummy ja keine readingList/setList.