Ungereimtheiten - Beobachtungen

[GoinAway]

Hallo allerseits,
Ihr habt inzwischen sicher mitbekommen, dass meine Programmierkenntnisse beschränkt sind und ich im wesentlichen durch Abschreiben und Ausprobieren dazulerne.

Aufgefallen ist mir nun, dass hier gut Vorgedachtes manchmal nicht (mehr) richtig funktioniert.

Wenn man dies so hat:

CUL_FHTTK

Haustuer   Closed
Kuechenfenster   Closed
Kuechentuer   Closed
z_Heizung   Closed, Low Batt
z_Wasser   Open

und benutzt dies

define n_Fenster notify .*:Window.*(Open|Closed) { \
  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="FHEM: @ ".$window_state;; \
    FB_mail('irgendwer@@gmail.com' (@@gmail.com'),$subject,$fhttk_status);;\
    Log 3, "@: Window ".$window_state;;\
  }\
}

und die dazu passende 99_marte.pm (wie in der Wiki beschrieben)

dann werden Kontakte, die nur auf Closed oder Open wechseln, korrekt gemeldet.

Nicht gemeldet werden die Kontakte, die den Status wechseln und zusätzlich Low Batt mitbringen.

NAME       z_Heizung
   NR         53
   OPEN       0
   PREVSTATE  Closed, Low Batt
   STATE      Closed, Low Batt
   TYPE       CUL_FHTTK

   Readings:
     2013-01-31 16:31:42   Battery         Low
     2013-01-31 16:10:11   Previous        Open
     2013-01-31 16:31:42   Reliability     ok
     2013-01-31 16:31:42   Window          Closed, Low Batt

Das ist natürlich sehr unschön, da muss der Einbrecher nur warten, bis die Battery leer ist :-)

Leider bin ich zu blöde, das geradezubiegen,
aber vielleicht findet sich ja jemand nettes ....

[Zrrronggg!]

Unabhängig vom Sachverhalt zu dem ich nicht viel sagen kann:

Das ist natürlich sehr unschön, da muss der Einbrecher nur warten, bis die Battery leer ist :-)

Da kann er aber lange warten. Ich habe von den  FHTTK-2 (also die neuere kleine Baufrom) ca. 6 Stück im Einsatz und NOCH NIE eine Batterie gewechselt.
Das älteste ist in Folie eingeschweisst als Sensor an meinem Einfahrtstor angebracht und somit Wind, Wetter und der vollen Bandbreite Berliner Lufttemperaturen von Sommer 30 bis Winter -20 Grad ausgesetzt.

Seit 2009.

Mit der ersten Batterie (ich habe allerdings eine "gute" gekauft nicht die beigelegte.)

[GoinAway]

Die FHT80TK-2 benutze ich auch. Und Du magst ja auch Recht haben.

Ich bin auf einem anderen Weg draufgekommen.

Ich wollte mit einem FHT80TK-2 2 Funktionen erschlagen, nämlich

1. über den Battery-Status erfahren, ob die Stromversorgung der Heizung generell ausgefallen ist ?
Dazu hätte ein gold-Cap noch eine Weile die Spannung bereitgestellt zum Melden.

2. der Kontakt an der Klemme sollte mir melden, wenn die Heizung auf Störung geht.

Darum bastle ich mit dem Battery Low herum.

Dennoch ist die nicht funktionierende Funktion unschön, weil unvollständig.

Dann werde ich mir wohl etwas anderes einfallen lassen müssen *schluchz*

[Zrrronggg!]

Ja, ich verstehe. Das Teil eignet sich an sich recht gut zu kreativem Basteln.

Allerdings tritt das Problem ja wohl mehr Softwareseitig auf. Die von dir genutzen Snippets sind ja für einen bestimmten Zewck gedacht und man muss die ja je nach deiner Anwendung gar nicht nutzen, bzw. die erscheine mir je nach dem was du machen willst auch als übertrieben komplex.

Paar Gedanken dazu:

1. Die Goldcap-Nummer brauchst du gar nicht. Der Vorteil des FHT80TK-2 ist ja, das er alle 2 Minuten seinen Zustand meldet, egal ob der sich geändert hat oder nicht. .H. du musst eigentlich "nur" pürfen, ob in den letzten z.B. 4-6 Minuten IRGENDEINE Meldung von dem Dingen reingekommen ist. Wenn du das Dinge mit einem Netzteil parallel zur Heizungsspanungsversorgung betreibst, kommt im Fall eines Stromausfalls keine Meldung mehr und voila!

2. Ob der Status sich geändert hat (und das ist es ja was du brauchst) kriegt man meiner Auffassung nach wesentlich einfacher hin als mit dem Giganto-konstrukt und einer 99-Datei. Der eigentliche Zweck unten ist ja eine Liste bei merhern kontakten anzufertigen, wenn ich das richtig sehe... das macht es etwas umfangreicher. Was du willst ist ja nur ein Auschnitt davon, wenn ich das recht verstehe.
2.1   Erstmal müsste es ja sowieso reichen, wenn das Dingen auf "open" ist (oder je nachdem wie du Klemme im Störungsfall belegst), denn ob das VORHER auch open war ist im Störungsfall ja herzlich egal. Eigentlich WILL man doch sogar, das die Störungsmeldung kommt, solange die Störung besteht, oder?
2.2   Selbst wenn nicht: Den vorherigen Zustand in ein Dummy kippen und ein define<blubber> notify TK:open {if Value("dummy") ne "open"   {fhem{"mach dies und jenes ...")} }   und fertig.  Wenn du nicht sowieso gleich die FHEM Funktion oldvalue benutzt.

Ich meine vielleicht verstehe ich das alles noch nicht richtig, aber ich habe den Eindruck, du machst es dir unnötig komplex und was du machen willst geht (leichter)

[broadway]

Hallo,
 ich nutze auch den FHTTK zur Störungsüberwachung der Heizung. Ein Relais am Störungsausgang der Heizung zur potentialfreien Kopplung wird an die Klemme des FHTTK angeschlossen. Bei Störung wird eine e-mail verschickt und ein dummy zeigt die Störung an bis sie von mir quittiert wird.

Die Idee von Zrongg werde ich noch aufnehmen, um zu merken, wenn die Batterie leer ist. Unten meine Definition. Sieht sehr lang aus, vieles ist aber für room, group, icon, eventmap, etc. also eher optische Einstellungen. Das sieht dann so aus:

(http://i.imgur.com/bVZLHYH.jpg)

Code Auswählen Erweitern

# Heizung Störmeldung mit Fensterkontakt
define Hz.Stoer.TFK CUL_FHTTK 3dbffc
attr Hz.Stoer.TFK IODev CUL_0
attr Hz.Stoer.TFK eventMap Closed:Stoerung Open:OK
attr Hz.Stoer.TFK group Stoermeldung
attr Hz.Stoer.TFK icon icoBlitz
attr Hz.Stoer.TFK model FHT80TF
attr Hz.Stoer.TFK room Heizung

# dummy speichert Störmeldung, bis sie quittiert wurde
define Hz.Stoerung dummy
attr Hz.Stoerung group Stoermeldung
attr Hz.Stoerung room Heizung
attr Hz.Stoerung webCmd quittiert

# e-mail, wenn Störung erkannt, erfordert DebianMail Prozedur in 99_Utils.pm
define Hz.Stoer.Notify notify Hz.Stoer.TFK:Window:.Stoerung {\
                if(Value("Hz.Stoer.Mail") ne "sent"){\
                        fhem "set Hz.Stoer.Mail sent";;\
                        fhem "set Hz.Stoerung aufgetreten $mday.$month.$year $hour:$min";; \
                        DebianMail('adresse@@provider.de','Heizung Stoerung',Value("Hz.Stoerung"));;\
                }\
}
attr Hz.Stoer.Notify group Stoermeldung
attr Hz.Stoer.Notify room Heizung

# zeigt an, ob e-mail geschickt wurde (um sie nur 1x zu schicken)
define Hz.Stoer.Mail dummy
attr Hz.Stoer.Mail group Stoermeldung
attr Hz.Stoer.Mail icon icoMail
attr Hz.Stoer.Mail loglevel 6
attr Hz.Stoer.Mail room Heizung

# Quittieren der Störmeldung
define Hz.Stoer.Quitt notify Hz.Stoerung:quittiert set Hz.Stoer.Mail -
attr Hz.Stoer.Quitt group Stoermeldung
attr Hz.Stoer.Quitt room Heizung

[broadway]

Noch mal das gleiche aufs Wesentliche beschränkt:

Code Auswählen Erweitern

# Heizung Störmeldung mit Fensterkontakt
define Hz.Stoer.TFK CUL_FHTTK 3dbffc
attr Hz.Stoer.TFK eventMap Closed:Stoerung Open:OK

# dummy speichert Störmeldung, bis sie quittiert wurde
define Hz.Stoerung dummy
attr Hz.Stoerung webCmd quittiert

# e-mail, wenn Störung erkannt, erfordert DebianMail Prozedur in 99_Utils.pm
define Hz.Stoer.Notify notify Hz.Stoer.TFK:Window:.Stoerung {\
                if(Value("Hz.Stoer.Mail") ne "sent"){\
                        fhem "set Hz.Stoer.Mail sent";;\
                        fhem "set Hz.Stoerung aufgetreten $mday.$month.$year $hour:$min";; \
                        DebianMail('tw.castell@@arcor.de','Heizung Stoerung',Value("Hz.Stoerung"));;\
                }\
}

# zeigt an, ob e-mail geschickt wurde (um sie nur 1x zu schicken)
define Hz.Stoer.Mail dummy
attr Hz.Stoer.Mail loglevel 6

# Quittieren der Störmeldung
define Hz.Stoer.Quitt notify Hz.Stoerung:quittiert set Hz.Stoer.Mail -

[GoinAway]

Danke für die Antworten und die Komfortlösung oben,
ich habe solange rumprobiert bis dies herauskam:
Link
Vielleicht hilfts ja wem :-)