Batterieüberwachung: ich bekomme es nicht hin

Begonnen von GoinAway, 30 Januar 2013, 17:57:03

Vorheriges Thema - Nächstes Thema

GoinAway

Hallo allerseits,
ich habe in meiner fhem.cfg u. a.

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

und mit
trigger Wasser Battery:low
in der Befehlszeile funktioniert das ja auch wunderbar.

Nun habe ich eine Batterie tatsächlich low gemacht, nämlich

NAME Wasser
PREVSTATE Closed, Low Batt
STATE Closed, Low Batt
TYPE CUL_FHTTK

Readings
Battery Low   2013-01-30 17:40:10
Previous Closed   2013-01-30 16:45:59
Reliability ok   2013-01-30 17:40:10
Sync Syncing   2013-01-30 16:28:11
Test Success   2013-01-16 10:46:16
Window Closed, Low Batt   2013-01-30 17:40:10

Nur leider kommt die Mail nicht.

Könnte mir bitte jemand sagen, was ich falsch mache ?

Rohan

Kannst du denn (überhaupt) per

{FB_mail('neubir@@gmail.com','FHEM Batteriewarnung','TestTestTest')}

Mails verschicken?

Und danke für deine Mail-Addy (wenn es denn die richtige ist) ;) .

Gruß
Thomas
Fhem auf Mini-ITX mit Celeron 2-Core, HMLAN (> 55 Devices), CUL (FS20 und EM), RFXtrx 433E, Arduino (einige DS18B20), RPi mit 1-Wire (DS2423 für S0-Signale, DS18B20+), RPi/Arduino mit MQ-5 und MQ-9 (CO- und CNG/LPG-Sensor), CO-20 IAQ Sensor

GoinAway

Hi, danke für die Antwort,
ich sagte doch oben bereits, dass es von der Befehlszeile aus funktioniert.

rahom

Hallo ratsuchender,

so wie es aussieht, stimmt dein Status

STATE Closed, Low Batt

nicht mit

define n_batt_chk notify .*:[Bb]attery.* { if("%" !~ m/ok/) {\

überein.

Du überprüfst auf [Bb]attery nicht ok   zb. STATE battery low
bei dir kommt aber Low Batt  und damit stimmt die Prüfung nicht.
Du musst also dein notify dahingehend ändern das es Low Batt üperprüft.

lg

rahom

Rohan

Hi,

Zitat von: Ratsuchender schrieb am Mi, 30 Januar 2013 22:04...ich sagte doch oben bereits ...

Sorry, überlesen.
Ich gelobe Besserung ;)

Gruß
Thomas
Fhem auf Mini-ITX mit Celeron 2-Core, HMLAN (> 55 Devices), CUL (FS20 und EM), RFXtrx 433E, Arduino (einige DS18B20), RPi mit 1-Wire (DS2423 für S0-Signale, DS18B20+), RPi/Arduino mit MQ-5 und MQ-9 (CO- und CNG/LPG-Sensor), CO-20 IAQ Sensor

GoinAway

Zitat von: rahom schrieb am Do, 31 Januar 2013 07:40
... Du überprüfst auf [Bb
attery nicht ok   zb. STATE battery low
bei dir kommt aber Low Batt  und damit stimmt die Prüfung nicht.

Hmm, ja, das es damit was zu tun hat ist mit klar.

Aber irgendwie habe ich einen wahrscheinlichen Denkfehler.

Ich dachte, ich prüfe allein den Battery-Status und nicht STATE ?

Wenn doch aber Battery != ok ist, dann ist doch die Bedingung erfüllt ?

*grübel*

UliM

Hi,
Du prüfst immer dann, wenn eine battery-message kommt, ob STATE ungleich ok ist, denn % enthält m.W. immer STATE, nicht den Wert des zuletzt übermittelten readings.

Es könnte also klappen mit
define n_batt_chk notify .*:[Bb]attery.* { if( (ReadingsVal("@","battery","") !~ m/ok/ ) || ( ReadingsVal("@","Battery","") !~ m/ok/ ) ) {\

=8-)
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

GoinAway

Danke Uli,
ist leider erfolglos, es ist wie vorher, der manuelle Aufruf in der Befehlszeile (wie oben) funktioniert,
automatisch leider nicht, obwohl doch

STATE      Closed, Low Batt
   Readings:
     2013-01-31 11:44:32   Battery         Low
     2013-01-31 11:39:19   Previous        Open, Low Batt
     2013-01-31 11:44:32   Window          Closed, Low Batt

Ich weiß nicht mehr weiter ...

rahom

um Dir weiter zu helfen, wäre es ganz sinnvoll wenn Du mal ein list von Deinem Gerät einstellst.
Damit können wir dann sehen was es überhaupt ist und was es für Readings es bringt.
Ich vermute nämlich das es überhaupt kein Reading namens battery hat. Dann kan es auch so gar nicht funktionieren.

Also mach bitte einmal

list <Gerätename>

lg
rahom

GoinAway

Hallo Rahom,
möchtest Du mal bitte im Post von mir von Do, 31 Januar 2013 11:50 über Dir schauen,
da ist doch der Auszug aus dem list.

rahom

hab ich doch glatt überlesen. Tomaten auf den Augen.
lg
rahom

GoinAway

Es ging um die Überwachung des Battery-Status der FHT80TF2, weil
ich diesen zum Zwecke der Meldung des Spannungsausfalls (an der Heizung) missbrauchen will, den Kontakt-Eingang brauche ich dann für die Ausfall-Meldung.
Merke: SpannungsausfallAnHeizung != Heizungsausfall

[Tip]
Um eine Unterspannung = Low Batt künstlich zu erzeugen muss man nur eine Diode in Flussrichtung in Reihe zu den Batterien schalten.
Ich habe mir aus zwei zugeschnittenen Kupferfolien und einem doppelseitigen Klebeband dazwischen einen Adapter gebaut, über den Kupferfolien ist die Diode eingelötet und ein Minischalter schließt die für Normalbetrieb kurz.

Meine batlow.cfg:define n_batlow notify .*:Window.* { if ( ReadingsVal("@","Battery","") !~ m/ok/ ) { \
  my $window_state=ReadingsVal("@", "Battery", "nA");;\
  my $deftype=$defs{@}{TYPE};;\
  return if ( $deftype ne "CUL_FHTTK" );;\
  if ( $defs{@}{PREVSTATE} ne $window_state ) { \
    my $fhttk_status=FHTTK_status;;\
    my $subject="FHEM: @ Batt: ".$window_state;; \
    FB_mail('irgendwer@@gmail.com',$subject,$fhttk_status);;\
    Log 3, "@: Battery ".$window_state;; } \
  }\
}

Einfach und geschacklos :-)
Wer es mag mag es mögen !

GoinAway


Moin,
ich komme doch nochmal auf das Thema zurück.

Zum Einen habe ich den Code ein wenig geändert:
 define contacts notify .*:Window.*() { \
 my $window_state=ReadingsVal("@", "Window", "nA");;\
 my $deftype=$defs{@}{TYPE};;\
 return if ( $deftype ne "CUL_FHTTK" );;\
 if ( $defs{@}{PREVSTATE} ne $window_state ) { \
   my $fhttk_status=FHTTK_status;;\
   my $subject="^ @ ".$window_state;; \
   FB_mail('xxxx@@yyyyy.zzz',$subject,$fhttk_status);;\
   Log 3, "@: Window ".$window_state;;\
 }\
}


Zum Anderen hat sich herausgestellt, dass das mit der Meldung Low Batt nicht immer zuverlässig funktioniert, weil
die Spannung bei Low Batt zu niedrig ist um den Sender zuverlässig anzusteuern bzw. das ausgesendete Signal zu schwach ist, um zuverlässig empfangen zu werden.
Im Nahfeld funktioniert das, über 2 Stockwerke hinweg nicht mehr.
Dies zur Warnung an alle, auf deren Basteltisch es (noch) funktioniert und dann in der Praxis doch nicht mehr.

Ich werde also wohl eine zeitliche Abfrage der letzen Meldung des CUL_FHTTK einbauen müssen, weiss aber noch nicht, wie das geht.
Vage Vorstellung:
Wenn die letzte Meldung zeitlich mehr als 30 Minuten zurück liegt, dann ist der CUL_FHTTK kaputt oder die Batterie leer, dann also Meldung.
Mal schauen, ob ich ein Beispiel finden kann.
Danke für die Aufmerksamkeit.

MisterEltako

Hi!

Vielleicht hilft dir nachfolgender Beitrag weiter, wenn du den Code entsprechend abwandelst:

Link

MfG, MisterEltako.
HMLAN-Konfigurations-Adapter, HM-Funkjalousieaktor/HM-Dimmaktor/HM-Schaltaktor f. Markenschalter, Jalousie-/Schaltaktor von Eltako, FT4 v. Eltako, TCM310

GoinAway

Danke, hilft mir nicht wirklich oder ich habe es mal wieder nicht verstanden.

Was mir fehlt ist der Vergleich, das kapiere ich nicht.

Ich habe die Readings der letzten Meldung:
Readings:
     2013-02-06 16:17:38   Battery         Low
     2013-02-06 16:05:33   Previous        Closed
     2013-02-06 16:17:38   Reliability     ok
     2013-02-05 17:20:02   Sync            Syncing
     2013-02-06 16:17:38   Window          Closed, Low Batt

und FHEM kennt sicherlich auch die aktuelle Uhrzeit.

Wie aber kommt man an den Zeitstempel ?
Wie aber kommt man an die Uhrzeit
Wie aber zieht man davon 1 Stunde ab ?
Wie vergleicht man die beiden Werte ?
Dabei ist wohl auch noch ein Format zu beachten ?