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

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1423
  • 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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
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: 1423
  • 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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
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: 531
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: 1423
  • 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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
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: 28
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: 1423
  • 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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
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: 1423
  • 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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
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: 28
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: 1423
  • 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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
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: 28
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: 1423
  • 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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
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: 1423
  • 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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
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: 1423
  • 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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
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: 1423
  • 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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
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: 1426
  • 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

 

decade-submarginal