Modul 98_monitoring zur Überwachung von Geräten

[Cyber1000]

Ich behaupte, dass es das simple notify/DOIF nicht gitb.

Naja meins sieht zum Beispiel jetzt so aus:

Code Auswählen Erweitern


m_activity:(warning|error).add:..+ {
my $message=fhem("get m_activity default",1);
sendMessage('Aktivitätswarnung', $message);
}

Und sendmessage verwendet mehr oder weniger den TelegramBot (und Kodi zu bestimmten Zeiten). Durch ein einfaches sendmessage, das ich überall verwende, ist im Endeffekt auch der Bot egal, ich kann ihn auch jederzeit zentral auswechseln. Die Uhrzeiten von Batteriewarnungen können ruhig auch in der Nacht kommen, das Handy hab ich (fast) nie im Schlafzimmer. Aber gut jeder hat da andere Vorlieben, sonst würden vermutlich viele hier ein vorgefertigtes System nehmen und sich nicht selber eines nach eigenen Wünschen zurechtbasteln 

Und vermutlich wars damals wie ich ein paar Zeilen Code zusammenbasteln wollte schon etwas zu spät (hust, kurz nach 0:00 und nach einem langen Arbeitstag), aber so ein paar "Anwendungsbeispiele" wären schon manchmal hilfreich.

Beim msgDialog Modul wird der wiki Artikel von der Community geschrieben

Ja vermutlich wäre ein wiki-Artikel dafür der bessere Ort als ein commandref-Eintrag, da sollte wohl wirklich nur das wesentliche stehn.

[Cyber1000]

Ich hätte da noch eine Frage das Modul betreffend, ich wollte/will das als Aktivitätsmonitor verwenden, nur waren mir am Anfang die Meldungen dann schon zu viel (teilweise für dummydevices, die sich nicht ständig melden - ich wasche auch nicht alle 12/24h Wäsche), deshalb habe ich kurzfristig das Monitoring auf inactive gesetzt und mal viele meiner devices neu benannt, ausgemistet, korrigiert; hab mit fhem vor gut einem Jahr angefangen und war mit dem naming dann teilweise doch inkonsequent, sodass ich in der blacklist sehr viele Geräte direkt eintragen hätte müssen.
Jetzt hab ich das Monitoring wieder aktiviert (set m_activity active), alles bereinigt (set m_acitivity clear all), es landen aber jetzt sehr wenige warningAdd_ oder errorAdd_ in den readings.

Code Auswählen Erweitern


defmod m_activity monitoring .*:.*
attr m_activity blacklist global eventTypes initialUsbCheck KODI n_.* d_.* m_.* l_.* w_.* st_.* virtual_switch_.* Benachrichtigung_.* Info_.* Dongle_.* Hauptnode_.*
attr m_activity 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 m_activity errorWait 60*60*24
attr m_activity 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 m_activity warningWait 60*60*12


Im Eventmonitoring hab ich aber nach wie vor Events die so aussehen:

Code Auswählen Erweitern

2018-12-12 21:13:38 ZWave Steckdose_Geschirrspueler Power: 0.4 W

Ich wüsste jetzt nicht, wie ich mit obiger blacklist "Steckdose_Geschirrspueler" weggefiltert haben sollte
Eine Idee was hier passiert sein könnte?

[Cyber1000]

Nachtrag:

• Blacklist gelöscht
• gewartet bis die Readings (errorAdd, warningAdd) da waren, die kamen dann auf einmal wieder durch Meldung der Geräte
• blacklist wieder 1:1 reingeschrieben
• dadurch sind die unerwünschten errorAdds und warningAdds rausgefallen

Jetzt scheint wieder alles zu funktionieren, set inactive/set active und clear all dürfte irgendwie das monitoring beschädigen, vielleicht hätte ich das clear all nicht machen dürfen.

[Cyber1000]

Nachtrag vom Nachtrag:
Die blacklist entfernt zwar die gewünschten errorAdd, warningAdd, aber events kommen anschließend auch nicht mehr rein (für keines der Geräte). Kann es sein, dass die blacklist keine regexp verträgt:

attr m_activity blacklist global eventTypes initialUsbCheck KODI n_.* d_.* m_.* l_.* w_.* st_.* virtual_switch_.* Benachrichtigung_.* Info_.* Dongle_.* Hauptnode_.*

[Cyber1000]

ok ich setze meinen Monolog fort , ich lass die blacklist jetzt ganz weg und mach das über einen negative Lookahead regex.

Also statt mein monitoring auf .*:.* reagieren zu lassen sieht mein DEF jetzt so aus:

Code Auswählen Erweitern

(?!global|eventTypes|initialUsbCheck|KODI|n_|d_|m_|l_|w_|st_|virtual_switch_|Benachrichtigung_|Info_|Dongle_|Hauptnode_|dev_|Sensor_LP).*:.*

Es wird somit auf alle Devices, die mit global oder n_ oder d_ oder ... beginnen, nicht mehr reagiert.
Vielleicht kann noch jemand das seltsame Verhalten mit blacklist erklären/verifizieren, ansonsten funktioniert das mal gut für mich.

[Schoko]

Hallo zusammen,
das Modul ist echt super, allerdings hab ich Probleme bei der Benachrichtgung.
Ich bekomme die Fehlereldung: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 223) line 1.
Ich hab einen Rückspülfilter angelegt mit einem Dashbutton (die Zeit hab ich absichtlich zum Test auf 20, bzw. 30 Sekunden eingestellt). Das zurücksetzen klappt super, es kommt nur keine Nachricht von dem DOIF im Telegram an. Der Bot funktioniert aber bei anderen Benachrichtigungen.
Anbei meine Config:

Code Auswählen Erweitern

define d_Rueckspuelfilter dash_dhcp
attr d_Rueckspuelfilter allowed 18:74:2E:77:7C:29
attr d_Rueckspuelfilter devAlias 18-74-2E-77-7C-29:DashRueckspuelfilter
attr d_Rueckspuelfilter port 6767
define Wasserfilter_monitoring monitoring d_Rueckspuelfilter:.*:.short
attr Wasserfilter_monitoring errorReturn {return unless(@errors);;\
return "Der Wasserfilter muss gewechselt werden.";;\
}
attr Wasserfilter_monitoring errorWait 30
attr Wasserfilter_monitoring warningReturn {return unless(@warnings);;\
return "Der Wasserfilter muss demnächst gewechselt werden.";;\
}
attr Wasserfilter_monitoring warningWait 20
define ServiceNotifications_DI DOIF ([12:35-12:38|8]\
&& (   [":^error add:"]\
     || [$SELF:cmd_nr] == 2\
)\
)(\
  set Schokos__Bot 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

evtl. hat ja jemand eine Idee

[igami]

Code bitte in code-tags (# Button über dem Eingabefeld) posten.

Ich sehe aber nichts was den Fehler verursachen sollte. Ist [$SELF:cmd_nr] zu dem Prüfzeitpunkt definiert oder kommt daher vielleicht das ""?

[Schoko]

Wenn ich das manuell definieren muss, ist es das wohl nicht. Ich hab leider auch nicht wirklich verstanden, für was das steht...

[igami]

Wenn ich das manuell definieren muss, ist es das wohl nicht. Ich hab leider auch nicht wirklich verstanden, für was das steht...

Jetzt weiß ich wieder warum mir der code so bekannt vorkommt, war ursprünglich mal von mir und hat auch funktioniert.
Der besagt, dass in dem von dir gewählten Zeitraum eine Nachricht verschickt wird, wenn ein error add auftritt oder außerhalb des Zeitraums aufgetreten ist. Durch die Attribute wird das dann noch zusätzlich entprellt.
Der Code funktioniert soweit. Wenn du dabei weitere Hilfe benötigst bitte im DOIF Unterforum fragen.
Woher deine Fehlermeldung kommt kann ich dir aber nicht beantworten.

[Schoko]

Vielen Dank für Deinen Tipp, dann versuch ich es mal im DOIF Bereich

[UweUwe]

Hallo,
kann ich das Monitoring Modul zur Überwachung von Türenkontakten (CUL-FHTTKs und HM)  verwenden. Ich würde gerne erkennen, wenn der Zustand von Open nach Closed und von Closed nach Open geht. Und das für alle Türen. Da ich das Ergebnis als Sensor für eine Alarmanlage nutzen möchte, brauche ich eine direkte Reaktion.

[igami]

Hallo,
kann ich das Monitoring Modul zur Überwachung von Türenkontakten (CUL-FHTTKs und HM)  verwenden. Ich würde gerne erkennen, wenn der Zustand von Open nach Closed und von Closed nach Open geht. Und das für alle Türen. Da ich das Ergebnis als Sensor für eine Alarmanlage nutzen möchte, brauche ich eine direkte Reaktion.

Dafür ist das monitoring Modul nicht geeignet. Die direkte Reaktion bekommst du doch als Event.

[Thyraz]

Sehr schönes Modul, dass ich bisher noch gar nicht entdeckt hatte.

Nur eine kurze Frage dazu:

Wozu gibt es die Variablen $addMatch und $removeMatch z.B. in errorFuncAdd errorFuncRemove?
Muss ich in errorFuncAdd  z.B. immer überprüfen ob $addMatch 1 ist?
Oder aus welchem Grund könnte errorFuncAdd aufgerufen werden, ohne dass $addMatch 1 ist?

Ich verstehe die CommandRef so, dass errorFuncAdd immer aufgerufen wird wenn ein Gerät in die Error-Liste aufgenommen werden soll.
Außerdem, dass $addMatch immer auf 1 ist wenn ein Gerät in die Error-Liste aufgenommen werden soll.

Klingt irgendwie doppelt gemoppelt, liegt aber sicher eher daran, dass ich irgendwas nicht verstanden habe. 

[Thyraz]

Und ich wiederhole mal einen Wunsch der schon ein paarmal geäußert wurde und an sich auch ganz gut durch äußere DOIFs / Notifies zu lösen ist.
Aber teilweise wäre es eben doch eleganter dies direkt im Modul lösen zu können:

Es geht darum noch einen Handler/Callback zu haben wenn ein Gerät in die Warning/Error Liste aufgenommen wird.

Ich hab dazu auch ein paar Beispiele warum das durchaus Sinn machen kann.
Es geht dabei nicht darum, sich in diesem Handler einfacher Benachrichtigungen zu schicken, da bin ich auf deiner Seite, dass sowas besser extra in einer Logik abgehandelt gehört.

Ich schreibe bisher aber bei mehreren Überwachungen, die ich gern auf dein Modul umschreiben würde, Werte zurück ins betroffene Gerät.
Man muss sich das dann etwa wie beim Statistics Modul vorstellen.
Mein bisheriges Monitoring liest und überwacht Readings/Events aus einem Gerät und schreibt dann Resultate wieder als Readings ins Gerät zurück um die Infos für das Gerät alle an einem Fleck zu haben.

Z.B. schreibe ich aktuell bei meiner Fensterüberwachung in jedes Fensterkontakt-Device ein Reading "warnLevel" zurück.
Der ist 0 wenn das Fenster zu bzw. erst kurz geöffnet ist, 1 wenn das Fenster langsam mal wieder zugemacht werden könnte (entspricht "warning" aus deinem Modul) und 2 wenn es höchste Eisenbahn wird (wäre dann "error").

Dies ist zum Beispiel hilfreich für die Visualisierung. Ist der warnLevel 1 oder 2 kann ich das Fenster-Icon in der UI sehr einfach in einer anderen Farbe oder mit einem anderen Icon darstellen.
Bei der aktuellen Umsetzung im Modul müsste ich dazu (sofern ich das bis jetzt verstanden habe) das warning und error Reading des monitoring devices parsen um zu sehen, ob der aktuelle Kontakt auf der Liste ist.

Man könnte das z.B. angelehnt an die *FuncAdd Funktionen dann *FuncAdded nennen.

Dann könnte man das z.B. so lösen:

Code Auswählen Erweitern


define WindowMonitoring monitoring .*:open .*:closed


Attribut warningFuncAdded:

Code Auswählen Erweitern


{ fhem("setreading $name warnLevel 1"); }


Attribut errorFuncAdded:

Code Auswählen Erweitern


{ fhem("setreading $name warnLevel 2"); }


Attribut warningFuncRemove:

Code Auswählen Erweitern


{
  fhem("setreading $name warnLevel 0");
  return 1;
}


Attribut errorFuncRemove:

Code Auswählen Erweitern


{
  fhem("setreading $name warnLevel 0");
  return 1;
}


[KernSani]

Im Prinzip stehen die Infos die du brauchst doch im state. Da sollte es jeweils ein einzelnes Event pro Gerät geben.


Kurz, weil mobil