FHEM Forum

                                                 

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




 

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                 

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);
}

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

>
> 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/
/g;  # Multi-line
  $a =~ s/&/&/g;
  $a =~ s/"/"/g;
  $a =~ s/  $a =~ s/>/>/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 = "\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 .= "
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 .= " ";
  }
  if ($battery_str ne "") {
  $str .= "\n- The following devices have low battery:\n".$battery_str;
$subject .= " ";
  }

  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;

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

Ich vergass: Das Modul wird einfach mit
checkstate
in der FHEM-Kommandozeile aufgerufen.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                 

Am Dienstag, 25. September 2012 18:47:28 UTC+2 schrieb Willi:
>
> Ich vergass: Das Modul wird einfach mit
> checkstate
> in der FHEM-Kommandozeile aufgerufen.
>
>
Hmm - das will trotz shutdown restart nicht ?!?!?
Muss man da noch was initialisieren oder so?
 

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                 

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

Hallo Torsten,

Du hast tolle Ideen,

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

MfG Willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                 

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                 

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                 

...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 ?


>  
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                 

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

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 ?




Am Freitag, 5. Oktober 2012 16:12:08 UTC+2 schrieb 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
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                 

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

Am Sonntag, 7. Oktober 2012 10:42:04 UTC+2 schrieb 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 ?
>
>
>
>
> Am Freitag, 5. Oktober 2012 16:12:08 UTC+2 schrieb 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
>>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                 

Moin,

ich habe 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)
- 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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                 

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                       

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 ?
>
>
>>  
>>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                 

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 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 -

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                       

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



Am Dienstag, 16. Oktober 2012 13:41:43 UTC+2 schrieb 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 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 -
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                 

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

Am Dienstag, 16. Oktober 2012 15:58:23 UTC+2 schrieb 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
>
>
>
> Am Dienstag, 16. Oktober 2012 13:41:43 UTC+2 schrieb 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 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 -
>>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

>
>
> 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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                 

>> 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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com