Wie überwacht Ihr Eure Werte?

[KUD]

Interessehalber wollte ich im Floorplan die Zeit/Datum der Temperaturwerte (S300TH) anzeigen lassen.
Habe mit der 99_myFloorplanList.pm rumgespielt.
Nach einer Weile hatte ich dann die Zeit/Datum neben den Werten stehen.
Alles OK.
Dann wollte ich noch den Fensterkontakt und einen Wasserfühler( HMS100) mit den Zeitstempeln versehen.
Nachdem das auch in die og. eingepflegt wurde, stllte ich fest, dass der letzte Wert des "Wasserfühlers" schon 3 Tage alt war.
ÄHHM? Am Ziel vorbei dachte ich...
Wäre es also nicht sinnvoll solche Plausibilitäten in FHEM direkt zu implementieren?
Es gib ja schon einen "Batterieüberwacher"

####### notify  Batteriealarm ##########
define n_batt_chk notify .*:[Bb]attery.* { if("%" !~ m/ok/) {\
  {FBMail('FHEM Batteriewarnung','@ %')};;\
  Log 3, "@: Batteriewarnung %";;\
  }\
}
##################################

Schick...Aber bei den letzten Daten meines Wassermelders stand "Battery OK".
Also das Datum wird bisher nirgends ausgewertet.
Wäre es nicht besser die "ReadingsTimestamp" der Devices alle Minuten kurz zu checken?

War nur so meine Idee. Oder wie stellt Ihr sicher, dass Euer Wassermelder auch noch Daten sendet und nicht Tod ist?

Gruss Kai-Uwe




 

[Michael Zielinski]

gute Frage - Momentan behelfe ich mir durch einen Täglichen Report per Email, wo das Datum mit angezeigt wird - aber ich überlege auch noch, wie das besser geht
Aber dazu muss ich erkennen, welche Geräte täglich senden müssen und sonst Fehler ausgeben - automatisiert...


#Statusreport per Mail senden
sub fhem_report {
  my $mz = "";
  my @mzdev=devspec2array("TYPE=CUL_FHTTK");
 
  $mz=$mz."CUL_FHTTK\n";
  my @mzdev=devspec2array("TYPE=CUL_FHTTK");
  foreach(@mzdev){$mz=$mz.ReadingsTimestamp($_,"Window",0).substr("$_                     ",0,20)." ".Value($_)."\n";};
 
  $mz=$mz."\nFS20\n";
  @mzdev=devspec2array("TYPE=FS20");
  foreach(@mzdev){$mz=$mz.ReadingsTimestamp($_,"state",0).substr("$_                     ",0,20)." ".Value($_)."\n";};
 
  $mz=$mz."\nCUL_WS\n";
  @mzdev=devspec2array("TYPE=CUL_WS");
  foreach(@mzdev){$mz=$mz.ReadingsTimestamp($_,"state",0).substr("$_                     ",0,20)." ".Value($_)."\n";};
  #  foreach(@mzdev){$mz=$mz."$_ ".Value($_)."\n";};

  $mz=$mz."\nHMS\n";
  @mzdev=devspec2array("TYPE=HMS");
  foreach(@mzdev){$mz=$mz.ReadingsTimestamp($_,"type",0).substr("$_                     ",0,20)." ".Value($_)."\n";};

  FBMail('FHEM Statusreport',$mz);
}

[Willi]

gute Frage - Momentan behelfe ich mir durch einen Täglichen Report per Email, wo das Datum mit angezeigt wird - aber ich überlege auch noch, wie das besser geht
Aber dazu muss ich erkennen, welche Geräte täglich senden müssen und sonst Fehler ausgeben - automatisiert...

Ich habe mir ein kleines Modul 99_Checkstate.pm geschrieben, welches ich alle paar Stunden aufrufe und welches folgendes macht für alle Sensoren

- Es wird geprüft, wann der Sensor das letzte Mal ein STATE oder Reading geschrieben hat.

- Wenn die Zeitdifferenz zu gross ist (konfigurierbar in Sekunden als Attribut und fest codiert im Modul für den Device-Type), wird beim State des Sensors ein "?" vor den State davorgeschrieben. dann sieht man auch in FHEMWEB und Floorplan, dass da etwas nicht stimmt.

- Es wird geprüft, ob Battery low ist

Am Ende wir eine Gesamtmail generiert (nur wenn etwas zu berichten ist) und zugesendet, in der angegeben wird, welche Sensoren ein Timeout haben und bei welchen Sensoren die Batterie gewechselt werden muss.

Klappt bisher ganz gut.

Ich habe das bisher nicht veröffentlicht, weil:

- ich keine Zeit hatte dies zu dokumentieren

- das Mailversenden nicht universell ist, sondern nur unter Linux läuft

- das Modul immer noch nicht fertig ist,

- ich den Supportaufwand scheue..

Das Modul einzusetzen bedeutet, dass man anfangs eine Menge Timeouts bei Sensoren gemeldet hat. Bei diesen muss man dann entscheiden, ob man die Timeouts höher setzt oder den timeout auf 0 setzt (0 für kein Timeout).

Evtl. will ja jemand das Modul perfektionieren und supporten ;-)

Anbei als Denkanstoss nur für Entwickler zur Weiterentwicklung....

Ansonsten würde ich so ein Modul in etwa einem Jahr nach weiterem intensiven Test veröffentlichen.

MfG Willi

-----------

##############################################

# $Id: 99_Checkstate.pm  $

#

# Checks for timeout and battery stat.

#

# Default timeout are set in the devtype_timeout array below.

# You may set an individual timeout by setting an attribute "timeout".

# The timeout must be specified in seconds. 0 means that the device is not checked for timeout.

# Before you can do so define a user attribute to all devices:

# attr global userattr timeout .......

#

# Devices are checked for battery state of the Reading battery exist.

# To exclude an device from battery check, just set an user atriibute "ignore_battery" to any value.

# attr global userattr ignore_batter .....y

#

package main;

use strict;

use warnings;

use POSIX;

use English qw<$OS_ERROR>;

sub CommandCheckstate($$);

sub XmlEscape($);

my $email = "willi\@herzigs.de";

my $hostname = "hersheeva";

my $subject = "";

# Default values for each device type:

my %devtype_timeout =

    (

"CUL_FHTTK"  => 30 * 60, # 30 Minutes, FHTTK report every 4 minutes

"CUL_WS"  => 3 * 60*60, # 3 hours, CUL_WS report every 3 minutes

"FHT"  => 1 * 60*60, # 1 hour, FHT report ....

"FS20"  => 0, # no timeout

"TRX_WEATHER"  => 10 * 60, # 10 Minutes, Oregon devices report every minute

"TRX_SECURITY" => 4 * 60*60, # 4 hours, TRX_SECURITY reports every hour

"TRX_LIGHT" => 0, # no timeout

"RFXX10REC" => 0, # no timeout

);

my $device_default_timeout = 1 * 60*60*24; # 1 Day

#####################################

sub

Checkstate_Initialize($$)

{

  my %lhash = ( Fn=>"CommandCheckstate",

                Hlp=>",check state of all devices if STATE is valid. Check for Battery change." );

  $cmds{checkstate} = \%lhash;

}

#####################################

sub

XmlEscape($)

{

  my $a = shift;

  return "" if(!defined($a));

  $a =~ s/\\\n/<br>/g;  # Multi-line

  $a =~ s/&/&amp;/g;

  $a =~ s/"/&quot;/g;

  $a =~ s/</&lt;/g;

  $a =~ s/>/&gt;/g;

  # Not needed since we've gone UTF-8

  # $a =~ s/([^ -~])/sprintf("&#%02x;", ord($1))/ge;

  # Esacape characters 0-31, as they are not part of UTF-8

  $a =~ s/(\x00-\x19)//g;

  return $a;

}

#####################################

sub

CommandCheckstate($$)

{

  my ($cl, $param) = @_;

  #my $str = "<FHZINFO>\n";

  my $str = "";

  my $lt = "";

  my $timeout_str = "";

  my $battery_str = "";

  delete($modules{""}) if(defined($modules{""}));

  for my $d (sort { my $x = $modules{$defs{$a}{TYPE}}{ORDER}.$defs{$a}{TYPE} cmp

               $modules{$defs{$b}{TYPE}}{ORDER}.$defs{$b}{TYPE};

       $x = ($a cmp $b) if($x == 0); $x; } keys %defs) {

next if(IsIgnored($d));

my $p = $defs{$d};

      my $t = $p->{TYPE};

 

      my $a1 = XmlEscape($p->{STATE});

my $TIME_STRING = "TIME";

      if (defined($p->{LASTIODev})) {

$TIME_STRING = $p->{LASTIODev}."_TIME";

}

my $state_time = "";

if (!defined($p->{$TIME_STRING})) {

my $latest_time = 0;

# Look into all Readings and get the latest Time_value:

my $hash = $defs{$d}{READINGS};

foreach my $n (sort keys %{$hash}) {

my $val = $hash->{$n};

if(ref($val)) {

# These are the READINGS:

my $tmp_value = $val->{VAL};

my $tmp_time = $val->{TIME};

my $tmp_time_num = time_str2num($tmp_time);

#Log 1,"ListReadings: val=$val nname=$n, value=$tmp_value, time=$tmp_time time_num=$tmp_time_

num";

if ($tmp_time_num > $latest_time) { $latest_time = $tmp_time_num; }

}

}

if ($latest_time != 0) { $state_time = FmtDateTime($latest_time); }

} else {

$state_time = $p->{$TIME_STRING};

}

next if ($state_time eq "");

      #$str .= "<type=$t name=\"$d\" time=\"$state_time\" state=\"$a1\" \n";

my $time_now = time();

my $time_num = time_str2num($state_time);

my $time_diff = $time_now - $time_num;

my $device_timeout = $device_default_timeout;

  if (exists $devtype_timeout{$t}) {

$device_timeout = $devtype_timeout{$t};

}

my $attr = AttrVal("$d","timeout", undef);

if (defined($attr)) {

  #$str .= sprintf("\t%s\t attribute timeout %s\n", $d, $attr);

$device_timeout = $attr;

}

# 

if ($device_timeout > 0 && $time_diff > $device_timeout) {

#Log 1,"Checkstate: -1- $d reported $state_time: \t'$p->{STATE}'";

if (defined ($p->{STATE})) {

if (! ($p->{STATE} =~ m/^\?.*/)) {

#Log 1,"Checkstate: $d reported $state_time";

$p->{STATE} = "? ".$p->{STATE};

  $timeout_str .= sprintf("\t%s\t reported %s\n", $d, $state_time);

} else {

$timeout_str .= sprintf("\t%s\t again reported %s\n", $d, $state_time);

}

} else {

  $timeout_str .= sprintf("\t%s\t reported %s\n", $d, $state_time);

}

      #$str .= "!!!time_num=$time_num time_diff=$time_diff (devtimeout=$device_timeout)\n";

} else {

      #$str .= "  time_num=$time_num time_diff=$time_diff (devtimeout=$device_timeout)\n";

  }

      my $r = $p->{READINGS};

      if($r) {

        foreach my $c (sort keys %{$r}) {

          my $h = $r->{$c};

          next if(!defined($h->{VAL}) || !defined($h->{TIME}));

          next if($c ne "battery");

my $ignore_battery_attr = AttrVal("$d","ignore_battery", undef);

next if (defined($ignore_battery_attr));

          if($h->{VAL} eq "low") {

          $battery_str .=

               sprintf("\t%s\t reported %s\n", $d, $h->{TIME});

}

        }

      }

  }

  $subject = "FHEM ".$hostname.": ";

  if ($timeout_str ne "") {

$str .= "\n- The following devices have timeouts:\n".$timeout_str;

$subject .= " <devices have timeouts>";

  }

  if ($battery_str ne "") {

  $str .= "\n- The following devices have low battery:\n".$battery_str;

$subject .= " <battery low for devices>";

  }

  if ($str ne "") {

open( my $mailh, '|-', "mail -s '$subject' $email" )

   or die( "Could not open pipe! $OS_ERROR" )

    ;

#print $mailh $str, "\n.\n";

print $mailh $str, "\n";

close $mailh;

  }

  return $str;

}

1;

[Willi]

Ich vergass: Das Modul wird einfach mit 

checkstate

in der FHEM-Kommandozeile aufgerufen.

[Michael Zielinski]

Hmm - das will trotz shutdown restart nicht ?!?!?
Muss man da noch was initialisieren oder so?
 

[Tom]

Hallo Willi,

interessantes Projekt!

2 Anregungen hätte ich dazu:

> Ich habe mir ein kleines Modul 99_Checkstate.pm geschrieben, welches ich

> - das Mailversenden nicht universell ist, sondern nur unter Linux läuft

hierzu würde ich empfehlen, den eigentlichen Versand in eine separate
Funktion auszulagern ("send_mail(params...)").
Dann brauchst Du Dich um diesen Teil überhaupt nicht kümmern, das muss
eben jeder Nutzer für sein System passend machen.
Man könnte im Wiki ein paar Beispiele hinterlegen, wenn noch nicht vorhanden...

> # Default timeout are set in the devtype_timeout array below.
> # You may set an individual timeout by setting an attribute "timeout".
> # The timeout must be specified in seconds. 0 means that the device is not
> checked for timeout.
> # Before you can do so define a user attribute to all devices:
> # attr global userattr timeout .......

die Variante mit dem Hardcoden ist immer... hm. Es kommen immer mal
wieder neue Devices auf den Markt, die dann doch nicht in der Liste
sind und somit permanenten Aufwand erfordern.

Hier wäre mein Vorschlag, ausschließlich über das userattr zu arbeiten
- somit hätten erst einmal ALLE keinen Timeout. Übrigens würde ich
auch ggf einen etwas spezifischeren Namen dafür wählen, z.B.
"warning_timeout" oder so. Es könnte ja später noch andere timeouts
geben. ;)

An Stelle der hart kodierten Liste könnte dann eine Empfehlung für
verschiedene Devices in der commandref bzw. im Wiki stehen (letzteres
hätte den Vorteil, dass auch andere sehr leicht ergänzen können).

Allerdings weiß ich gerade nicht, wie man dann am besten mit ganzen
Gruppen umgeht. Man möchte ja nicht für jeden FHT einzeln das
timeout-Attribut setzen müssen... Hmpf.

Gruß
Torsten

[Willi]

Das Modul muss mit dem Namen 99_Checkstate.pm im FHEM-Module-Verzeichnis abgespeichert werden.

Nach dem Restart oder "reload 99_Checkstate.pm" sollte man es mittels checkstate aufrufen werden können.

[Willi]

Hallo Torsten,

Du hast tolle Ideen,

Ändert Du das im Modul und checkst ins SVN das ein?

MfG Willi 

[Tom]

Hi Willi,

> Du hast tolle Ideen,
> Ändert Du das im Modul und checkst ins SVN das ein?

soll ich das jetzt als Ironie oder als Lob verstehen? :-/

Ich hab' noch nicht einmal einen Wiki-Zugang, geschweige denn SVN...
An meinen Programmierkenntnissen krankt es auch noch ziemlich, aber
immerhin haben schon 2 meiner Ideen zu brauchbaren Ergebnissen in der
Gruppe und im Wiki geführt.

Du schriebst ja, dass das bisherige Modul frühestens in einem Jahr
"spruchreif" sein würde - meine eigenen Projekterfahrungen zeigen,
dass man da doch oft noch was komplett wieder umwirft. Vielleicht sind
meine Anregungen dann nützlich; wenn nicht, bin ich auch nicht böse.
Ich weiß ja auch gar nicht, ob Du die Entwicklung überhaupt
diskutieren willst - sorry, wenn Du das als Kritik aufgefasst hast....

Gruß
Torsten

[Willi]

soll ich das jetzt als Ironie oder als Lob verstehen? :-/

Hallo Torsten,

sowohl als auch. War aber nicht böse gemeint.

Du schriebst ja, dass das bisherige Modul frühestens in einem Jahr
"spruchreif" sein würde - meine eigenen Projekterfahrungen zeigen,
dass man da doch oft noch was komplett wieder umwirft. Vielleicht sind
meine Anregungen dann nützlich; wenn nicht, bin ich auch nicht böse.

Kein Problem. Ich wusste nicht, dass Du gelesen hast, dass ich das Modul aus Zeitgründe nicht innerhalb der nächsten Monate wesentlich verbessern werde.

Generell finde ich Deine Änderungsvorschläge gut..

Zur Zeit ist das Modul erst mal eine Krücke, die ich für eigene Zwecke verwende, weil mir die Funktionalität in FHEM fehlte. Bei mir passiert es häufiger mal, dass ein Sensor nicht erreichbar ist oder sogar sich mein CULv3 sich mal wieder aufhängt (beim letzteren vermute ich langsam ein HW-Problem. Leider ist die Garantie abgelaufen...).

Mein Modul sollte erst mal ein Denkanstoss sein.

Evtl. wollen solch ein Modul ja noch mehr User einsetzen und evtl. findet jemand ja eine viel bessere Lösung als meine. Deshalb werde ich erst mal warten wie das Feedback und die Meinungen sind, bevor ich hier weitere Arbeit reinstecke.

 

Ich weiß ja auch gar nicht, ob Du die Entwicklung überhaupt
diskutieren willst - sorry, wenn Du das als Kritik aufgefasst hast....

War ein Missverständnis. Siehe oben.

MfG Willi 

[Tom]

>> soll ich das jetzt als Ironie oder als Lob verstehen? :-/

> sowohl als auch. War aber nicht böse gemeint.

ok, dann sind wir uns ja einig. ;)

> Zur Zeit ist das Modul erst mal eine Krücke, die ich für eigene Zwecke
> verwende, weil mir die Funktionalität in FHEM fehlte. Bei mir passiert es

geht mir ähnlich. Ich verwende daher für jeden FHT einen Watchdog und
nutze auch den Battery-Notify (mit dem bin ich aber auch nicht ganz
glücklich, denn kurz vor Schluß wird so ein FHT ganz schön hektisch -
und spätestens alle 30 min eine Mail nervt dann auch irgendwann).
Wäre schon cool, wenn man ein recht offenes "Systemstatus-Check-Modul"
hätte, was zumindest einen großen Teil erschlagen kann.

> Evtl. wollen solch ein Modul ja noch mehr User einsetzen und evtl. findet

hier! :D

> jemand ja eine viel bessere Lösung als meine. Deshalb werde ich erst mal
> warten wie das Feedback und die Meinungen sind, bevor ich hier weitere
> Arbeit reinstecke.

Ich fürchte, da werden eher weitere Wünsche kommen. :o)

Gruß
Torsten

[Dennis]

Ich würde es auch einsetzen :-)

Aus Endanwendersicht ( :-) ) würde ich mir wünschen das "unklare"
Sensoren
(Nicht aktiv / Bat Low) auch mit einem anderen Symbol auf dem
Floorplan angezeigt werden (können) bzw, einfach
"herausgefiltert" werden können.

Wäre es nicht schlau das "BatteryState" in "DeviceState" umzutaufen ?
Das könnte man doch gut
auswerten, denkbare Werte wären dann: Failure (z.B. Timeout), Alert
(z.B. für Benutzerdefinierte Wertüber/unterschreitungen), BatteryLow,
OK

Gruß Dennis

[KUD]

...HOHA. Da habe ich ja was losgetreten.

Ist  aber auch eine megadringende Angelegenheit.
Was nützen Sensoren, die ausfallen und die Aktoren warten das was kommt ?!
In meinem Fall läuft der Keller voll Wasser und die Pumpe denkt es ist alles trocken.
Also bitte, wenn irgendwie vertretbar das Modul verfügbar machen.
Auf der Webseite könnte doch eine Art Statuszeile, welche auf allen Ebenen sichtbar ist, solch ein Ausfall bemerkbar machen.
Vielleicht auch eine Meldung via MP3-Klingel ?

 

[Dennis]

Hallo Forum,

ich habe mich nun auch mal an Perl versucht und den Code von Willi neugeschrieben um besser zu verstehen was passiert - Dadurch ist 

der Code auch deutlich kleiner geworden.

"Meine" Version setzt voraus das die zu überwachenden Geräte das Attribut device_timeout (in min) gesetzt haben, 

das macht natürlich erstmal einmaligen Aufwand da man dieses Attribut nun bei jedem Gerät einstellen muss das man überwachen möchte. 

Desweiteren werden die Ergebnisse derzeit nur in das Log geschrieben.

Ich bin noch nicht so fit in Perl - Von daher würde ich mich freuen wenn der Code noch optimiert werden kann, 

z.B. müssten die Dummy Devices nicht mit durchgeloopt werden, da müsste eine REGEXP hin, regexp kann ich gar nicht :-(

Auch weiss ich nicht ob noch irgendetwas abgefangen werden muss.

Anstelle des Loggens sollte natürlich auch was sinnvolleres geschehen !

Testen konnte ich das nur mit den wenigen Devices die ich hier habe.

Aufruf über {checkstate2} Ergebnisse im fhem log !

Würde mich über konstruktives Feedback und Ergänzung des Code freuen !

Dennis

[AnonymousHolger]

HAllo Dennis,

ich bekomme es nicht ans laufen.

Habe die 99_Checkstate2.pm hochgeladen und mit reload 99_Checkstate2 aktiviert.

dann noch in die CFG folgendes statement (kurze Zeitspanne 1 Min. ist natürlich nur für Testzwecke)

define CheckStates at +*00:01:00 checkstate2
attr CheckStates room 5_SYSTEM

If Logfile gibt es nur Fehlermeldung:

Unknown command checkstate2, try help

Wo liegt mein Denkfehler ?

[Dennis]

Hi,

die { } müssen noch drumherum, da es sich um eine Perlfunktion handelt die noch nicht 

FHEM bekannt ist (wie das gemacht wird habe ich noch nicht erfahren).

Ich würde es auch noch nicht mit at aufrufen (da würde dein Logfile ggf. jede minute die 

gleichen Einträge bekommen).

Trag stattdessen {checkstate2} in das Textfeld ein, Enter drücken und dann sollte im FHEM 

Log das Resultat der Prüfung aufschlagen.

Schau mal ob das so funktioniert ;-)

Gruß Dennis

[Dennis G]

Moin,

ich habe mal wieder eine neue Version fertig:

Es muss als Parameter nun mitgegeben werden:

- LOG -> Ergebnis im fhem log

- HTML -> Ergebnis als html Tabelle (weblink basteln und im floorplan oder raum anzeigen),

sieht dann so aus, NEU: Devicename als Link !

- MAIL -> Ergebnis als Mail: Achtung, da es keine Globale Mailfunktionalität gibt muss die entsprechende Zeile 

               in dem Script angepasst werden (sucht nach "TODO" )

Beispielaufruf:

{checkstate2("html")}

Gerne Rückmeldung geben ob es bei euch funktioniert bzw. was verbessert werden kann !

Danke, Gruß ...

Dennis

[punker]

Wie könnte man diesen Vorschlag umsetzen?

mfg

Dieter

[Dennis G]

Mit 99_Checkstate2.pm (der Beitrag vor deinem) geht das (Anzeige von
Geräten die sich nicht mehr melden), werde versuche daraus am
Wochenende ein "offizielles"
FHEM Modul zu bauen, funktionieren tut es auch schon jetzt (und darf
auch gerne ausprobiert werden)....

Die Version die ich gerade in Arbeit habe gibt auch die Anzahl der
betroffenen Geräte mit, darauf kann man dann mit
einem Notify reagieren um z.B. eine Klingel anzusteuern...Ggf. setze
ich noch ein Reading bei den betroffenen Geräten welches dann auch
ausgewertet werden kann.

Gruß Dennis

On 16 Okt., 12:57, punker <punker...@googlemail.com> wrote:
> Wie könnte man diesen Vorschlag umsetzen?
>
> mfg
> Dieter
>
> Am Mittwoch, 26. September 2012 08:50:18 UTC+2 schrieb KUD:
>
>
>
>
>
> > ...HOHA. Da habe ich ja was losgetreten.
> > Ist  aber auch eine megadringende Angelegenheit.
> > Was nützen Sensoren, die ausfallen und die Aktoren warten das was kommt ?!
> > In meinem Fall läuft der Keller voll Wasser und die Pumpe denkt es ist
> > alles trocken.
> > Also bitte, wenn irgendwie vertretbar das Modul verfügbar machen.

> > *Auf der Webseite könnte doch eine Art Statuszeile, welche auf allen
> > Ebenen sichtbar ist, solch ein Ausfall bemerkbar machen.*
> > Vielleicht auch eine Meldung via MP3-Klingel ?- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

[Prof. Dr. Peter A. Henning]

In sicherheitskritischen Fällen sollte man die Anzeige nicht einer Webseite überlassen.

Bitte mal hier nachsehen: http://www.fhemwiki.de/wiki/Kategorie:Statusdisplay

Fall meine Bewässerung verdächtig lange läuft, gibt es z.B. ein nervtötendes Piepen.

LG

pah

[punker]

Hi Dennis,

das mit der 99_Checkstate2.pm hab ich schon ausprobiert und funzt einwandfrei.

Mit dem Umsetzen hab ich nur das hier von KUD gemeint:

"Auf der Webseite könnte doch eine Art Statuszeile, welche auf allen Ebenen sichtbar ist, solch ein Ausfall bemerkbar machen."

Wäre nicht schlecht und wenn vielleicht sogar die Farbe von grün (= alles OK) nach rot (= n.i.O) wechselt - bzw. ein Icon.

mfg

Dieter

[Dennis G]

Hi Dieter,

im Grunde ist man in der Umsetzung ja frei, die Checkstate soll ja nur die betroffenen Geräte ermitteln - Mit dem Rückgabewert kann man 

dann ja anfangen was man möchte (HTML ändern, E-Mail senden, Alarmhupe einschalten...)... Es ist ja eher unwahrscheinlich (Murphys Gesetz :-)) 

das man gerade auf der Website ist wenn etwas ausfällt ;-)

Gruß Dennis