Fenster Drehgriffkontakt HM-Sec-RHS

[Guest]

Originally posted by: <email address deleted>

Hallo,

ich habe mir einen HM Dregriffkontakt (HM-Sec-RHS) zugelegt und mir sind da
noch ein paar Dinge unklar. Hat jemand Erfahrung mit dem Sensor?

Ich habe den Kontakt direkt mit dem zugehörigen HM-CC-TC gepairt. Musste
dazu übrigens den -TC resetten und anschließend neu mit FHEM pairen.
Mit FHEM selbst habe ich den Kontakt nicht gepairt, da es für die reine
Statusanzeige ja reichen sollte, wenn FHEM nur mitlauscht.

Der Sensor schickt 3 Status ( open, closed, tilted ), aber nicht bei einem
Wechsel von tilted zu open oder umgekehrt. Liegt das daran, dass den -TC
nur der Unterschied zwischen offen und geschlossen interessiert? Lässt sich
das ändern, indem man den Kontakt zusätzlich mit fhem pairt?

Was mich außerdem wundert: Wenn ich das Fenster öffne oder schließe, zeigt
der Thermostat das unmittelbar an. Ich dachte, die TCs machen den Funk nur
alle 2-3 Minuten an. Wieso funktioniert das mit dem Sensor sofort? Saugt
der TC seine Batterie jetzt schneller leer, weil ein Fensterkontakt gepairt
ist?

Gruß
Carsten

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

[Guest]

Originally posted by: <email address deleted>

Hallo Carsten,

devicepair ist bei HM nicht bidirektional. Keines der beiden Devices kennt
sein gegenueber. Demnach koenne sie sich auch nichtaufeinder einstellen.

Wenn du willst solltest du aber ueber FHEM die devices pairen koennen und
den pairing status auslesen koennen.

Mit FHEM sollte - wenn alles klappt - ein abgesetzter pairing request auf
den Stack landen und beim TC beim naechsten wakeup eingebaut werden -
automatisch.
Beim RHS genauso - nur steht dertimeout bei 88200 - also dauert es etwa
einen Tag.
=> schickt dein RHS jeden tag eine "70" message?

Und noch etwas: Sobald das TC seinen peer hat sollte es funktionieren. ein
sender (also dein RHS) braucht operationell nicht gepairt zu sein. Hier hat
es nur den nutzen, dass du eine Meldung bekommts (rote LED?) wenn der
gepairte empfaenger nicht antwortet

Gruss
Martin

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

[Guest]

Originally posted by: <email address deleted>

Hallo.

Wenn du willst solltest du aber ueber FHEM die devices pairen koennen und
> den pairing status auslesen koennen.
>

Wie gesagt. Solange FHEM mitlesen kann, reicht mir das. Mittlerweile kommen
auch die Wechsel von open zu tilted und umgekehrt an. Keine Ahnung, warum
das am Sonntag nicht ging.

Beim RHS genauso - nur steht dertimeout bei 88200 - also dauert es etwa
> einen Tag.
> => schickt dein RHS jeden tag eine "70" message?
>
>
Der Sensor läuft erst seit Sonntag Nachmittag. Im Log steht am Anfang ein
"alive:yes / battery: ok". Seitdem nur die Open/Tilted/Closed - Meldungen.


Was ich aber immer noch nicht verstehe, ist, wieso der TC die RHS-Meldungen
unmittelbar empfangen kann, obwohl er ja angeblich aus Energiespargründen
nur alle 2-3 Minuten den Funk anmacht.


Gruß

Carsten
 

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

[rudolfkoenig]

                                                   

> Was ich aber immer noch nicht verstehe, ist, wieso der TC die RHS-Meldungen
> unmittelbar empfangen kann, obwohl er ja angeblich aus Energiespargründen
> nur alle 2-3 Minuten den Funk anmacht.

Hypothese: Der verwendete CC1101 unterstuetzt Wake-on-Radio: Die MCU wird vom
CC1101 geweckt, falls fuer eine bestimmte Zeit Radiosignale anlegen. Dieses
Zeit-Intervall kann man programmieren, und sein Wert kenne ich nicht.
MWn verwendet MAX! diesen Feature.

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

[Guest]

Originally posted by: <email address deleted>

>
> Hypothese: Der verwendete CC1101 unterstuetzt Wake-on-Radio: Die MCU wird
> vom
> CC1101 geweckt, falls fuer eine bestimmte Zeit Radiosignale anlegen.
> Dieses
> Zeit-Intervall kann man programmieren, und sein Wert kenne ich nicht.
> MWn verwendet MAX! diesen Feature.
>

Klingt plausibel.

Das hieße dann, dass zumindest meine Sorge unbegründet ist, dass der
Batterieverbrauch des TCs jetzt durch Dauerfunken dramatisch ansteigt.
Richtig?

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

[Guest]

Originally posted by: <email address deleted>

> Klingt plausibel.
>
> Das hieße dann, dass zumindest meine Sorge unbegründet ist, dass der
> Batterieverbrauch des TCs jetzt durch Dauerfunken dramatisch ansteigt.
> Richtig?
>

zum Empfangen muss ich nicht senden.  Und der Empfaender sollte deutlich
weniger verbrauchen als der Sender.
Die Sender sind hoffentlich immer aus, wenn nicht gerade eine Message raus
muss - bei allen Devices.

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

[Guest]

Originally posted by: <email address deleted>

Die Anleitung sagt dazu auf S.18 folgendes:

"Sobald ein Tür-Fenster-Kontakt bzw. ein Fenster-Dreh- griffkontakt an den Wandthermostat angelernt wurde, ak- tiviert dieser seinen WAKE-ON-RADIO-MODE, damit die Ereignismitteilungen die vom Tür-Fenster-Kontakt bzw. Tür-Fens- ter-Drehgriff gesendet werden, empfangen werden können. Dies hat zu Folge dass der Stromverbrauchs des Gerätes ansteigt und dadurch die Batterielebensdauer gesenkt wird."

Link: http://www.elv-downloads.de/service/manuals/78480_HM_CC_TC_UM.pdf

LG
Alex

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

[Guest]

Originally posted by: <email address deleted>

Danke für den Hinweis.

Das habe ich komplett überlesen. Dann werd ich mal abwarten, wieviel
schneller die Batterie den Geist aufgibt.

Am Dienstag, 2. Oktober 2012 22:15:16 UTC+2 schrieb Alex:
>
> Die Anleitung sagt dazu auf S.18 folgendes:
>
> "Sobald ein Tür-Fenster-Kontakt bzw. ein Fenster-Dreh- griffkontakt an
> den Wandthermostat angelernt wurde, ak- tiviert dieser seinen
> WAKE-ON-RADIO-MODE, damit die Ereignismitteilungen die vom
> Tür-Fenster-Kontakt bzw. Tür-Fens- ter-Drehgriff gesendet werden,
> empfangen werden können. Dies hat zu Folge dass der Stromverbrauchs des
> Gerätes ansteigt und dadurch die Batterielebensdauer gesenkt wird."
>
> Link: http://www.elv-downloads.de/service/manuals/78480_HM_CC_TC_UM.pdf
>
> LG
> Alex

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

[Guest]

Originally posted by: <email address deleted>

Alex,

Klar, dass auch der Empfaenger strom braucht.
Ist aber interessant fuer die Handhabung und programmierung - evtl muss man
das Verhalten unterscheiden...
Danke
Martin

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

[Guest]

Originally posted by: <email address deleted>

Mit FHEM sollte - wenn alles klappt - ein abgesetzter pairing request auf
> den Stack landen und beim TC beim naechsten wakeup eingebaut werden -
> automatisch.
> Beim RHS genauso - nur steht dertimeout bei 88200 - also dauert es etwa
> einen Tag.
> => schickt dein RHS jeden tag eine "70" message?
>
>
Noch ein Nachtrag dazu.

So wie es aussieht, schickt der Kontakt alle 23:51h ein Alive, wenn er
zwischendurch nichts anderes zu melden hatte:

Am Dienstag wurde das Fenster um 8:54 geschlossen. Seitdem nicht mehr
geöffnet.
Am Mittwoch kam um 8:45 Uhr ein
alive: yes
battery: ok
contact: closed

Heute kam die gleiche Meldung um 8:36 Uhr.

Laut ELV-FAQ kann man diesen Intervall bei allen Sec-Sensoren auch
konfigurieren. Da ich es aber nicht als Alarmanlage nutze ( Bei einem
Drehgriffsensor auch irgendwie eine seltsame Idee ), reicht mir das so.

Unschön finde ich nur, dass bei einem Senden an das Gerät der letzte
gesendete Befehl statt dem Status im WEB angezeigt wird. Also z.B.
"statusRequest" statt "Geschlossen". Da ich aber eigentlich auch keinen
Grund habe, Befehle an den Sensor zu schicken, ist das auch kein wirkliches
Problem.

Gruß

Carsten

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

[Guest]

Originally posted by: <email address deleted>

Hallo Carsten,

beim RHS ist ein cyclic timeout von 88200 angegeben - das sind sicher
Sekunden, also ein Tag. Warum es nciht genau stimmt weiss ich nicht.
Wie ich es sehe ist es nicht an die absolute Zeit gebunden - sondern
einfach nur zyklisch
Wie man die Message abschaltet, koennte ich dir sagen - List0, register 9
stellt es ein.

Kannst du einmal List0 auslesen? Evtl steht der Timer dort, beschrieben ist
er nicht explizit.

Auslesen sollte mit 'set getConfig' oder mit ' set getRegRaw
List0 0' funktionieren

Gruss
Martin

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

[Guest]

Originally posted by: <email address deleted>

Nachtrag zum state:
mit statusRequest sollte es wieder funktionieren.
halt- der RHS funktioniert nur bei wakeup und config... da geht wohl auch
ein statusRequest nicht.

Nachdem es mir auch nicht gefaellt such ich noch nach einer Loesung
requests und status zu trennen.

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

[ext23]

                                                 

>
> Der Sensor schickt 3 Status ( open, closed, tilted ), aber nicht bei einem
> Wechsel von tilted zu open oder umgekehrt. Liegt das daran, dass den -TC
> nur der Unterschied zwischen offen und geschlossen interessiert? Lässt sich
> das ändern, indem man den Kontakt zusätzlich mit fhem pairt?
>

So schaut es aus wenn er mit FHEM gepaired ist:

2012-09-26_06:39:45 wz_Fenster tilted
2012-09-26_07:25:57 wz_Fenster open
2012-09-26_07:25:58 wz_Fenster closed
2012-09-26_18:36:36 wz_Fenster open
2012-09-26_20:45:23 wz_Fenster closed
2012-09-27_06:35:02 wz_Fenster open
2012-09-27_06:35:03 wz_Fenster tilted
2012-09-27_07:30:14 wz_Fenster closed
2012-09-28_06:18:08 wz_Fenster open
2012-09-28_06:18:09 wz_Fenster tilted
2012-09-28_06:41:16 wz_Fenster closed

 

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