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
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
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
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
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
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.
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.
Danke 8)
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.
Zitat von: betateilchen am 30 Oktober 2013, 11:21:44
Danke 8)
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 8)
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?
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.
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.
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.
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.
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.
Hallo Martin,
ist das hier eigentlich schon funktional?
Zitat von: martinp876 am 30 Oktober 2013, 16:55:52
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.
Viele Grüße
Christoph
Hallo Christoph,
das Register ist "im Device" -also funktional seitdem es HM programmierte
das Register ist in FHEM zu schreiben - kurz nachdem wir den RT "erstellt" hatten
Die "Namensänderung" der Registerwerte ist aktiv - kannst du doch selbst kontrollieren mit
get <RT_Clima> regList
Ausser der Names-"verdeutlichung" war nichts geplant - und die ist drin
Gruss Martin
Zitat von: martinp876 am 05 November 2013, 14:40:21
Hallo Christoph,
das Register ist "im Device" -also funktional seitdem es HM programmierte
das Register ist in FHEM zu schreiben - kurz nachdem wir den RT "erstellt" hatten
Die "Namensänderung" der Registerwerte ist aktiv - kannst du doch selbst kontrollieren mit
get <RT_Clima> regList
Ausser der Names-"verdeutlichung" war nichts geplant - und die ist drin
Gruss Martin
Hallo Martin,
das war/ist mir schon klar.
Ich habe Deine Ausführungen weiter oben so verstanden, dass mit diesen beiden Registern (modePrioManu/modePrioParty) gesteuert werden kann, dass weitere Modiänderungen nicht ausgeführt werden.
Wenn ich z.B. wegen Urlaub zwei Wochen nicht zuhause bin, kann ich über den Parytmodus alle RTs für diesen Zeitraum runterregeln. Innerhalb dieser Zeit des Partymodus (hier wohl besser: Urlaubsfunktion) soll es möglich sein, alle durch FHEM gesendeten Befehle (z.B. durch notifys) zu ignorieren. Habe ich das so korrekt verstanden?
Ich hatte nun mit den diversen zur Verfügung stehenden Parametern dieser Register herumgespielt, konnte aber keinerlei Effekte erkennen.
Viele Grüße
Christoph
Hallo Christoph,
erst einmal sollte klar sein, dass ich dies interpretiere - ausgetestet habe ich es nicht. Meist kann man sich aber auf die "wortwahl" von HM verlassen - und die haben es geschrieben und implementiert.
ups - noch ein Fehler - die Literals sind vertauscht. Nimm Version 4159 von HMConfig.pm
Habe es probiert - prinipiell funktioniert es.
Ich verstehe das folgende Quellen unterscheiden werden (unbestätigt)
CCU: Zentrale
self: handrad
RT: templiste ??? oder "team-RT" ???
TC: externen controller (wohl noch keiner zu kaufen)
SC: fenster-kontakt
Gruss Martin
So, ich habe da gestern mal etwas an den Einstellungen herumgespielt.
Setze ich modePrioManu auf self, kann ich am Thermostat, wenn er im Manu-Mode ist, über das Stellrad KEINE Veränderungen mehr vornehmen.
Ich hatte noch modePrioParty auf self gesetzt: Hier kann ich jedoch keinen Effekt erkennen. Analog hätte ich dann hier erwartet, dass ich am Thermostat keine Änderungen bzw. Einstellungen am Partymode einstellen kann.
Die anderen Modi werde ich auch noch ausprobieren.
Hallo Christoph,
es sieht so aus, als ob der update bei dir noch nicht drin ist.
Habe es noch einmal getestet - wenn der mode "manu" ist und modePrioManu auf "self" kann ich am Handrad ändern, aber nicht von der Zentrale.
Wichtig ist das file HMConfig.pm
ggf aus SVN nachladen
Gruss Martin