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

HM-CC-RT-DN Funk-Heizkörperthermostat
HM-CC-RT-DN an Heizkörper montiert
Allgemein
Protokoll	HomeMatic
Typ	thermostat
Kategorie	Heizungsventile
Technische Details
Kommunikation	868 MHz
Kanäle	6
Betriebsspannung	3 V
Leistungsaufnahme	180 mA
Versorgung	2x LR6/Mignon/AA
Abmessungen	54x65x93 mm (BxHxT)
Sonstiges
Modulname	CUL_HM
Hersteller	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-Stellantriebs.

Vorbemerkungen

→ Einstellungen und Informationen, die alle HomeMatic Thermostate betreffen, sind unter HomeMatic Type Thermostat zu finden.

Der HM-CC-RT-DN kann die Temperatur selbst messen (im Gegensatz zum 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 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 USB Konfigurations-Adapter und eine auf der eQ-3 Webseite herunterladbare Firmwareupdate-Software. Weitere Details sind unter Firmware Update beschrieben.

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

gepeert werden.

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.5 (2020)

Betrieb mit FHEM

Der Funk-Heizkörperthermostat muss zuerst mit FHEM gepairt werden. Stellen Sie sicher, dass FHEM aktuell ist (update durchführen)

Das Pairing sollte wie in HomeMatic Devices pairen beschrieben durchgeführt werden (mittlere Taste mindestens drei Sekunden drücken, um den Vorgang auszulösen). Vereinzelt muss mehrfach gepairt werden, es wurde auch berichtet, dass dabei die Batterie zwichendurch entfernt und neu eingelegt werden muss.

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 oder ein HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor dienen.

Ein Temperatur-Sensor tempSensor kann mit dem _Weather-Kanal wie folgt gepeert werden:

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

Beispiel:

 set EG_Buero_WANDTHERMOSTAT_Weather peerChan 0 EG_Buero_THERMOSTAT_Weather single set

ACHTUNG: Das Wandthermostat sowie das Thermostat Ventil (Beispiel "EG_Buero_WANDTHERMOSTAT" und EG_Buero_THERMOSTAT) werden vorher in FHEM den Status "CMDs_done" anzeigen. Beim peerChan wird dann bei beiden "CMDs_pending" stehen. Wobei das Wandthermostat sehr schnell wieder auf CMDs_done zurück springt. Allerdings ist dringend darauf zu achten, dass das Thermostat Ventil auch wieder auf "CMDs_done" wechselt, bevor man den nächsten Befehl absendet. Das Heizkörper Ventil kann unter Umständen 3 bis 5 min benötigen bis wieder "CMDs_done" steht. Evtl. kann man dies durch die BOOST Taste beschleunigen. Da das Ventil etwa alle 3 min aufwacht, prüft und Daten sendet / empfängt. Sollte man mit dem Befehlen weiter gemacht haben, so kann es zu dem Problem führen, dass einer nicht mehr mit dem Pending aufhört. In dem Fall empfiehlt es sich beide Devices von FHEM abzumelden und auf Werkseinstellung zu resetten.

Zum Test haucht man das Wandthermostat an oder hält es einige Zeit in der Hand bis die Temperatur steigt, nach etwa 3 Minuten sollte man auch am Thermostat Ventil einen Temperaturanstieg sehen.

Channel (Kanal) 02 _Climate

Dieser Kanal erlaubt es dem 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 und 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 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 (siehe diesen Thread):

set <fensterSensor> peerChan 0 <rt_WindowRec>_WindowRec single 

Zum Löschen (=unpeeren) dieser Kopplung:

set <fensterSensor> peerChan 0 <rt_WindowRec>_WindowRec single unset

Achtung: Der Peer-(Lösch-)Vorgang muss erst am Fensterkontakt durch Drücken der Anlerntaste ausgelöst werden, und zwar auch dann, wenn der Fensterkontakt schon vorher mit FHEM gepairt wurde. Dann kann der oben genannte Befehl in FHEM abgesetzt werden. 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 <rt_WindowRec>_WindowRec regSet winOpnTemp <Temp> <fensterSensor>

Weitere Hinweise im Forum, siehe FHEM Forum-Beitrag

Channel (Kanal) 04 _Clima

Dieser Kanal dient zum Einstellen der Betriebsparameter, auch Temperaturlisten sind hierauf zu übertragen. Mit dem Modul Wochenplan / Weekprofile können die Wochenpläne komfortabel in FHEM erstellt und an die Thermostate übertragen werden.

In älteren Versionen von FHEM wurde dieser Kanal durch autocreate als _ClimRT_tr angelegt. Der Hersteller hat hier offenbar die internen Bezeichnungen geändert, denn beim Vorläufermodell 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, <HM-CC-RT-DN#2>_ClimaTeam, ..., <HM-CC-RT-DN#8>_ClimaTeam die Kanalbezeichnungen der jeweiligen ClimaTeam-Kanäle sind:

set <HM-CC-RT-DN#1>_ClimaTeam peerChan 0 <HM-CC-RT-DN#2>_ClimaTeam single
set <HM-CC-RT-DN#1>_ClimaTeam peerChan 0 <HM-CC-RT-DN#3>_ClimaTeam single
set <HM-CC-RT-DN#2>_ClimaTeam peerChan 0 <HM-CC-RT-DN#3>_ClimaTeam single
...

Channel (Kanal) 06 _remote

Dieser Kanal kann 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 aber beim nächsten Schaltpunkt überschrieben.

Modus Manu

Die Temperatur wird manuell eingestellt, das Wochenprogramm wird nicht abgearbeitet. "Manuell Einstellen" bedeutet entweder am Handrad oder durch Übermittlung eines "set desired temp"-Befehls von FHEM (oder equivalent von einer CCU).

Modus Party (Urlaub)

Die eingestellte Temperatur gilt bis zu einem gegebenen Endzeitpunkt, anschließend wechselt das Thermostat in den Auto-Modus.

Welchen Modus nutzen?

Im Umfeld von FHEM sind alle drei Modi einsetzbar. Betrieb in "Auto" hat den Vorteil, dass bei Ausfall der FHEM-Instanz der Thermostat trotzdem noch die eingespeicherten Wochenprogramme abarbeitet. Nachteilig ist aber, dass die Steuerung komplexer wird, weil sowohl die Einstellungen am Thermostat als auch Schaltbefehle von FHEM das Verhalten beeinflussen. Vielfach wird daher im Umfeld von FHEM der Modus "Manu" benutzt, hier wird die Temperatur nur per einzelnem FHEM Schaltbefehl gesteuert, ausgelöst z.b. durch "at" Kommandos, Anwesenheitserkennung oder Bewegungsmelder. Sollte FHEM (oder die Funkverbindung) ausfallen, bleibt der Thermostat allerdings auf der letzten eingestellten Temperatur stehen.

Denkbar ist auch, den Modus "Auto" zu verwenden und dann die Steuerung per FHEM dadurch durchzuführen, dass durch FHEM die Wochenprogramme verändert werden. Dies verbindet zwar die Vorteil der vorgenannten Methoden, ist aber am Aufwendigsten in der Programmierung und erzeugt die höchste Funklast.

Auch der Urlaubsmodus ist einsetzbar, so kann beispielsweise bei Abwesenheit ein niedrigeres Temperaturprofil eingestellt werden, ohne dass eventuell vorhandene 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.

• 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 Urlaub() 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:

1. Aktuelle Dateien (z.B. 10_CUL_HM) verwenden!
2. Bei dem controlParty-Befehl kein Komma zwischen den Parametern.
3. Bei der Funktion die Parameterübergabe definieren ($$$$$)

Aufruf:

{Urlaub ("16", "06.12.13", "16:30", "09.12.13" ,"05:00")}

Funktion:

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");
    }
  }

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 Übertragungsmodus 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 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 dieses 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 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 HMInfo Befehl models um herauszufinden, welche Devices welchen Modus unterstützen.

Attribut burstAccess

Devices, die abschaltbaren burst haben kann man ein attribut burstAccess 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 conditional-Burst zu Verfügung steht, wird der burst gezielt vom User angestoßen.

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)

set WZ1_4 regSet burstRx on

prüfen mit:

get WZ1_4 reg burstRx

Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)

attr WZ1 burstAccess 1_auto

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). 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 aktualisiert werden, z.B. "battery"(nicht batteryLevel). Um diese Readings zu bekommen, ist ein

set Device_Channel04 controlMode auto

notwendig. Daraufhin werden die Readings übertragen/aktualisiert.

Anscheinend (siehe dieses Forenthema) wird bei Firmware 1.5 ein weiteres Attribut benötigt

attr <devicename> commStInChn off

Simulation von Fensterkontakten und externen Temperatursensoren

Für jeden separat zu steuernden HM-CC-RT-DN kann nur je ein Kanal eines virtuellen Devices als Temperatur- bzw. Fensterkontakt genutzt werden. Insbesondere die virtuellen Kanäle der VCCU eignen sich nicht dazu, mehrere HM-CC-RT-DN unabhängig voneinander anzusteuern! Hat man mehrere unabhängig arbeitende RT's, muß für jeden auch ein eigenes virtuelles Gerät angelegt werden!

Die folgenden Beispiele sind nicht für Anfänger und Unwissende geeignet! Es gibt zahlreiche Stolpersteine:

1. Die HMId für virtuelle Geräte muss einmalig im System sein. Sie muss selbst gewählt werden und es darf keine vorhandene ID verwendet werden!
2. Es kann vorkommen, das beim Anlegen eines virtual Gerätes kein attr IODev gesetzt wird. Das Attribute ist aber notwendig, sonst arbeitet das Gerät nicht! Bitte kontrollieren und gegebenenfalls per Hand setzen.

Grober Ablauf:

• erstelle ein virtuelles Device
• erstelle dazu einen virtuellen Kanal (bzw. mehrere, wenn sowohl ein virtueller Fensterkontakt wie ein virtueller Temperaturkanal benötigt werden).
• peere den Kanal mit dem RT (als Fenster-Kontakt oder als remote, wenn du willst)
• sende ein postEvent / stelle die neue Temperatur im Kanal ein

Fensterkontakte

Angelehnt an diese Forenbeitrag

define virtKitchenSensors CUL_HM 221133

Um das Device als virtuelles zu kennzeichnen benötigt man den folgenden Befehl (legt weitere Attribute an):

attr virtKitchenSensors model VIRTUAL

Kanal bzw. Kanäle erstellen (benötigt uU. einen Neustart von FHEM, bevor der Befehl zur Verfügung steht):

set virtKitchenSensors virtual 1 

oder (für das Anlegen je eines Kanals für einen Fenster- und Temperatur-Kanal):

set virtKitchenSensors virtual 2 

Als Zwischenergebnis sehen wir in der Detailansicht des virtKitchenSensors ein bzw. zwei weitere Devices mit Namen virtKitchenSensors_Btn1 bzw. virtKitchenSensors_Btn2.

Umbenennen des 1. Kanals:

rename virtKitchenSensors_Btn1 virtualKitchenDoor

Danach sollte man das webCmd-Attribut wie folgt vergeben:

attr virtualKitchenDoor webCmd postEvent open:postEvent closed 

Anschließend peeren und (wer weniger wie den default-Wert von 12°C einstellen möchte) Temperatur festlegen mit:

set virtualKitchenDoor peerChan 0 <Thermostat_Window_Rec> single set
set <Thermostat_Window_Rec> regSet winOpnTemp 5 virtualKitchenDoor

Ggf noch interne "Fenster-auf" Erkennung abschalten

set <HM-CC-RT-DN>_Clima regSet winOpnMode off

Die virtuelle Tür wird dann entsprechend über ein Notify getriggert. Einfache Form (nur ein Fensterkontakt im Raum):

define notify_virtualKitchenDoor notify Fensterkontakt_1:(open|closed) set virtualKitchenDoor postEvent $EVENT

Komplexere Form (zwei Fensterkontakte):

define notify_virtualKitchenDoor notify (Fensterkontakt_1|Fensterkontakt_2) {if($EVENT eq "open" and Value("virtualKitchenDoor") eq "set_postEvent closed"){fhem("set virtualKitchenDoor postEvent open")} elsif (Value("virtualKitchenDoor") eq "closed" && Value("Fensterkontakt_2") eq "closed") {fhem("set virtualKitchenDoor postEvent closed")}}

Die postEvent-Anweisung wird unmittelbar an die Funkschnittstelle weitergegeben und löst einen burst aus.

Temperatursensoren

Angelehnt an diesen Forenbeitrag

1. Virtuelles HomeMatic Device mit eigener HM Id definieren, (s.o.), es kann auch ein weiterer Kanal des oben erstellten Devices genutzt werden

2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen, wieder mit set virtKitchenSensors virtual 1 bzw. set virtKitchenSensors virtual 2 (2 geht auch, wenn bereits ein erster Kanal vorhanden war).

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

rename virtKitchenSensors_Btn1 Kitchen_vT_Sensor1

bzw. rename virtKitchenSensors_Btn2 Kitchen_vT_Sensor1

4. Virtuellen Peer Sensor mit dem Weather Channel des RT-DN peeren:

set Kitchen_vT_Sensor1 peerChan 0 <RT_DN>_Weather single

5. Peering kontrollieren (Voraussetzung: Device hm vom Typ HMInfo existiert):

set hm peerXref

Beispiel-Ausgabe:

peerXref done: 
x-ref list 
   wz_Thermostat_Weather => Kitchen_vT_Sensor1 
   Kitchen_vT_Sensor1 => wz_Thermostat_Weather

6. Gemessene Temperatur vom z.B. 1-Wire DS1820 dem virtuellen HM Sensor übergeben. Z.B. bei jeder Aktualisierung des Messwerts per notify:

define at_Kitchen_vT notify myRealKitchenTempSensor:temperature:.* set Kitchen_vT_Sensor1 virtTemp $EVTPART1

Die virtTemp-Anweisung ändert zunächst nur den Wert im virtuellen Kanal. Diese wird zu bestimmten Zeiten als broadcast gesendet. Diese Zeiten kennt der RT und hält sich kurzfristig empfangsbereit.

Sollte es Probleme geben, dass der RT des Öfteren wieder auf seine eigenen Messwerte wechselt, weil die von FHEM errechnete Sendezeit und die vom RT errechnete Empfangszeit zu weit auseinanderliegen, sollte das Attr cyclicMsgOffset im Virtuellen Kanal beachtet werden. Näheres dazu ist ca. ab hier im Forum zu finden.

7. Sicherstellen, dass nicht längerfristig veraltete Temperaturdaten berücksichtigt werden: Aufgrund des oben beschriebenen Verfahrens wird der im virtuellen Kanal vorhandene Wert solange immer wieder gesendet, wie dieser dort steht. Fällt z.B. der echte Sensor oder das Interface nicht nur vorübergehend aus, muß der Wert gelöscht werden. Hier ein Vorschlag für ein at, das alle 15 Minuten alle virtuellen Temperaturwerte löscht, die älter als eine Stunde sind, und damit den Rückfall des jeweiligen RT auf seinen internen Sensor bewirkt:

defmod a_delete_outdated_virtTemps at +*00:15 {\
my @vTemps = devspec2array("TYPE=CUL_HM:FILTER=model=VIRTUAL:FILTER=temperature~.+");;\
 for my $vTemp (@vTemps) {\
   CommandDeleteReading(undef,"$vTemp temperature" ) if ReadingsAge($vTemp,"temperature",0) > HOURSECONDS ;;\
 }\
}

Erhält der RT eine gewisse Zeitlang (ca. 15 Minuten) keinen Wert von seinem (virtuellen) Peer, schaltet er auf den internen Temperatursensor zurück und signalisiert dies durch ein blinkendes Funksymbol im Display.

Exkurs: HMCCUDEV

Das Nachfolgende entspricht dem Stand Janaur 2020. Die HMCCU-Module sind jedoch derzeit in der Weiterentwicklung, so dass es sich ggf. empfiehlt, im Forum nachzufragen.

Das Nutzen externer Sensoren scheint mit HMCCU nicht möglich zu sein, siehe Forenbeitrag: RaspberryMatic (HMCCU) und LaCrosse Temperature als "Wandthermostat", die Weitergabe eines externen Türkontakts ist eventuell möglich, siehe Forenbeitrag: HMCCU mit Thermostat HM-CC-RT-DN und ZWave Türsensor, an anderer Stelle hat der Modulentwickler ausgeführt, es könnten nur HomeMatic Geräte als Sensoren verwendet werden.

Auflistung und Beschreibung der Readings

Einige der Readings können via "regSet" parametriert werden. Wobei der Registername etwas anders geschrieben wird als der Reading Name (ohne R-).

set <name> regSet <register> <value>

Beispiel für Reading R-winOpnPeriod erhöhen auf 60 Minuten:

set EG_Buero_THERMOSTAT_Clima regSet winOpnPeriod 60

Eine vollständige Liste erhält man auch, wenn man einen falschen Registernamen angibt.

 supported register are backOnTime boostPeriod boostPos btnLock btnNoBckLight burstRx cyclicInfoMsg cyclicInfoMsgDis dayTemp daylightSaveTime decalcTime decalcWeekday globalBtnLock localResDis lowBatLimitRT modePrioManu modePrioParty modusBtnLock nightTemp noMinMax4Manu pairCentral regAdaptive reguExtI reguExtP reguExtPstart reguIntI reguIntP reguIntPstart showInfo showWeekday sign tempMax tempMin tempOffset valveErrPos valveMaxPos valveOffsetRt winOpnBoost winOpnDetFall winOpnMode winOpnPeriod winOpnTempI

Reading	Beispielwert	Mögliche Werte	Beschreibung
CommandAccepted	yes	yes; no	Letztes Kommando akzeptiert (yes/ No)
R-boostPeriod	5 min	1 min bis x min	Zeit wie lange das Ventil im Boost Modus sein soll.
R-boostPos	80%	0 bis 100	Ventilposition die im Boost Modus gesetzt wird.
R-btnNoBckLight	off	on; off	???
R-dayTemp	21 C	Siehe R-tempMin bis R-tempMax	Solltemperatur die gesetzt werden soll, wenn das Sonnensymbol am Thermostat gedrückt wird. Ebenso wird bei dieser Solltemperatur das Sonnensymbol im Display angezeigt.
R-daylightSaveTime	on	on; off	???
R-decalcTime	11:00	00:00 bis 23:59	Uhrzeit wann die Entkalkungsfahrt durchgeführt werden soll.
R-decalcWeekday	Sat	Mon; Tue; Wed; Thu; Fri; Sat; Sun	Tag an dem die Entkalkungsfahrt durchgeführt werden soll.
R-modePrioManu	all	all; ???	???
R-modePrioParty	all	all; ???	???
R-nightTemp	17 C	Siehe R-tempMin bis R-tempMax	Solltemperatur die gesetzt werden soll, wenn das Mondsymbol am Thermostat gedrückt wird. Ebenso wird bei dieser Solltemperatur das Mondsymbol im Display angezeigt.
R-noMinMax4Manu	off	on; off	???
R-regAdaptive	on	on; off	???
R-reguExtI	15	???	???
R-reguExtP	30	???	???
R-reguExtPstart	30	???	???
R-reguIntI	18	???	???
R-reguIntP	33	???	???
R-reguIntPstart	44	???	???
R-showInfo	time	date; time	Zeige Datum oder Uhrzeit im Display an
R-showWeekday	off	on; off	Zeige den Wochentag im Display an
R-sign	off	on; off	???
R-tempMax	30.5 C	???	Größte einstellbare Temperatur
R-tempMin	4.5 C	???	Kleinste einstellbare Temperatur
R-tempOffset	0.0K	0.0 bis ???	Temperaturabweichung gemessene Temperatur vs. realer Temperatur in Grad Kelvin. Angabe in 0.5-Schritten ohne Einheitenzeichen, z.B. 0.5 oder -1.0
R-valveErrPos	15%	???	???
R-valveMaxPos	100%	0 bis 100	Maximale Ventilstellung die das Thermostat fahren darf.
R-valveOffsetRt	0%	0 Bis 100	???
R-winOpnBoost	off	on; off	Startet nach dem Fensterschließen die Boostfunktion um unabhängig von der Raumtemperatur den Heizkörper eine Zeit x aufzuheizen. (Siehe R-boostPeriod & R-boostPos)
R-winOpnDetFall	1.4 K	0.5 bis 2.5	Temperatur Sturz zwischen zwei Messungen, die als Fenster offen erkannt werden.
R-winOpnMode	off	on; off	Thermostat soll anhand eines schnellen Temperaturabfalls erkennen, dass das Fenster geöffnet ist.
R-winOpnPeriod	15 min	1 bis 60 Minuten	Dauer bis das Signal Fenster offen wieder entfernt wird.
R-winOpnTemp	12 C	Siehe R-tempMin bis R-tempMax	Temperatur die eingestellt werden soll, wenn das Fenster als offen erkannt wird.
R_0_tempListSat	07:00 20.0 22:30 22.0 24:00 20.0	incomplete = Daten werden mit Thermostat abgeglichen Zeit/Temperaturangaben siehe Beispiel	Tages Solltemperaturen abhängig von der Uhrzeit. - Der Beginn um 00:00 ist nicht einzutragen. - Es sind immer Paare einzutragen (Uhrzeit Temperatur). - Der letzte Eintrag muss an jedem Tag 24:00 sein. - Uhrzeiten sind auf halbe Stunden beschränkt. Einträge 08:00 und 08:30 sind gültig. 08:20 ist ungültig.
R_1_tempListSun	07:00 20.0 22:00 22.0 24:00 20.0	Siehe R_0_tempListSat	Siehe R_0_tempListSat
R_2_tempListMon	04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0	Siehe R_0_tempListSat	Siehe R_0_tempListSat
R_3_tempListTue	04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0	Siehe R_0_tempListSat	Siehe R_0_tempListSat
R_4_tempListWed	04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0	Siehe R_0_tempListSat	Siehe R_0_tempListSat
R_5_tempListThu	04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0	Siehe R_0_tempListSat	Siehe R_0_tempListSat
R_6_tempListFri	04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0	Siehe R_0_tempListSat	Siehe R_0_tempListSat
R_tempList_State	verified	incomplete = Daten werden mit Thermostat abgeglichen verified = Daten sind mit Thermostat abgeglichen	Aktualisierungsstatus der Wochen Temperatur Einstellungen
ValvePosition	36	0 bis 100	aktuelle Ventilstellung
boostTime	-	- 1 min bis n min	Zeit wie lange der Boostmodus noch aktiv ist.
controlMode	auto	auto = Thermostat wird nach der TempListe gesteuert manual = Die eingestellte Temperatur am Thermostat wird nicht verändert, außer bei Verwendung von WinOpn; boost = Thermostat wird in den Boost Modus gesetzt. Siehe R-boostPeriod/Pos day = Thermostat wird auf die eingestellte Tag Temperatur gesetzt (R-dayTemp). night = Thermostat wird auf die eingestellte Nacht Temperatur gesetzt (R-nightTemp).	Setzt das Thermostat in einen bestimmten Modus
desired-temp	22	N/A	Solltemperatur
measured-temp	23.2	N/A	Isttemperatur
partyEnd	-	???	Ende Datum/Zeit in dem die Party Temperatur (partyTemp) gesetzt sein soll.
partyStart	-	???	Start Datum/Zeit in dem die Party Temperatur (partyTemp) gesetzt sein soll.
partyTemp	-	-; 20.0	Party Temperatur
recentStateType	ack	???	???
state	T: 23.2 desired: 22.0 valve: 36		Aktuelle Statusinformation

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.

Der Thermostat heizt über die Solltemperatur hinaus

In der Regel ist das ein ganz normales Verhalten, wenn der Thermostat nicht mit einem externen Temperaturfühler oder einem Wandthermostat gepeert ist. In dem Fall muss sich der Thermostat auf den eingebauten Temperatursensor verlassen, der sehr nahe an der Heizung selbst sitzt. Dadurch ist die gemessene Temperatur höher, als sie z.B. in der Raummitte wäre. Der Hersteller hat hier einen mehr oder weniger intelligenten Algorithmus eingebaut, um diesen Effekt zu kompensieren. Das sieht dann so aus, als ob der Thermostat nicht richtig regelt. Dieses Verhalten kann man im Prinzip nur verhindern, indem man einen externen Temperatursensor oder einen Wandthermostat peert. Wie das geht ist hier beschrieben: #Channel (Kanal) 01 _Weather. Normalerweise regelt der Thermostat dann genau auf die Solltemperatur. Ansonsten sollte man sich auch fragen, ob das gezeigte Verhalten vielleicht doch gut genug ist. Dazu platziert man irgendein Thermometer möglichst in der Mitte des Raums und beobachtet den Temperaturverlauf eine Weile. Wenn man dann noch eine Abweichung feststellt, kann es sinnvoll sein, diese mittels des Registers R-tempOffset zu beheben.

Pairen bei Firmware 1.5

Ein weiterer, etwas weniger komplexer Vorschlag zur Vermeidung von Pairing Problemen mit V1.5 findet sich im gleichen ELV Diskussionsthema und besteht aus den folgenden Schritten:

1. Pairing, wie angegeben
2. Zeit in FHEM abwarten, die für das Anlernen gesetzt wurde
3. Batterie entfernen, 30 Sekunden warten, Batterie wieder einsetzen
4. Erneut die Anlerntaste (mittlere Taste) lang drücken - AC sollte erscheinen
5. getConfig und burstXmit auf dem Device ausführen
6. Eventuell noch mal getConfig und Anlerntaste

Das nachfolgende Vorgehen bietet sich ab Firmware 1.5 ab, da sonst das pairen nicht erfolgreich sein wird:

1. Pairing wie angegeben
2. GetConfig erst, nachdem die Zeit von hmPairForSec abgelaufen ist
3. burstXmit
4. set <gerät> reset
5. set <gerät> unpair
   jetzt nichts löschen!
6. harten HW Reset nach Handbuch am Gerät
7. erneut pairen

Der Tipp stammt aus diesem Beitrag im ELV Forum. Dies Vorgang konnte teilweise auch für Geräte mit Firmware 1.4 bestätigt werden.

Falls es Probleme während der Prozedur gibt, bitte den Abschnitt HM-CC-RT-DN_spezifische_Update_Informationen beachten.

Akkubetrieb

Auch frisch geladenen NiMh-Akkus weisen nur eine Zellenspannung von nur ca. 1,2 Volt auf. Deshalb wird schnell die battery:low Warngrenze erreicht, die bei U < 2,4V liegt und mitunter unmittelbar nach dem Einsetzen mit der Kalibierungsfahrt unterschritten wird. Mit NiMh-Akkus mit geringer Selbstentladung (z.b. Panasonic Eneloop) ist ein Betrieb jedoch sinnvoll möglich, da der Spannungsabfall bei den sehr geringen Entladeströmen im Stellantrieb relativ lange oberhalb 1,3 Volt verläuft.

Links

• Produktinfo bei EQ-3
• Bedienungsanleitung bei EQ-3 (PDF)
• Datenblatt bei EQ-3 (PDF)
• Ventil-Kompatibilitätsliste bei EQ-3 (zur Zeit nicht verfügbar)
• Forenthema zum Thermostat
• Reparatur einer durch mechanischen Stoß von außen abgerissenen Lichtschranke