Modul 98_monitoring zur Überwachung von Geräten

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

Vorheriges Thema - Nächstes Thema

meier81

Hi igami,

hab heute nochmal stundenlang probiert, leider ohne Erfolg, immer mit dem Ergebnis wie ich es hier schon geschildert habe:

Zitat von: meier81 am 25 Juli 2018, 22:56:28
So kam heute mal zum testen deiner Änderung:

muß leider berichten das nach der Änderung jetzt gar nichts mehr passiert, habe zum testen bei einem neuen Fühler die Überwachungszeit gesetzt und es wird kein errorAdd-Eintrag im monitoring-Modul hinzugefügt. Habe im notify auch die 0 gegen eine 1 getauscht, ist ja aber erstmal nicht relevant bei dem Problem.
Hier mal meine COnfig zur Sicherheit:

define DeviceMonitor monitoring ^[^:]+:(?!Activity).+$
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=.+


Hast du noch eine Idee wo da der Fehler steckt? Bei dem regex Ausdruck hört bei mir nämlich der Horizont auf (leider). Ich glaube damit muß ich mich aber mal auseinandersetzen in Zukunft das ich das auch mal verstehe.


Hast du noch einen Rat für mich was ich da noch anpassen müsste?

Danke dir mal, Gruß Markus
QNAP NAS mit Debian VM, darauf FHEM, debmatic, influxdb2 und Grafana || HB-RF-ETH || SIGNALduino 433MHz mit Maple mini || WS980 Wetterstation || Xiaomi Mi Robot mit valetudo-FW || Buderus web KM100 || div. Tasmota-Devices

igami

Zitat von: meier81 am 28 Juli 2018, 00:20:38
Hast du noch einen Rat für mich was ich da noch anpassen müsste?
Was bekommst du bei "list device_timeout=.+" ?
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

Zitat von: ToM_ToM am 27 Juli 2018, 12:28:26
Könntest du dir das bitte mal anschauen?
Zum testen mal bitte Zeile 486 durch folgenden Code ersetzen:

  notifyRegexpChanged($hash, $NOTIFYDEV);
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

ToM_ToM

Hallo igami,

habe das getestet. Leider immer noch das gleiche Problem.

Es tritt auch nur bei den Devices auf bei denen der Regex mit .* beginnt.

z.B.: bei sowas:
defmod Batterie_monitoring monitoring (.*:battery:.low|.*LOWBAT:.yes|.*LOWBAT:.true) (.*:battery:.ok|.*LOWBAT:.no|.*LOWBAT:.false)

VG, Thomas
Hardware: BananaPi, Busmaster CUL, SanDisk 16GB Ultra SD, 16 GB USB-Stick | Software: Armbian, FHEM 5.8

ToM_ToM

Hi igami,

ich habe es jetzt nochmal in Ruhe getestet. Die Anpassung hat doch funtktioniert. Da hatte ich wohl vorhin irgendwas übersehen.

Vielen Dank! :)
Hardware: BananaPi, Busmaster CUL, SanDisk 16GB Ultra SD, 16 GB USB-Stick | Software: Armbian, FHEM 5.8

igami

Zitat von: ToM_ToM am 29 Juli 2018, 20:02:50
ich habe es jetzt nochmal in Ruhe getestet. Die Anpassung hat doch funtktioniert. Da hatte ich wohl vorhin irgendwas übersehen.
Dann werde ich es nächste Woche selbst noch mal testen und dann einchecken. Ich erinnere mich, dass ich bei der Entwicklung irgendwelche Probleme mit notifyRegexpChanged hatte. Nur weiß ich nicht mehr genau welche :-[
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

meier81

Hallo igami,
hat etwas gedauert, war ein paar Tage unterwegs. Hie die Antwort auf deine Frage

Zitat von: igami am 29 Juli 2018, 09:42:00
Was bekommst du bei "list device_timeout=.+" ?

Der Befehl bringt mir die Aufstellung meiner Devices die das Attribut Device_timeout haben, also alle meine Fühler:

Fuehler_Arbeitszimmer
Fuehler_Aussen
Fuehler_Bad
Fuehler_Dachgeschoss
Fuehler_Elias
Fuehler_Kueche
Fuehler_Schlafzimmer
Fuehler_Wohnzimmer



Gruß Markus
QNAP NAS mit Debian VM, darauf FHEM, debmatic, influxdb2 und Grafana || HB-RF-ETH || SIGNALduino 433MHz mit Maple mini || WS980 Wetterstation || Xiaomi Mi Robot mit valetudo-FW || Buderus web KM100 || div. Tasmota-Devices

meier81

Hab zudem folgenden Fehler im Log:
1: devspec2array ^[^: Unmatched [ in regex; marked by <-- HERE in m/^(^[ <-- HERE ^)$/ at fhem.pl line 1288.


Denke das der rexex-Ausdruck einen Fehler enthält, habe anbei mal einen Screenshot des Moduls gemacht.

QNAP NAS mit Debian VM, darauf FHEM, debmatic, influxdb2 und Grafana || HB-RF-ETH || SIGNALduino 433MHz mit Maple mini || WS980 Wetterstation || Xiaomi Mi Robot mit valetudo-FW || Buderus web KM100 || div. Tasmota-Devices

igami

Aktualisier mal bitte das whitelist Attribut, dann sollte in dem INTERNAL NOTIFYDEV auch was anders stehen.
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

meier81

Hi igami,

danke für den Tipp, das brachte den entscheidenen Erfolg. Das Problem ist nur das das ganze einen Neustart nicht übersteht, nach dem Neustart steht nämlich wieder im NOTIFYDEV ^[^


Gibt es eine Möglichkeit das ganze dauerhaft zu speichern, ist blöd wenn das nach jedem Neustart verschwindet.
QNAP NAS mit Debian VM, darauf FHEM, debmatic, influxdb2 und Grafana || HB-RF-ETH || SIGNALduino 433MHz mit Maple mini || WS980 Wetterstation || Xiaomi Mi Robot mit valetudo-FW || Buderus web KM100 || div. Tasmota-Devices

igami

Zitat von: meier81 am 02 August 2018, 21:21:19
Gibt es eine Möglichkeit das ganze dauerhaft zu speichern, ist blöd wenn das nach jedem Neustart verschwindet.
Muss ich fixen und das schaffe ich eventuell morgen, sodass es dann am Sonntag per update verfügbar ist.
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

meier81

Okay, dann warte ich mal und schaue wenn das Update da ist. Ich gebe dir nochmal Rückmeldung ob es dann funktioniert.
QNAP NAS mit Debian VM, darauf FHEM, debmatic, influxdb2 und Grafana || HB-RF-ETH || SIGNALduino 433MHz mit Maple mini || WS980 Wetterstation || Xiaomi Mi Robot mit valetudo-FW || Buderus web KM100 || div. Tasmota-Devices

peterk_de

Hallo zusammen,

ich habe vor kurzem dieses tolle Modul in Betrieb genommen - als Ablösung für eigenes Gebastel aus Dummys und DOIFs - und monitore damit schon eine ganze Menge - herzlichen Dank!

Bei einem Anwendungszweck ist mir allerdings ein Problem aufgefallen. Ich nutze es, um festzustellen, ob meine lePresenced-Services noch laufen:

defmod system.monitoring.lepresenced monitoring (tag\..*):.*rssi_.*
attr system.monitoring.lepresenced errorFuncAdd {$event =~ m/^rssi_(.+):/;;\
$name = $1;;\
return 1;;\
}
attr system.monitoring.lepresenced errorWait 20*60
attr system.monitoring.lepresenced warningWait 10*60


Hiermit überwache ich analog zum dash_dhcp-Beispiel, ob von einem presence-Device die Readings, die mit rssi_.* beginnen, regelmäßig aktualisiert werden (ein Bluetooth-Dongle was immer zu Hause ist und immer von allen lepresenced-Installationen empfangen können werden sollte).

Dabei "entgehen" dem Monitoring aber offenbar immer wieder events. Das betreffende presence-Device sieht so aus (Auszug):

defmod tag.alwaysathome PRESENCE lan-bluetooth AC:DC:AC:DC:AC:DC 192.168.178.60:5222
attr tag.alwaysathome DbLogExclude rssi.* event-min-interval rssi_.*:60
attr tag.alwaysathome event-min-interval rssi_.*:60
attr tag.alwaysathome event-on-change-reading state
attr tag.alwaysathome event-on-update-reading rssi_.*

setstate tag.alwaysathome 2018-08-15 14:32:16 rssi_Bad-Oben -83
setstate tag.alwaysathome 2018-08-15 14:32:16 rssi_Flur -85
setstate tag.alwaysathome 2018-08-15 14:32:16 rssi_Kinderzimmer -79
setstate tag.alwaysathome 2018-08-15 14:32:16 rssi_Küche -82
setstate tag.alwaysathome 2018-08-15 14:32:16 rssi_Schlafzimmer -82
setstate tag.alwaysathome 2018-08-15 14:32:16 rssi_Wohnzimmer -53
setstate tag.alwaysathome 2018-08-15 14:32:16 state present


Im Eventmonitor sehe ich z.B. die Events für "rssi_Flur" minütlich kommen, aber das Monitoring ignoriert die. So werden error_adds etc. für einige Readings wie Flur erst gar nicht automatisch angelegt (für ein paar andere aber schon!) und andere gehen, obwohl die Events regelmäßig kommen, nach anfänglichem aktualisieren der error-add-Zeit für 1-2 Stunden irgendwann trotzdem auf error, obwohl die Events unverändert kommen. Das ganz ist ziemlich zufällig und betrifft immer wieder andere Events.

Igami, hast du ne Idee, woran das liegen könnte?
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

meier81

Hallo igami,

Zitat von: igami am 03 August 2018, 16:37:02
Muss ich fixen und das schaffe ich eventuell morgen, sodass es dann am Sonntag per update verfügbar ist.

du bist noch nicht dazugekommen das zu fixen?

Gruß Markus
QNAP NAS mit Debian VM, darauf FHEM, debmatic, influxdb2 und Grafana || HB-RF-ETH || SIGNALduino 433MHz mit Maple mini || WS980 Wetterstation || Xiaomi Mi Robot mit valetudo-FW || Buderus web KM100 || div. Tasmota-Devices

peterk_de

OK ich habe glaube ich das Problem mit den Fehlenden Events durch verbose 5 eingrenzen können: Die fehlenden Events kommen beim monitoring-Device nicht an. Vermutlich, weil sie durch das Presence-Device alle auf einmal ausgelöst werden. Auszug aus dem Event-Monitor:

2018-08-16 10:19:28.556 PRESENCE tag.alwaysathome rssi_Bad-Oben: -80
2018-08-16 10:19:28.556 PRESENCE tag.alwaysathome rssi_Flur: -85
2018-08-16 10:19:28.556 PRESENCE tag.alwaysathome rssi_Kinderzimmer: -77
2018-08-16 10:19:28.556 PRESENCE tag.alwaysathome rssi_Küche: -81
2018-08-16 10:19:28.556 PRESENCE tag.alwaysathome rssi_Schlafzimmer: -81
2018-08-16 10:19:28.556 PRESENCE tag.alwaysathome rssi_Wohnzimmer: -54


Das Log vom monitoring-device zeigt dann genau einen Trigger nur für das erste von diesen Events, die anderen fehlen:

2018.08.16 10:19:28.504 4: monitoring (test.monitoring) triggered by "tag.alwaysathome rssi_Bad-Oben: -80"
2018.08.16 10:19:28.504 5: monitoring (test.monitoring) only addRegex is defined
2018.08.16 10:19:28.506 5: monitoring (test.monitoring)
    entering monitoring_modify
        reading:   error
        operation: remove
        value:     Bad-Oben
        at:        now
2018.08.16 10:19:28.552 5: monitoring (test.monitoring)
    entering monitoring_modify
        reading:   error
        operation: add
        value:     Bad-Oben
        at:        2018-08-16 10:21:28


Scheint so, als ob FHEM dem Modul Events "unterschlägt", nach meinem Verständnis muss es an dieser Zeile bzw. der Funktion deviceEvents liegen:

  my $events = deviceEvents($dev_hash, AttrVal($SELF, "addStateEvent", 0));

So und nun bin ich mit meinem Latein am Ende :-D
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...