Übersicht (Zusammenfassung) zur Geräteüberwachung

Begonnen von KernSani, 09 Februar 2019, 15:45:56

Vorheriges Thema - Nächstes Thema

KernSani

Liebe Gemeinde,

Problemstellung: Ich überwache verschiedenen Geräte auf verschiedene Weise (z.B.: Die berühmte Batterieüberwachung mittels readingsGroup, oder einzelene Services mittels 98_serviced). Meistens resultieren diese Überwachungen in einer Liste von Einzelüberwachungen. I.d.R will ich aber nicht jedee einzelne Batterie sehen, sondern nur wissen, ob alles ok ist. Könnte man sicher auch anders lösen, aber weil ich gerade nix andres zu tun hatte habe ich mir ein rudimentäres Modul gestrickt, das folgendes macht:

* über eine devspec werden die zu überwachenden Devices definiert
* Für jedes dieser Devices überprüft das Modul, ob ein bestimmtes reading (default: state) einen definierten Wert (default:ok) hat.
* Wenn die Überprüfung für alle Devices erfolgreich ist, ist alles gut und Status ist "good"
* Ansonsten ist Status "bad"
* Das Ganze wird mit rotem oder grünem Icon und Anzahl der "bad" Devices (von total Devices) ausgegeben
* Optional kann ein Link zur Detailseite (also z.B. der Battery-Readingsgroup) mitgegeben werden, der  bei Click auf das Icon aufgerufen wird.

EDIT: Habe mir nach igamis Kommentar nochmal Gedanken gemacht und bin zu dem Schluss gekommen, dass ich wahrscheinlich tatsächlich ein Rad neu erfinde... Habe meine gewünschte Darstellung mit etwas Gefummel auch im Monitoring Modul abbilden können. Stelle ich auf Wunsch gerne zur Verfügung.
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KernSani

Ich habe noch ein bisschen daran rumgeschraubt, Doku geschrieben (Commandref) und dem Teil ein "getDetails" Kommanda spendiert, mit dem sich die überwachten Devices mit ihrem Status anzeigen lassen
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

igami

Bevor wir nun ein weiteres Modul zur Überwachung von Geräten einführen: monitoring macht etwas ähnliches auf Basis von Events
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

Hi igami,
Ich nutze monitoring ebenfalls. Das ist sehr viel màchtiger.
Dieses Teil habe ich mir eigentlich zusammen gestrickt um überwachende Devices (wie z.B. Alle serviced Devices) in eine Übersicht zu bekommen.Häte man wahrscheinlich auch mit einer readingsGroup lösen kônnen... hatte aber eh schon die meiste Logik in diversen myUtils.
Das Teil ist bewusst ein Codeschnippsel. Ich habe nicht vor, das großartig weiter zu entwickeln.
Schönen Sonntag:-)




Kurz, weil mobil
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

curt

Die Aufgabenstellung des Ursprungsbeitrags löst "ReadingsSupervision" hervorragend: Nur selten war ich mit einem Modul so glücklich wie mit diesem. - Dies geschrieben, da nachfolgende Leser auch suchen.

Siehe
https://forum.fhem.de/index.php/topic,49408.0.html
RPI 4 - Jeelink HomeMatic Z-Wave

Wzut

@curt, freut mich zwar das du das Modul so magst :) aber hier ist der Ansatz ein anderer.
RS ist für Readings/Geräte die sich über einen Zeitraum X nicht mehr gemeldet haben , z.B. kein Wert mehr vom Temp Sensor,
hier wird aber geprüft ob das Gerät etwas sendet was man eigentlich nicht möchtet, wie z.B Bat low statt Bat ok.
Du kannst aber zweistufig arbeiten, erste Warnmeldung wenn Bat low statt ok ist und zweite Meldung wenn das Ding wirklich tot ist und nicht mal mehr low aktualisieren kann.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Jamo

Hallo KernSani,
würdest Du dein Lösung mittels monitoring hier zur Verfügung stellen?
Ich bin da auch sehr dran interessiert . . .
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

KernSani

Zitat von: inoma am 04 März 2019, 17:20:14
Hallo KernSani,
würdest Du dein Lösung mittels monitoring hier zur Verfügung stellen?
Ich bin da auch sehr dran interessiert . . .

Aber gerne... Ich gehe mal davon aus, dass du die Überwachung mit dem Monitoring Modul bereits hast... Dann erstmal ein sub in den myUtils, die mir das Icon usw... zusammenbastelt, mittlerweile ist devStateIcon etwas mächtger geworden, daher wäre es vielleicht einfacher lösbar, habe ich mir aber bisher keine Gedanken gemacht:

sub myUtilsMonitoringIcon($) {
    my ($name) = @_;
my $icon = "";
my $allCt = ReadingsNum($name,"allCount",0);
my $iconList = AttrVal( $name, "ks_icons", "" );
    my ( $iconRed, $iconYellow,$iconGreen ) = split( ",", $iconList );

$icon = "$iconGreen\@green" if ($allCt == 0);
$icon = "$iconYellow\@yellow" if (ReadingsNum($name,"warningCount",0) > 0);
$icon = "$iconRed\@red" if (ReadingsNum($name,"errorCount",0) > 0);
my $img = FW_makeImage( $icon, "");
my $target =AttrVal($name,"ks_target","detail=$name");
my $info = FW_makeImage( "rc_INFO2", "");
my $infoBtn = "<a class= 'pointer' onClick='FW_cmd(FW_root+\"?cmd.$name=get $name all&XHR=1\",function(data){FW_okDialog(data)})'\>$info</a>";
my $text =       
"<a href='fhem?$target'>"
. $img . "&nbsp;&nbsp;&nbsp; "
. ReadingsVal( $name, "errorCount",   0 ) . "/". ReadingsVal( $name, "warningCount", 0 ) . "</a></td><td>";

$text.= "&nbsp;&nbsp;&nbsp; " .$infoBtn if ($allCt > 0);
;
return "<div>" . $text . "</div>";

}


die sub wird im devStateIcon genutzt:

attr SYS_IO_Monitoring devStateIcon {myUtilsMonitoringIcon($name)}

Um das Ganze flexibel zu machen ein paar user-Attribute:

attr SYS_IO_Monitoring userattr ks_icons ks_target ks_reading

die natürlich gepflegt werden:

attr SYS_IO_Monitoring ks_icons cul_usb,cul_usb,cul_usb
attr SYS_IO_Monitoring ks_reading ioStatus
attr SYS_IO_Monitoring ks_target room=IODevices

ks_icons sind die Icons für Fehler,Warnung,OK in devStateIcon genutzt werden
ks_target ist das Ziel, das bei Click auf das Icon aufgerufen wird
ks_reading ist das reading das beim Click auf den Info-Button ausgewertet wird (siehe die nächsten beiden Attribute)

Formatierung der Rückgabe von "get error/warning":

attr SYS_IO_Monitoring warningReturn {return unless(@warnings);;\
@warnings= sort {lc($a) cmp lc($b)} @warnings;;\
my $ret = "<html><h3>Warnings</h3>";;\
$ret .= "<table><tr><td><b>Device</b></td><td><b>Reading</b></td>";;\
for my $p (@warnings) {\
            $ret .= "<tr><td>".AttrVal($p,"alias",$p)."</td><td>" .ReadingsVal($p,AttrVal($SELF,"ks_reading","N/A"),""). "</td></tr>";;\
        }\
$ret .= "</table></html>";;\
return $ret;;\
}\

und

attr SYS_IO_Monitoring errorReturn {return unless(@errors);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
my $ret = "<html><h3>Errors</h3>";;\
$ret .= "<table><tr><td><b>Device</b></td><td><b>Reading</b></td>";;\
for my $p (@errors) {\
            $ret .= "<tr><td>".AttrVal($p,"alias",$p)."</td><td>" .ReadingsVal($p,AttrVal($SELF,"ks_reading","N/A"),""). "</td></tr>";;\
        }\
$ret .= "</table></html>";;\
return $ret;;\
}\


Kann natürlich nach belieben angepasst werden...
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...