Autor Thema: neues Modul 98_monitoring zur Überwachung von Geräten  (Gelesen 2813 mal)

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
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.
« Letzte Änderung: 21 März 2017, 06:04:46 von igami »
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring
« Antwort #1 am: 10 März 2017, 20:39:15 »
Schon 11 Mal runtergeladen und noch kein Feedback? ;)
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline mahowi

  • Sr. Member
  • ****
  • Beiträge: 586
Antw:neues Modul 98_monitoring
« Antwort #2 am: 10 März 2017, 20:48:24 »
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.
CUBe (MAX): HT, WT+, FK, EcoTaster | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring
« Antwort #3 am: 10 März 2017, 20:58:12 »
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.
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline ThomasMagnum

  • New Member
  • *
  • Beiträge: 31
Antw:neues Modul 98_monitoring
« Antwort #4 am: 11 März 2017, 07:45:10 »
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

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring
« Antwort #5 am: 11 März 2017, 08:18:33 »
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.
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring
« Antwort #6 am: 12 März 2017, 08:27:45 »
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
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline ThomasMagnum

  • New Member
  • *
  • Beiträge: 31
Antw:neues Modul 98_monitoring
« Antwort #7 am: 15 März 2017, 09:25:23 »
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

Offline dieter56

  • Jr. Member
  • **
  • Beiträge: 53
Antw:neues Modul 98_monitoring
« Antwort #8 am: 15 März 2017, 12:29:50 »
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

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring
« Antwort #9 am: 15 März 2017, 17:06:40 »
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

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.

Ich habe schon Pläne, was ich damit machen werde.
An was denkst du denn so?

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;;\
}
« Letzte Änderung: 16 März 2017, 08:54:16 von igami »
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline ThomasMagnum

  • New Member
  • *
  • Beiträge: 31
Antw:neues Modul 98_monitoring
« Antwort #10 am: 16 März 2017, 08:18:14 »
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

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring
« Antwort #11 am: 16 März 2017, 09:15:40 »
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 :)

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.
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring
« Antwort #12 am: 17 März 2017, 06:37:46 »
Eine englische Commandref habe ich nun auch hinzugefügt und die deutsche ist nun auch als deutsche commandref vorhanden.
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring
« Antwort #13 am: 18 März 2017, 14:05:55 »
Gibt es noch weiteres Feedback zum Modul? Besonders interessiert mich ob irgendetwas nicht funktioniert. Ich würde das dann gerne in FHEM einchecken.
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring
« Antwort #14 am: 19 März 2017, 07:46:06 »
Bitte das git repository aus den update Quellen entfernen, das Modul ist nun ofiziell in FHEM eingecheckt.
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline kvo1

  • Hero Member
  • *****
  • Beiträge: 1445
  • FHEMonaut
Antw:monitoring
« Antwort #15 am: 20 März 2017, 22:20:07 »
Hallo igami

grade per zufall gelesen,klingt gut und muss ich mal testen bei Gelegenheit !

danke für die Mühe

kvo1
RPi1: mit CUL: HM-CC-RT-DN,HM-ES-PMSw1-Pl,HM-LC-BL1-FM,HM-LC-Bl1PBU-FM,HM-LC-SW1-PL2,HM-SCI-3-FM,HM-SEC-SC-2,KFM-Sensor
RPi2: Viessmann(optolink) mit 99_VCONTROL.pm,
Cubietruck: Wheezy / Apache / Owncloud
Cubietruck: Armbian(Jessie) / fhem 5.7 / LMS 7.9
RPi3: (Test) mit 7" Touch  &  HM-MOD-RPI-PCB

Offline KernSani

  • Sr. Member
  • ****
  • Beiträge: 956
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #16 am: 26 März 2017, 23:59:07 »
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   
Vom Arzt oder Apotheker empfohlen: https://fhem.de/commandref.html

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #17 am: 27 März 2017, 06:30:56 »
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 :)

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

(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.
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline kvo1

  • Hero Member
  • *****
  • Beiträge: 1445
  • FHEMonaut
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #18 am: 27 März 2017, 08:27:18 »
So, ich habe mal das "Batterieüberwachung" - Beispiel aktiviert, werde dann berichten!

Danke nochmal für das Modul !

RPi1: mit CUL: HM-CC-RT-DN,HM-ES-PMSw1-Pl,HM-LC-BL1-FM,HM-LC-Bl1PBU-FM,HM-LC-SW1-PL2,HM-SCI-3-FM,HM-SEC-SC-2,KFM-Sensor
RPi2: Viessmann(optolink) mit 99_VCONTROL.pm,
Cubietruck: Wheezy / Apache / Owncloud
Cubietruck: Armbian(Jessie) / fhem 5.7 / LMS 7.9
RPi3: (Test) mit 7" Touch  &  HM-MOD-RPI-PCB

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #19 am: 27 März 2017, 08:55:36 »
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.

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 ;)
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline kvo1

  • Hero Member
  • *****
  • Beiträge: 1445
  • FHEMonaut
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #20 am: 27 März 2017, 11:58:39 »
Zitat
Hast du das per "Raw definition" gemacht? Falls ja, funktionert das gut?
hmmm, wie meinst Du das ?

RPi1: mit CUL: HM-CC-RT-DN,HM-ES-PMSw1-Pl,HM-LC-BL1-FM,HM-LC-Bl1PBU-FM,HM-LC-SW1-PL2,HM-SCI-3-FM,HM-SEC-SC-2,KFM-Sensor
RPi2: Viessmann(optolink) mit 99_VCONTROL.pm,
Cubietruck: Wheezy / Apache / Owncloud
Cubietruck: Armbian(Jessie) / fhem 5.7 / LMS 7.9
RPi3: (Test) mit 7" Touch  &  HM-MOD-RPI-PCB

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #21 am: 27 März 2017, 12:28:32 »
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.
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline hoods

  • Jr. Member
  • **
  • Beiträge: 52
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #22 am: 06 April 2017, 16:40:59 »
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_speedtestoder (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
Odroid C2, FHEM 5.8, HMUSB, Jeelink, Rademacher DuoFern Stick, Benning WR über HTTPMOD

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #23 am: 06 April 2017, 17:18:56 »
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_speedtestoder (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.

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
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline hoods

  • Jr. Member
  • **
  • Beiträge: 52
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #24 am: 06 April 2017, 17:37:15 »
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
Odroid C2, FHEM 5.8, HMUSB, Jeelink, Rademacher DuoFern Stick, Benning WR über HTTPMOD

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #25 am: 06 April 2017, 17:44:55 »
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.
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #26 am: 06 April 2017, 18:10:47 »
Vielleicht baue ich auch noch ein whiteList attribut ein.
gesagt, getan :)
Ab morgen per update verfügbar
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #27 am: 07 April 2017, 06:07:00 »
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
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #28 am: 08 April 2017, 09:20:55 »
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\
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline mumpitzstuff

  • Full Member
  • ***
  • Beiträge: 158
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #29 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?

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...

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #30 am: 13 April 2017, 22:20:01 »
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

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

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.
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline mumpitzstuff

  • Full Member
  • ***
  • Beiträge: 158
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #31 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.

Offline KernSani

  • Sr. Member
  • ****
  • Beiträge: 956
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #32 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...

Vom Arzt oder Apotheker empfohlen: https://fhem.de/commandref.html

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #33 am: 14 April 2017, 07:03:34 »
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:
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.

@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.
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline hoods

  • Jr. Member
  • **
  • Beiträge: 52
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #34 am: 16 April 2017, 22:12:19 »
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
Odroid C2, FHEM 5.8, HMUSB, Jeelink, Rademacher DuoFern Stick, Benning WR über HTTPMOD

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #35 am: 17 April 2017, 17:38:55 »
Wie kann ich weiter eingrenzen warum die Devices auf der Error und Warning Liste landen?
erzeugen die devices auch events?

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
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline Brockmann

  • Sr. Member
  • ****
  • Beiträge: 816
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #36 am: 18 April 2017, 12:20:22 »
Zitat
clear (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...

Offline hoods

  • Jr. Member
  • **
  • Beiträge: 52
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #37 am: 18 April 2017, 16:37:40 »
Zitat
erzeugen 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,battery

Werde mal mit errorRemove und warningRemove die unerwünschten Devices von den Listen nehmen. Mal schauen ob Sie anschliessend wieder erscheinen.

Gruss Sven
Odroid C2, FHEM 5.8, HMUSB, Jeelink, Rademacher DuoFern Stick, Benning WR über HTTPMOD

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #38 am: 18 April 2017, 19:02:04 »
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 :)
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #39 am: 21 April 2017, 06:17:29 »
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.
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline KernSani

  • Sr. Member
  • ****
  • Beiträge: 956
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #40 am: 21 April 2017, 06:24:24 »
Cool. Funktioniert das nach Neustart dann auch bei verwaisten timern? (Habe gerade die Nachricht bekommen, dass global dich seit 24h nicht gemeldet hat ;-))
Vom Arzt oder Apotheker empfohlen: https://fhem.de/commandref.html

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #41 am: 21 April 2017, 07:41:52 »
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
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline friesenjung

  • Full Member
  • ***
  • Beiträge: 120
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #42 am: Gestern um 16:35:59 »
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...
FHEM auf Raspi 2, TCM-EnOcean, Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304, Pushover, CUL_HM

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #43 am: Gestern um 16:58:06 »
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?
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline friesenjung

  • Full Member
  • ***
  • Beiträge: 120
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #44 am: Gestern um 19:35:08 »
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...
FHEM auf Raspi 2, TCM-EnOcean, Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304, Pushover, CUL_HM

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1586
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #45 am: Gestern um 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;;\
}
Pi3 mit fhem.cfg + DbLog/logProxy
FHEM Module: LuftdatenInfo, monitoring, Nmap
FHEM Module ToDo: archetype, alexaWebApp, DaikinD3nIU, DaikinHTTPinterface, TBot_Dialog
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

 

decade-submarginal