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

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • 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: 1719
  • 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.

Online mahowi

  • Sr. Member
  • ****
  • Beiträge: 638
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: 1719
  • 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: 32
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: 1719
  • 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: 1719
  • 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: 32
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: 1719
  • 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: 32
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: 1719
  • 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: 1719
  • 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: 1719
  • 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: 1719
  • 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: 1454
  • 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

  • Hero Member
  • *****
  • Beiträge: 1309
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   
RasPi: RFXTRX, HM, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • 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: 1454
  • 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: 1719
  • 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: 1454
  • 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: 1719
  • 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: 54
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: 1719
  • 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: 54
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: 1719
  • 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: 1719
  • 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: 1719
  • 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: 1719
  • 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: 186
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: 1719
  • 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: 186
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

  • Hero Member
  • *****
  • Beiträge: 1309
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...

RasPi: RFXTRX, HM, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • 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: 54
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: 1719
  • 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: 54
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: 1719
  • 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: 1719
  • 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

  • Hero Member
  • *****
  • Beiträge: 1309
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 ;-))
RasPi: RFXTRX, HM, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • 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: 132
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #42 am: 25 April 2017, 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: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #43 am: 25 April 2017, 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: 132
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #44 am: 25 April 2017, 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: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #45 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;;\
}
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: 132
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #46 am: 26 April 2017, 17:37:00 »
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
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: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #47 am: 26 April 2017, 17:51:32 »
Was willst du mit dem DOIF machen?
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: 132
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #48 am: 26 April 2017, 18:02:49 »
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
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: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #49 am: 26 April 2017, 18:04:35 »
Und woran scheiterst du?
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: 132
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #50 am: 26 April 2017, 18:17:22 »
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
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: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #51 am: 26 April 2017, 18:54:44 »
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.
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: 132
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #52 am: 02 Mai 2017, 18:09:33 »
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:
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...
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: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #53 am: 02 Mai 2017, 18:25:51 »
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
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: 1454
  • FHEMonaut
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #54 am: 08 Mai 2017, 08:15:09 »
Hallo  friesenjung,

Zitat
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)!

ist vlt. etwas offtop aber kannst Du die Benachrichtigungslogik mal bitte kurz beschreiben ?

danke

vko1
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 l2r

  • Full Member
  • ***
  • Beiträge: 458
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #55 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
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #56 am: 09 Mai 2017, 12:48:36 »
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?
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 l2r

  • Full Member
  • ***
  • Beiträge: 458
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #57 am: 09 Mai 2017, 13:14:00 »
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
« Letzte Änderung: 09 Mai 2017, 13:23:09 von l2r »
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #58 am: 09 Mai 2017, 13:23:55 »
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
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 l2r

  • Full Member
  • ***
  • Beiträge: 458
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #59 am: 09 Mai 2017, 13:35:13 »
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
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #60 am: 09 Mai 2017, 13:38:44 »
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

Wobei es rein logisch ja auch sinn macht, wenn beide im Error sind auch beide zu reinigen?!
Ne, soll ja Betriebsstunden abhängig sein
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 l2r

  • Full Member
  • ***
  • Beiträge: 458
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #61 am: 09 Mai 2017, 13:42:48 »
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
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #62 am: 09 Mai 2017, 13:44:08 »
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
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 l2r

  • Full Member
  • ***
  • Beiträge: 458
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #63 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
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Offline gloob

  • Sr. Member
  • ****
  • Beiträge: 836
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #64 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:
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.
« Letzte Änderung: 09 Mai 2017, 13:55:24 von gloob »
Raspberry Pi 3 | miniCUL 433MHz | MySensors WLAN Gateway | HM-LC-Bl1PBU-FM | HM-CC-RT-DN | HM-ES-PMSw1-Pl | HM-MOD-EM-8 | Sonoff Relais

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #65 am: 09 Mai 2017, 14:05:58 »
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:
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.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #66 am: 10 Mai 2017, 05:58:07 »
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 ::)
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 l2r

  • Full Member
  • ***
  • Beiträge: 458
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #67 am: 10 Mai 2017, 12:27:26 »
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
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #68 am: 10 Mai 2017, 12:39:48 »
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.
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 l2r

  • Full Member
  • ***
  • Beiträge: 458
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #69 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
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #70 am: 10 Mai 2017, 18:31: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.
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.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline friesenjung

  • Full Member
  • ***
  • Beiträge: 132
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #71 am: 12 Mai 2017, 22:20:32 »
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...
FHEM auf Raspi 2, TCM-EnOcean, Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304, Pushover, CUL_HM

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4376
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #72 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
« Letzte Änderung: 13 Mai 2017, 14:24:04 von Prof. Dr. Peter Henning »

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #73 am: 13 Mai 2017, 14:52:01 »
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?
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 Benni

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1458
  • FHEMinist
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #74 am: 13 Mai 2017, 16:11:49 »
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.
FHEM (FL 9.9) (configDB+DbLog) auf Debian Wheezy.
Jede Menge HM mit HMLAN und HMUART (WeMos+esp-link) über VCCU
UniRoll an CUL868. Sebury F2-2 RFID über ESPEasy
Module: 98_rssFeed und 98_QRCode

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4376
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #75 am: 13 Mai 2017, 20:02:03 »
Zitat
Es 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.

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

Zitat
Ich 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

Offline Marlen

  • Full Member
  • ***
  • Beiträge: 259
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #76 am: 16 Mai 2017, 14:55:35 »
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

Offline l2r

  • Full Member
  • ***
  • Beiträge: 458
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #77 am: 16 Mai 2017, 14:58:52 »
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
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Offline ToKa

  • Full Member
  • ***
  • Beiträge: 164
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #78 am: 16 Mai 2017, 21:54:03 »
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
RaspberryPi3 mit RaZberry2 für ZWAVE
Fibaro: FGWPE/F-101 Switch,  FGSD002 Smoke Sensor
Popp / Duwi: ZW ZS 3500 Plugin Switch, 009105 Wall Plug Switch Schuko (IP44)
EUROtronic COMET Z Wall Radiator Thermostat Valve Control

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1719
  • RTFM
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #79 am: 16 Mai 2017, 22:07:46 »


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

  • Full Member
  • ***
  • Beiträge: 164
Antw:neues Modul 98_monitoring zur Überwachung von Geräten
« Antwort #80 am: 16 Mai 2017, 23:09:13 »
Super, vielen Dank - doch so einfach, wenn man alle attribute richtig versteht  :-[
RaspberryPi3 mit RaZberry2 für ZWAVE
Fibaro: FGWPE/F-101 Switch,  FGSD002 Smoke Sensor
Popp / Duwi: ZW ZS 3500 Plugin Switch, 009105 Wall Plug Switch Schuko (IP44)
EUROtronic COMET Z Wall Radiator Thermostat Valve Control