Alle 24 Stunden öffnet der HM-SEC-SC

[ThorstenH]

Hallo,

ich habe einen Fensterkontakt (HM-SEC-SC) zum Testen an fhem angelernt (HMLAN). In letzter Zeit habe ich den Kontakt aber in der Schublade belassen, da ich zum Testen keine Zeit habe. Komischerweise sendet der Kontakt trotzdem ungefähr alle 24 Stunden ein "open". Der Kontakt liegt sicher offen in der Schublade, da geht auch keiner dran.

Code Auswählen Erweitern

2013-09-23_11:21:11 threestatesensor_test alive: yes
2013-09-23_11:21:11 threestatesensor_test battery: ok
2013-09-23_11:21:11 threestatesensor_test sabotageError: off
2013-09-23_11:21:11 threestatesensor_test open
2013-09-23_11:21:11 threestatesensor_test contact: open (to HMLAN1)
2013-09-23_11:24:10 threestatesensor_test Activity: alive
2013-09-24_11:12:41 threestatesensor_test alive: yes
2013-09-24_11:12:41 threestatesensor_test battery: ok
2013-09-24_11:12:41 threestatesensor_test sabotageError: off
2013-09-24_11:12:41 threestatesensor_test open
2013-09-24_11:12:41 threestatesensor_test contact: open (to HMLAN1)
2013-09-25_11:03:39 threestatesensor_test alive: yes
2013-09-25_11:03:39 threestatesensor_test battery: ok
2013-09-25_11:03:39 threestatesensor_test sabotageError: off
2013-09-25_11:03:39 threestatesensor_test open
2013-09-25_11:03:39 threestatesensor_test contact: open (to HMLAN1)
Hat schon mal einer so was gehabt? Woran kann das liegen?

Ich habe nur einen Watchdog darauf (deshalb habe ich das überhaupt bemerkt)

Code Auswählen Erweitern

threestatesensor_test:open 00:00:05 threestatesensor_test:closed {
  system("/volume1/addons/fhem/bin/sendmail.sh", "Testkontakt offen", "Testkontak ist offen.");
  fhem("setstate watchdog_window_open_threestatesensor_test defined");
}Daran kann es doch auch nicht liegen, oder?

Auch das Zusammenspiel der anderen Fensterkontakte mit den Thermostaten hat bei mir auf Dauer noch nie so richtig gut geklappt, vielleicht hängt das ja damit zusammen.

Viele Grüße
Thorsten

[ThorstenH]

Ich brauche auch nur das Gehäuse öffnen und es kommt eine mail:

Gehäuse noch zu (Schalter dabei immer offen):
Activity alive 2013-09-27 10:46:19
Activity: unknown 2013-09-21 22:40:30
alive yes 2013-09-27 20:14:32
battery ok 2013-09-27 20:14:32
contact open (to HMLAN1) 2013-09-27 20:14:32
sabotageError off 2013-09-27 20:14:32
state open 2013-09-27 20:14:32


Gehäuse geöffnet:
Activity alive 2013-09-27 10:46:19
Activity: unknown 2013-09-21 22:40:30
alive yes 2013-09-27 20:16:41
battery ok 2013-09-27 20:16:41
contact open (to HMLAN1) 2013-09-27 20:16:41
sabotageError on 2013-09-27 20:16:41
state open 2013-09-27 20:14:32

[betateilchen]

Einmal pro Tag wacht der Sensor automatisch auf, das liegt am alive-Cycle Prinzipiell kannst Du das durchaus abschalten

Mit dem Triggern auf "open" musst Du bei den Dingern aufpassen. Der Sabotagekontakt schickt nämlich ebenfalls ein "open" wenn das Gehäuse geöffnet wird.
Ein open kommt nicht immer zwingend vom Magnetkontakt.

In letzter Zeit habe ich den Kontakt aber in der Schublade belassen, da ich zum Testen keine Zeit habe.

Pragmatische Lösung: Batterie raus.

[ThorstenH]

Hi,

aber woran erkenne ich denn jetzt, ob

• der Kontakt geöffnet wurde
• ein alive Signal kam
• das Gehäuse geöffnet wurde

?

Mit dem alive kommt ja auch der Batteriestatus, deshalb möchte ich es nicht abschalten. Der alive-Cycle steht auf 028:00, nicht auf 24 Stunden. Komisch, dass das Signal nach 24 Stunden kommt.

[betateilchen]

Das hier ist die actCycle Meldung:

Code Auswählen Erweitern

2013-09-23_11:24:10 threestatesensor_test Activity: alive


Das hier ist die "Fenster auf" Meldung - nur zwei Zeilen:

Code Auswählen Erweitern


2013-09-27 21:06:39 CUL_HM Melder_FKl offen
2013-09-27 21:06:39 CUL_HM Melder_FKl contact: offen (to HMUSB)



Das hier ist Meldung, wenn das Gehäuse geöffnet wird:

Code Auswählen Erweitern


2013-09-27 21:07:58 CUL_HM Melder_FKl alive: yes
2013-09-27 21:07:58 CUL_HM Melder_FKl battery: ok
2013-09-27 21:07:58 CUL_HM Melder_FKl sabotageError: on
2013-09-27 21:07:58 CUL_HM Melder_FKl zu
2013-09-27 21:07:58 CUL_HM Melder_FKl contact: zu (to HMUSB)


Es wird also zusätzlich zum Alarm (sabotageError) auch noch der komplett Status des Sensors gesendet.

Das mit dem Gehäusedeckel "open" ist bei einem anderen Sensor (RHS), nicht beim SC, sorry das hab ich vorhin verwechselt.



---

[ThorstenH]

Ok, vielleicht habe ich mich zu ungenau ausgedrückt. Wie erkennt mein watchdog den Unterschied?

[betateilchen]

Schalte den ActCycle ab.

[martinp876]

Hi,

verstehe ich nicht ganz.

der SC sollte ein Register "cyclicInfoMsg" haben, das steht IM device. Solange das an ist sendet der SC einmal am Tag den Zustand. Ausserdem würde er zu diesem Zeitpunkt seine command-queue abarbeiten.

Du kannst es also ausschalten mit folgenden effekten :
- keine regelmäßige zustandsmeldung
- action-detector sollte abgeschaltet werden (actCycle auf off setzen). Sonst wird er das device auf "dead" setzen (auch kein Problem... nur ein Eintrag)
- commandos werden nur noch mit "Config" (anlerntaste) abgearbeitet.
- kein Batteriestatus mehr

Alternativen:
- attr event-in-change .*
es wird nur ein event bei Aenderung gesendet. Dann sollte nur eine email kommen, wenn der zustand von zu/tilt nach auf wechselt

der sabotagekontakt sollte mit "offen/zu" nichts zu tun haben, das ist ein anderer Parameter
Dass aufgrund des sabotage-kontakts eine meldung gesendet wird ist mit neu (nicht ausgeschlossen). i.A. werden sollche "conditions" immer nur zusammen mit anderer info gesendet, lösen also nie eine message aus sondern fahren nur mit.

Gruss Martin

[ThorstenH]

Hallo,

erst mal danke für die Beiträge. Was ich eigentlich nicht will, ist den Testkontakt abschalten, sei es durch Batterie raus oder Abschalten der zyklischen Meldungen. Ich hatte nur diesen Effekt, dass die zyklischen Meldungen nicht nur "alive" senden, sondern auch  "open". Das wollte ich nur verstehen und wissen, ob das normal ist (habe ich  jetzt verstanden, ist normal). Schliesslich ist das nicht der einzige Kontakt bei mir im Haus.

Fehlte noch: wie damit umgehen, z.B. anhand des Watchdogs.

Alternativen:
- attr event-in-change .*
es wird nur ein event bei Aenderung gesendet. Dann sollte nur eine email kommen, wenn der zustand von zu/tilt nach auf wechselt

Dadurch würde der Watchdog nur ausgelöst, falls es tatsächlich eine Änderung gibt?

Das wäre eine Lösung für den Watchdog. Wie sieht es mit den TCs aus, die mit einem Kontakt gepeert sind? Also "Fenster auf, Temperatur runter". Kann der TC mit diesem Attribut des SC leben? Oder wirkt sich das Attribut nur in fhem intern aus?


Zur Sabotagemeldung an fhem/HMLAN[/b]

Wenn ich das Gehäuse öffne kommt:
FHEM LOG:

Code Auswählen Erweitern

2013.09.28 08:59:28.315 1: HMLAN_Parse: HMLAN1 R:E1E7C35   stat:0000 t:019DF95F d:FF r:FFBB     m:2C A610 1E7C35 DE7474 0601C80E

Wenn ich den Kontakt öffne kommt:
FHEM LOG

Code Auswählen Erweitern

2013.09.28 08:54:20.829 1: HMLAN_Parse: HMLAN1 R:E1E7C35   stat:0000 t:01994815 d:FF r:FFC0     m:23 A441 1E7C35 DE7474 010EC8
2013.09.28 08:54:20.925 1: HMLAN_Send:  HMLAN1 S:S6358B9DE stat:  00 t:00000000 d:01 r:6358B9DE m:23 8002 DE7474 1E7C35 0101C800
2013.09.28 08:54:21.218 1: HMLAN_Parse: HMLAN1 R:R6358B9DE stat:0002 t:00000000 d:FF r:7FFF     m:23 8002 DE7474 1E7C35 0101C800

In beide Fällen kommt jeweils ein:

Code Auswählen Erweitern

CUL_HM threestatesensor_test contact: open (to HMLAN1)

im telnet mit "inform timer 1".

[betateilchen]

Dass aufgrund des sabotage-kontakts eine meldung gesendet wird ist mit neu

Dann hast Du grade wieder was dazugelernt. Natürlich sendet der Kontakt eine Meldung (on/off), wenn der Sabotagekontakt auslöst - genau das ist ja Sinn des Kontaktes. Der lässt sich genau wie die eigentlich offen/zu Erkennung (der hier diskutierte SC kennt kein tilt) abfangen und sofort einen Alarm auslösen.

Beim RHS heißt der Sabotagekontakt übrigens "cover" mit open/close.

[martinp876]

@udo: man lernt nie aus. ich dachte mich zu erinnern, dass jemand dies gegenteilig getestet hat. nun, wenn man die Devices nicht selbst hat und testet.. Danke

@Thorsten,
event-on-change beeinflusst in keiner weise das verhalten der HM-devices untereinander, also wenn sie direkt gepeert sind.
FHEM erlaubt sich - nein, ist so eingestellt - dass alle messages möglichst komplett dekodiert und gemeldet werden. ein SC sendet einen trigger mit status und alle 24h eine statusmeldung, auch mit status. Es ist also normal, dass so ein trigger mehrfach kommen kann.
event-on-change beeinflusst das erzeugen von triggern in FHEM. beachte auch event-on-update. du kannst filtern, welche Ereignisse nur bei aenderung einen trigger erzeugen und welche immer.
Im allgemeinen ist zu empfehlen möglichst alles auf event-on-change zu setzen. das spart deinem system einiges an rechenzeit. Das datum in Readings ist dennoch aktuell.

Gruss Martin

[ThorstenH]

EDIT: Selbst schuld. Ich habe gestern Nacht ein update meiner Disk Station gemacht. Die Konfiguration hatte ich nicht per Save gespeichert, also war das attribut wieder weg. Daher habe ich...

...heute morgen um 09:16 wieder eine mail bekommen:

Code Auswählen Erweitern

2013-09-28_09:15:04 threestatesensor_test sabotageError: off
2013-09-28_09:15:08 threestatesensor_test sabotageError: on
2013-09-28_09:15:23 threestatesensor_test sabotageError: off
2013-09-28_09:15:29 threestatesensor_test open
2013-09-28_09:15:29 threestatesensor_test contact: open (to HMLAN1)
2013-09-28_09:18:04 threestatesensor_test sabotageError: on
2013-09-28_09:24:57 threestatesensor_test sabotageError: off
2013-09-29_01:04:24 threestatesensor_test Activity: unknown
2013-09-29_09:16:07 threestatesensor_test alive: yes
2013-09-29_09:16:07 threestatesensor_test battery: ok
2013-09-29_09:16:07 threestatesensor_test sabotageError: off
2013-09-29_09:16:07 threestatesensor_test open
2013-09-29_09:16:07 threestatesensor_test contact: open (to HMLAN1)
2013-09-29_09:24:24 threestatesensor_test Activity: alive

Blöd, aber ist nun mal so. Warte ich halt nochmal 24 Stunden...

[ThorstenH]

Bis jetzt keine mail mehr vom watchdog.
Danke!
Thorsten