Modul 98_monitoring zur Überwachung von Geräten

[jkriegl]

Danke, ging pfeilschnell und klappt wunderbar.

[Muk.s]

Hallo igami,
Zuerst mal Danke für das vielseitige und flexible Modul.
Spart mir jede Menge notify's .
Könntest Du bei Gelegenheit evtl. noch ein ,,setInactiveFunc" Attribut einbauen?

Danke

[igami]

Könntest Du bei Gelegenheit evtl. noch ein ,,setInactiveFunc" Attribut einbauen?

Neue Version im Anhang, bitte testen. Wird bei "set inactive", "attr disable 1" und "delete" ausgeführt.

[Muk.s]

Das war fix 
Teste es die Tage und melde mich

[Muk.s]

Kurze Rückmeldung:
Bei "set xxx Inactive" funktioniert das neue Attribut, bei "attr disable 1" leider nicht. Außerdem reagiert das modul nicht richtig auf "attr disable 0", der state bleibt auf "disabled" selbst wenn ich das Attribut lösche. "Delete" habe ich noch nicht getestet

[igami]

Schaue ich mir nächst Woche noch mal an.

[Muk.s]

Glaube der Fehler liegt hier:

Code Auswählen Erweitern

elsif($attribute eq "disable"){
    if($cmd eq "set" and $value == 1){
      monitoring_setActive($hash);
    }
    else{
      monitoring_setInactive($hash);
      readingsSingleUpdate($hash, "state", "disabled", 0);
      Log3($SELF, 3, "$hash->{TYPE} ($SELF) attr $SELF disabled");
    }
  }

Hiermit funktioniert's:

Code Auswählen Erweitern

elsif($attribute eq "disable"){
    if($cmd eq "set" and $value == 0){
      monitoring_setActive($hash);
    }
    else{
      monitoring_setInactive($hash);
      readingsSingleUpdate($hash, "state", "disabled", 1);
      Log3($SELF, 3, "$hash->{TYPE} ($SELF) attr $SELF disabled");
    }
  }

Ein kleines Problem gibt es noch: Wenn ,,disable" 1 ist und gelöscht wird, bleibt state trotzdem  auf disabled.

[Peter aus Calw]

Hallo igami,
habe Dein Modul in meinem FHEM eingerichtet (erste Tests erfolgreich) und möchte eine entsprechende Errormeldung an meine Emailadresse senden.
mit dieser (DOIF) DEF möchte ich das versuchen :

Code Auswählen Erweitern

([16:30-21:00|8]&&[":^error add:"]|[$SELF:cmd_nr] == 2)
(set TelegramBot message ({DebianMail('hp.abele@t-online.de','Monitoring Nachricht')}))
DOELSEIF ([":^error add:"])

bin aber nicht sicher ob dann die entsprechenden Gerätenahmen in das Email geschrieben werden ?
Würdest Du einen Oldie unterstützen ?
LG Peter

[igami]

Würdest Du einen Oldie unterstützen ?

Selbstverständlich! Aber nur in der Form Hilfe zur Selbsthilfe

Erstmal was generelles: and wird vor or ausgewertet, ist wie Punkt vor Strich beim Rechnen. Ich vermute, dass du die Emails nicht in dem beabsichtigten Zeitraum bekommst.

Ich benutze selbst keinen E-Mail versand mehr in Telegram, aber ich kann nicht erkennen an welcher Stelle die Fehlermeldungen übergeben werden.
Die bekommst du z.B. mit "get TYPE=monitoring error"

[Cyber1000]

Hi,

Tolles Modul bin durch einen Hinweis hiergelandet (weil ich einen Aktivitätsmonitor bei mir aktivieren/selbst schreiben wollte) und hab das Modul ohne gröbere Schwierigkeiten zum Laufen gebracht für Batterie und Aktivität (gut letzteres muss ich noch ein wenig testen ...)

Frage:
- Gibt es eine einfache Möglichkeit in einer ReadingsGroup die Batterien bzw. Aktivitäten darzustellen mit (ok, warning, error) in Zusammenarbeit mit dem Monitoring-Modul.
- Vielleicht hab ich auch etwas überlesen (zugegeben ich hab nicht alle 16 Seiten dieses Threads verfolgt und es ist heute schon etwas später )
- Mit ReadingsGroup fühl ich mich noch nicht 100%ig sicher

Danke!

[raiderxxl]

Ich hab das so:

Code Auswählen Erweitern

defmod rg_battery readingsGroup .*:battery
attr rg_battery DbLogExclude .*
attr rg_battery alias Batteriestatus
attr rg_battery group Batteriestatus
attr rg_battery mapping %ALIAS
attr rg_battery noheading 1
attr rg_battery notime 1
attr rg_battery room FHEM->Systemstatus
attr rg_battery sortDevices 1
attr rg_battery valueIcon {'battery.ok' => 'measure_battery_100@green', 'battery.low' => 'measure_battery_0@red'}


Grüßle

Pascal

[igami]

Tolles Modul bin durch einen Hinweis hiergelandet (weil ich einen Aktivitätsmonitor bei mir aktivieren/selbst schreiben wollte) und hab das Modul ohne gröbere Schwierigkeiten zum Laufen gebracht für Batterie und Aktivität (gut letzteres muss ich noch ein wenig testen ...)

letzteres ist auch gar nicht so leicht, bitte teilen, wenn du eine brauchbare Lösung hast

Frage:
- Gibt es eine einfache Möglichkeit in einer ReadingsGroup die Batterien bzw. Aktivitäten darzustellen mit (ok, warning, error) in Zusammenarbeit mit dem Monitoring-Modul.
- Vielleicht hab ich auch etwas überlesen (zugegeben ich hab nicht alle 16 Seiten dieses Threads verfolgt und es ist heute schon etwas später )
- Mit ReadingsGroup fühl ich mich noch nicht 100%ig sicher

Das ist eher eine readingsGroup Frage wie sich Kommagetrennte Listen hübsch darstellen lassen. Ich kann dir da nicht weiter helfen da ich kein readingsGroup nutze.

[ToM_ToM]

Gibt es eine einfache Möglichkeit in einer ReadingsGroup die Batterien bzw. Aktivitäten darzustellen mit (ok, warning, error) in Zusammenarbeit mit dem Monitoring-Modul.

Hi Cyber1000,

hier mal wie ich das gelöst habe. Vielleicht hilft dir das.

Code Auswählen Erweitern


defmod Batterieuebersicht readingsGroup <Device>,<Batteriestatus>,<Batterielevel>,<Activity> .*:battery,batteryLevel,Activity\

attr Batterieuebersicht DbLogExclude .*
attr Batterieuebersicht mapping %ALIAS %ROOM
attr Batterieuebersicht room Allgemein
attr Batterieuebersicht valueColumn { battery => 1,batteryLevel => 2, Activity => 3 }
attr Batterieuebersicht valueFormat { if (defined $VALUE) {return $VALUE;;;;} else { return 'none';;;;} }
attr Batterieuebersicht valueIcon {'battery.ok' => 'batterie@green', 'battery.low' => 'batterie@red'}


[Cyber1000]

Hi,

Danke für eure Antworten, muss ich wohl am Wochenende noch ein wenig testen und herumspielen mit den readingsgroups.

Zum Modul selbst:
- Da kann man wirklich viel damit machen, hab mir jetzt auch noch eine Temperaturüberwachung darauf aufgebaut (Einzelne Temperatursensoren haben Ober- und Untergrenze als userattr definiert, das Modul setzt dann einen error bei Verlassen des Bereichs)
- Die Aktivitäten hab ich schon mal so halb getestet, aber ich muss das nochmal nur mit Dummy-Geräten und kürzerer Zeit testen. Irgendwie kams mir so vor, als ob die Meldungen nicht nach 12/24h da sind, sondern verzögert, einmal kamen sie erst nach einem Neustart von fhem. Muss allerdings sagen ich hatte eine 1 Jahr alte Installation von fhem drauf, die ich erst jetzt upgedatet hab. Ansonsten halt einige Sachen blacklisten müssen, notifies die ich abgespeichert hab und dann eben nach 12 Stunden nicht wieder geändert hab, wollten sich auch wieder melden.
- Wenn ich was brauchbares stabiles hab stell ichs gern unter Codeschnipsel oder ins wiki.
- Ein simples notify oder DOIF als Beispiel für den Nachrichtenversand wär ganz nett in der commandref direkt beim Modul oder im Wiki gewesen. Das hab ich hier ein wenig vermisst (und wie gesagt alle 16 Seiten hab ich mir nicht durchgelesen).

Ansonsten tolles Modul!

[igami]

- Ein simples notify oder DOIF als Beispiel für den Nachrichtenversand wär ganz nett in der commandref direkt beim Modul oder im Wiki gewesen. Das hab ich hier ein wenig vermisst (und wie gesagt alle 16 Seiten hab ich mir nicht durchgelesen).

Ich behaupte, dass es das simple notify/DOIF nicht gitb. Das fängt schon bei der Art der Übermittlung an: msg Befehl, TelegramBot, Jabber, Whatsapp, E-Mail, Pushbullet, MQTT, ... . Weiterhin sollten Benachrichtigungen auch intelligent sein (z.B. Interessiert mich ein Batteriewechsel mitten in der Nacht nicht). Daher habe ich mich in der Commandref auf diese Passage festgelegt:

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.

Beim msgDialog Modul wird der wiki Artikel von der Community geschrieben und ich lese den dan bei größeren Änderungen quer. Das können wir für monitoring auch gerne so machen