FHEMWiki - Benutzerbeiträge [de]

HM-ES-PMSw1-Pl Funk-Schaltaktor 1-fach mit Leistungsmessung

2016-11-22T17:45:29Z

Hokascha: /* Links */

{{Infobox Hardware
|Bild=HM-ES-PMSw1-PI-Frontansicht.jpg
|Bildbeschreibung=Frontansicht
|HWProtocol=HomeMatic
|HWType=Aktor (Zwischenstecker) mit Leistungsmessung
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=6
|HWVoltage=230V
|HWPowerConsumption=<0,6W
|HWPoweredBy=Netz
|HWSize=59 x 123 x 40mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}

'''HM-ES-PMSw1-Pl'''
[[HM-ES-PMSw1-Pl Funk-Schaltaktor 1-fach mit Leistungsmessung|HM-ES-PMSw1-Pl]] ist ein [[HomeMatic]] Funk-Schaltaktor in Zwischenstecker-Ausführung, der über die Schaltfunktion hinaus auch Informationen über den aktuellen Verbrauch der angeschlossenen Verbraucher sowie über die anliegende Spannung und Netzfrequenz liefert. Dieser Aktor ist seit dem 20.12.2013 verfügbar.

Ein Gerät mit gleichem Funktionsumfang ist als [[HM-ES-PMSw1-DR Hutschienen-Schaltaktor mit Leistungsmessung|HM-ES-PMSw1-DR]] für die Hutschienenmontage verfügbar.

[[Datei:HM-ES-PMSw1-PI-Seitenansicht.jpg|thumb|HM-ES-PMSw1-PI Seitenansicht]]

== Features ==
HomeMatic Funk-Schaltaktor mit Leistungsmessung für zwei Funktionsbereiche:
* Schalten von angeschlossenen Verbrauchern (Schaltkanal)
* Messen von Spannung, Strom, Wirkleistung, Frequenz und Energieverbrauch (Messkanal)
* Automatische Schalten von angelernten Aktoren beim Über- oder Unterschreiten von definierten Schwellwerten (Sensorkanäle)

Der Schaltkanal kann angeschlossene Verbraucher oder angelernte HomeMatic Aktoren ein- bzw. ausschalten.
Der Messkanal verfügt über eine Messfunktion und Empfangs- sowie Übertragungsmöglichkeit von Messdaten (z.B. Spannung, Strom, Wirkleistung, Frequenz und Energieverbrauch bis 3680 Watt/16 A). Die Messdaten werden je nach Verbraucherverhalten in Abständen von einigen Sekunden bis mehreren Minuten übertragen, der Sendezyklus kann durch verschiedene Register konfiguriert werden (Änderungsschwellwerte). Des weiteren kann er - in Abhängigkeit von definierbaren Schwellwerten (Über- / Unterschreitung) - andere Aktoren schalten.

'''Technische Daten:'''
* Spannungsversorgung: 230 V/50 Hz
* Stromaufnahme: 16 A max.
* Leistungsaufnahme Ruhebetrieb: < 0,6 W
* Max. Schaltleistung: 3680 W (ohmsche Last)
* Schutzart: IP 20
* Relais: Schließer
* Schaltzyklen: 50.000 bei cosφ=1
* Abmessungen (B x H x T): 59 x 123 x 40 mm
* Gewicht: 165 g (ohne Netzstecker)
* Messauflösung Leistung: 0,01 W
* Messbereich Leistung: 0–3.680 W
* Messgenauigkeit Leistung: 1 % ±0,03 W
* Messauflösung Strom: 1 mA
* Messbereich Strom: 0–16 A
* Messgenauigkeit Strom: 1 % ±1 mA
* Messauflösung Spannung: 0,1 V
* Messbereich Spannung: 200–255 V
* Messgenauigkeit Spannung: 0,5 % ±0,1 V
* Messauflösung Frequenz: 0,01 Hz
* Messbereich Frequenz: 48,72–51,27 Hz
* Messgenauigkeit Frequenz: 0,1 % ±0,01 Hz

(Angaben ohne Gewähr)

== Hinweise zur Inbetriebnahme und Installation ==
Der PMSw1 funktioniert "out-of-the-box", nachdem er an Fhem angelernt (gepairt) worden ist.

Das [[Pairing (HomeMatic)|Pairing]] sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.

== Betrieb mit FHEM ==
Der PMSw1 verfügt über insgesamt 6 Kanäle (HM-Jargon: channels), von denen der Schaltkanal (Kanal 1) und der Messkanal (Kanal 2) in FHEM primär genutzt werden. Die Kanäle 3 - 6 sind zur Konfiguration der Schaltvorgänge [[Peering (HomeMatic)|gepeerter]] Aktoren bei Änderungen des Leistungsverbrauchs (Kanal 3), des Stromverbrauchs (Kanal 4), der elektrischen Spannung (Kanal 5) oder der Frequenz (Kanal 6). Diese Kanäle können ausschließlich über Register konfiguriert werden.

=== Channels (Kanäle) 01 bis 06 ===
==== Channel 01 (_Sw) ====
Der eigentliche Schaltkanal, über den die am PMSw1 eingesteckten Verbraucher ein- und ausgeschaltet werden können.

Log-Datei des Kanals:

<Datum>_<Zeit> HMPMSW_01_Sw set_on
<Datum>_<Zeit> HMPMSW_01_Sw level: 100 %
<Datum>_<Zeit> HMPMSW_01_Sw pct: 100
<Datum>_<Zeit> HMPMSW_01_Sw deviceMsg: on (to HMLAN1)
<Datum>_<Zeit> HMPMSW_01_Sw timedOn: off
<Datum>_<Zeit> HMPMSW_01_Sw set_off
<Datum>_<Zeit> HMPMSW_01_Sw level: 0 %
<Datum>_<Zeit> HMPMSW_01_Sw pct: 0
<Datum>_<Zeit> HMPMSW_01_Sw deviceMsg: off (to HMLAN1)
<Datum>_<Zeit> HMPMSW_01_Sw timedOn: off

==== Channel 02 (_Pwr) ====

Der Messkanal des PMSw1, über den die momentane Netzspannung, die Frequenz (in Hz), die aktuellen Verbrauchswerte (Last, Watt) sowie die seit Inbetriebnahme umgewandelte Leistung ("Verbrauch", Wh) usw. an die Zentrale (hier Fhem) übermittelt werden.

Log-Datei des Kanals:

<Datum>_<Zeit> HMPMSW_01_Pwr energy: 153.2
<Datum>_<Zeit> HMPMSW_01_Pwr power: 90.92
<Datum>_<Zeit> HMPMSW_01_Pwr current: 427
<Datum>_<Zeit> HMPMSW_01_Pwr voltage: 233.4
<Datum>_<Zeit> HMPMSW_01_Pwr 50: -
<Datum>_<Zeit> HMPMSW_01_Pwr boot: on
<Datum>_<Zeit> HMPMSW_01_Pwr energy: 153.8
<Datum>_<Zeit> HMPMSW_01_Pwr power: 80.85
<Datum>_<Zeit> HMPMSW_01_Pwr current: 384
<Datum>_<Zeit> HMPMSW_01_Pwr voltage: 232.2
<Datum>_<Zeit> HMPMSW_01_Pwr 50: -
<Datum>_<Zeit> HMPMSW_01_Pwr boot: on
<Datum>_<Zeit> HMPMSW_01_Pwr energy: 157.5
<Datum>_<Zeit> HMPMSW_01_Pwr power: 86.41
<Datum>_<Zeit> HMPMSW_01_Pwr current: 409
<Datum>_<Zeit> HMPMSW_01_Pwr voltage: 232.6
<Datum>_<Zeit> HMPMSW_01_Pwr 50: -
<Datum>_<Zeit> HMPMSW_01_Pwr boot: on

==== Channel 03 (_SenPwr) ====

Dieser Sensorkanal beinhaltet die Logik für eine automatische Schaltung aller angelernten Aktoren auf Basis des '''momentanen Leistungsverbrauchs''' (Überschreitung oder Unterschreitung) der angeschlossenen Verbraucher. Mittels der verfügbaren Register kann man genau einstellen, nach welchen Bedingungen aufgrund des '''momentanen Leistungsverbrauches''' ein Schaltbefehl gesendet werden soll.

Log-Datei des Kanals (verfügbaren Register):

<Datum>_<Zeit> HMPMSW_01_SenPwr R-cndTxCycBelow: 0
<Datum>_<Zeit> HMPMSW_01_SenPwr R-txThrLoPwr: 200 W
<Datum>_<Zeit> HMPMSW_01_SenPwr R-transmitTryMax: 6
<Datum>_<Zeit> HMPMSW_01_SenPwr R-cndTxCycAbove: 200
<Datum>_<Zeit> HMPMSW_01_SenPwr R-cndTxFalling: off
<Datum>_<Zeit> HMPMSW_01_SenPwr R-txThrHiPwr: 100 W
<Datum>_<Zeit> HMPMSW_01_SenPwr R-cndTxRising: off
<Datum>_<Zeit> HMPMSW_01_SenPwr R-ledOnTime: 0.5 s

Dieser Kanal dient nur zum Auslesen und Setzen der Register für die Schaltautomaik und stellt daher keine Readings oder speziellen Kommandos zur Verfügung.

==== Channel 04 (_SenI) ====
Dieser Sensorkanal beinhaltet die Logik für eine automatische Schaltung aller angelernten Aktoren auf Basis des '''momentanen Stromverbrauchs''' (Überschreitung oder Unterschreitung) der angeschlossenen Verbraucher. Mittels der verfügbaren Register kann man genau einstellen, nach welchen Bedingungen aufgrund des '''momentanen Stromverbrauchs''' ein Schaltbefehl gesendet werden soll.

Log-Datei des Kanals (verfügbaren Register):

<Datum>_<Zeit> HMPMSW_01_SenI R-cndTxCycBelow: 0
<Datum>_<Zeit> HMPMSW_01_SenI R-txThrLoCur: 20 mA
<Datum>_<Zeit> HMPMSW_01_SenI R-transmitTryMax: 6
<Datum>_<Zeit> HMPMSW_01_SenI R-cndTxCycAbove: 200
<Datum>_<Zeit> HMPMSW_01_SenI R-cndTxFalling: off
<Datum>_<Zeit> HMPMSW_01_SenI R-txThrHiCur: 10 mA
<Datum>_<Zeit> HMPMSW_01_SenI R-cndTxRising: off
<Datum>_<Zeit> HMPMSW_01_SenI R-ledOnTime: 0.5 s

Dieser Kanal dient nur zum Auslesen und Setzen der Register für die Abschaltautomatik und stellt daher keine Readings oder speziellen Kommandos zur Verfügung.

==== Channel 05 (_SenU) ====
Dieser Sensorkanal beinhaltet die Logik für eine automatische Schaltung aller angelernten Aktoren auf Basis der aktuell anliegenden '''elektrischen Spannung''' (Überschreitung oder Unterschreitung). Mittels der verfügbaren Register kann man genau einstellen, nach welchen Bedingungen auf Basis der '''elektrischen Spannung''' ein Schaltbefehl durchgeführt werden soll.

Log-Datei des Kanals (verfügbaren Register):

<Datum>_<Zeit> HMPMSW_01_SenU R-cndTxCycBelow: 0
<Datum>_<Zeit> HMPMSW_01_SenU R-transmitTryMax: 6
<Datum>_<Zeit> HMPMSW_01_SenU R-txThrLoVlt: 24 V
<Datum>_<Zeit> HMPMSW_01_SenU R-cndTxCycAbove: 200
<Datum>_<Zeit> HMPMSW_01_SenU R-cndTxFalling: off
<Datum>_<Zeit> HMPMSW_01_SenU R-txThrHiVlt: 22 V
<Datum>_<Zeit> HMPMSW_01_SenU R-cndTxRising: off
<Datum>_<Zeit> HMPMSW_01_SenU R-ledOnTime: 0.5 s

==== Channel 06 (_SenF) ====
Dieser Sensorkanal beinhaltet die Logik für eine automatische Schaltung aller angelernten Aktoren auf Basis der '''Frequenz''' (Überschreitung oder Unterschreitung) der anliegenden Spannung. Mittels der verfügbaren Register kann man genau einstellen, nach welchen Bedingungen auf Basis der '''Frequenz''' ein Schaltbefehl durchgeführt werden soll.

Die Abschaltung erfolgt dann selbstständig durch den Aktor.

Log-Datei des Kanals (verfügbaren Register):

<Datum>_<Zeit> HMPMSW_01_SenF R-cndTxCycBelow: 0
<Datum>_<Zeit> HMPMSW_01_SenF R-txThrHiFrq: 49.8 Hz
<Datum>_<Zeit> HMPMSW_01_SenF R-txThrLoFrq: 50.2 Hz
<Datum>_<Zeit> HMPMSW_01_SenF R-transmitTryMax: 6
<Datum>_<Zeit> HMPMSW_01_SenF R-cndTxCycAbove: 200
<Datum>_<Zeit> HMPMSW_01_SenF R-cndTxFalling: off
<Datum>_<Zeit> HMPMSW_01_SenF R-cndTxRising: off
<Datum>_<Zeit> HMPMSW_01_SenF R-ledOnTime: 0.5 s

Dieser Kanal dient nur zum Auslesen und Setzen der Register für die Abschaltautomatik und stellt daher keine Readings oder speziellen Kommandos zur Verfügung.

=== Beispielkonfiguration ===
Ein Master-Slave-Beispiel aus dem [http://forum.fhem.de/index.php/topic,32840.msg253040.html#msg253040 Forum] um einen HM-ES-PMSw1-Pl mit einem HM Aktor zu [[Peering (HomeMatic)|peeren]]:

Es gibt vier Sensorkanäle: Leistung (03), Strom (04), Spannung (05) und Frequenz (06). Wenn in Abhängigkeit vom Strom geschaltet werden soll, wird der Strom-Komparator-Channel mit einem Aktor gepeert.

set HM-ES-PMSw1-Pl_Senl peerChan 0 hm_aktor set

Dann wird der Komparator eingestellt. Hier werden die Events konfiguriert die der Komparator an den Aktor senden soll. Eine Übersicht gibt es mit <code>get regList</code>:

list: register | range | peer | description
1: cndTxCycAbove | literal | | cyclic trigger if level is above cndTxDecAbove options:on,off
1: cndTxCycBelow | literal | | cyclic trigger if level is below cndTxCycBelow options:on,off
1: cndTxDecAbove | 0 to 255 | | level for cndTxCycAbove
1: cndTxDecBelow | 0 to 255 | | level for cndTxCycBelow
1: cndTxFalling | literal | | trigger if falling options:on,off
1: cndTxRising | literal | | trigger if rising options:on,off
1: ledOnTime | 0 to 1.275s | | LED ontime
1: sign | literal | | signature (AES) options:on,off
1: transmitTryMax | 1 to 10 | | max message re-transmit
1: txThrHiCur | 0 to 16000mA | | threshold low current
1: txThrLoCur | 0 to 16000mA | | threshold high current
4: expectAES | literal | required | expect AES options:on,off
4: peerNeedsBurst | literal | required | peer expects burst options:on,off

Zuerst musst entschieden werden, was wie geschaltet werden soll: bei welchem Strom soll ein-/ausgeschaltet werden. Bei positiver oder negativer Flanke. Sollen die Schaltbefehle permanent wiederholt werden, oder nur bei Änderung kommen und welche Schaltwerte sollen bei den Ereignissen gesendet werden.

Beispiel, 2 Events erzeugen:
#wenn i von unter 10mA nach über 100mA wechselt, wird ein Event mit dem Wert 200 gesendet (daraus machen wir später im Aktor ein on).
#wenn i von über 100mA nach unter 10mA wechselt, wird ein Event mit dem Wert 0 gesendet (daraus machen wir später im Aktor ein off).

Schaltschwellen definieren:

txThrHiCur 100
txThrLoCur 10

Cyclisches Senden abschalten:

cndTxCycAbove off
cndTxCycBelow off

Beide Schaltflanken auswerten, positiv soll anschalten, negativ soll ausschalten:

cndTxFalling on
cndTxRising on

und zum Schluss die Werte setzen, die der Messsensor bei den Events übermitteln soll. Zur Erinnerung: positive Flanke => 200 und negative Flanke => 0:

cndTxDecAbove 200
cndTxDecBelow 0

Danach wird im Aktor festgelegt, was beim Eintreffen von den Werten 0,200 geschehen soll.

=== event Monitor ===
<Bitte ergänzen>

=== fhem.log Auszug ===

2013.12.29 19:06:11.957 3: CUL_HM Unknown device CUL_HM_HM_ES_PMSw1_Pl_24A920, please define it
2013.12.29 19:06:11.976 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920 CUL_HM 24A920 A1A5B840024A9200000001400AC4B455130393635383038513F0100
2013.12.29 19:06:11.994 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920 FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920
2013.12.29 19:06:16.879 3: Device CUL_HM_HM_ES_PMSw1_Pl_24A920 added to ActionDetector with 000:10 time
2013.12.29 19:06:16.889 3: CUL_HM pair: CUL_HM_HM_ES_PMSw1_Pl_24A920 powerMeter, model HM-ES-PMSw1-Pl serialNr KEQ0965808
2013.12.29 19:06:16.998 3: Device CUL_HM_HM_ES_PMSw1_Pl_24A920 added to ActionDetector with 000:10 time
2013.12.29 19:06:17.905 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw CUL_HM 24A92001
2013.12.29 19:06:17.909 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw
2013.12.29 19:06:18.906 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr CUL_HM 24A92002
2013.12.29 19:06:18.909 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr
2013.12.29 19:06:19.906 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr CUL_HM 24A92003
2013.12.29 19:06:19.909 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr
2013.12.29 19:06:20.906 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI CUL_HM 24A92004
2013.12.29 19:06:20.910 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI
2013.12.29 19:06:21.907 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU CUL_HM 24A92005
2013.12.29 19:06:21.974 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU
2013.12.29 19:06:22.096 2: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_24A920 getConfig
2013.12.29 19:06:22.917 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF CUL_HM 24A92006
2013.12.29 19:06:22.921 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF
2013.12.29 19:06:28.968 2: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw statusRequest
2013.12.29 19:06:29.980 2: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU getConfig
2013.12.29 19:06:33.990 2: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF getConfig

=== fhem.cfg ===
<pre>define CUL_HM_HM_ES_PMSw1_Pl_24A920 CUL_HM 24A920
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 .devInfo 3F0100
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 .stc 51
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 IODev LANCUL
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 actCycle 000:10
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 actStatus alive
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 autoReadReg 4_reqStatus
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 expert 2_full
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 firmware 1.4
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 peerIDs
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 room CUL_HM
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 serialNr KEQ0965808
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 subType powerMeter
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 webCmd getConfig

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920 FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920 logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920 room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw CUL_HM 24A92001
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr CUL_HM 24A92002
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr peerIDs
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr CUL_HM 24A92003
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI CUL_HM 24A92004
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU CUL_HM 24A92005
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF CUL_HM 24A92006
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF room CUL_HM
</pre>

=== Loggen von Werten ===
Leider werden die Verbauchswerte nicht automatisch geloggt, das von FHEM angelegte Log sammelt nur Informationen des Haupt-Devices.

Damit hier auch die Verbrauchs- und Stromwerte mitgeloggt werden, muss man dies dem Log des Haupt-Device (bevorzugt per WebInterface) hinzufügen.

Am Ende sollte die entsprechende Definition wie folgt aussehen:
:<code>define FileLog_Keller.Waeschetrockner FileLog ./log/Keller.Waeschetrockner-%Y.log Keller.Waeschetrockner|Keller.Waeschetrockner_Pwr:.*</code>

Die Devicenamen sind natürlich an die vorliegenden Gegebenheiten anzupassen.

=== Plots/Grafiken ===
Hier ein Beispielplot für den Channel 02 (Pwr):

[[Datei:HM-ES-PMSw1-PI cut.jpg|Plot des HM-ES-PMSw1-PI (Channel 02)]]

Inhalt der zugehörigen gplot-Datei (SVG_FileLog_HMPMSW_01_Pwr_1.gplot):

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "Energie"
set y2label "Power"

#FileLog 4:HMPMSW_01_Pwr.energy\x3a::
#FileLog 4:HMPMSW_01_Pwr.power\x3a::

plot "<IN>" using 1:2 axes x1y1 title 'Energie' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Power' ls l1 lw 1 with lines

und die Definitionen dafür beim Device (fhem.cfg):

define SVG_FileLog_HMPMSW_01_Pwr_1 SVG FileLog_HMPMSW_01_Pwr:SVG_FileLog_HMPMSW_01_Pwr_1:CURRENT

== Tipps ==
Um dafür zu sorgen, dass nach einem Stromausfall der Aktor den Schaltausgang von sich aus auf "An" stellt (Default ist "Aus"), kann man wie folgt vorgehen:

# Device auf übliche Weise mit Fhem pairen
# Interne Peers/Register für Fhem aktivieren <code>set <deviceName> regSet intKeyVisib visib</code>
# Erneutes getConfig auf das Device durchführen <code>set <deviceName> getConfig</code>
# Ch01 (Sw) mit Ch05 (SenU) peeren <code>set <deviceName>_SenU peerChan 0 <deviceName>_Sw single set</code>
# Erneutes getConfig auf das Device durchführen <code>set <deviceName> getConfig</code>
# Register auf Ch01 (Sw) setzen <code> set <deviceName>_Sw regSet lgSwJtDlyOff on self01 </code> <code> set <deviceName>_Sw regSet lgSwJtOn on self01 </code> <code> set <deviceName>_Sw regSet shSwJtDlyOff on self01 </code> <code> set <deviceName>_Sw regSet shSwJtOn on self01 </code> <code> set <deviceName>_Sw regSet lgSwJtDlyOff on self05 </code> <code> set <deviceName>_Sw regSet lgSwJtOn on self05 </code> <code> set <deviceName>_Sw regSet shSwJtDlyOff on self05 </code> <code> set <deviceName>_Sw regSet shSwJtOn on self05 </code>
# Register auf Ch05 (SenU) setzen <code> set <deviceName>_SenU regSet cndTxRising on </code> <code> set <deviceName>_SenU regSet txThrHiVlt 200 </code> <code> set <deviceName>_SenU regSet txThrLoVlt 180 </code>

== Bekannte Probleme ==
* Sobald der PMSw1 selbst von der Spannungsversorgung getrennt worden ist, verliert er die bisherigen Verbrauchswerte.
* Nach einem Stromausfall steht der Schalter auf "Aus", das angeschlossene Gerät ist also ebenfalls aus. Dies kann - falls man den Aktor nur zur reinen Verbrauchsmessung verwendet - bei der Messung von z.B. Kühlschrank, Kühltruhe oder Heizung zu unerfreulichen Auswirkungen führen. Eine Abhilfe schaffen die unter [[#Tipps|Tipps]] aufgeführten Register-Einstellungen.
: Mit der Firmware 2.5 wurde am 16.3.2015 im Switch-Channel das Register powerUpAction eingeführt.

== Links ==
* [http://files.elv.de/Assets/Produkte/13/1302/130248/Downloads/130248_schaltaktor_messen_um.pdf Manual]
* [http://files.elv.de/Assets/Produkte/13/1302/130248/Downloads/130248_schaltaktor_messfunktion_data.pdf Datenblatt]
* [http://www.eq-3.de/produkt-detail-aktoren/items/homematic-funk-schaltaktor-1-fach-mit-leistungsmessung-zwischens.html Produktinfo]
* [http://www.meintechblog.de/2014/01/homematic-funk-steckdose-mit-leistungsmessung-deine-waschmaschine-ist-fertig/ Beispiel-Anwendung]
[[Kategorie:HomeMatic Components]]
[[Kategorie:Energieverbrauchsmessung]]
[[Kategorie:Schalter (Empfänger)]]

Virtueller Controller VCCU

2016-10-24T14:28:26Z

Hokascha: Typos

Eine '''Virtuelle CCU''', auch '''VCCU''' genannt, ist eine Zentrale für [[HomeMatic]]-Geräte. Die VCCU tritt beim [[Pairing (HomeMatic)|Pairing]] an die Stelle des ''I/O-Devices'' (auch "Schnittstelle" genannt, zum Beispiel [[CUL]] und [[HM-CFG-LAN]]).

HomeMatic-Geräte werden überlicherweise mit einer Zentrale gepaired, um sie zentral verwalten zu können. Der Pairing-Partner ist im einfachsten Fall das I/O-Device ([[CUL]], [[HM-CFG-LAN]], …) selbst. Nachteilig dabei ist, dass der Ausfall der Schnittstelle bewirkt, dass alle gepairten Geräte nicht mehr bedient werden können. Dies lässt sich im Gegensatz zu ungepairten Protokollen (z.b. FS20) auch nicht durch doppelte Definition mit abweichenden IO-Devices lösen, da das Pairing nur mit einer ''hmId'' erfolgen kann. Daher kann auch durch mehrere Schnittstellen / IOs keine Redundanz erreicht werden. Ähnliches gilt für eine Vergrösserung der Funkabdeckung durch mehrere Schnittstellen.

Dieses Problem kann durch eine VCCU gelöst werden. Die VCCU ist eine virtuelle Zentrale; sie tritt beim Pairing an die Stelle der Schnittstelle. Sie erhält eine eigene ''hmId'', mit der die HM Sensoren und Geräte gepaired werden. Die Funkschnittstelle(n) werden dann von der VCCU als reine "dumme" IOs verwaltet. Dieses bietet vielfältige Möglichkeiten, z.b. die Verwendung mehrerer IOs, aus denen die VCCU die "beste" nach diversen Kriterien (z.B. RSSI) auswählt. Dadurch kann sowohl die Redundanz als auch die Funkabdeckung erhöht werden.

Durch das Pairen der Geräte mit einer virtuellen CCU ergeben sich folgende Vorteile:

* Die Verwendung mehrerer I/O-Devices wird möglich. Das sorgt für Redundanz (Ausfallsicherheit) und/oder Reichweiten-Vergrößerung.
* Der Tausch eines I/O-Devices ist transparent für gepairte Geräte.
* Die VCCU stellt virtuelle Kanäle zur Verfügung, mit denen HomeMatic-Geräte [[Homematic Peering Beispiele|gepeert]] werden können.
* "Geordnete" Termination von Nachrichten. (Da die üblichen Funkschnittstellen (wie CUL im HM-Mode oder HM-LAN-Konfigurator) relativ "dumm" sind, führen viele Zustände zu den bekannten "Help me" Einträge im Log.)

Der einzige Nachteil einer VCCU gegenüber dem direkten Pairing mit dem I/O-Device ist ein Mehraufwand bei der initialen Konfiguration vom Fhem.

== Kurzbeschreibung ==

Ein virtueller Controller '''VCCU''' ist der Protokoll-Endpunkt der Zentrale und ersetzt dabei logisch (jedoch nicht physikalisch) z.b. den [[HM-CFG-LAN LAN Konfigurations-Adapter]] einer "klassichen" FHEM Konfiguration

Es können einer VCCU einzelne oder mehrere IO Devices zugeordnet werden. Man bündelt dadurch mehrere I/O Devices (z.B. CULs und HM-CFG-LANs) zu einem ''Pool''. Den HM-Devices in FHEM (Aktoren, Sensoren) kann dann als I/O Device die ''VCCU'' zugeordnet werden, dies geschieht durch das Attribut ''IOgrp.''

Durch diese Gruppierung der I/O Devices und dem Zuordnen der VCCU zu einem Device entstehen verschieden Vorteile, abhängig des Einsatzes der VCCU. So kann ein beliebiges I/O Device im Device Pool der VCCU ausfallen und das oder die verbliebenden I/O Devices übernehmen diese Funktion (abhängig von der Funkreichweite/Erreichbarkeit). Die VCCU wird das nächst verfügbare I/O Device zum Senden/Empfangen verwenden.

Ein weitere Vorteil ist, dass durch die VCCU auch das I/O Device genutzt werden kann, welches die beste Funkqualität aufweist. Dies kann z.B. bei beweglichen Sensoren/Aktoren (Fernbedienungen) sinnvoll sein, oder wenn die Funkqualität durch andere Faktoren beeinflusst wird (z.B. Tür/Tor oder andere "bewegliche" Störfaktoren)

== Mehrere VCCUs in einer Installation==

Theoretisch erlaubt Fhem die parallele Nutzung mehrer VCCUs, praktisch ergeben sich dadurch jedoch keine Vorteile gegenüber einer einzigen VCCU. Insbesondere kann eine VCCU verschiedene I/O-Devices bedienen, zum Beispiel einen [[CUL]] ''und'' ein [[HM-CFG-LAN]].

Jede VCCUs muss eine eindeutige ''HomeMatic-ID'' haben, mit der HomeMatic-Geräte gepaired werden. Folglich kann jedes HomeMatic-Gerät nur mit ''einer'' VCCU gepaired werden.

Da die VCCU überschreibt die hmid eines I/O Device mit seiner eignen, daher können nicht mehrere VCCUs das selbe I/O Device verwenden.

== Definition der VCCU==
=== hmId wählen ===
Eine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Bei Schnittstellen und Zentralen ist dies eine ''hmId''. Da die VCCU eine (virtuelle) Zentrale ist, muss sie auch mit einer ''hmId'' versehen werden. Dies geschieht per define analog zur Anlage einer physischen Schnittstelle (siehe weiter unten)

Eine VCCU gibt die ''hmId'' an die ihr zugewiesenen IOs (Funkschnittstellen) weiter. D.H. alle von einer VCCU genutzen I/Os haben nach der Zuweisung die selbe ''hmId''.

Definiert man eine VCCU nachdem I/Os (CUL oder HMLAN) für Homematic angelegt sind, sollte die ''hmId'' der bereits vorhandene Funkschnittstelle verwenden, hierdurch kann man sich das Neupairen der HM Devices ersparen. Hat man bereits mehre Funkschnittstellen im Einsatz, werde diese unterschiedliche ''hmId''s haben, zumindest eine Schnittstelle wird nach der Zuweisung zur VCCU seine ''hmId'' also ändern. Für mit dieser Schnittstelle schon gepairte Devices ist ein Neupairen unumgänglich.

Ausserdem muss in jedem Fall das attr IOgrp eines vor Anlage der VCCU gepairten Gerätes auf die VCCU angelegt/geändert werden., z.B. so
attr <device> IOgrp VCCU
(Siehe weiter unten ein Tipp, wie dies leicht nachträglich erledigt werden kann)

Mit der Anlage einer VCCU hat das eventuell angelegte attribut IODev eines HM_Devices keine Funktion mehr. Vielmehr setzt die VCCU das IODev automatisch je nach Verfügbarkeit und Funklage. Es ist jedoch nicht erforderlich angelegte IODev Attribute zu entfernen.

=== Einrichten ===
define VCCU CUL_HM <hmId>
attr VCCU model CCU-FHEM
attr VCCU IOList <io1>[,<io2>,...]

Das Attribut IOList dient dazu festzulegen, welche physikalischen Schnittstellen ("IO") von der VCCU genutzt werden, dies sind in der Regel alle HM-fähigen Schnittstellen einer Installtion.
IOList beinhaltet die Komma-getrennte Liste der IOs, so wie sie in FHEM angelegt sind.

Es seien z.b. in FHEM bereits die beiden Schnittstellen HMLAN und CULHM angelegt:

define HMLAN0 HMLAN 192.168.168.2:1000
attr HMLAN0 hmId 123456
attr HMLAN0 hmLanQlen 1_min
attr HMLAN0 icon hm_lan

define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 hmId 123456
attr CUL0 icon cul_cul
attr CUL0 rfmode HomeMatic

Dann kann zusätzlich die VCCU mit der selben hmId angelgt werden und die beiden physikalischen Schnittstellen ihr zugewiesen:

define VCCU CUL_HM 123456
attr VCCU IOList CUL0,HMLAN0
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update

Wird die VCCU mit einer von vorhandene Schnittstellen abweichenden ''hmId'' angelegt, so wird die ''hmId'' der ihr zugewiesenen Schnittstelle(n) automatische angepasst. Dies hat in der Regel zur Folge, das HM Devices neu gepairt werden müssen.

Dies trifft auch zu, wenn bereits vorhandene Schnittstellen unterschiedliche hmIDs haben, dann wird sich die hmID mindestens einer Schnittstelle ändern. (Der Einfachheit halber war im obigen Beispiel angenommen, dass auch vorher die beiden Schnittstellen bereits die gleiche ID hatten.)

=== Auswirkungen auf IOs / Funkschnittstellen===
Sind IOs durch das Attribut IOList einer VCCU zugewiesen, werden die notwendigen Attribute im IO gesetzt, so wird die hmId durch die VCCU kontrolliert. Ein HMLAN/USB ist etwas enger verbunden als CUL IOs. Beim HMLAN kann die HMId nicht mehr geändert werden. Die kontrollierende VCCU wird in den Internals ''owner'' und ''owner_CCU'' des IO automatisch eingetragen. 

=== Pairen von HM Devices===
HM Devices sollten vorzugsweise direkt mit der VCCU gepairt werden, hierzu werden die normalen Befehle
hmPairForSec
hmPairSerial
verwendet. Es ist im übrigen weiter möglich (aber nicht sinnvoll / empfehlenswert) auch nach Anlage einer VCCU HM Devices mit diesen Kommandos direkt an ein IO zu pairen, d.h. diese Kommandos haben auch nach Anlage einer VCCU noch eine Funktion an der physikalischen Schnittstelle (im Gegensatz z.b. zum attr IODev)

== Dynamisches IO ==
FHEM sendet Befehle an an ein HM Device in der Regel immer über das gleiche IO-Device. Fällt es aus, wird nicht mehr gesendet, selbst wenn ein zweites IO verfügbar wäre. Ausserdem gibt es ''bewegliche'' Fernbedienungen welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen werden könnten.

Die VCCU adressiert beide Probleme:

Durch das Attibut IOgrp
attr <dev> IOgrp <vccu>:<preferredIO>
kann bestimmt werden, wie die VCCU die IO Devices genau nutzt. Insbesondere ist optional ein Preferd IO Device definierbar: bei stationären Devices - der häufigste Fall - sollte man das beste IO auswählen und als Default nutzen. Ein weiteres IO wird bei Ausfall des Ersten genutzt.

Das preferredIO ist jedoch optional und kann insbesondere bei beweglichen HM Devices (Fernbedienungen) weggelassen werden.

Es können auch mehrere preferredIO definiert werden, diese werden in der definierten Reihenfolge genutzt
attr <dev> IOgrp <vccu>:<prefIO1>,<prefIO2>,<prefIO3>

Beispiele:

Durch
attr <device> IOgrp VCCU:HMLAN1
wird die VCCU zuerst versuchen Befehle an <device> mit HMLAN1 zu senden, falls seine condition=ok.
Falls nicht wird (einer) der verbleibende(n) IOs verwendet, hier der mit dem besten RSSI.

Durch
attr <device> IOgrp VCCU
wird durch die VCCU der IO mit dem besten RSSI zum Device gewählt, falls seine condition=ok ist.

Da dies für jedes angelegte HM Device einzeln definiert werden kann/muss, kann so auch eine Verteilung des Funkverkehrs vorgenommen werden, z.b. um die 1%-Regel (HighLoad) zu berücksichtigen, dennoch bleibt die Redunanz bei Ausfall einer Schnittstelle erhalten.

=== Bemerkungen ===
Es wird empfohlen, das Attribut IOgrp in allen Devices zu setzen. Kanäle senden nicht selbständig, haben daher kein Attribut IOgrp. 
Das Attribut '''IODev''' wird automatisch gesetzt, Usereinträge haben keine Funktion. Es zeigt jedoch indirekt das letzte genutzte output-device. 
Die besprochene Steuerung betrifft das '''Senden'''. Empfangen und verarbeitet werden Nachrichten immer von allen verfügbaren Quellen.

=== Setzen der IOgrp auf (fast) allen Devices mit einem einzigen Befehl ===
Hat man eine bestehende Fhem-Installation mit mehreren/vielen Devices, kann das Setzen der ''IOgrp'' aufwändig sein.
Relativ einfach geht es bei allen HM Geräten durch Filtern der sechstelligen DEF (HMID):

attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp VCCU

Den obigen Befehl in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen.
VCCU steht für den Namen der VCUU und ist entsprechend zu ersetzen.
Durch die 6 Punkte werden nur die Geräte erfasst, die Kanäle haben 8 stellige IDs und bleiben unberührt.

Anschließend nicht vergessen die Konfiguration mit save zu speichern.

== Virtuelle Kanäle der VCCU==
: ''→ Siehe auch: [[HomeMatic#IO_Entities]]''

Eine VCCU kann bis zu 50 virtuelle Kanäle, sogenannte '''IO-Entities''', bedienen. Diese können als Sender/Sensoren oder Empfänger genutzt werden. Man kann diese Kanäle mit einem realen Kanal peeren und Aktionen triggern.

Man peert beispielsweise einen Dimmer mit einer IO-Entity um "Tastendrücke" in der Zentrale auslösen zu können. Sowohl kurze (short) als auch lange (long) Tastendrücke können so an den Dimmer gesendet werden.
Auch mehrere Aktoren können mit einer IO-Entity gepeert werden, beispielsweise um alle Lichter der Gruppe mit einem "press" gleichzeitig zu schalten.

=== Anlegen ===
set VCCU virtual <AnzahlButton>
z.B.
set VCCU virtual 10
legt 10 Kanäle für die VCCU an, die Kanäle 1-10. Evtl. vorhandene Kanäle größer 10 werden gelöscht.

=== Kommandos ===
: ''→ Siehe auch: [http://fhem.de/commandref.html#CUL_HMvirtual CommandRef]''

Verfügbare Kommandos auflisten:

get vccu_Btn1 cmdList

Insbesondere gibt es:

set vccu_Btn1 press short
set vccu_Btn1 press long
set vccu_Btn1 postEvent <condition>

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]

HM-CC-RT-DN Funk-Heizkörperthermostat

2016-10-20T16:43:33Z

Hokascha: /* Fensterkontakte */ Typo

{{Infobox Hardware
|Bild=HM-CC-RT-DN.jpg
|Bildbeschreibung=HM-CC-RT-DN an Heizkörper montiert
|HWProtocol=[[HomeMatic]]
|HWType=[[HomeMatic Type Thermostat|thermostat]]
|HWCategory=[[:Kategorie:Heizungsventile|Heizungsventile]]
|HWComm=868 MHz
|HWChannels=6
|HWVoltage=3 V
|HWPowerConsumption=180 mA
|HWPoweredBy=2x LR6/Mignon/AA
|HWSize=54x65x93 mm (BxHxT)
|HWDeviceFHEM=[[CUL_HM]]

|HWManufacturer=ELV / eQ-3
}}

'''HM-CC-RT-DN''' (häufig einfach '''RT''' genannt) ist ein Funk-''Heizkörperthermostate'' mit integriertem ''Stellantrieb''. Das Thermostat ist seit September 2013 verfügbar und ist der Nachfolger des [[HM-CC-VD Funk-Stellantrieb]]s.

== Vorbemerkungen ==
: ''→ Einstellungen und Informationen, die alle [[HomeMatic]] Thermostate betreffen, sind unter [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]] zu finden.''

Der HM-CC-RT-DN kann die Temperatur selbst messen (im Gegensatz zum [[HM-CC-VD Funk-Stellantrieb|Vorgänger]]) und verfügt über eine Fenster-Offen-Erkennung sowie eine Boost-Funktion. Der HM-CC-RT-DN ''kann'' von einem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] gesteuert werden, das ist aber ''optional''.

Das Gerät wird seit Anfang Oktober 2013 von Fhem unterstützt (siehe Diskussion im {{Link2Forum|Topic=14738|LinkText=Forum}}).

Der HM-CC-RT-DN scheint das erste HomeMatic-Device zu sein, bei dem ein Update der Firmware auch vom Anwender durchgeführt werden kann. Ein Firmware-Update erfordert einen [[HM-CFG-USB_USB_Konfigurations-Adapter|USB Konfigurations-Adapter]] und eine auf der eQ-3 Webseite herunterladbare Firmwareupdate-Software. Weitere Details sind unter [[#Firmware Update|Firmware Update]] beschrieben.
{{Hinweis|Die Solltemperaturen eines HM-CC-RT-DN lassen sich ''nicht'' durch einen [[HM-CC-TC Funk-Wandthermostat]] ''steuern''. Dieser kann nur die Ist-Temperatur an den HM-CC-RT-DN weitergeben, damit nicht die am HM-CC-RT-DN direkt gemessene Raumtemperatur zur Regelung verwendet wird.}}
Mit einem HM-CC-RT-DN können maximal (neben der Zentrale/Fhem):
* 7 HomeMatic Heizkörperthermostate
* 8 HomeMatic Tür-Fensterkontakte / Fenster-Drehgriffkontakte
* 8 Tastenpaare von HomeMatic Fernbedienungen bzw. Display-Wandtaster
* 1 HomeMatic Innen-Temperatur-Sensor
[[Peering (HomeMatic)|gepeert]] werden.

{{Hinweis|Wird für Wartungs-/Umbaumaßnahmen das Wasser der Heizung abgelassen bzw. diese neubefüllt, sind alle Stellantriebe manuell dauerhaft auf '''on''' zu setzen: set <HM_Stellantrieb>_Clima controlManu on. Beim Einsatz eines Wandthermostaten ist der Wandthermostat entsprechend einzustellen.}}

== Technische Daten ==
* Betriebsspannung: 2 Stck. 1,5V LR6/Mignon/AA
* Stromaufnahme: 180 mA max.
* Abmessungen (B x H x T): 54 x 65 x 93 mm
* Gewicht: 180 g (ohne Batterien)
* Ventilanschluss: M30 x 1,5 mm

Aktuelle Firmware: 1.4

== Betrieb mit FHEM ==
Der Funk-Heizkörperthermostat muss zuerst mit Fhem [[Pairing (HomeMatic)|gepairt]] werden. Stellen Sie sicher, dass Fhem aktuell ist (update durchführen)

Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden

=== Channels (Kanäle) ===
==== Channel (Kanal) 01 _Weather ====

Dieser Kanal dient zur Einspeisung der (gemessenen) ''Ist-Temperatur''. Als Sensor können zum Beispiel das [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] oder ein [[HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor innen (IT)|HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor]] dienen.

Ein Temperatur-Sensor ''tempSensor'' kann mit dem ''_Weather''-Kanal wie folgt [[Peering (HomeMatic)|gepeert]] werden:

set <tempSensor> peerChan 0 <HM-CC-RT-DN>_Weather single

==== Channel (Kanal) 02 _Climate ====
Dieser Kanal erlaubt es dem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] den HM-CC-RT-DN zu steuern. Dazu müssen die beiden Geräte gepeert werden:

set <HM-TC-IT-WM-W-EU>_Climate peerChan 0 <HM-CC-RT-DN>_Climate single set

==== Channel (Kanal) 03 _WindowRec ====
Mit diesem Kanal können Fensterkontakte ([[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] und [[HM-Sec-RHS Funk-Fenster-Drehgriffkontakt|HM-SEC-RHS]]) ihren Fensterstatus (geöffnet / gekippt) an ein oder mehrere Thermostate senden. Die Thermostate stellen anschließend die entsprechende (konfigurierbare) Temperatur ein. Der Temperaturwert kann je Fenster-Sensor unterschiedlich definiert werden. Sind mehrere Fenster gleichzeitig geöffnet, so wird der Thermostat auf die Temperatur des Sensors mit dem geringsten Temperaturwert eingestellt.
Ferner wird empfohlen, bei Einsatz von externen Sensoren, die interne „Fenster auf Erkennung“ zu deaktivieren (weitere Details sind im [[HM-CC-RT-DN Funk-Heizkörperthermostat#Channel .28Kanal.29 04 _Clima|Channel (Kanal) 04 _Clima]] beschrieben).

Der Befehl zum Peeren lautet, wobei <fensterSensor> die Fhem-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single

Zum Löschen (=unpeeren) dieser Kopplung:
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single unset

'''Achtung''': Der Peer-(Lösch)Vorgang muss am Fensterkontakt durch Drücken der Anlerntaste bestätigt werden, und zwar auch dann, wenn der Fensterkontakt schon vorher mit Fhem gepairt wurde. Wichtig scheint auch, dass der Fensterkontakt geschlossen ist wenn man die Anlerntaste drückt.

Der Befehl zur Temperatureinstellung des Heizkörperthermostaten für den Zustand "Fenster offen" lautet, wobei <fensterSensor> die Fhem-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates, sowie <Temp> die einzustellende Temperatur (ganzzahliger Wert):
set <HM-CC-RT-DN>_WindowRec regSet winOpnTemp <Temp> <fensterSensor>

==== Channel (Kanal) 04 _Clima ====
Dieser Kanal dient zum Einstellen der Betriebsparameter, auch [[#Temperaturlisten|Temperaturlisten]] sind hierauf zu übertragen.

{{Hinweis|In älteren Versionen von Fhem wurde dieser Kanal durch ''autocreate'' als <code>_ClimRT_tr</code> angelegt. Der Hersteller hat hier offenbar die internen Bezeichnungen geändert, denn beim Vorläufernmodell HM-CC-TC mussten Temperaturlisten auf den Kanal ''Climate'' übertragen werden.}}

Die maximale Öffnung des Ventils kann mittels folgendem Befehl eingestellt werden (hier auf 80 %):
set <HM-CC-RT-DN>_Clima regSet valveMaxPos 80

Die interne "Fenster-auf"-Erkennung kann man wie folgt abschalten:
set <HM-CC-RT-DN>_Clima regSet winOpnMode off

==== Channel (Kanal) 05 _ClimaTeam ====
Dieser Kanal erlaubt es mehrere HM-CC-RT-DN zu einem "Team" zu gruppieren. Ein Mitglied des Teams meldet
* Änderungen der Temperatur am Handrad
* Einschalten des Boost-Modus am Taster
an seine "Teamkollegen" weiter. Folgende Änderungen werden '''nicht''' weitergegeben:
* Status der Fensterkontakte
* Temperaturlisten/Wochenplan und daraus folgende Änderungen
* Änderungen durch Fernbedienungen
* Änderungen durch eine HomeMatic-Zentrale

Befehl zum Peeren, wobei ''<HM-CC-RT-DN#1>_ClimaTeam'' und ''<HM-CC-RT-DN#2>_ClimaTeam'' die Kanalbezeichnungen der beiden ClimaTeam-Kanäle sind:
set <HM-CC-RT-DN#1>_ClimaTeam peerChan 0 <HM-CC-RT-DN#2>_ClimaTeam single

==== Channel (Kanal) 06 _remote ====
Dieser Kanal ann an eine Fernbedienung gekoppelt werden. Per Tastendruck kann man einen bestimmten Mode und/oder eine bestimmte Temperatur wählen. Dabei kann die Reaktion auf einen langen oder kurzen Tastendruck gesondert eingestellt werden.

Der Befehl zum peeren lautet, wobei <button> die Kanalbezeichnung der Fernbedienung und <rt-remote> die Kanalbezeichnung des Heizkörperthermostates ist:
set <button> peerChan 0 <HM-CC-RT-DN>_remote single

=== Betriebsmodus Auto, Manu, Party (Urlaub) ===

Der HM-CC-RT-DN verfügt über drei Betriebsmodus: Auto, Manu (Manuell) und Party (Urlaub).

==== Modus Auto ====
Das Gerät arbeitet gemäß des gespeicherten Wochenprogramms. Manuelle Änderungen sind möglich, werden beim nächsten Schaltpunkt überschrieben.

==== Modus Manu ====
Die Temperatur wird manuell eingestellt, das Wochenprogramm wird nicht abgearbeitet.

==== Modus Party (Urlaub) ====
Die eingestellte Temperatur gilt bis zu einem gegebenen Endzeitpunkt, anschließend wechselt das Thermostat in den ''Auto''-Modus. So kann beispielsweise bei Abwesenheit ein niedrigeres Temperaturprofil eingestellt werden ohne dass die Temperaturlisten verändert werden müssen.

set <HM-CC-RT-DN>_Clima controlParty 16 06.12.13 16:30 09.12.13 05:00

Dadurch wird
* von 06.12.2013, 16:30 Uhr
* bis 09.12.2013, 05:00 Uhr
* die gewünschte Raumtemperatur auf 16 °C eingestellt.

{{Hinweis|
* Der Befehl muss auf dem Kanal 4 ''(_Clima)'' erfolgen.
* Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30).}}

Mit der folgenden Funktion <code>Urlaub()</code> kann man eine ganze Wohnung (also mehrere RTs) mit nur einem Befehl in den Party-Modus versetzen. Im Beispiel werden zwei Heizkörper ("Treppenhaus" und "Kammer") angesteuert.

Zu beachten sind folgende Dinge:
# Aktuelle Dateien (z.B. <code>10_CUL_HM</code>) verwenden!
# Bei dem ''controlParty''-Befehl ''kein'' Komma zwischen den Parametern.
# Bei der Funktion die Parameterübergabe definieren <code>($$$$$)</code>

'''Aufruf:'''
:<code>{Urlaub ("16", "06.12.13", "16:30", "09.12.13" ,"05:00")}</code>

'''Funktion:'''
<source lang=perl>
my $Urlaub;
sub
Urlaub($$$$$)
{
my ($temp, $startDate, $startTime, $endDate, $endTime) = @_;

# HM-CC-RT-DN akzeptiert nur Zeiten, die auf Minute 00 oder 30 enden.
# Daher $startTime und $endTime abrunden
$startTime =~ s/\:[0-2].$/:00/;
$startTime =~ s/\:[3-5].$/:30/;
$endTime =~ s/\:[0-2].$/:00/;
$endTime =~ s/\:[3-5].$/:30/;

# controlParty bei jedem HM-CC-RT-DN setzen.
for my $rt (qw(Kammer Treppenhaus)) {
fhem ("set $rt controlParty $temp $startDate $startTime $endDate $endTime");
}
}
</source>

=== Tastensperre ===

Um zu verhindern, dass der Modus oder die Temperatur per Tasten bzw. Drehrad am HM-CC-RT-DN verändert wird, kann eine Tastensperre gesetzt werden. Dies erfolgt mittels des Befehls:

set <HM-CC-RT-DN> regSet btnLock on

Rückgängig machen geht per:

set <HM-CC-RT-DN> regSet btnLock off

Diese Tastensperre kann man aber am HM-CC-RT-DN durch eine Tastenkombination wieder zurücksetzen. Um sie nur per Fhem rücksetzen zu können, muss

set <HM-CC-RT-DN> regSet globalBtnLock on

eingegeben werden. Rückgängig geht wieder per:

set <HM-CC-RT-DN> regSet globalBtnLock off

Es gibt auch eine Tastensperre die nur das Umschalten des Modus (Auto, Manuell, Urlaub) am Gerät verhindert. Diese wird mit

set <HM-CC-RT-DN> regSet modusBtnLock on

eingeschaltet. Abschalten geht mit:

set <HM-CC-RT-DN> regSet modusBtnLock off

=== Burst-Modus ===
Das ist ein '''Übertragungs'''modus für Nachrichten zwischen HM-Geräten und der Zentrale. Der RT erwacht alle 2,5 Minuten und dann überträgt die Zentrale die Kommandos. Wenn man einen Fensterkontakt oder eine Fernsteuerung nutzt, muss der RT sofort reagieren - dann muss man den Burst ''enablen''. Der RT kann in diesem Fall sofort aufgeweckt werden und bearbeitet die Anforderung (Request). Das kann man auch von der Zentrale aus nutzen (so man möchte). Das ist der '''Vorteil''' des eingeschalteten Burst-Modus.

'''Nachteil:''' Der Burst-Modus benötigt mehr Leistung, das heißt die Batterien müssen häufiger gewechselt werden: Der RT muss den Receiver ständig empfangsbereit halten. Außerdem wachen bei jedem Burst wachen ''alle'' Burst-Empfänger auf – egal an wen die Kommunikation gerichtet war.

'''Burst – wie es funktioniert'''

Schickt ein Sender eine burst Sequenz, wachen alle burst-Empfänger auf und prüfen die Message.
Wenn sie betroffen sind bleiben sie eine Zeit lang wach, ansonsten schlafen sie wieder ein.
Man beachte also, dass Senden eines Burst Energie in ALLEN burst-Empfängern verbraucht, egal ob sie angesprochen sind.

'''HMLAN und burst'''

[[HMLAN]] hat ein Sendebudget das über eine Stunde berechnet wird. Burst belastet diese Konto deutlich - so können nicht mehr als 100 bursts /h gesendet werden - dann geht HMLAN in overload Wenn zusätzliche Nachrichten gesendet werden sind es entsprechend weniger.
Es ist als nicht vorteilhaft, unnötig bursts zu senden.

'''Burst devices'''

Es gibt Devices, die immer auf burst reagieren und solche bei denen es abgeschaltet werden kann. So reagiert ein Rauchmelder immer auf Burst damit er seine Team-Kollegen hören kann.
Ein TC oder RT hingegen hat diese Funktion abschaltbar. 'Per default ist dies ausgeschaltet um Batterie zu sparen'. Wenn ein VD gesteuert wird ist der TC ja selbst wach. Wird er aber mit einem Fensterkontakt gekoppelt muss es eingeschaltet werden – sonst verpasst er die Nachricht.

'''ConditionalBurst devices'''

Devices mit abschaltbarem Burst wie z.B. der ''HM-CC-RT-DN'' haben ein Register, ''burstRx'', mit dem das burst-Erwachen eingestellt werden kann.
Sendern, die einen burst-Aktor erwecken sollen, muss man sagen, welcher Peer Burst benötigt. Hier kann ggf. das Register ''peerNeedsBurst'' nach dem Peeren gesetzt werden. FHEM versucht dies automatisch beim Peeren zu erledigen. Siehe [[HomeMatic HMInfo|HMinfo]] Befehl ''models'' um herauszufinden, welche Devices welchen Modus unterstützen.

'''Attribut burstAccess'''

Devices, die abschaltbaren burst haben kann man ein attribut bustAccess 1_auto setzen. Es wird beim Abschicken eines Kommandos versucht, das Device mit burst zu wecken. Sollte es nicht funktionieren wird gewartet, bis das Device aufwacht (meist reagieren solche Devices auch auf wakeup). Das Setzen des Attributs ist angenehm – es werden aber ggf. viele bursts gesendet.

'''Kommando burstXmit'''

Mit diesem Kommando, das bei Devices mit contitional-Burst zu Verfügung steht, wird der burst gezielt von User angestossen.

Der User schickt erst seine Kommandos an das device. Die Kommandos werden im Command-stack gesammelt.

Dann sendet der User ein set burstXmit.

Es passiert das gleiche wie bei burstAccess.

FHEM versucht mittels burst zu wecken und sendet bei Erfolg die Messages aus dem Kommandostack.

Im Gegensatz zu burstAccess ist burstXmit gezielt einsetzbar und kann sparsamer verwendet werden.

''' FHEM und burst devices'''

FHEM sendet eine burst automatisch mit Kommandos zu Devices, die nur burst unterstützen.

'''So aktiviert man den burst-Betrieb am HM-CC-RT-DN'''

''Burst Mode einschalten'' (der Kanal 4 des Device WZ1 heisst hier WZ1_4)
:<code>set WZ1_4 regSet burstRx on </code>
prüfen mit:
:<code>get WZ1_4 reg burstRx </code>
''Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)''
:<code>attr WZ1 burstAccess 1_auto</code>

Hinweis: Das Attribut im Device und nicht im Kanal setzen, ansonsten gibt es eine Fehlermeldung.

=== Temperaturlisten ===
Die Temperaturlisten des HM-CC-RT-DN werden identisch mit denen anderer HomeMatic Thermostate verwaltet (siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]]). Beim HM-CC-RT-DN ist der Kanal 4 (_Clima) für die Temperaturlisten zuständig.

==Fhem-Log==
In den folgenden Logs heißt Kanal 4 noch "_ClimRT_tr". Inzwischen würde man dort "_Clima" sehen.

=== Device-Log ===
2013.10.10 20:03:24 3: CUL_HM Unknown device CUL_HM_HM_CC_RT_DN_2212BC, please define it
2013.10.10 20:03:24 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC CUL_HM 2212BC A1A0184002212BC0000001000954B4551303531303031375900FFFF
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017
2013.10.10 20:03:24 3: LANCUL pairing (hmPairForSec) not enabled
2013.10.10 20:03:24 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC-%Y.log CUL_HM_HM_CC_RT_DN_2212BC
2013.10.10 20:03:24 3: Device Heizung_Wohnzimmer added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: Heizung_Wohnzimmer thermostat, model HM-CC-TC serialNr JEQ0044286
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017
2013.10.10 20:03:25 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Weather CUL_HM 2212BC01
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather
2013.10.10 20:03:26 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Climate CUL_HM 2212BC02
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate
2013.10.10 20:03:27 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_WindowRec CUL_HM 2212BC03
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec
2013.10.10 20:03:28 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr CUL_HM 2212BC04
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr
2013.10.10 20:03:29 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam CUL_HM 2212BC05
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam
2013.10.10 20:03:30 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_remote CUL_HM 2212BC06
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote
2013.10.10 20:03:35 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getSerial
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getConfig
2013.10.10 20:03:54 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time

=== Event monitor ===
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr motorErr: ok
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr measured-temp: 18.4
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr desired-temp: 18
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr ValvePosition: 3 %
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr mode: manu
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr unknown0: 24
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr T: 18.4 desired: 18 valve: 3 %
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC battery: ok
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC batteryLevel: 3.1 V
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC measured-temp: 18.4
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC desired-temp: 18
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC actuator: 3 %

== Firmware Update ==
Seit 24.10.2014 gibt es für den HM-CC-RT-DN die neue Firmware Version 1.4. Diese kann von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic Firmware Update]].

=== HM-CC-RT-DN spezifische Update Informationen ===
Durch gleichzeitiges Drücken der "Auto-/Manu"-Taste und der "Comfort-/Eco"-Taste am HM-CC-RT-DN während man die Batterien wieder einlegt wird der updatemodus gestartet. Während des Updates steht "FUP" im Display. Nach erfolgreichem Update erscheint "Ins" im Display und es muss eine erneute Adaptierfahrt durch drücken der Boost-Taste ausgelöst werden. Anschließend sollte der HM-CC-RT-DN wieder normal funktionieren. Die eingestellten Parameter und das Pairing mit FHEM gehen beim Update nicht verloren. Sollte das Update fehlschlagen, erscheint "Err" bzw. "CrC" im Display.

Normalerweise sollte dann durch erneutes starten der Prozedur am PC und HM-CC-RT-DN das ganze erneut durchführbar sein.

Es gibt einige Readings, die nicht durch ein einfaches ''getConfig'' aktualisisert werden, z.B. "battery"(nicht batteryLevel). Um diese Readings zu bekommen, ist ein
:<code>set Device_Channel04 controlMode auto </code>
notwendig. Daraufhin werden die Readings übertragen/aktualisiert.

== Simulation von Fensterkontakten und externen Temperatursensoren ==
grober Ablauf:
* erstellen ein virtuelles Device
* erstelle dazu einen virtuellen Kanal
* peeren den Kanal mit dem RT (als fenster-kontakt oder als remote, wen du willst)
* sende ein postEvent

=== Fensterkontakte ===
''Entnommen aus diesem {{Link2Forum|Topic=31078|Message=236245|LinkText=Forenbeitrag}}''
define virSC CUL_HM 221133
attr virSC autoReadReg 4_reqStatus
attr virSC expert 2_full
attr virSC model virtual_1
attr virSC peerIDs
attr virSC subType virtual
attr virSC webCmd press short:press long

define virtualKitchenDoor CUL_HM 22113301
attr virtualKitchenDoor dummy 1
attr virtualKitchenDoor expert 1
attr virtualKitchenDoor group Virtual
attr virtualKitchenDoor model virtual_1
attr virtualKitchenDoor webCmd postEvent open:postEvent closed

Anschließend peeren und Temperatur festlegen mit:
set virtualKitchenDoor peerChan 0 <Thermostat_Window_Rec> single set
set <Thermostat_Window_Rec> regSet winOpnTemp 5 virtualKitchenDoor

Die virtuelle Tür wird dann entsprechend über ein Notify getriggert:
define notify_virtualKitchenDoor notify (Fensterkontakt_1|Fensterkontakt_2) {if(Value("Fensterkontakt") eq "open" && Value("Fensterkontakt_2") eq "open"){fhem("set virtualKitchenDoor postEvent open")}else{fhem("set virtualKitchenDoor postEvent closed")}}

=== Temperatursensoren ===
''Entnommen aus diesem {{Link2Forum|Topic=19686|Message=233788|LinkText=Forenbeitrag}}''

1. Virtuelles HomeMatic Device mit _deiner_ HM Id definieren:
define wz_vT CUL_HM <hmId>

2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen:
set wz_vT virtual 1

3. Es ist kein virtueller Button sondern ein virtueller Temperatursensor - darum rename:
rename wz_vT_Btn1 wz_vT_Sensor1

4. Virtuellen Peer Sensor mit dem Weather Channel des RT-DN peeren:
set wz_vT_Sensor1 peerChan 0 <RT_DN>_Weather single

5. Peering kontrollieren (Voraussetzung: Device ''hm'' vom Typ [[HomeMatic HMInfo|HMinfo]] existiert):
:<code>set hm peerXref</code>
Beispiel-Ausgabe:
peerXref done:
x-ref list
wz_Thermostat_Weather => wz_vT_Sensor1
wz_vT_Sensor1 => wz_Thermostat_Weather

6. Gemessene Temperatur vom z.B. 1-Wire DS1820 dem virtuellen HM Sensor übergeben. Z.B. alle zwei Minuten per at:
define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0)); fhem "set wz_vT_Sensor1 virtTemp $T" }

Fertig.

== Bekannte Probleme ==
=== TempList: Bad format ... ===
Wenn Sie beim Setzen einer Temperaturliste nach dem o.a. Schema ("SetTempList...") die Meldung

Bad format, use HH:MM TEMP ......

erhalten, sollten Sie zunächst ein [[update]] von Fhem durchführen.

== Links ==
* [http://www.eq-3.de/produkt-detail-aktoren/items/homematic-funk-heizkoerperthermostat.html Produktinfo]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-CC-RT-DN_UM_GE_eQ-3_web.pdf Bedienungsanleitung (PDF)]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Heizkoerperthermostat_105155_Produktdatenblatt_V2.2.pdf Datenblatt (PDF)]
* [http://www.eq-3.de/Downloads/eq3/downloads/Ventilkompatibilitaeten.pdf Ventil-Kompatibilitätsliste (PDF)]
* {{Link2Forum|Topic=14738|LinkText=Forenthema zum Thermostat}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]