Störmeldeliste erstellen

[bismosa]

Hallo!

ich brauche da mal einen Tipp...
Ich möchte eine art "Störmeldeliste" haben um mir im Fehlerfall eines Gerätes im FTUI sowohl einen Hinweis als auch eine Liste mit den Störungen anzeigen lassen zu können.
Dabei möchte ich nach Möglcihkeit unterscheiden zwischen Störung/Warnung.

Beispiele:
Warnung: Fenstersensor abgefallen, NAS Festplatte 75% voll, Zyklusprüfung der Wassermelder etc.
Fehler: Heizungsausfall, Wassermelder, Überwachungskamera ausgefallen, etc.

Alle GEräte melden mir dies sowohl als Mail als auch als Pushover.

Bisher habe ich ein KindleDisplay. Dies fragt alle 2 Min. (über ein Script in myUtils) alle Devices ab und bringt mit ggf. die Fehlerliste auf den Bildschirm.

Meine Ansätze wären jetzt:
1.) DOIF - Sobald eine Bedingung in den Devices vorliegt, alle anderen Bedingungen prüfen und eine Liste in ein Dummy schreiben. Hier müsste ich relativ flexibel sein..
2.) Für jeden Warnungs/Fehlerfall ein Dummy erstellen. Entweder mit Structure oder DOIF auf die entsprechenden Dummys reagieren und eine Liste ausgeben

Wie sind eure Ansätze dafür? Gibt es da vielleicht schon etwas, was ich nicht gefunden habe?

Gruß
Bismsoa

[Gisbert]

Hallo bismosa,

kannst du deine Lösung (Script in myUtils, Definitionen etc.) hier veröffentlichen?
Ich bin daran interssiert, da ich meine halbgare Lösung nicht besonders gelungen finde, aber was besseres hab ich nicht hingekriegt.
Die Suche im Forum oder in Google hat mich nicht weitergebracht.

Ich möchte, wie du, gerne mitbekommen, wenn eines meiner diversen Geräte aussteigt und keine Daten mehr an die Zentrale sendet.
Das Problem ist, dass bei einer Störung keine Readings geschrieben werden, und damit auch keine Events erzeugt werden, auf die man triggern könnte.
Ein weiteres Problem ist, das die verschiedenen Geräte sehr unterschiedlich update-Zyklen haben, so dass man für jedes Gerät im Grunde eine separate Abfrage braucht.

Als Kompromiss frage ich dann alle Devices in einem DOIF in festgelegten Zeitabständen ab, wobei nur die Lösung [+:mm] einfällt, damit wird jede Stunde bei mm-Minuten gefragt, also bei [+:02] jeweils 2 Minuten nach einer vollen Stunde. Ich vergleiche dann wie alt die Readings sind, und gebe dann eine Meldung raus oder reboote ein Gerät.

Wie gesagt, es gefällt mir nicht wirklich, und ich wäre an einer besseren Lösung interessiert:

Code Auswählen Erweitern

define SensorAktualitaet \
DOIF ([+:02] and [{sunrise_abs(1130)} - {sunset_abs(-600)}] and ReadingsAge("WH3080","Zeitstempel_Lux.Av","") > 1200 \
((set Pushover.Nachricht msg 'Sensor außer Betrieb' 'WH3080 Licht:\n[WH3080:Zeitstempel_Lux.Av]')) \
DOELSEIF ([+:32] and ReadingsAge("Temp.OG","Zeitstempel","") > 180) \
("wget -qO /dev/null http://192.168.2.9/?cmd=Reboot") \
((set Pushover.Nachricht msg 'Sensor außer Betrieb' 'Temp.OG:\n[Temp.OG:Zeitstempel]\nReboot NodeMCU!')) \
DOELSEIF ([+:33] and ReadingsAge("Wassermelder","Zeitstempel","") > 86400) \
((set Pushover.Nachricht msg 'Sensor außer Betrieb' 'Wassermelder:\nDer Sensor ist möglicherweise offline !')) \
DOELSEIF ([+:34] and ReadingsAge("Garagentor.Kontakt","Zeitstempel","") > 3600) \
((set Pushover.Nachricht msg 'Sensor außer Betrieb' 'Garagentor Kontakt:\nDer Sensor ist möglicherweise offline !')) \
DOELSEIF ([+:05] \
and ReadingsAge("WH3080","Zeitstempel_Lux.Av","") <= 1200 \
and ReadingsAge("Temp.OG","Zeitstempel","") <= 180 \
and ReadingsAge("Wassermelder","Zeitstempel","") <= 86400 \
and ReadingsAge("Garagentor.Kontakt","Zeitstempel","") <= 3600) \

Wenn ich auf alle Devices mit der gleichen Zeit triggere, dann sehe ich maximal ein Device, was ausgefallen ist, das nachfolgende kommt dann nicht mehr zum Zug.

Um es nochmals etwas generelles zu beschreiben:
ich möchte regelmäßig, in kurzen Abständen von sagen wir 10 Minuten, abfragen, ob meine Geräte noch online sind, und die Readings damit aktuell sind.

Viele Grüße Gisbert

[bismosa]

Hallo,

ich habe mir jetzt den ganzen Tag Gedanken dazu gemacht...richtig "glücklich" bin ich mit meiner Lösung nicht....
Bisher habe ich nur mein KindleDisplay. Dies fragt bei FHEM nach einer aktuellen SVG. Bevor diese dann generiert wird, lasse ich einfach nur ein Script in den myUtils laufen ala:

Code Auswählen Erweitern


#Fenster -> Sensor ab
my @fenster = devspec2array("NAME=Fenster_.*:FILTER=state=dimup");
foreach my $fenst (@fenster) {
my $fenstName=AttrVal($fenst, "TTSName","$fenst"); #Namen des Devices
push @Warningliste, "$fenstName Sensor ab!";
$warningcount+=1;
}

Oder bei den Wassermeldern, die nur eien Fehler senden sich aber nie zurücksetzen:

Code Auswählen Erweitern


#Wassermeldeer -> Wenn LastState zu Alt -> Nicht melden!!
my @Wassermelder = devspec2array("NAME=Wassermelder_.*:FILTER=state=Alarm");
foreach my $Wassermeld (@Wassermelder) {
#Wenn Reading aelter als 30Min nicht anzeigen!
if (time-time_str2num(ReadingsTimestamp("$Wassermeld","state",0)) < 60*30){
if ($Wassermeld eq "Wassermelder_Heizung"){
push @Warningliste, "$Wassermeld bitte Eimer leeren!";
$warningcount+=1;
}else{
push @Warningliste, "$Wassermeld Ueberschwemmung!!";
$errorcount+=1;
}
}
}

Normale Dummies

Code Auswählen Erweitern


#Heizung ausfall
if (ReadingsVal("HeizungsStoerung" , "state","off") eq "on"){
push @Warningliste, "Heizung ausgefallen!!";
$errorcount+=1;
}

Und die Raspberry-Überwachung:

Code Auswählen Erweitern


#Raspberry Ueberwachung
if (ReadingsVal("rpi_status", "cam_SD1_free","0")<=500000){
push @Warningliste, "cam_SD1 Speicherplatz!";
$warningcount+=1;
}

Also so nichts spannendes.

Ich habe nur wenige Geräte, die ich laufend überwache...aber z.B. bei den Wassermeldern wird mit einem at um 18Uhr geprüft, ob die letzten 2 Wochen etwas gesendet wurde...sonst wird mir eine Push-Nachricht geschickt, dass ich das mal wieder tun sollte...

Bei meiner Überwachungskamera + Openelec Raspberry führe ich mit einem Bash-Script ein Ping aus. Wenn nicht erreichbar, wird mir das in einem Dummy angezeigt...und ich bekomme gleich eine Meldung.
Das Bash Script hat noch ein paar mehr Aufgaben:

Code Auswählen Erweitern


#!/bin/bash
fhem="http://server:8083"
time1Temp=0
time2Temp=0
time3Temp=0
timeSpeicher=0
CamOnline=2
OpenelecOnline=2
JaroliftOnline=2
while true; do
fhemDevice="rpi_status"

#Temperaturen
#Nur melden, wenn zu warm!
#Sonst alle 15Min melden
temp1=`cat /sys/devices/virtual/thermal/thermal_zone0/temp`
if [ "$temp1" -gt 50000 ] || [ $(( $(date +%s) - $time1Temp )) -gt 900 ] ; then
echo "Melde temp! $temp1"
time1Temp=$(date +%s)
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20server_temp%20${temp1// /%20} &> /dev/null &
fi

#Speicherplatz
#Alle 15Min melden
if [ $(( $(date +%s) - $timeSpeicher )) -gt 900 ] ; then
echo "Melde Speicher"
timeSpeicher=$(date +%s)
#Server
#Memory
serverMemTotal=`free | grep Mem | awk '{print $2}'`
serverMemUsed=`free | grep Mem | awk '{print $3}'`
serverMemFree=`free | grep Mem | awk '{print $4}'`   
echo "wget -qO $fhem/fhem?cmd=setreading%20$fhemDevice%20server_mem_total%20${serverMemTotal// /%20} &> /dev/null &"
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20server_mem_total%20${serverMemTotal// /%20} &> /dev/null &
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20server_mem_used%20${serverMemUsed// /%20} &> /dev/null &
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20server_mem_free%20${serverMemFree// /%20} &> /dev/null &
#SD
serverSD1Total=`df / | tail -1 | awk '{print $2}'`
serverSD1Used=`df / | tail -1 | awk '{print $3}'`
serverSD1Free=`df / | tail -1 | awk '{print $4}'`
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20server_SD1_total%20${serverSD1Total// /%20} &> /dev/null &
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20server_SD1_used%20${serverSD1Used// /%20} &> /dev/null &
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20server_SD1_free%20${serverSD1Free// /%20} &> /dev/null &
#HDD
serverHDDTotal=`df /media/HDD1 | tail -1 | awk '{print $2}'`
serverHDDUsed=`df /media/HDD1 | tail -1 | awk '{print $3}'`
serverHDDFree=`df /media/HDD1 | tail -1 | awk '{print $4}'`
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20server_HDD_total%20${serverHDDTotal// /%20} &> /dev/null &
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20server_HDD_used%20${serverHDDUsed// /%20} &> /dev/null &
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20server_HDD_free%20${serverHDDFree// /%20} &> /dev/null &
#HDD2
serverHDD2Total=`df /media/HDD2 | tail -1 | awk '{print $2}'`
serverHDD2Used=`df /media/HDD2 | tail -1 | awk '{print $3}'`
serverHDD2Free=`df /media/HDD2 | tail -1 | awk '{print $4}'`
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20server_HDD2_total%20${serverHDD2Total// /%20} &> /dev/null &
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20server_HDD2_used%20${serverHDD2Used// /%20} &> /dev/null &
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20server_HDD2_free%20${serverHDD2Free// /%20} &> /dev/null &
fi

#Erreichbarkeit
#CAM
ping -c 3 cam > /dev/null 2>&1
if [ $? -ne 0 ] ; then
#echo "cam nicht erreichbar"
if [ $CamOnline != 0 ] ; then
echo "Melde Cam nicht erreichbar"
CamOnline=0
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20cam_online%200 &> /dev/null &
fi
else
#echo "cam erreichbar"
if [ $CamOnline != 1 ] ; then
echo "Melde Cam erreichbar"
CamOnline=1
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20cam_online%201 &> /dev/null &
fi
fi
#Openelec
ping -c 3 openelec > /dev/null 2>&1
if [ $? -ne 0 ] ; then
#echo "Openelec nicht erreichbar"
if [ $OpenelecOnline != 0 ] ; then
echo "Melde Openelec nicht erreichbar"
OpenelecOnline=0
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20openelec_online%200 &> /dev/null &
fi
else
#echo "Openelec erreichbar"
if [ $OpenelecOnline != 1 ] ; then
echo "Melde Openelec erreichbar"
OpenelecOnline=1
wget -qO/dev/null $fhem/fhem?cmd=setreading%20$fhemDevice%20openelec_online%201 &> /dev/null &
fi
fi
#Nur alle 3 Sekunden ausführen!
sleep 3
done


Das wird einfadch automatisch von der rc.local gestartet

Code Auswählen Erweitern


#FHEM Raspberry Status
sudo /root/RPiInfoFHEM.sh >/dev/null 2>&1 &

Bestimmt nicht optimal...aber es hat so nichts direkt mit FHEM zu tun und macht nun seit vielen Monaten problemlos seinen Dienst. Eine Prozessorlast konnte ich noch nicht beobachten.
Vermutlich wäre das auch besser direkt als cron...dann kann es nicht "abstürzen"...aber das hatte ich noch nicht.

Nun ist aber die "NEUE" Lösung dran. Nach langem Grübeln bin ich der Meinung...so schlecht ist der "manuelle" Weg wohl gar nicht. Es hat ja funktioniert...und jedes Gerät hat nunmal seine Eigenschaften und bessonderheiten...das bekommt man nicht so einfach unter einen Hut.
Daher habe ich jetzt angefangen mit einem DOIF (nur zur Triggerung...der Code ist so viel...das habe ich gleich in den myUtils gemacht) gleich eine HTML-Tabelle zu erstellen. Diese lässt sich dann als Label in FTUI einbinden (sogar inkl. Buttons und Symbolen, Farben etc. Dann braucht man keine "Logik" mehr im FTUI.
Als Beispiel wie ich die Umsetzung meine hier mal meine Tabelle Fenster-Batterie-Liste:

Code Auswählen Erweitern


sub HTML_Fenster_Liste($$){
my $SelfDevice=shift;
my $Max=shift;

    my %hash;

    ##Alle einlesen
    my @Devices=devspec2array("NAME=.*:FILTER=battery=low");
    foreach my $Device (@Devices){
        $hash{$Device}{"Age"}=ReadingsAge("$Device", "battery", 0);
    }
   
    ##Sortieren
    my $htmlKurz='<div align="left"><table><tbody>';
    my $html='<div align="left"><table><tbody>';
    my $i=0;
   
        for (sort { $hash{$a}->{Age} <=>  $hash{$b}->{Age} } keys %hash){
        my $Age=$hash{$_}{"Age"};
        my $Text=Sekunden2TextKurz($Age);
       
        ##Farbe beachten!
        ##0 900 3600
        my $color="";
        ##Log 1, "Alter $Age";
        if ($Age > 3600){
            $color="#FF0000";
        } elsif ($Age > 900){
            $color="yellow";
        } else {
            $color="green";
        }
        ##Log 1, "Color: $color";
        ##Kein Symbol:
        $html.="<tr><td></td>";
        $html.='<td><div style="color:'.$color.'">'.$_.'</div></td>';
        $html.='<td><div style="color:'.$color.'">'.$Text.'</div></td>';
        $html.="</tr>";
       
        if ($i < $Max){
            ##Log 1, "Anzahl $i $Max";
            $htmlKurz.="<tr><td></td>";
            $htmlKurz.='<td><div style="color:'.$color.'">'.$_.'</div></td>';
            $htmlKurz.='<td><div style="color:'.$color.'">'.$Text.'</div></td>';
            $htmlKurz.="</tr>";
        }
        $i=$i+1;
    }
if (ReadingsVal("$SelfDevice","Anzahl", "$i") ne $i){
fhem("sleep 1; setreading $SelfDevice Anzahl $i");
}
   
   
    $html.="</tbody></table></div>";
    $htmlKurz.="</tbody></table></div>";
if (ReadingsVal("$SelfDevice","HTML", "$html") ne $html){
fhem("setreading $SelfDevice HTML $html");
}
if (ReadingsVal("$SelfDevice","HTMLKURZ", "$htmlKurz") ne $htmlKurz){
fhem("setreading $SelfDevice HTMLKURZ $htmlKurz");
}
}


Also wird HTML-Code erzeugt, in ein Reading geschmissen und dieses dann in FTUI mit einem Label ausgelesen.
Bei der "Störmeldeliste" bin ich noch nicht sehr weit:

Code Auswählen Erweitern


sub MeldeListeGet($){
    my $SelfDevice=shift;
    my %hashWarnings;
    my %hashErrors;
    my $FensterWarnungenCount=0;
    my @Errors;
    my $ErrorCount=0;
    my @Warnings;
    my $WarningCount=0;
    ######################################################################
    ##Fenstersensoren
   my @DevicesFensterKaputt=devspec2array("NAME=Fenster_.*:FILTER=STATE=Kaputt");
    foreach my $Device (@DevicesFensterKaputt){
        $ErrorCount+=1;
        $FensterWarnungenCount+=1;
        $hashErrors{$Device}{"Error"}="$Device abgefallen";
        $hashErrors{$Device}{"Confirm"}="";
        $hashErrors{$Device}{"Symbol"}="oa-message_attention";
    }
    ##Batterie leer
    my @DevicesFensterBatt=devspec2array("NAME=Fenster_.*:FILTER=battery!=ok");
    foreach my $Device (@DevicesFensterBatt){
        $ErrorCount+=1;
        $hashErrors{$Device."__Batt"}{"Error"}="$Device Batterie leer";
        $hashErrors{$Device."__Batt"}{"Confirm"}="";
        $hashErrors{$Device."__Batt"}{"Symbol"}="oa-measure_battery_0  fa-rotate-90";
    }
    ##Batterie reading zu alt
    if (ReadingsVal("chkBattFenster","Anzahl",0) > 5){
        $WarningCount+=1;
        my $chkBattFensterCount=ReadingsVal("chkBattFenster","Anzahl",0);
        $hashWarnings{"chkBattFenster"."__BattAlt"}{"Error"}="$chkBattFensterCount Fenster zu prüfen!";
        $hashWarnings{"chkBattFenster"."__BattAlt"}{"Confirm"}="";
        $hashWarnings{"chkBattFenster"."__BattAlt"}{"Symbol"}="mi-battery_unknown";
    } else {
        my @DevicesFensterBattOld=split /,/, ReadingsVal("chkBattFenster","Devices","");
        foreach my $Device (@DevicesFensterBattOld){
            $WarningCount+=1;
            $hashWarnings{$Device."__BattAlt"}{"Error"}="$Device testen!";
            $hashWarnings{$Device."__BattAlt"}{"Confirm"}="";
            $hashWarnings{$Device."__BattAlt"}{"Symbol"}="mi-battery_unknown";
        }
    }

    ##HTML ausgabe
    my $html='<div align="left"><table><tbody>';
    ##Erst Störmeldungen
    $html.=MeldeListeGetHTML(\%hashErrors, "#FF0000");
    $html.=MeldeListeGetHTML(\%hashWarnings, "yellow");
   
   
    $html.="</tbody></table></div>";
    fhem("sleep 1; setreading $SelfDevice HTML $html");
    fhem("setreading $SelfDevice WarningCount $WarningCount");
    fhem("setreading $SelfDevice ErrorCount $ErrorCount");
    return $html;
}

sub MeldeListeGetHTML($$){
    my %hashErrors=%{shift()};
    my $Farbe=shift;
    my $html="";
    foreach my $DeviceName (keys %hashErrors){
        my $Device=$DeviceName;
        $Device =~ s/__Batt$//;
        $Device =~ s/__BattAlt$//;
   
        ##Symbol
        $html.="<tr><td> <div class=\"tiny compressed\" data-type=\"symbol\" data-icon=\"";
        my $Symbol=$hashErrors{$DeviceName}{"Symbol"};
        $html.=$Symbol;
        $html.="\" data-on-color=\"$Farbe\" data-off-color=\"$Farbe\"></div></td>";
       
        ##Text
        my $Errortext=$hashErrors{$DeviceName}{"Error"};
        $html.="<td><div style=\"color:$Farbe\">".$Errortext."</div></td>";
       
        ##ggf. Button zum Zurücksetzen
        if ($hashErrors{$DeviceName}{"Confirm"} eq ""){
            $html.="<td></td>";
        } else {
            $html.="<td><div data-type=\"switch\" class=\"small\" data-icon=\"oa-message_ok\" data-color=\"green\" data-device=\"";
            $html.="$Device";
            if ("$Device" =~ /^Wassermelder_/){
                $html.="\" data-set-on=\"off\" data-set-off=\"Alarm\" ";           
            }
            $html.="> </div></td>";
        }
        $html.="</tr>"
    }
    return $html;

}


Also habe ich bisher nur die Fenstersensoren...und das generieren der HTML-Tabelle fertig.
Ich packe also Errors und Warnings in unterschiedliche hashes. Dazu die eigentliche Fehlermeldung, bei Bedarf einen Button zur Bestätigung und das gewünschte Symbol...nun ist es eigentlich nur noch eine Fleissarbeit...

Gruß
Bismosa

[Gisbert]

Hallo Bismosa,

vielen Dank für deine Informationen.
Ich fürchte jedoch, dass deine Lösungen für mich deutlich zu kompliziert sind.

Ich glaube, dass ich nur eine gute Funktionalität hinbekomme, wenn ich die Abfragen vereinzelne, entweder in Form von DOIFs oder notitfys. Damit vermeide ich, dass die nachrangigen Bedingungen in einem DOIF durch vorherige blockiert werden.

Viele​ Grüße​ Gisbert​

[bismosa]

Hallo,

ja ich weiß...ich bin manchmal echt kompliziert... 

Dabei versuche ich es ja immer irgendwie zu vereinfachen. Gelingt mir allerdings zu selten.
Letztendlich müsste eigentlich der part des externen Bash-Scriptes für Dich interessant sein. Hier wird regelmäßig geprüft, ob meine Geräte noch verfügbar sind (ping). Das geht zumindest bei WLAN-Geräten problemlos.

Bei allen anderen...einfache DOIFs...und meiner Erfahrung nach...lieber ein paar mehr einzelne als alles in einem. Macht die Sache viel einfacher.
Ich denke mit DOIF sollte sich auch etwas machen lassen mit z.B. ResetWait o.ä. also sobald ein Reading reinflattert...timer zurücksetzen. Wäre so eine spontanidee. Müsste dann aber für jedes Device ein eigenes DOIF her.

Gruß
Bismosa

[Thorsten Pferdekaemper]

Hi,
ich denke, dass man daraus auch ein FHEM-Modul machen könnte. Ähnliches gibt es ja bereits, wie z.B. das ActionDetector Device bei Homematic oder das Modul "monitoring". ActionDetector ist halt leider HM-spezifisch und für "monitoring" muss man wohl noch Einiges mit notify/at/DOIF außenherum bauen.
Vielleicht sollten wir mal sammeln, was so ein generelles Modul können sollte bzw. was denn überhaupt die Anforderungen sind. Dazu müsste man dann noch ein entsprechendes FTUI-Widget und einen FUIP-View bauen, der das ganze auch gefällig anzeigt.

Also hier mal der Beginn einer Anforderungsliste für das Modul:

• Analog zu ActionDetector eine Überwachung ob jedes (?) Device innerhalb einer bestimmten Zeit mindestens ein Event abgesondert hat. Das würde schon einmal helfen, "tote" Geräte zu erkennen. Natürlich ist das vom Device abhängig, müsste also pro Device einstellbar sein.
• Dasselbe mit "Anstupsen" (Polling). Manche Devices senden von sich aus nicht unbedingt Events, sondern wollen gefragt werden. Das ist jetzt natürlich noch Device-spezifischer.
• Unterscheidung von Message-Klassen (oder so). D.h. Fehler, Warnung, Information etc.
• Überwachung der Werte bestimmter Readings. Gleich, größer, kleiner etc. sollte gehen
• Irgendein ganz flexibler Mechanismus für "beliebigen Kram". Das könnte z.B. ein einfaches "set" sein, mit dem man dann von außen eine Meldung in die Liste geben kann.
• Automatisches oder manuelles Bestätigen. Wenn z.B. ein Device, welches nicht mehr erreichbar war, wieder erreichbar wird, dann darf die Meldung von alleine verschwinden. Bei einer Überschwemmung sollte man vielleicht in jedem Fall mal nachsehen gehen.
• Überwachte Readings je nach Alter unterschiedlich behandeln. Das kann bedeuten, dass man alte Readings ignoriert, oder aber auch dass es als "schlimmer" eingestuft wird, wenn es lange so bleibt.
• Zu einer Meldung sollte sich das System anzeigen können: Device, Reading und Wert (falls überwacht), Meldungs-Klasse (ggf. als Farbe), Zeit der Meldung, beschreibender Text , Icon

Ich glaube, dass man das kaum als eine Instanz "Störmeldeliste" hinbekommt. Dafür ist die Konfiguration zu komplex, wenn man es einigermaßen FHEM-üblich machen will. Mir riecht das eher danach, dass es mit einem Modul "Störmeldung" (ein besserer Name wäre da auch nicht schlecht) gehen könnte. Dieses Modul könnte dann alle Möglichkeiten anbieten, aber man kann sich eben immer nur eine Ausprägung aussuchen.
Z.B. hätte man dann eine Instanz "activityMonitor", eine Instanz "wassermelder" und eine Instanz "batteries", in etwa:

• activityMonitor überwacht die Events aller Devices (oder mit einer RegEx/DevSpec ausgesuchter Devices) und erzeugt eine Meldung wenn für ein Device nach einer Stunde kein Event kam. Die Meldungen sind Fehlermeldungen und setzen sich von selbst zurück.
• wassermelder überwacht das Reading state auf "Alarm". Die Meldungen sind Fehlermeldungen und setzen sich nicht von selbst zurück.
• batteries überwacht das Reading batteryOk auf "nicht ok" (oder so). Die Meldungen sind Warnungen, werden aber nach drei Tagen zu Fehlermeldungen. Sie setzen sich von selbst zurück.

Natürlich könnte dann jede Störmeldungs-Instanz mehrere (gleichartige) Meldungen sammeln. Für eine zusammenfassende Aufbereitung bräuchte man dann doch noch mal eine übergeordnete Liste, damit man in FHEMWEB/FTUI/FUIP keine allzu großen Klimmzüge machen müsste.

Meinungen?
Gruß,
  Thorsten

[KölnSolar]

Hallo Thorsten,
alle Posts sind recht laaaaaang. Daher hab ich vielleicht den Kern nicht verstanden.

Die kritischsten Devices sind bei mir die Funktransceiver und der Router. Dann kommen Sensoren u. Aktoren der Heizungssteuerung, dann mein "Meldungsdevice" echo  und irgendwann eher unwichtige Klimasensoren.

Ich will damit sagen, unterschiedliche devices haben unterschiedliche Prioritäten einerseits und ich denke man muss zwischen Aktoren(tw. unidirektional) und Sensoren differenzieren.

Unidirektinale Aktoren lassen sich nicht systematisch, sondern nur durch individuelle Sensorik(ggfs. den User  ) prüfen.

Sensoren lassen sich über ReadingsAge prüfen(schwierig wird es, wenn event-on.... eingesetzt wird. dann muss ein relativ hohes Alter gewählt werden).

Bidirektionale Aktoren evtl. ähnlich. Aber da könnte ja auch ein hoher Zyklus nötig sein(SommerBsp.: regensensorgesteuerter Aktor  )

Folglich prüfe ich gemäß obiger Priorität meine Funksticks per zyklischem(at)ReadingsAge, den Router über presence(+ Aktion bei Ausfall), die Heizungssteuerung über watchdogs(keine Info, sondern Aktion) und den Rest manuell.

Alle devices automatisch prüfen zu wollen wird sicherlich eine beträchtliche Systemlast nach sich ziehen. Im Sinne von keep it simple vielleicht einfach nur ein Modul zur Standardisierung von ReadingsAge-Abfragen anstatt meinen ats mit MinimalPerlcode? 

Grüße Markus

[bismosa]

Hallo!

Ich glaube, dass man das kaum als eine Instanz "Störmeldeliste" hinbekommt. Dafür ist die Konfiguration zu komplex, wenn man es einigermaßen FHEM-üblich machen will.

Das sehe ich genau so. Sicherlich ist es am Anfang sehr schwierig sich ein Konzept aufzubauen...gerade wenn man schon viele Geräte hat...aber wenn man einen Plan hat geht es eigentlich.

Das Modul "monitoring" kannte ich noch gar nicht. Mist...das hätte ich mal früher sehen sollen. Dann hätte ich es mit einer Liste nicht so schwierig machen müssen.
Eigentlich sollte sich doch damit der Anwendungsfall von Markus schon nachstellen lassen...meldet es sich nicht frühzeitig genug wandert es auf die Warnungsliste...

Geräte, die eine "Störmeldung" bei mir verursachen werden eh immer über ein DOIF oder notify "überwacht". Von dort aus gehen auch immer die Meldungen per Mail oder Pushover auf das entsprechende Gerät (auch dies bei mir eine Mischung aus code in der myUtils und einem Dummy für die Einstellungen damit ich einzelne Geräte hinzufügen/entfernen kann ohne alle DOIFs oder notifys anzupassen)

Ich denke ich muss mir das monitoring Modul noch einmal genauer anschauen. Damit müsste sich eigentlich schon vieles erledigen lassen. Vielleicht sogar besser als bei jedem zutreffenden Event alles durchzusehen ob der Status ok ist.
Vorerst werde ich jedoch meinen angefangenen Weg zu Ende bringen. Mal schauen, wie sich das in der Praxis dann macht.

Gruß
Bismosa

[Thorsten Pferdekaemper]

alle Posts sind recht laaaaaang. Daher hab ich vielleicht den Kern nicht verstanden.

Tja, den Kern herauszuschälen ist oft gar nicht so einfach. Daher habe ich mich auch noch nicht daran gemacht, etwas zu bauen, sondern will erst einmal die Diskussion abwarten.
Ich denke, dass der allererste Beitrag in diesem Thread einigermaßen erklärt, was das eigentlich soll. Ich stelle mir eine einigermaßen flexible Liste von Meldungen vor, in der alles verarbeitet wird, was irgendwie dem Benutzer mitgeteilt werden soll. Dabei geht es nicht (primär) um die Art und Weise der Mitteilung (FTUI, Mail, Push-Nachricht,...), sondern mehr darum, welche Ereignisse/Mechanismen diese Meldungen erzeugen sollen.
...aber das ist momentan nur mein Eindruck. Vielleicht reden wir hier auch über ein allgemeines Workflow-Modul.

Ich will damit sagen, unterschiedliche devices haben unterschiedliche Prioritäten einerseits

Ja, wahrscheinlich braucht man etwas detaillierteres als nur eine "Meldungsklasse".

Unidirektinale Aktoren lassen sich nicht systematisch, sondern nur durch individuelle Sensorik(ggfs. den User  ) prüfen.

Also wenn nur der User etwas prüfen kann, dann könnte man höchstens regelmäßig (z.B. einmal pro Tag/Woche) eine Meldung erzeugen wie "Bitte Wassertstandsmelder prüfen" und den Benutzer manuell bestätigen lassen.
Bei "individueller Sensorik" ist es dann halt der entsprechende Sensor, der überwacht wird.

Sensoren lassen sich über ReadingsAge prüfen(schwierig wird es, wenn event-on.... eingesetzt wird. dann muss ein relativ hohes Alter gewählt werden).

Wenn man ein eigenes Modul draus macht, dann hat man es etwas einfacher. Man lässt sich einfach alle Events liefern und sortiert sie entsprechend ein. Dazu noch ein Timer für die Meldungen und fertig.

Bidirektionale Aktoren evtl. ähnlich. Aber da könnte ja auch ein hoher Zyklus nötig sein(SommerBsp.: regensensorgesteuerter Aktor  )

Klar, dass die Zyklen (bzw. maximal tolerierbare Zeit bis zum nächsten Event) pro Device unterschiedlich sind. Allerdings gibt es ja nicht nur das "Haupt-Reading", sondern auch andere Events. Z.B. könnte ein batteriebetriebener Sensor regelmäßig seinen Batteriestand senden. Dann weiß man auch, dass er noch lebt.

den Router über presence(+ Aktion bei Ausfall), die Heizungssteuerung über watchdogs(keine Info, sondern Aktion)

Das mit den automatischen Aktionen hatte ich nicht so auf dem Radar. (Oder verstehe ich da was falsch?)

Alle devices automatisch prüfen zu wollen wird sicherlich eine beträchtliche Systemlast nach sich ziehen. Im Sinne von keep it simple vielleicht einfach nur ein Modul zur Standardisierung von ReadingsAge-Abfragen anstatt meinen ats mit MinimalPerlcode? 

Siehe oben: Ich denke, dass das innerhalb eines Moduls sogar besser ist (wenn man's richtig macht). Zumindest alles, was Du über ReadingsAge machst, könnte man auch über Events machen. Die werden sowieso erzeugt und das Modul könnte sich dranhängen. 

Sicherlich ist es am Anfang sehr schwierig sich ein Konzept aufzubauen...gerade wenn man schon viele Geräte hat...aber wenn man einen Plan hat geht es eigentlich.

Es wäre meiner Meinung nach schöner, wenn wir einmal ein gutes Konzept machen und das dann für viele funktioniert, ohne dass man da noch sehr viel überlegen muss.

Das Modul "monitoring" kannte ich noch gar nicht. Mist...das hätte ich mal früher sehen sollen. Dann hätte ich es mit einer Liste nicht so schwierig machen müssen.

Das ist jedenfalls ein Anfang. Wenn ich mir allerdings die Doku zu dem Modul anschaue, dann scheint man doch noch eine ganze Menge programmieren zu müssen. Das würde ich gerne vermeiden.

Gruß,
   Thorsten

[KölnSolar]

Wenn man ein eigenes Modul draus macht, dann hat man es etwas einfacher. Man lässt sich einfach alle Events liefern und sortiert sie entsprechend ein. Dazu noch ein Timer für die Meldungen und fertig.

Siehe oben: Ich denke, dass das innerhalb eines Moduls sogar besser ist (wenn man's richtig macht). Zumindest alles, was Du über ReadingsAge machst, könnte man auch über Events machen. Die werden sowieso erzeugt und das Modul könnte sich dranhängen.

Klar, anstatt ReadingsAge könnte man jeweils die events einfangen und damit dann modulintern den "timer" des devices zurücksetzen. Allerdings muss dann das Modul zyklisch seine "timer" prüfen. Also letztendlich auch nicht anders als eine ReadingsAge-Abfrage.
Um es noch einmal herauszustellen: Es soll ja ein "Ereignis"(Meldung etc.) ausgelöst werden, weil ja gerade kein event in einer vorgegebenen Zeit gekommen ist.

Zitat

Bidirektionale Aktoren evtl. ähnlich. Aber da könnte ja auch ein hoher Zyklus nötig sein(SommerBsp.: regensensorgesteuerter Aktor  )


Klar, dass die Zyklen (bzw. maximal tolerierbare Zeit bis zum nächsten Event) pro Device unterschiedlich sind. Allerdings gibt es ja nicht nur das "Haupt-Reading", sondern auch andere Events. Z.B. könnte ein batteriebetriebener Sensor regelmäßig seinen Batteriestand senden. Dann weiß man auch, dass er noch lebt.

Ja, wenn sie denn batteriebetrieben sind oder sonstwie ein Lebenszeichen von sich geben. Aber das tun sie ja eher nicht. Btw. bei den batteriebetriebenen Sensoren habe ich das Problem mit aktuellen Methoden(notify auf reading battery), dass die nicht zielführend sind. Aus Erfahrung bringen mir low oder niedrige Prozentwerte nichts, da die Batterien noch lange halten. 

Das mit den automatischen Aktionen hatte ich nicht so auf dem Radar. (Oder verstehe ich da was falsch?)

Eine Info über ein "ausgefallenes" device zu erhalten ist ja nett. Aber letztendlich dient diese ja nur dazu eine Aktion des Users auszulösen. Im Beispiel des Routers lässt sich das aber automatisieren, indem die DSL-Verbindung neu aufgebaut wird.
Auch beim Beispiel der Heizungssteuerung bringt mir eine Meldung recht wenig, da eine unverzügliche Reaktion erforderlich ist: Temperatur des Kessels steigt in einem "Startzeitraum" nicht um delta T an ==> erneuter Einschaltbefehl für den unidirektionalen Aktor. Klassisches watchdog-Beispiel.

Wo ich so meine Gedanken heruntertippe, mal zusammengefasst:
Nach meinem Empfinden ist es das Ziel ähnlich der Funktionalität vom  watchdog-Modul in der Funktionalität SAME allgemeiner zu realisieren:
- bleibt ein event aus(modulintern oder per ReadingsAge überprüft) startet eine Aktion, die aber auch nur eine Meldung sein kann
  (zusätzlich natürlich noch ein Logeintrag level 1; das message-device könnte ja auch mal nicht funktionieren und im Log hat man eine
   zeitliche Dokumentation von Ausfällen)
   Das Modul könnte auch anstatt der action/message nur ein event auslösen und der User muss/kann individuell in seiner Installation per
   notify/DOIF reagieren.
- Parameter: device, reading(event), timelag, action und/oder message (im Gegensatz zu watchdog aber nicht Prüfung eines "fremden"
  events) (anstatt der action auch nur ein event auslösen)
- technische Realisierung der Modulsteuerung: ähnlich dem Alarm-Modul über Attribut(e?) in den einzelnen devices ?
- Initialisierung: automatisches setzen der Attribut(e) bei allen devices, die ein battery-reading(oder vergleichbar)(alternativ Modulname, da 
  darüber die devices "klassifiziert" sind ?)haben, mit über Modul- Attribute definierten Parameter-defaults(Timelag, (action/message))

(nur ein event(absent ?)+Logeintrag zu erzeugen gefällt mir irgendwie fast noch besser, als action/message + Logeintrag zu erzeugen)

Andere Ziele sollte das Modul nicht verfolgen, da es meines Erachtens dann wieder zu komplex wird. Komplexe Dinge bzw. Dinge hoher Priorität sind nach wie vor individuell umzusetzen. Das Modul sollte dann maximal unterstützend wirken.

Und je länger ich drüber nachdenke: Ist es nicht nur eine Erweiterung des presence-Moduls für die devices, die nicht einfach zyklisch abgefragt werden können ?

Grüße Markus

[bismosa]

Hallo!

irgendwie habe ich das Gefühl das Du gerne ein tolles Modul bauen möchtest 
Eigentlich wollte ich in diesem Thread nur mal nachfragen, ob es schon etwas gibt was ich übersehen habe. Wie z.B. Monitoring. Aber gerne können wir auch weitere Ideen verfolgen.

Ich habe mir das monitoring jetzt mal genauer angesehen. Ich denke das geht schon in die richtige Richtung. Man kann auf bestimmte Events reagieren (auf die Liste setzen) und nach einer gewissen Zeit ein Fehler-Event erzeugen. Diese Meldungen lassen sich dann wieder zurücksetzen.

Vielleicht sollten wir mal sammeln, was für Anwendungsfälle wir so haben und eine Liste machen, was alles machbar sein sollte.
Ich fange mal an:

- Gerät(e) hat/haben sich eine bestimmte Zeit nicht mehr gemeldet
- Gerät hat ein Reading mit Fehlerstatus (z.B.: RPI-GPIO oder ein Dummy das gesetzt wurde, abgefallener Fenstersensor, Wassermelder)
  - Batteriestatus von Geräten
- Gerät wird regelmäßig angepingt...keine Antwort -> Fehler (ggf. nach einer bestimmten Zeit...mein WLAN ist so überlastet, dass es gelegentlich mal zusammenbricht)
- Gerät hat ein Reading mit einem Wert "<=" ">=" "=="

Das sind generell schon die Fälle, die ich habe. Ich denke mit monitoring könnte man diese Fälle bereits abdecken (außer das pingen...das darf FHEM nicht blocken). Dafür müsste man allerdings mehrere Monitoring-Devices erstellen. Diese können dann wieder zusammenfassen und auswerten (vielleicht mit einem DOIF)
Da wäre es schon super, wenn man alles in einem Device generell lösen könnte...aber da fehlt mir ein bisschen die Idee. Denn alles generalisieren ist hier vermutlich viel komplizierter....

Als Spontanidee könnte man es vielleicht ähnlich dem "FReplacer" machen. Hier werden viele Readings durchnummeriert gesetzt...so könnte man unterschiedliche Anwendungsfälle integrieren. Allerdings würde ich das in der Definition bevorzugen...das ist einfacher zu bearbeiten.

Ich denke man bräuchte auf jeden Fall diese Variablen:
<device[:reding]><Readingalter | Fehler bzw. OK Status | Vergleichsoperator+Min bzw.Max Value | Ping | ...><Nachricht><<Prio><Error/Warning>

Ob das dann einfacher wird?


Für meine derzeitige "Störmeldeliste" habe ich es jetzt erst einmal so gelöst, dass ich sobald ein Prüf-Event (z.B. Sensor melder Fehler etc.) ein DOIF Triggere und alles einzeln abfrage.

Code Auswählen Erweitern


(["^Wassermelder_"]
or [HeizungsStoerung]
or ["^Fenster_"]
or ["rpi_status"]
or ["GPIO_Heizung_Brenner"]
)({
MeldeListeGet("$SELF");
})

Beispiele:

Code Auswählen Erweitern


$RPIVal=ReadingsVal("rpi_status", "openelec_HDD_free","0");
if ($RPIVal<=100000000){
$ErrorCount+=1;
$MB=$RPIVal/1024;
$hashErrors{"openelec_HDD_free"}{"Error"}="Video HDD nur ".sprintf("%.2f", $MB)."MB frei!";
$hashErrors{"openelec_HDD_free"}{"Confirm"}="";
$hashErrors{"openelec_HDD_free"}{"Symbol"}="mi-storage";
}
$RPIVal=ReadingsVal("rpi_status", "openelec_temp","0");
if ($RPIVal>=70000){
$ErrorCount+=1;
$hashErrors{"openelec_temp"}{"Error"}="Video CPU ".sprintf("%.2f", $RPIVal)."°C !";
$hashErrors{"openelec_temp"}{"Confirm"}="";
$hashErrors{"openelec_temp"}{"Symbol"}="oa-temp_temperature_max";
}
my @DevicesFensterKaputt=devspec2array("NAME=Fenster_.*:FILTER=STATE=Kaputt");
foreach my $Device (@DevicesFensterKaputt){
$ErrorCount+=1;
$FensterWarnungenCount+=1;
$hashErrors{$Device}{"Error"}="$Device abgefallen";
$hashErrors{$Device}{"Confirm"}="";
$hashErrors{$Device}{"Symbol"}="oa-message_attention";
}
my @Wassermelder=devspec2array("NAME=Wassermelder_.*:FILTER=STATE=Alarm");
foreach my $Device (@Wassermelder){
if ($Device eq "Wassermelder_Heizung"){
$WarningCount+=1;
$hashWarnings{$Device}{"Error"}="$Device bitte Eimer leeren!";
$hashWarnings{$Device}{"Confirm"}="TODO!!!";
$hashWarnings{$Device}{"Symbol"}="fa-exclamation";
} else {
$ErrorCount+=1;
$hashErrors{$Device}{"Error"}="$Device Überschwemmung!";
$hashErrors{$Device}{"Confirm"}="TODO!!!";
$hashErrors{$Device}{"Symbol"}="oa-message_attention";
}
}

So lassen sich relativ einfach neue Devices mit anderen Anforderungen "nachtragen".
Ein sehr großes Manko hat es allerdings: Es wird sehr häufig aufgerufen...wie "Leistungshungrig" mein Code hier ist...keine Ahnung. Wäre blöd, wenn ich durch die ständige Ausführung mein FHEM blockiere.

Da wäre es besser mit einer generellen Liste in einem Modul etc. zu arbeiten. Dann muss nur auf das entsprechende Device reagiert werden.

Sorry...wieder nicht kurz.

Gruß
Bismosa

[Gisbert]

Hallo zusammen,

ich fasse mich kurz, da am Handy

Meine Anforderungen wären folgende:

• nur ausgewählte Devices werden überwacht
• Kriterium am liebsten ReadingAge, aber individuell einstellbar in Minuten
• Zykluszeit für die Abfrage, z.B. alle 10 Minuten, auch individuell einstellbar
• Pushmeldungen, Email oder andere (z.B. Reset des Devices) bzw. auch alles zusammen sollen rausgeschickt werden
• Limitierung der Meldung auf eine individuell einstellbare Anzahl, z.B. bei n=3 sollen nach Ablauf der jeweiligen Zykluszeit insgesamt 3 Meldungen raus, danach ist erst mal Schluss
• als Reading Anzahl der Devices, die alive sind und die keinen Mucks mehr von sich geben
• als Reading die Namen der leblosen Devices

Mit einem DOIF kann man nur einen Teil der obigen Liste erschlagen, insbesondere die Gleichzeitigkeit bei Ausfall mehrer Devices gelingt gar nicht.

Viele​ Grüße​ Gisbert​

PS: im Wünsche äußern bin ich gut, allein bei mir hapert's bei der Programmierung 

[Gisbert]

Hallo Bismosa, Thorsten und Markus,

gibt es noch Interesse in dieser Angelegenheit weiterzumachen? Ich finde eine Solche Störerliste interessant.

In der Zwischenzeit versuche ich mich mit dem Modul "monitoring", das einen Teil der angesprochenen Wünsche/Spezifikationen enthält, auseinanderzusetzen.

Viele​ Grüße​ Gisbert​

[Thorsten Pferdekaemper]

Hi,
Interesse ja, aber ich habe zurzeit einen Haufen anderen Kram zu erledigen.
Gruß,
   Thorsten

[bismosa]

Hallo!

JEIN...ich habe festgestellt, dass meine Anforderungen da wohl zu anspruchsvoll sind für ein "einfaches" Modul.
Das Modul Monitoring sieht da vielversprechend aus...damit kann man bestimmt einiges machen.
Ich habe mich jetzt erst einmal mit meiner "manuellen" Lösung vergnügt und bin damit recht zufrieden. Da erzeuge ich die Liste direkt als HTML und kann mir das im FUIP/FTUI anzeigen lassen.
Bei Interesse, kann ich da nochmal meine komplette Lösung beschreiben.

Gruß
Bismosa