HM-CC-RT-DN

Thomask · 28 Oktober 2013, 18:16:21

Hallo,

ich habe seit 2 Tagen das neue Thermostat zu laufen. (ist mein erstes HM-Thermostat überhaupt).
Es funktioniert mit der Steuerung auch bisher gut.

Mir bleiben 2 Fragen, die ich mir auch mit Suche im Forum nicht beantworten kann.

1. Beim Anlernen werden 6 Kanäle angelegt, von denen der 4.(ClimRT) der Steuerung dient.
Soweit so gut.
Kann mir jemand erklären, wofür die anderen Kanäle dienen? Ich finde keine gute Beschreibung.
a: Climate
b: ClimaTeam (ich denke Verbindung mehrerer Thermostate)
c: remote
d: Weather
e: WindowRec (Fensterkontakte???)

2. kann ich mit einem Set-Befehl die internen Funktionen wie %-Zahl der Boost-Funktion, Entkalkungstag und -zeit, Odffset u.a. verändern.
Wenn ja, wie muss der Befehl lauten?

Ich habe schon eine recht umfangreiche Installation, aber der Thermostat ist doch erheblich komplexer.

Wäre schön, wenn mir das jemand erklären könnte.

PS: optimal wäre eine ausführliche Beschreibung und Erklärung im Wiki.
Die bisherige Beschreibung des RT-DN ist ja noch sehr gering.

Danke erstmal.
Thomas

martinp876 · 28 Oktober 2013, 18:54:22

Hallo Thomas,

für HM hilfreich ist (hoffe ich) das einsteigerdoc.

HM hat di 6 Kanäle gebaut, in FHEM werden sie dargestellt. Die meisten dienen dazu, anderen Geräte direkt zu peeren, so dass die ohne Zentrale daten austauschen können (die Zentrale hört natürlich mit)
Weather kann mit einem externen Thermostat gepeert werden
Climate - keine Ahnung, noch keine Funktion gefunden. War bei TCs der "aktive" Kanal
WindowRec - kann mit fensterkontakten gepeert werden
climaTeam - hier kann man mehrere RTs in einem Raum zu einer Gruppe peeren. Manuelle Einstellungen werden dann "durchgereicht"
remote - man kann eine "normale" fernbedienung peeren und den Heizkörper "remote" einschalten

schau dir einmal
get <RT> regList
get <RT_Clima> regList
get <RT_remote> regList
....

an.
da lässt sich das alles einstellen mit
set <RT_Clima> regSet <register> <value> <peer>
bei Clima ist kein peer notwendig, wohl z.B.bei remote

HM ist dafür ausgelegt sehr viel im Aktor zu machen - die Zentrale stellt ein, überwacht, loggt und realisiert "sonderfunktionen".

Gruss Martin

Thomask · 28 Oktober 2013, 19:40:45

Hallo Martin,

vielen Dank für die derart schnelle Antwort.

Die Einsteigerdoc habe ich viel zur Hand genommen, als ich vor ca. 1 1/2 Jahren mit FHEM angefangen habe.
Die ist eine tolle Hilfe.

Das mit den Set's habe ich aufgrund Deiner Info nun hinbekommen.

Danke nochmal.
Thomas

Rohan · 28 Oktober 2013, 20:30:41

Hi,

Zitat von: martinp876 am 28 Oktober 2013, 18:54:22... Climate - keine Ahnung, noch keine Funktion gefunden. War bei TCs der "aktive" Kanal ...

warten wir mal ab, bis der angekündigte Raumregler für den HM-CC-RT-DN kommt. Ich glaube, dass der Climate-Channel dann seine Reinkarnation erfährt

Gruß
Thomas

martinp876 · 29 Oktober 2013, 07:01:00

bin ich mir nicht sicher -
der RT würde dann von einem Regler zu einem Ventil degradiert -
oder der Raumregler sendet einfach nur die "externen temperaturwerte"

Aber vielleicht muss man den RT-CLIMATE dann mit dem TC-IT peeren - mal sehen

Das XML ist schon vorhanden - und rudimentär in fhem unter HM-TC-IT-WM-W-EU zu finden

Gruss Martin

betateilchen · 29 Oktober 2013, 17:57:52

wie werde ich eigentlich das Attribut webCmd beim RT-Device los? Das getConfig und das burstXmit versauen mir die ganze Optik wegen der auftretenden Überbreite im Frontend.

Ich kann das Attribut zwar löschen und die Änderung auch abspeichern, aber nach jedem fhem-Neustart wird es wieder neu angelegt.

martinp876 · 30 Oktober 2013, 11:15:27

auf vielfachen Wunsch eines Einzelnen gibt es ab Version 4135 einen "manual mode". FHEM wird wenig/keine automatischen Aktionen ergreifen. dazu muss man
eine HMInfo entity anlegen
attribut hmManualOper auf 1_manual setzen

in fhem.cfg sollte man hmInfo möglichst früh definieren und das Attribut setzen damit es nach restart wirksam ist bevor etwas anderes definiert wird.

Sollte danach noch irgend etwas automatisch passieren bitte mit -genauer- Beschreibung melden. Wird - wenn irgend möglich - alles unterdrückt.

betateilchen · 30 Oktober 2013, 11:21:44

Danke

Ist eigentlich schon jemand aufgefallen, wie der RT sich verhält, wenn das Fenster geöffnet wird (wird erkannt, im Display angezeigt, sowie die Temperatur korrekt auf windowOpen geregelt) und dann, zu einem Zeitpunkt zu dem das Fenster immer noch offen ist, ein "set desired-temp xx" kommt?

Er ignoriert das offene Fenster und fängt an zu heizen. Und das sowohl im Modus "auto" als auch im Modus "manu"

Für mich sieht das irgendwie nach einem Firmwarefehler aus.

CQuadrat · 30 Oktober 2013, 11:42:52

Zitat von: betateilchen am 30 Oktober 2013, 11:21:44
Danke

Ist eigentlich schon jemand aufgefallen, wie der RT sich verhält, wenn das Fenster geöffnet wird (wird erkannt, im Display angezeigt, sowie die Temperatur korrekt auf windowOpen geregelt) und dann, zu einem Zeitpunkt zu dem das Fenster immer noch offen ist, ein "set desired-temp xx" kommt?

Er ignoriert das offene Fenster und fängt an zu heizen. Und das sowohl im Modus "auto" als auch im Modus "manu"

Für mich sieht das irgendwie nach einem Firmwarefehler aus.

Ich konnte auch noch kein einziges Mal beobachten, dass ein geöffnetes Fenster anhand des "Temperatursturzes" erkannt wurde. Naja, vielleicht ist es einfach noch zu warm draußen

martinp876 · 30 Oktober 2013, 11:45:58

set desired-temp ist doch ein fhem-kommando. Willst du sagen, dass FHEM eine desired-temp schickt?
hast du einen SC gepeert oder nutzt den internen fensterkontakt?
hast du die Zeiten definiert? Nach 15 min schaltet der Interne Fenser-offen erkenner zurück - wie es in den Registern festgelegt ist.
hast du diese Funktionen abgeschaltet?
kurzum - bitte infos - was sagen die Einstellungen Register/peers des WindowRec - und hast du sie auch frisch gelesen?

betateilchen · 30 Oktober 2013, 13:11:10

Es geht nicht um den Temperatursturz beim Öffnen des Fensters, ohne Verwendung eines Fensterkontaktes.

Ausgangslage: Ein RT ist korrekt mit dem RHS an der Balkontür des Wohnzimmers gepeered.

17:00 RT steht auf Solltemperatur 16°
17:10 Tür wird geöffnet, RT erkennt das, zeigt "Fenster offen" auch im Display an und regelt die Temperatur auf 12° runter
17:25 Tür wird geschlossen, RT erkennt das und regelt die Temperatur wieder auf 16°

Soweit so gut

Jetzt zur beschriebenen "Problemsituation":

17:50 RT steht auf Solltemperatur 16°
17:51 Tür wird geöffnet. RT erkennt das, zeigt "Fenster offen" auch im Display an und regelt die Temperatur auf 12° runter
18:00 fhem schickt ein "set desired-temp 20.5" an den RT (z.B. aufgrund eines Zeitplans oder eines Google Kalenders)
18:01 RT fängt an zu heizen, um die 20.5° zu erreichen, obwohl die Tür immer noch geöffnet ist!

Nach meinem Verständnis sollte der RT die 20.5° zwar als neue Solltemperatur entgegennehmen, aber erst dann aktivieren, wenn die Tür wieder geschlossen wird.

CQuadrat · 30 Oktober 2013, 13:36:32

Zitat von: betateilchen am 30 Oktober 2013, 13:11:10
Jetzt zur beschriebenen "Problemsituation":

17:50 RT steht auf Solltemperatur 16°
17:51 Tür wird geöffnet. RT erkennt das, zeigt "Fenster offen" auch im Display an und regelt die Temperatur auf 12° runter
18:00 fhem schickt ein "set desired-temp 20.5" an den RT (z.B. aufgrund eines Zeitplans oder eines Google Kalenders)
18:01 RT fängt an zu heizen, um die 20.5° zu erreichen, obwohl die Tür immer noch geöffnet ist!

Das gleiche passiert, wenn ich die RTs in den Partymode schicke. Z.B. mit:
set Hzkp.*ClimRT_tr controlParty T DD.MM.YY MM:HH DD.MM.YY MM:HH

Dann gehen auch die RTs in den Partymodus, bei denen das Fenster offen steht (Bug oder Feature?).
Schick wäre es meiner Meinung nach, wenn hier "Fenster offen" solange aktiv wäre, wie auch das Fenster noch geöffnet ist.

martinp876 · 30 Oktober 2013, 16:55:52

so wie ich bisher alle TCs und RTs kenne passt das ins Bild. Es wird immer die Temperatur eingestellt, die vom letzten Trigger kommt. Ich kenne keine Ausnahme.
demnach war zu erwarten, dass man die Temperatur auch bei offenem Fenster ändern kann - das ist ein neuer Trigger, er ist gültig also wird er eingestellt.
Auch die Erfahrungen vom TC bei "cent" und "manu" und dem Ändern durch eine andere Quelle - werden beim nächsten prüfen (also wenn hier ein trigger kommt) überschrieben.
Kann man als bug oder als feature sehen - ist aber hier egal. Wichtig zu wissen: so funktionieren die RTs!
Änderungen müssen bei eQ3 eingespeist werden. Hier hat es keinen Sinn.

Als Vorteil kann man sehen, dass man in der Lage ist bei "internem Fenster-detektor" auch schon vorher die Temperatur wieder hoch zu drehen. Aber auch hier gilt - egal ob Vorteil oder Nachteil- es ist Fakt

Es gibt zwar keine wirkliche Priorität, aber sicher habt ihr die Register durchgesehen und
modePrioManu |literal | allow tempChange for manual by... options:CCU,RT_SC,self,all,RT_CCU
modePrioParty |literal | allow tempChange for party by... options:CCU,RT_SC,self,all,RT_CCU

werde ich ändern (etwas ausführlicher)
modePrioManu |literal | allow tempChange for manual only by... options:CCU,RT_TC_SC_SELF,all,RT_TC_CCU_SELF,self
modePrioParty |literal | allow tempChange for party only by... options:CCU,RT_TC_SC_SELF,all,RT_TC_CCU_SELF,self

Damit werden ccu, rt, tc, sc und self als mögliche Quellen angegeben, welche dann in den Modi manu oder party nicht zu Änderungen führen dürfen. Probiert habe ich es nicht, löst auch nicht dieses Problem ... aber es sollte ein selektives inhibit machen - viel Spass.

Übrigens funktionieren auch alle anderen Aktoren nach diesem Prinzip - immer der letzte Trigger ist der gültige und überschreibt den aktuellen Vorgang.

betateilchen · 30 Oktober 2013, 17:28:41

Mein TC hat das definitiv sehr lange nicht so gemacht. Bis vor ein paar Wochen, als auch da dieses (Fehl-)Verhalten plötzlich auftrat. Ich hatte dazu sogar extra einen Thread hier im Forum eröffnet.

DerMexikaner · 30 Oktober 2013, 21:35:34

Zitat
Ist eigentlich schon jemand aufgefallen, wie der RT sich verhält, wenn das Fenster geöffnet wird (wird erkannt, im Display angezeigt, sowie die Temperatur korrekt auf windowOpen geregelt) und dann, zu einem Zeitpunkt zu dem das Fenster immer noch offen ist, ein "set desired-temp xx" kommt?

Er ignoriert das offene Fenster und fängt an zu heizen. Und das sowohl im Modus "auto" als auch im Modus "manu"

Hallo Betateilchen,
das von Dir beschriebene Verhalten hat mich auch gestört. Ich benutze Heating_Control und Dietmar hat als Abhilfe ein Attribut windowsensor spendiert. Seitdem werden offene Fenster bei mir nicht mehr ignoriert.