HM-RC-4-2 Funkfernbedienung 4 Tasten: Unterschied zwischen den Versionen

Aktuelle Version vom 10. September 2019, 13:38 Uhr

HomeMatic Fernbedienung mit 4 Tasten in Form eines Schlüsselanhängers

Features

HomeMatic Fernbedienung mit 4 Tasten in Form eines Schlüsselanhängers, mit Status-LED, die in den Farben Grün, Rot und Orange leuchten bzw. blinken kann. Robuster Aufbau, Batterie ist eine normale Microzelle (AAA), Nachkauf daher günstiger als bei Sendern mit Knopfzellen, allerdings bedingt die Microzelle auch ein grösseres Gehäuse. Vorgänger der HM-RC-4-3.

Hinweise zum Betrieb mit FHEM

Anbindung der Fernbedienung an FHEM

Wie alle HomeMatic-Komponenten wird die Fernbedienung durch das Modul CUL_HM (oder eine echte CCU, s.u.) angebunden. Die Funkverbindung ist mittels eines HomeMatic IOs ("Funkschnittstelle") oder eines CUL/CUNx/COC etc. im HM-Mode möglich. Obwohl kein SEC im Name auftaucht, ist bei dieser Fernbedienung im Auslieferungszustand AES aktiv. Das Pairen mit HM IOs funktioniert ohne Probleme, für alle CUL Derivate muss unbedingt der Hinweis im Artikel AES Encryption im Abschnitt I/O-Device <-> Gerät beachtet werden. Die dort beschrieben Installation muss durchgeführt werden! Wenn irgend möglich ist die Einrichtung einer VCCU und das direkte pairen an die VCCU anstatt an eine physikalische Funkschnittstelle vorzuziehen.

Pairing der Fernbedienung mit FHEM

Pairen wie unter HomeMatic_Devices_pairen beschrieben. Die Taste zum pairen befindet sich hinter dem kleinen Loch auf der Rückseite der Fernbedienung. Mit aufgebogener Büroklammer oder ähnlich 3 Sekunden drücken.

Nach erfolgreichem Pairen sollte in etwa folgendes in der cfg stehen:

define CUL_HM_HM_RC_4_2_227C77 CUL_HM 227C77
attr CUL_HM_HM_RC_4_2_227C23 .devInfo 040000
attr CUL_HM_HM_RC_4_2_227C77 .stc 40
attr CUL_HM_HM_RC_4_2_227C77 firmware 1.1
attr CUL_HM_HM_RC_4_2_227C77 model HM-RC-4-2
attr CUL_HM_HM_RC_4_2_227C77 room CUL_HM
attr CUL_HM_HM_RC_4_2_227C77 serialNr KEQ0456756
attr CUL_HM_HM_RC_4_2_227C77 subType remote
define CUL_HM_HM_RC_4_2_227C77_Btn_01 CUL_HM 227C7701
attr CUL_HM_HM_RC_4_2_227C77_Btn_01 model HM-RC-4-2
attr CUL_HM_HM_RC_4_2_227C77_Btn_01 peerIDs 
attr CUL_HM_HM_RC_4_2_227C77_Btn_01 room CUL_HM
define CUL_HM_HM_RC_4_2_227C77_Btn_02 CUL_HM 227C7702
attr CUL_HM_HM_RC_4_2_227C77_Btn_02 model HM-RC-4-2
attr CUL_HM_HM_RC_4_2_227C77_Btn_02 room CUL_HM
define CUL_HM_HM_RC_4_2_227C77_Btn_03 CUL_HM 227C7703
attr CUL_HM_HM_RC_4_2_227C77_Btn_03 model HM-RC-4-2
attr CUL_HM_HM_RC_4_2_227C77_Btn_03 room CUL_HM
define CUL_HM_HM_RC_4_2_227C77_Btn_04 CUL_HM 227C7704
attr CUL_HM_HM_RC_4_2_227C77_Btn_04 model HM-RC-4-2
attr CUL_HM_HM_RC_4_2_227C77_Btn_04 room CUL_HM

Auswertung

Das Betätigen des Senders löst in der Regel mindestens zwei Events aus, da auch der Batteriestatus bei jeder Tastenbetätigung mit übermittelt wird.

Eine unspezifische Abfrage der Art:

define act_on_Taste4 notify CUL_HM_HM_RC_4_2_227C77_Btn_04 set Aktor1 on

wird also den Befehl "set Aktor1 on" 2x senden. Es ist daher in der Regel sinnvoll, das Button-Event explizit abzufragen, z.b. so:

define act_on_Taste4 notify CUL_HM_HM_RC_4_2_227C77_Btn_04:Short.* set Aktor1 on

Kurze Tastendrücke generieren Events der Form "Short 1_x". Short ist immer Short_1, bei Long zählt dies bei längeren Tastendrücken hoch. x ist ein fortlaufender Zähler, der bei jedem Tastendruck erhöht (und nach 255 zurückgesetzt) wird.

Für die Reaktion auf einen langen Tastendruck empfiehlt es sich nicht, als Regex für das Event nur "Long.*" zu wählen. Der längere Tastendruck würde sonst 4x je Sekunde ein neues Event auslösen und das Notify mehrfach triggern, solange die Taste gedrückt wird. Besser ist, sich auf Event in den ersten 3 Sekunden zu beschränken:

define act_on_Taste4 notify CUL_HM_HM_RC_4_2_227C77_Btn_04:Long.1.* set Aktor1 on

"Long.1.*" entspricht der (ersten) Reaktion eines Homematic-Gerätes. Der Punkt . zwischen Long und der Zahl ist der erforderliche Platzhalter für das _ im Event. Das Notify reagiert nach 3 Sekunden dann mehrfach auf alle Folgeevents wie Long_11, Long_12, Long_13 ... "Long.9.*" würde entsprechend erst bei sehr viel längerem Druck reagieren.

Alternativ ist es möglich, auf das Event "LongRelease" zu reagieren - dieses entsteht aber nur, wenn der Taste ein peer zugewiesen ist:

define act_on_Taste4 notify CUL_HM_HM_RC_4_2_227C77_Btn_04:LongRelease.* set Aktor1 on

Dieses Event entsteht nur einmal beim Loslassen der (länger) gedrückten Taste, ist aber u.U. haptisch ungünstiger, weil die Aktion erst beginnt, wenn die Taste losgelassen wurde.

LED / Rückantwort

Ohne weitere Maßnahmen wird der Empfang eines Befehls nicht an die Fernbedienung zurück gemeldet, d.h. die LED der Fernbedienung leuchtet nach Tastendruck Orange auf, um zu zeigen, dass der Befehl abgesetzt wurde. Die Rückmeldung, ob der Befehl empfangen wurde, wird aber von einem gepeerten Aktor veranlasst. Der Einsatz der Fernbedienung ist im Zusammenhang mit FHEM auch ohne Peering möglich und womöglich der Regelfall. Pairing mit FHEM allein reicht nicht aus. Will man die Fernbedienung mit keinem Aktor direkt peeren, wird daher keine Entität den Empfang des Tastendrucks bestätigen. Um dieses Problem zu umgehen, bieten sich diverse Varianten an. Im folgenden seien zwei beschrieben:

Einrichten eines virtuellen HM Devices

Es lässt sich eine virtuelle HM Instanz/Device einrichten, dessen einziger Zweck es ist, peerbare Channels zur Verfügung zu stellen. Zum einen können diese Channels dazu genutzt werden virtuelle Buttons zu erzeugen, die man auf der WebGUI platzieren kann, und die bei Betätigung direkt gepeerte HM-Aktoren bedienen, vor allem aber kann man Fernbedienung (oder sonstige Sensoren) mit den virtuellen Channels peeren, um eine Rückantwort (ACK) zu erhalten. Die Funktion des virtuellen IDvices ist dann nur zu bestätigen, dass es den Tastendruck empfangen hat.

Hierzu zunächst ein virtuelles HM Device anlegen, diese benötigt eine eigne HMID:

define <Virtual_Irgendeinname> CUL_HM 654321
attr <Virtual_Irgendeinname> hmClass receiver
attr <Virtual_Irgendeinname> subType switch

Bei der Vergabe der HMIS ist zu beachten, dass der Code 6stellig hexadezimal ist. Werden Buchstaben als Bestandteil der HMIC gewählt, müssen diese als Großbuchstaben angegeben werden. Die HMID muss anders sein als die vorhandener echter Funkschnittstellen oder einer eventuell eingerichteten VCCU.

Anschliessend die Anzahl der Cannels festelegen (es sind maximal 50 möglich, weniger ist besser):

set <Virtual_Irgendeinname> virtual 5

Abschliessend einen Button der Fernbedienung mit einem Channel peeren. Zuerst die kleine Taste auf der Rückseite der HM-RC-4-2 Funkfernbedienung drücken, wenn die LED Grün leuchtet den Befehl

set <HM-RC-4-2>_Btn_01 peerChan 0 <Virtual_Irgendeinname>_Btn1 single

absetzen, dann die zu peerende Taste (hier Button 1) drücken.

Wenn das Peering erfolgreich war, sollte die LED an der HM-RC-4-2 mehrmals schnell blinken.

Anschliessend wird jeder Tastendruck bei Empfang mit grün bestätigt (ACK) oder bei fehlerhaftem Empfang mit roter LED quittiert (NACK).

Dies sagt nichts über die tatsächliche Aktion aus, die FHEM ausführt, diese hängt davon ab, welche Abfragen und Aktionen definiert sind. Es wird durch den virtuellen Channel rein der Empfang der Nachricht quittiert. Es ist daher bei grenzwertiger Funklage auch denkbar, dass die grüne LED nicht leuchtet oder gar ein NACK gemeldet wird, FHEM die konfigurierte Aktion aber trotzdem ausführt.

Nutzung einer VCCU

Alternativ zum obigen Vorgehen können auch die virtuell Channels eine VCCU genutzt werden. Dazu zuerst die Anzahl der virtuellen Channels setzen:

set <VCCU> virtual 5

(es sind maximal 50 möglich, weniger ist besser)

Abschliessend einen Button der Fernbedienung mit einem Channel peeren. Zuerst die kleine Taste auf der Rückseite der HM-RC-4-2 Funkfernbedienung drücken, wenn die LED Grün leuchtet den Befehl

set <HM-RC-4-2>_Btn_01 peerChan 0 <VCCU>_Btn1 single

absetzen, dann die zu peerende Taste (hier Button 1) drücken.

Wenn das Peering erfolgreich war, sollte die LED an der HM-RC-4-2 mehrmals schnell blinken.

Anschliessend wird jeder Tastendruck bei Empfang mit grün bestätigt (ACK) oder bei fehlerhaftem Empfang mit roter LED quittiert (NACK).

Dies sagt nichts über die tatsächliche Aktion aus, die FHEM ausführt, dies hängt davon ab, welche Abfragen und Aktionen definiert sind. Es wird durch den virtuellen cannel rein der Empfang der Nachricht quittiert. Es ist daher bei grenzwertiger Funklage auch denkbar, das die grüne LED nicht leuchtet oder gar ein NACK gemeldet wird, FHEM die konfigurierte Aktion aber trotzdem ausführt.

Hinweis zum Anlegen der Channels bei der baugleichen ROTO_ZEL-STG-RM-HS-4

Bei der baugleichen ROTO_ZEL-STG-RM-HS-4 wird mit Stand Januar 2016 von autocreate zwar das device selbst automatisch angelegt, jedoch nicht die 4 Kanäle für die 4 Tasten. Die Kanäle müssen manuell angelegt werden. Startpunkt ist die HMID des device, z.B.

1907C9

Die Kanäle werden dann angelegt mit der HMID, an die die Kanalnummer 01...04 angehängt werden, also

Verwendet wird der reguläre define-Befehl, also

define <Kanalname> CUL_HM 1907C901

usw. Die Channels werden danach regulär unter dem device angezeigt und können bei Bedarf regulär gepeert werden.

Betrieb an einer CCU/CCU2/CCU3

Neben der oben beschriebenen Variante des Betriebs an einer VCCU/einem CUL kann der Handsender natürlich auch an einer "echten" CCU betrieben werden. Dazu muss der Handsender zuerst über die Bedienoberfläche der CCU angelernt werden. Danach kann die Integration in FHEM erfolgen. Die Herausforderungen sind ähnlich dem Betrieb an einer VCCU. Man möchte eine Rückmeldung (=grüne LED am Handsender) und eine Benachrichtigung (=Event) in FHEM.

Dazu gibt es Hinweise im Forum:

Ob die Events kommen, kann im Event Monitor von FHEM überprüft werden.

Wenn dort keine Events zu sehen sind oder nur das Event "hmstate:initialized" auftaucht, dann sollte bei dem CCU-Device, an das der Handsender anlegernt wurde, überprüft werden, ob das Attribut ccudev-readingfilter gesetzt wurde. Eventuell werden die Events des Handsenders deswegen weggefiltert. Zum Testen das Attribut einfach löschen.