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

Offline igami

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2525
  • RTFM
    • commandref
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
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im Januar 2019.

MAINTAINER: archetype, Heating_Control, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap, RandomTimer, Twilight, WeekdayTimer
ToDo: adb, FluxLED

Offline mumpitzstuff

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

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

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2525
  • RTFM
    • commandref
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
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im Januar 2019.

MAINTAINER: archetype, Heating_Control, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap, RandomTimer, Twilight, WeekdayTimer
ToDo: adb, FluxLED

Offline hoods

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

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2525
  • RTFM
    • commandref
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
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im Januar 2019.

MAINTAINER: archetype, Heating_Control, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap, RandomTimer, Twilight, WeekdayTimer
ToDo: adb, FluxLED

Offline Brockmann

  • Sr. Member
  • ****
  • Beiträge: 905
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: 89
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

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2525
  • RTFM
    • commandref
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
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im Januar 2019.

MAINTAINER: archetype, Heating_Control, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap, RandomTimer, Twilight, WeekdayTimer
ToDo: adb, FluxLED

Offline igami

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2525
  • RTFM
    • commandref
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
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im Januar 2019.

MAINTAINER: archetype, Heating_Control, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap, RandomTimer, Twilight, WeekdayTimer
ToDo: adb, FluxLED

Offline KernSani

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

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2525
  • RTFM
    • commandref
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
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im Januar 2019.

MAINTAINER: archetype, Heating_Control, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap, RandomTimer, Twilight, WeekdayTimer
ToDo: adb, FluxLED

Offline friesenjung

  • Full Member
  • ***
  • Beiträge: 220
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,  Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304SOL, Homematic: CUL_HM / M-MOD-RPI-PCB, Pushover, TCM-EnOcean

Offline igami

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2525
  • RTFM
    • commandref
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
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im Januar 2019.

MAINTAINER: archetype, Heating_Control, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap, RandomTimer, Twilight, WeekdayTimer
ToDo: adb, FluxLED

Offline friesenjung

  • Full Member
  • ***
  • Beiträge: 220
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,  Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304SOL, Homematic: CUL_HM / M-MOD-RPI-PCB, Pushover, TCM-EnOcean