Modul 98_monitoring zur Überwachung von Geräten

Begonnen von igami, 09 März 2017, 22:12:42

Vorheriges Thema - Nächstes Thema

igami

Zitat von: mumpitzstuff am 13 April 2017, 15:38:37
Wenn ich mir jetzt eine Push Nachricht schicken lassen möchte, dann muss ich das im Attribut errorReturn (Perl Code) machen? Wird die dann nur einmalig verschickt wenn der Fehler neu in die Fehlerliste aufgenommen wird?
errorReturn ist dafür da um die Nachricht zu formatieren, das Modul selbst sendet nicht, sondern sammelt nur. Ich lasse mir immer eine Nachricht schicken, wenn ich seit 15 Minuten zu hause bin

defmod rr_MichaelPrange_monitoring_notification DOIF ([rr_MichaelPrange:presence] eq "present")(\
  set TelegramBot message @12345678 \
      {(fhem("get TYPE=monitoring:FILTER=msgPeerId=.*12345678.* default"))}\
    \n/heimdall\
)\
DOELSE
attr rr_MichaelPrange_monitoring_notification wait 60*15


Zitat von: mumpitzstuff am 13 April 2017, 15:38:37
Was macht man mit errorFuncAdd? Kannst du das vielleicht kurz an einem Beispiel erklären?
Steht in der commandref ;)
Zitat
errorFuncAdd {<perl code>}
In dieser Funktion stehen die folgende Variablen zur Verfügung:

    $name
    Name des Event auslösenden Gerätes
    $event
    Beinhaltet das komplette Event, z.B. measured-temp: 21.7 (Celsius)
    $addMatch
    Hat den Wert 1, falls das add-event zutrifft
    $removeMatch
    Hat den Wert 1, falls das remove-event zutrifft
    $SELF
    Eigenname des monitoring

Gibt die Funktion eine 1 zurück, wird das Gerät, nach der Wartezeit, auf die error-Liste gesetzt.
Wenn das Attribut nicht gesetzt ist wird auf $addMatch geprüft.
Beispiele für die Anwendung stehen ebenfalls in der commandref und zwar "regelmäßige Wartungsarbeiten (z.B. Räume putzen)" und "Betriebsstunden abhängige Wartungsarbeiten (z.B. Beamer Filter reinigen)"

Zitat von: mumpitzstuff am 13 April 2017, 15:38:37
Hintergrund: Ich würde das Ding gern einsetzen, um dein Batterie Beispiel zu nehmen, möchte mir aber nach 1 Woche im Warning Status (switch zu error) eine Push Nachricht schicken lassen. Weiterhin würde ich damit gern die Benachrichtigung für das Blumen giessen umsetzen. Das würde mir diverse Notify und Watchdog Anweisungen ersparen...
Zum senden brauchst du noch einen weiteren helper (notify, DOIF, watchdog, at, ...). Die Wartezeit kannst du ja nach deinen Wünschen anpassen, im Beispiel sind es 14 Tage, du möchtest 7.

Für das Blumen giessen kannst du dich an dem Räume putzen Beispiel orientieren, du musst dich nur entscheiden womit du das gießen quittierst, ich nutze da gerne DashButtons.

Falls du noch Fragen hast einfach schreiben, wenn möglich wo genau du Probleme hast. Ich bemühe mich immer die commandref so verständlich wie möglich zu halten.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

mumpitzstuff

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.

KernSani

@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, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

igami

Zitat von: mumpitzstuff am 13 April 2017, 23:24:22
Das mit der Funktion stimmt, ist mir in den relativ großen Beispielen irgendwie unter gegangen.

Ich hatte gehofft direkt beim Übergang eines Gerätes entweder von normal nach warning oder von warning nach error eine Art Action hinterlegen könnte. Das Zurücksetzen würde übrigens entweder durch den Wechsel der Batterie bzw. das Gießen der Blumen erfolgen, weil dann die Feuchtigkeit wieder über das WarningLevel steigt. Ich hoffe ich Fine nach Ostern etwas Zeit zum Experimentieren.
Man könnte so eine Funktion einbauen, aber ich finde die Möglichkeiten die DOIF bietet (wait und die Abfrage auf andere Zustände wie presence) besser. Bei uns in der Firma bekommen wir z.B. nur Benachrichtigungen während der Arbeitszeit und auch nur maximal alle Viertelstunde. Das hatte ich hier mal geschrieben:
Zitat von: igami am 11 März 2017, 08:18:33
Ich habe ein DOIF das inetwa so aussieht:

defmod ServiceNotifications_DI DOIF ([16:30-21:00|8]\
&& (   [":^error add:"]\
     || [$SELF:cmd_nr] == 2\
)\
)(\
  set TelegramBot message {(fhem("get TYPE=monitoring default"))}\
)\
DOELSEIF\
([":^error add:"])

attr ServiceNotifications_DI cmdState send notifications|notifications pending
attr ServiceNotifications_DI cmdpause 60*15
attr ServiceNotifications_DI do always
attr ServiceNotifications_DI icon time_automatic
attr ServiceNotifications_DI wait 60*15

Trifft ein "error add:" event ein wird 15 Minuten gewartet, dann bekomme ich eine Nachricht mit allen Sammelmeldungen. Passiert das außerhalb des Zeitraums wird es in die Warteschlange gepackt.

Zitat von: KernSani am 14 April 2017, 00:17:56
@igami:

keine Ahnung ob es ein Problem ist oder ein bereits gelöstes Problem. Ich hatte eine ältere monitoring Version am Laufen und habe gestern ein Device (global activity monitor gelöscht). Heute morgen hatte ich haufenweise folgende Meldung im Log:

2017.04.13 10:59:58 1: ERROR: empty name in readingsBeginUpdate
2017.04.13 10:59:58 1: stacktrace:
2017.04.13 10:59:58 1:     main::readingsBeginUpdate           called by ./FHEM/98_monitoring.pm (404)
2017.04.13 10:59:58 1:     main::monitoring_modify             called by fhem.pl (2918)
2017.04.13 10:59:58 1:     main::HandleTimeout                 called by fhem.pl (613)


Nach einem update und shutdown/restart tritt es nicht mehr auf. Ich frage mich nur, ob beim delete irgendwelche internalTimer nicht ordentlich aufgeräumt werden...


Tatsächlich werden die Timer nicht gelöscht und die aufgerufene Funktion überprüft auch nicht ob es das monitoring noch gibt. Werde ich bei gelegenheit einbauen.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

hoods

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

igami

Zitat von: hoods am 16 April 2017, 22:12:19
Wie kann ich weiter eingrenzen warum die Devices auf der Error und Warning Liste landen?
erzeugen die devices auch events?

Zitat von: hoods am 16 April 2017, 22:12:19
Desweiteren habe ich in der Error Liste Devices, die kürzlich neu angelegt wurden und direkt danach umbenannt wurden. Ein Beispiel ist DUOFERN_49B111. Dieses Devices gibt es nicht mehr, da es mit rename in Rollo_WZ_L umbenannt wurde. Leider sind beide Devices auf der Error Liste obwohl es das erste Device gar nicht mehr gibt.

Wie kann ich das bereinigen?
Einfach mit errorRemove von der Liste nehmen.

Das Beispiel ist irgendwie noch nicht ganz ausgereift. Mittlerweile gibt es auch ein whitelist Attribut: https://forum.fhem.de/index.php/topic,68765.msg617790.html#msg617790
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

Brockmann

Zitatclear (warning|error|all)
Removes all devices from the specified list and aborts timers for this list. With "all", all devices are removed from both lists and all running timers are aborted.
Werden die internen Timer wirklich gelöscht?

Ich war irritiert, weil drei Stunden nach einem clear all schon wieder Geräte in der Errorliste auftauchten, obwohl das frühestens nach 25 Stunden passieren soll.
Also habe ich mir mal die internen Timer angesehen und da stehen jede Menge Timer von monitoring_modify drin - jedenfalls wesentlich mehr als in den Readings des monitoring-Moduls...

hoods

Zitaterzeugen die devices auch events?

Ich denke doch, folgende Parameter sind gesetzt und ich erhalte im Logfile auch entsprechende Einträge.
attr Wasserwaechter_Bad event-min-interval .*:600
attr Wasserwaechter_Bad event-on-change-reading temperature,temperature2,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

igami

Zitat von: Brockmann am 18 April 2017, 12:20:22
Werden die internen Timer wirklich gelöscht?

Ich war irritiert, weil drei Stunden nach einem clear all schon wieder Geräte in der Errorliste auftauchten, obwohl das frühestens nach 25 Stunden passieren soll.
Also habe ich mir mal die internen Timer angesehen und da stehen jede Menge Timer von monitoring_modify drin - jedenfalls wesentlich mehr als in den Readings des monitoring-Moduls...
Tatsächlich werden die timer nicht gelöscht, sondern nur die Readings. Ich werde mal zusehen, dass ich es diese Woche noch schaffe ein Update für das Modul zu schreiben.

Aber es freut mich, dass das Modul genutzt wird :)
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

igami

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

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

KernSani

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, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

igami

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

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

ioT4db

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 Synology mittels Docker,  Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304SOL, Homematic: CUL_HM / M-MOD-RPI-PCB, Pushover, Xiaomi s50

igami

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

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

ioT4db

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 Synology mittels Docker,  Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304SOL, Homematic: CUL_HM / M-MOD-RPI-PCB, Pushover, Xiaomi s50