HM-SEC-RHS und Sabotage Meldung

Begonnen von Guest, 12 April 2012, 19:26:41

Vorheriges Thema - Nächstes Thema

Guest

Originally posted by: <email address deleted>

Hallo zusammen,

ich unternehme seit heute meine allerersten Gehversuche mit FHEM und
nachdem die Inbetriebnahme des HM LAN Adapters schon mal geklappt hat und
ich auch 2 Sensoren angelernt habe, hier nun meine erste Frage :-/

Der HM-SEC-RHS (Sensor für den Fenstergriff) gibt im geschlossenen Zustand
keine Sabotage-Meldung aus. Wenn das Fenster gekippt oder offen ist, kein
Problem. Aber bei geschlossen kommt bei "inform on" nur ein "CUL_HM
bu_Fenster alive: yes". Müsste ad nicht eine Sabotagemeldung kommen?

Danke!

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

Guest

Originally posted by: <email address deleted>

Den hat hier wohl keiner? Da ich mir zum Testen erstmal nur einen bestellt
habe, würde mich mal interessieren, ob es sich um einen Defekt handelt, ich
einen Denkfehler habe oder ob das wirklich so implementiert ist.

Bei Letzterem wäre der Einsatz als zusätzlicher Alarmmelder ja ziemlich
sinnlos: Fenster einschlagen, Batteriedeckel auf, abschalten und gut ist?

MR

Am Donnerstag, 12. April 2012 19:26:41 UTC+2 schrieb Mario Ruprecht:
>
> Hallo zusammen,
>
> ich unternehme seit heute meine allerersten Gehversuche mit FHEM und
> nachdem die Inbetriebnahme des HM LAN Adapters schon mal geklappt hat und
> ich auch 2 Sensoren angelernt habe, hier nun meine erste Frage :-/
>
> Der HM-SEC-RHS (Sensor für den Fenstergriff) gibt im geschlossenen Zustand
> keine Sabotage-Meldung aus. Wenn das Fenster gekippt oder offen ist, kein
> Problem. Aber bei geschlossen kommt bei "inform on" nur ein "CUL_HM
> bu_Fenster alive: yes". Müsste ad nicht eine Sabotagemeldung kommen?
>
> Danke!
>

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

rudolfkoenig

                                                   

> Problem. Aber bei geschlossen kommt bei "inform on" nur ein "CUL_HM
> bu_Fenster alive: yes". Müsste ad nicht eine Sabotagemeldung kommen?

Du koenntest hmProtocolEvents einschalten, und mit inform pruefen ob fhem nicht
etwas verschweigt.

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

Guest

Originally posted by: <email address deleted>

Danke für die Antwort, mit dem, was da kommt, kann ich leider (noch) nicht
soviel anfangen.

Hier mal das Abziehen der Batteriekappe und das wieder aufstecken:
 HMLAN HMLAN1 RCV L:0D N:66 CMD:A610 (TYPE=16,WAKEMEUP,BCAST,BIDI,RPTEN)
SRC:150E83 DST:81A4E1 0601000E (INFO_SYSTEM_STATUS CHANNEL:01 STATUS:00
UNKNOWN:0E)
HMLAN HMLAN1 SND L:0D N:19 CMD:8002 (TYPE=2,RPTEN) SRC:81A4E1 DST:150E83
01010D00 (ACK_STATUS CHANNEL:01 STATUS:0D)
CUL_HM bu_Fenster alive: yes
HMLAN HMLAN1 RCV L:0D N:19 CMD:8002 (TYPE=2,RPTEN) SRC:81A4E1 DST:150E83
01010D00 (ACK_STATUS CHANNEL:01 STATUS:0D)

HMLAN HMLAN1 RCV L:0D N:67 CMD:A610 (TYPE=16,WAKEMEUP,BCAST,BIDI,RPTEN)
SRC:150E83 DST:81A4E1 06010000 (INFO_SYSTEM_STATUS CHANNEL:01 STATUS:00
UNKNOWN:00)
HMLAN HMLAN1 SND L:0D N:1A CMD:8002 (TYPE=2,RPTEN) SRC:81A4E1 DST:150E83
01010D00 (ACK_STATUS CHANNEL:01 STATUS:0D)
CUL_HM bu_Fenster cover: closed
CUL_HM bu_Fenster alive: yes
HMLAN HMLAN1 RCV L:0D N:1A CMD:8002 (TYPE=2,RPTEN) SRC:81A4E1 DST:150E83
01010D00 (ACK_STATUS CHANNEL:01 STATUS:0D)

Im Gegensatz hier das Abziehen der Kappe bei "geöffnetem" Fenster:
 HMLAN HMLAN1 RCV L:0D N:6B CMD:A610 (TYPE=16,WAKEMEUP,BCAST,BIDI,RPTEN)
SRC:150E83 DST:81A4E1 0601C80E (INFO_SYSTEM_STATUS CHANNEL:01 STATUS:C8
UNKNOWN:0E)
HMLAN HMLAN1 SND L:0D N:20 CMD:8002 (TYPE=2,RPTEN) SRC:81A4E1 DST:150E83
01010D00 (ACK_STATUS CHANNEL:01 STATUS:0D)
CUL_HM bu_Fenster cover: open
CUL_HM bu_Fenster sabotage
HMLAN HMLAN1 RCV L:0D N:20 CMD:8002 (TYPE=2,RPTEN) SRC:81A4E1 DST:150E83
01010D00 (ACK_STATUS CHANNEL:01 STATUS:0D)



Am Freitag, 13. April 2012 09:45:39 UTC+2 schrieb Rudolf Koenig:
>
> > Problem. Aber bei geschlossen kommt bei "inform on" nur ein "CUL_HM
> > bu_Fenster alive: yes". M�sste ad nicht eine Sabotagemeldung kommen?
>
> Du koenntest hmProtocolEvents einschalten, und mit inform pruefen ob fhem
> nicht
> etwas verschweigt.
>

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

rudolfkoenig

                                                   

Betrachten wir nur die "SRC:150E83" Zeilen, der Rest ist fhems ACK.

Hier mal das Abziehen der Batteriekappe und das wieder aufstecken:
... 0601000E ...
... 06010000 ...

Im Gegensatz hier das Abziehen der Kappe bei "geöffnetem" Fenster:
... 0601C80E  ...

Fhem entscheidet, dass nur dann sabotage vorliegt, falls dieser Wert (im
10_CUL_HM.pm mit $p fuer payload bezeichnet) dem regexp
   0601..0E entspricht, und dabei ".." nicht 00 ist.
Dieser Code hat mir Peter (aus Wien) zugeschickt.  Ob das jetzt so richtig ist
oder nicht, muss jemand mit solchen Geraeten, experimentieren (und etwas
Verstand :) entscheiden.

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

Guest

Originally posted by: <email address deleted>

Okay, verstehe.

Allerdings nicht, warum er gerade den Status im geschlossenen Zustand mit
Deiner Ausnahme 00 ignorieren sollte.

Hier mal die Werte von meinen Gerät:

=> Fenster geschlossen
Kappe offen: 0601000E
Kappe geschlossen: 06010000

==> Fenster gekippt
Kappe offen: 0601C80E
Kappe geschlossen: 0601C800

==> Fenster offen
Kappe offen: 0601640E
Kappe geschlossen: 06016400

Wenn ich mir die anderen Zustände so anschaue (Fenster auf/zu ohne
Sabotage), scheint eigentlich nur das letzte Byte mit dem Hexwert E auf
Sabotage schließen zu lassen, oder vereinfache ich hier zu sehr?

Vielleicht/hoffentlich meldet sich besagter Peter ja nochmal zu Wort ...

Danke auf jeden Fall, scheint ja dann zumindest kein HW-Defekt zu sein.

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

Oskar

                                                     

Ich hab mal geschaut...
Am 13.04.2012 um 10:47 schrieb Mario Ruprecht:
> Wenn ich mir die anderen Zustände so anschaue (Fenster auf/zu ohne Sabotage), scheint eigentlich nur das letzte Byte mit dem Hexwert E auf Sabotage schließen zu lassen, oder vereinfache ich hier zu sehr?

Scheinbar nicht, denn bei den sogenannten Shutter-Contact existiert überhaupt kein Wert für "Cover Open".  Das offene Gehäuse ist nur über den integrierten Sabotage-Kontakt erkennbar.  Ich hab das mal im SVN geändert, bei mir macht es jetzt das richtige, und sagt auch ob das Fenster offen, gekippt oder zu ist.

Eigentlich sollte Sabotage persistent sein, wird aber derzeit nach der nächsten Meldung mit geschlossenem Gehäuse überschrieben.  Solange ich keinen Plan habe, wie man den Status sinnvoll löschen könnte, lasse ich das erstmal so.  Wer das für Alarmzwecke nutzt, sollte halt drauf triggern und damit was anfangen ;-)

Grüße
   Oskar

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
--
fhem geht auch auf mac os x