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

Ph1959de: Weitere Tipps zu Pairingproblemen mit Firmware V1.5

2023-11-10T10:11:24Z

Weitere Tipps zu Pairingproblemen mit Firmware V1.5

← Nächstältere Version		Version vom 10. November 2023, 12:11 Uhr
Zeile 767:		Zeile 767:

	=== Pairen bei Firmware 1.5 ===		=== Pairen bei Firmware 1.5 ===
			{{Randnotiz\|RNTyp=y\|RNText=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:
			# Pairing, wie angegeben
			# Zeit in FHEM abwarten, die für das Anlernen gesetzt wurde
			# Batterie entfernen, 30 Sekunden warten, Batterie wieder einsetzen
			# Erneut die Anlerntaste (mittlere Taste) lang drücken - AC sollte erscheinen
			# getConfig und burstXmit auf dem Device ausführen
			# Eventuell noch mal getConfig und Anlerntaste
			}}
	Das nachfolgende Vorgehen bietet sich ab Firmware 1.5 ab, da sonst das pairen nicht erfolgreich sein wird:		Das nachfolgende Vorgehen bietet sich ab Firmware 1.5 ab, da sonst das pairen nicht erfolgreich sein wird:
	# Pairing wie angegeben		# Pairing wie angegeben
Zeile 772:		Zeile 780:
	# burstXmit		# burstXmit
	# set <gerät> reset		# set <gerät> reset
	# set <gerät> unpair		# set <gerät> unpair <br>jetzt '''nichts löschen!'''
	# harten HW Reset nach Handbuch am Gerät		# harten HW Reset nach Handbuch am Gerät
	# erneut pairen		# erneut pairen

Ph1959de: syntaxhighlight korrigiert (ersetzt durch `)`


2023-04-08T17:51:40Z
syntaxhighlight korrigiert (ersetzt durch <code>)

				
				
				
				
				
				← Nächstältere Version
				Version vom 8. April 2023, 19:51 Uhr
				
Zeile 338:
Zeile 338:
notwendig. Daraufhin werden die Readings übertragen/aktualisiert. notwendig. Daraufhin werden die Readings übertragen/aktualisiert.



Anscheinend (siehe {{Link2Forum|Topic=93074|Msg=1252268|LinkText=dieses Forenthema}}) wird bei Firmware 1.5 ein weiteres Attribut benötigt, Anscheinend (siehe {{Link2Forum|Topic=93074|Msg=1252268|LinkText=dieses Forenthema}}) wird bei Firmware 1.5 ein weiteres Attribut benötigt
<syntaxhighlight> :<code>attr <devicename> commStInChn off</code>
attr <devicename> commStInChn off 
</syntaxhighlight> 



== Simulation von Fensterkontakten und externen Temperatursensoren == == Simulation von Fensterkontakten und externen Temperatursensoren ==



Ph1959de: Forenlink auf Vorlagenbenutzung umgestellt
2023-01-23T07:25:12Z
Forenlink auf Vorlagenbenutzung umgestellt

				
				
				
				
				
				← Nächstältere Version
				Version vom 23. Januar 2023, 09:25 Uhr
				
Zeile 338:
Zeile 338:
notwendig. Daraufhin werden die Readings übertragen/aktualisiert. notwendig. Daraufhin werden die Readings übertragen/aktualisiert.



Anscheinend ([https://forum.fhem.de/index.php?topic=93074.msg1252268#msg1252268]) benötigt man bei Firmware 1.5 ein weiteres Attribut,<syntaxhighlight> Anscheinend (siehe {{Link2Forum|Topic=93074|Msg=1252268|LinkText=dieses Forenthema}}) wird bei Firmware 1.5 ein weiteres Attribut benötigt,
<syntaxhighlight>
attr <devicename> commStInChn off attr <devicename> commStInChn off
</syntaxhighlight> </syntaxhighlight>



Beta-User: update von virtuellen Sensoren
2023-01-12T14:16:11Z
update von virtuellen Sensoren

				
				
				
				
				
				← Nächstältere Version
				Version vom 12. Januar 2023, 16:16 Uhr
				
Zeile 359:
Zeile 359:
  define virtKitchenSensors CUL_HM 221133   define virtKitchenSensors CUL_HM 221133
Um das Device als virtuelles zu kennzeichnen benötigt man den folgenden Befehl (legt weitere Attribute an):   Um das Device als virtuelles zu kennzeichnen benötigt man den folgenden Befehl (legt weitere Attribute an):  
  attr virtKitchenSensors modelForce VIRTUAL   attr virtKitchenSensors model VIRTUAL



Kanal bzw. Kanäle erstellen: Kanal bzw. Kanäle erstellen (benötigt uU. einen Neustart von FHEM, bevor der Befehl zur Verfügung steht):
  set virtKitchenSensors virtual 1     set virtKitchenSensors virtual 1  
oder (für das Anlegen je eines Kanals für einen Fenster- und Temperatur-Kanal): oder (für das Anlegen je eines Kanals für einen Fenster- und Temperatur-Kanal):



Prodigy7: /* Pairen bei Firmware 1.5 */
2022-12-19T15:17:13Z
Pairen bei Firmware 1.5

				
				
				
				
				
				← Nächstältere Version
				Version vom 19. Dezember 2022, 17:17 Uhr
				
Zeile 777:
Zeile 777:
# erneut pairen # erneut pairen
Der Tipp stammt aus [https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481 diesem Beitrag] im ELV Forum. Dies Vorgang konnte teilweise auch für Geräte mit Firmware 1.4 bestätigt werden. Der Tipp stammt aus [https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481 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 Funk-Heizkörperthermostat#HM-CC-RT-DN spezifische Update Informationen|HM-CC-RT-DN_spezifische_Update_Informationen]] beachten.



=== Akkubetrieb === === Akkubetrieb ===



Andies: /* HM-CC-RT-DN spezifische Update Informationen */ siehe Forum
2022-12-19T02:47:12Z
HM-CC-RT-DN spezifische Update Informationen:  siehe Forum

				
				
				
				
				
				← Nächstältere Version
				Version vom 19. Dezember 2022, 04:47 Uhr
				
Zeile 337:
Zeile 337:
:<code>set Device_Channel04 controlMode auto </code> :<code>set Device_Channel04 controlMode auto </code>
notwendig. Daraufhin werden die Readings übertragen/aktualisiert. notwendig. Daraufhin werden die Readings übertragen/aktualisiert.

Anscheinend ([https://forum.fhem.de/index.php?topic=93074.msg1252268#msg1252268]) benötigt man bei Firmware 1.5 ein weiteres Attribut,<syntaxhighlight>
attr <devicename> commStInChn off
</syntaxhighlight>



== Simulation von Fensterkontakten und externen Temperatursensoren == == Simulation von Fensterkontakten und externen Temperatursensoren ==



Ph1959de: Link auf HMInfo angepasst
2021-12-03T10:54:18Z
Link auf HMInfo angepasst

				
				
				
				
				
				← Nächstältere Version
				Version vom 3. Dezember 2021, 12:54 Uhr
				
Zeile 15:
Zeile 15:
|HWManufacturer=ELV / eQ-3 |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.
'''HM-CC-RT-DN''' (häufig einfach '''RT''' genannt) ist ein Funk-''Heizkörperthermostate'' mit integriertem ''Stellantrieb''. Das Thermostat ist seit September&nbsp;2013 verfügbar und ist der Nachfolger des [[HM-CC-VD Funk-Stellantrieb]]s. 



== Vorbemerkungen == == Vorbemerkungen ==
Zeile 78:
Zeile 77:
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). 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 (siehe [https://forum.fhem.de/index.php/topic,41541.msg348044.html#msg348044 diesen Thread]): 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 {{Link2Forum|Topic=41541|LinkText=diesen Thread}}):
  set <fensterSensor> peerChan 0 <rt_WindowRec>_WindowRec single     set <fensterSensor> peerChan 0 <rt_WindowRec>_WindowRec single  



Zeile 238:
Zeile 237:



Devices mit abschaltbarem Burst wie z.B. der ''HM-CC-RT-DN'' haben ein Register, ''burstRx'', mit dem das burst-Erwachen eingestellt werden kann.   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. 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'''   '''Attribut burstAccess'''  
Zeile 398:
Zeile 397:
  set Kitchen_vT_Sensor1 peerChan 0 <RT_DN>_Weather single   set Kitchen_vT_Sensor1 peerChan 0 <RT_DN>_Weather single



5. Peering kontrollieren (Voraussetzung: Device ''hm'' vom Typ [[HomeMatic HMInfo|HMinfo]] existiert): 5. Peering kontrollieren (Voraussetzung: Device ''hm'' vom Typ [[HMInfo]] existiert):
:<code>set hm peerXref</code> :<code>set hm peerXref</code>
Beispiel-Ausgabe: Beispiel-Ausgabe:
Zeile 424:
Zeile 423:
=== Exkurs: HMCCUDEV  === === Exkurs: HMCCUDEV  ===
{{Hinweis|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.}} {{Hinweis|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 {{Link2Forum|Topic=107134|LinkText=Forenbeitrag: RaspberryMatic (HMCCU) und LaCrosse Temperature als "Wandthermostat"}}, die Weitergabe eines externen Türkontakts ist eventuell  möglich, siehe {{Link2Forum|Topic=106807|LinkText=Forenbeitrag: HMCCU mit Thermostat HM-CC-RT-DN und ZWave Türsensor}}, an anderer Stelle hat der Modulentwickler ausgeführt, es könnten nur {{Link2Forum|Topic=107501|Message=1015944|LinkText=Homematic Geräte}} als Sensoren verwendet werden. Das Nutzen externer Sensoren scheint mit HMCCU nicht möglich zu sein, siehe {{Link2Forum|Topic=107134|LinkText=Forenbeitrag: RaspberryMatic (HMCCU) und LaCrosse Temperature als "Wandthermostat"}}, die Weitergabe eines externen Türkontakts ist eventuell  möglich, siehe {{Link2Forum|Topic=106807|LinkText=Forenbeitrag: HMCCU mit Thermostat HM-CC-RT-DN und ZWave Türsensor}}, an anderer Stelle hat der Modulentwickler ausgeführt, es könnten nur {{Link2Forum|Topic=107501|Message=1015944|LinkText=HomeMatic Geräte}} als Sensoren verwendet werden.



== Auflistung und Beschreibung der Readings == == Auflistung und Beschreibung der Readings ==

Einige der Readings können via "regSet" parametriert werden. Einige der Readings können via "regSet" parametriert werden.
Wobei der Registername etwas anders geschrieben wird als der Reading Name (ohne R-). Wobei der Registername etwas anders geschrieben wird als der Reading Name (ohne R-).
  :<code>set <name> regSet <register> <value> </code>
  set <name> regSet <register> <value> 
Beispiel für Reading R-winOpnPeriod erhöhen auf 60 Minuten:   Beispiel für Reading R-winOpnPeriod erhöhen auf 60 Minuten:  
  set EG_Buero_THERMOSTAT_Clima regSet winOpnPeriod 60 :<code>set EG_Buero_THERMOSTAT_Clima regSet winOpnPeriod 60 </code>



Eine vollständige Liste erhält man auch, wenn man einen Falschen Register Namen angibt. 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    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



Zeile 776:
Zeile 773:
# erneut pairen # erneut pairen
Der Tipp stammt aus [https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481 diesem Beitrag] im ELV Forum. Dies Vorgang konnte teilweise auch für Geräte mit Firmware 1.4 bestätigt werden. Der Tipp stammt aus [https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481 diesem Beitrag] im ELV Forum. Dies Vorgang konnte teilweise auch für Geräte mit Firmware 1.4 bestätigt werden.




=== Akkubetrieb === === Akkubetrieb ===



Soulman: /* Bekannte Probleme */ Ergänzung Akkubetrieb
2021-03-13T16:11:26Z
Bekannte Probleme:  Ergänzung Akkubetrieb

				
				
				
				
				
				← Nächstältere Version
				Version vom 13. März 2021, 18:11 Uhr
				
Zeile 776:
Zeile 776:
# erneut pairen # erneut pairen
Der Tipp stammt aus [https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481 diesem Beitrag] im ELV Forum. Dies Vorgang konnte teilweise auch für Geräte mit Firmware 1.4 bestätigt werden. Der Tipp stammt aus [https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481 diesem Beitrag] im ELV Forum. Dies Vorgang konnte teilweise auch für Geräte mit Firmware 1.4 bestätigt werden.


=== 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 == == Links ==



LordVoodoo: Anmerkung ergänzt, nach dem das Vorgehen bei einem Thermostat mit Firmware 1.4 ebenfalls ein Pairing erfolgreich machte. Zuvor immer unvollständig.
2021-01-30T17:01:15Z
Anmerkung ergänzt, nach dem das Vorgehen bei einem Thermostat mit Firmware 1.4 ebenfalls ein Pairing erfolgreich machte. Zuvor immer unvollständig.
Änderungen zeigen


Beta-User: /* Temperatursensoren */
2020-12-11T10:07:38Z
Temperatursensoren

				
				
				
				
				
				← Nächstältere Version
				Version vom 11. Dezember 2020, 12:07 Uhr
				
Zeile 406:
Zeile 406:
     Kitchen_vT_Sensor1 => wz_Thermostat_Weather      Kitchen_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 notify: 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   define at_Kitchen_vT notify myRealKitchenTempSensor:temperature:.* set Kitchen_vT_Sensor1 virtTemp $EVTPART1



Zeile 413:
Zeile 413:



7. Sicherstellen, dass nicht längerfristig veraltete Temperaturdaten berücksichtigt werden: 7. Sicherstellen, dass nicht längerfristig veraltete Temperaturdaten berücksichtigt werden:
Aufgrund des oben beschriebenen Verfahrens wird solange der im virtuellen Kanal vorhandene Wert 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: 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 {\   defmod a_delete_outdated_virtTemps at +*00:15 {\
  my @vTemps = devspec2array("TYPE=CUL_HM:FILTER=model=VIRTUAL:FILTER=temperature~.+");;\   my @vTemps = devspec2array("TYPE=CUL_HM:FILTER=model=VIRTUAL:FILTER=temperature~.+");;\
   foreach my $vTemp (@vTemps) {\    for my $vTemp (@vTemps) {\
     CommandDeleteReading(undef,"$vTemp temperature" ) if ReadingsAge($vTemp,"temperature",0) > HOURSECONDS ;;\      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  === === Exkurs: HMCCUDEV  ===
{{Hinweis|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.}} {{Hinweis|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.}}

← Nächstältere Version		Version vom 8. April 2023, 19:51 Uhr
Zeile 338:		Zeile 338:
	notwendig. Daraufhin werden die Readings übertragen/aktualisiert.		notwendig. Daraufhin werden die Readings übertragen/aktualisiert.

	Anscheinend (siehe {{Link2Forum\|Topic=93074\|Msg=1252268\|LinkText=dieses Forenthema}}) wird bei Firmware 1.5 ein weiteres Attribut benötigt,		Anscheinend (siehe {{Link2Forum\|Topic=93074\|Msg=1252268\|LinkText=dieses Forenthema}}) wird bei Firmware 1.5 ein weiteres Attribut benötigt
	<~~syntaxhighlight~~>		:<code>attr <devicename> commStInChn off</code>
	attr <devicename> commStInChn off
	</~~syntaxhighlight~~>

	== Simulation von Fensterkontakten und externen Temperatursensoren ==		== Simulation von Fensterkontakten und externen Temperatursensoren ==

← Nächstältere Version		Version vom 23. Januar 2023, 09:25 Uhr
Zeile 338:		Zeile 338:
	notwendig. Daraufhin werden die Readings übertragen/aktualisiert.		notwendig. Daraufhin werden die Readings übertragen/aktualisiert.

	Anscheinend (~~[https://forum.fhem.de/index.php?topic~~=93074~~.msg1252268#msg1252268]~~) ~~benötigt man~~ bei Firmware 1.5 ein weiteres Attribut,<syntaxhighlight>		Anscheinend (siehe {{Link2Forum\|Topic=93074\|Msg=1252268\|LinkText=dieses Forenthema}}) wird bei Firmware 1.5 ein weiteres Attribut benötigt,
			<syntaxhighlight>
	attr <devicename> commStInChn off		attr <devicename> commStInChn off
	</syntaxhighlight>		</syntaxhighlight>

← Nächstältere Version		Version vom 12. Januar 2023, 16:16 Uhr
Zeile 359:		Zeile 359:
	define virtKitchenSensors CUL_HM 221133		define virtKitchenSensors CUL_HM 221133
	Um das Device als virtuelles zu kennzeichnen benötigt man den folgenden Befehl (legt weitere Attribute an):		Um das Device als virtuelles zu kennzeichnen benötigt man den folgenden Befehl (legt weitere Attribute an):
	attr virtKitchenSensors ~~modelForce~~ VIRTUAL		attr virtKitchenSensors model VIRTUAL

	Kanal bzw. Kanäle erstellen:		Kanal bzw. Kanäle erstellen (benötigt uU. einen Neustart von FHEM, bevor der Befehl zur Verfügung steht):
	set virtKitchenSensors virtual 1		set virtKitchenSensors virtual 1
	oder (für das Anlegen je eines Kanals für einen Fenster- und Temperatur-Kanal):		oder (für das Anlegen je eines Kanals für einen Fenster- und Temperatur-Kanal):

← Nächstältere Version		Version vom 19. Dezember 2022, 17:17 Uhr
Zeile 777:		Zeile 777:
	# erneut pairen		# erneut pairen
	Der Tipp stammt aus [https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481 diesem Beitrag] im ELV Forum. Dies Vorgang konnte teilweise auch für Geräte mit Firmware 1.4 bestätigt werden.		Der Tipp stammt aus [https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481 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 Funk-Heizkörperthermostat#HM-CC-RT-DN spezifische Update Informationen\|HM-CC-RT-DN_spezifische_Update_Informationen]] beachten.

	=== Akkubetrieb ===		=== Akkubetrieb ===

← Nächstältere Version		Version vom 19. Dezember 2022, 04:47 Uhr
Zeile 337:		Zeile 337:
	:<code>set Device_Channel04 controlMode auto </code>		:<code>set Device_Channel04 controlMode auto </code>
	notwendig. Daraufhin werden die Readings übertragen/aktualisiert.		notwendig. Daraufhin werden die Readings übertragen/aktualisiert.

			Anscheinend ([https://forum.fhem.de/index.php?topic=93074.msg1252268#msg1252268]) benötigt man bei Firmware 1.5 ein weiteres Attribut,<syntaxhighlight>
			attr <devicename> commStInChn off
			</syntaxhighlight>

	== Simulation von Fensterkontakten und externen Temperatursensoren ==		== Simulation von Fensterkontakten und externen Temperatursensoren ==

← Nächstältere Version		Version vom 3. Dezember 2021, 12:54 Uhr
Zeile 15:		Zeile 15:
	\|HWManufacturer=ELV / eQ-3		\|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.
	'''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 ==		== Vorbemerkungen ==
Zeile 78:		Zeile 77:
	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).		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 (siehe ~~[https://forum.fhem.de/index.php/topic,~~41541~~.msg348044.html#msg348044~~ diesen Thread]):		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 {{Link2Forum\|Topic=41541\|LinkText=diesen Thread}}):
	set <fensterSensor> peerChan 0 <rt_WindowRec>_WindowRec single		set <fensterSensor> peerChan 0 <rt_WindowRec>_WindowRec single

Zeile 238:		Zeile 237:

	Devices mit abschaltbarem Burst wie z.B. der ''HM-CC-RT-DN'' haben ein Register, ''burstRx'', mit dem das burst-Erwachen eingestellt werden kann.		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.		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'''		'''Attribut burstAccess'''
Zeile 398:		Zeile 397:
	set Kitchen_vT_Sensor1 peerChan 0 <RT_DN>_Weather single		set Kitchen_vT_Sensor1 peerChan 0 <RT_DN>_Weather single

	5. Peering kontrollieren (Voraussetzung: Device ''hm'' vom Typ [[~~HomeMatic~~ HMInfo~~\|HMinfo~~]] existiert):		5. Peering kontrollieren (Voraussetzung: Device ''hm'' vom Typ [[HMInfo]] existiert):
	:<code>set hm peerXref</code>		:<code>set hm peerXref</code>
	Beispiel-Ausgabe:		Beispiel-Ausgabe:
Zeile 424:		Zeile 423:
	=== Exkurs: HMCCUDEV ===		=== Exkurs: HMCCUDEV ===
	{{Hinweis\|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.}}		{{Hinweis\|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 {{Link2Forum\|Topic=107134\|LinkText=Forenbeitrag: RaspberryMatic (HMCCU) und LaCrosse Temperature als "Wandthermostat"}}, die Weitergabe eines externen Türkontakts ist eventuell möglich, siehe {{Link2Forum\|Topic=106807\|LinkText=Forenbeitrag: HMCCU mit Thermostat HM-CC-RT-DN und ZWave Türsensor}}, an anderer Stelle hat der Modulentwickler ausgeführt, es könnten nur {{Link2Forum\|Topic=107501\|Message=1015944\|LinkText=~~Homematic~~ Geräte}} als Sensoren verwendet werden.		Das Nutzen externer Sensoren scheint mit HMCCU nicht möglich zu sein, siehe {{Link2Forum\|Topic=107134\|LinkText=Forenbeitrag: RaspberryMatic (HMCCU) und LaCrosse Temperature als "Wandthermostat"}}, die Weitergabe eines externen Türkontakts ist eventuell möglich, siehe {{Link2Forum\|Topic=106807\|LinkText=Forenbeitrag: HMCCU mit Thermostat HM-CC-RT-DN und ZWave Türsensor}}, an anderer Stelle hat der Modulentwickler ausgeführt, es könnten nur {{Link2Forum\|Topic=107501\|Message=1015944\|LinkText=HomeMatic Geräte}} als Sensoren verwendet werden.

	== Auflistung und Beschreibung der Readings ==		== Auflistung und Beschreibung der Readings ==

	Einige der Readings können via "regSet" parametriert werden.		Einige der Readings können via "regSet" parametriert werden.
	Wobei der Registername etwas anders geschrieben wird als der Reading Name (ohne R-).		Wobei der Registername etwas anders geschrieben wird als der Reading Name (ohne R-).
			:<code>set <name> regSet <register> <value> </code>
	set <name> regSet <register> <value>
	Beispiel für Reading R-winOpnPeriod erhöhen auf 60 Minuten:		Beispiel für Reading R-winOpnPeriod erhöhen auf 60 Minuten:
	set EG_Buero_THERMOSTAT_Clima regSet winOpnPeriod 60		:<code>set EG_Buero_THERMOSTAT_Clima regSet winOpnPeriod 60 </code>

	Eine vollständige Liste erhält man auch, wenn man einen ~~Falschen Register Namen~~ angibt.		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		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

Zeile 776:		Zeile 773:
	# erneut pairen		# erneut pairen
	Der Tipp stammt aus [https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481 diesem Beitrag] im ELV Forum. Dies Vorgang konnte teilweise auch für Geräte mit Firmware 1.4 bestätigt werden.		Der Tipp stammt aus [https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481 diesem Beitrag] im ELV Forum. Dies Vorgang konnte teilweise auch für Geräte mit Firmware 1.4 bestätigt werden.


	=== Akkubetrieb ===		=== Akkubetrieb ===

← Nächstältere Version		Version vom 13. März 2021, 18:11 Uhr
Zeile 776:		Zeile 776:
	# erneut pairen		# erneut pairen
	Der Tipp stammt aus [https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481 diesem Beitrag] im ELV Forum. Dies Vorgang konnte teilweise auch für Geräte mit Firmware 1.4 bestätigt werden.		Der Tipp stammt aus [https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481 diesem Beitrag] im ELV Forum. Dies Vorgang konnte teilweise auch für Geräte mit Firmware 1.4 bestätigt werden.


			=== 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 ==		== Links ==

← Nächstältere Version		Version vom 11. Dezember 2020, 12:07 Uhr
Zeile 406:		Zeile 406:
	Kitchen_vT_Sensor1 => wz_Thermostat_Weather		Kitchen_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 notify:		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		define at_Kitchen_vT notify myRealKitchenTempSensor:temperature:.* set Kitchen_vT_Sensor1 virtTemp $EVTPART1

Zeile 413:		Zeile 413:

	7. Sicherstellen, dass nicht längerfristig veraltete Temperaturdaten berücksichtigt werden:		7. Sicherstellen, dass nicht längerfristig veraltete Temperaturdaten berücksichtigt werden:
	Aufgrund des oben beschriebenen Verfahrens wird ~~solange~~ der im virtuellen Kanal vorhandene Wert 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:		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 {\		defmod a_delete_outdated_virtTemps at +*00:15 {\
	my @vTemps = devspec2array("TYPE=CUL_HM:FILTER=model=VIRTUAL:FILTER=temperature~.+");;\		my @vTemps = devspec2array("TYPE=CUL_HM:FILTER=model=VIRTUAL:FILTER=temperature~.+");;\
	~~foreach~~ my $vTemp (@vTemps) {\		for my $vTemp (@vTemps) {\
	CommandDeleteReading(undef,"$vTemp temperature" ) if ReadingsAge($vTemp,"temperature",0) > HOURSECONDS ;;\		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 ===		=== Exkurs: HMCCUDEV ===
	{{Hinweis\|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.}}		{{Hinweis\|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.}}

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

Ph1959de: Weitere Tipps zu Pairingproblemen mit Firmware V1.5

Ph1959de: syntaxhighlight korrigiert (ersetzt durch )

Ph1959de: Forenlink auf Vorlagenbenutzung umgestellt

Beta-User: update von virtuellen Sensoren

Prodigy7: /* Pairen bei Firmware 1.5 */

Andies: /* HM-CC-RT-DN spezifische Update Informationen */ siehe Forum

Ph1959de: Link auf HMInfo angepasst

Soulman: /* Bekannte Probleme */ Ergänzung Akkubetrieb

LordVoodoo: Anmerkung ergänzt, nach dem das Vorgehen bei einem Thermostat mit Firmware 1.4 ebenfalls ein Pairing erfolgreich machte. Zuvor immer unvollständig.

Beta-User: /* Temperatursensoren */

Ph1959de: syntaxhighlight korrigiert (ersetzt durch `)`