hm-cc-rt-dn und controlMode

Begonnen von Frood42, 15 Oktober 2021, 10:57:15

Vorheriges Thema - Nächstes Thema

Frood42

Eine Frage habe ich da zu dem hm-cc-rt-dn
in einem anderen Thread meinte einer, dass er den controlMode auf manual (und nicht auto) stellt, weil er es in seiner Steuerung "übergehen" will.
Da sich meine hm-cc-rt-dn irgendwie verselbstständigen, habe ich nun vermutet, dass dies am mode "auto" liegt. In der Anleitung steht, dass dies der Modus ist, in dem das eingestellte Wochen-Programm "abläuft". Nun, da habe ich aber nie etas eingestellt bzw einprogrammiert.

Daher die Frage: Für den Betrieb nur mit fhem: Stellt man das Ding auf "Manu" oder auf "Auto" ?

MadMax-FHEM

#1
Zitat von: Frood42 am 15 Oktober 2021, 10:57:15
Eine Frage habe ich da zu dem hm-cc-rt-dn
in einem anderen Thread meinte einer, dass er den controlMode auf manual (und nicht auto) stellt, weil er es in seiner Steuerung "übergehen" will.

Kann man machen aber: wozu? Dann kann man gleich "dumme" Stellmotoren nehmen...
Siehe auch weiter unten ;)

Zitat von: Frood42 am 15 Oktober 2021, 10:57:15
Nun, da habe ich aber nie etas eingestellt bzw einprogrammiert.

Da ist schon was vorbelegt ;)
Du kannst dir das doch auch anschauen im fhem-Device (also wenn per CUL_HM eingebunden / bei HMCCU: keine Ahnung)


Zitat von: Frood42 am 15 Oktober 2021, 10:57:15
Daher die Frage: Für den Betrieb nur mit fhem: Stellt man das Ding auf "Manu" oder auf "Auto" ?

Muss jeder selber entscheiden.
Ich fahre (meist) mit Automatik, denn dann läuft die Heizung autark auch OHNE fhem, zumindest nach dem aktuell eingestellten Programm.

Mit fhem schalte ich auf manual und niedrige Temp, wenn ich die Wohnung (länger) verlasse(n habe)...
...und zurück auf automatik, wenn ich zurückkomme (oder per "Fernsteuerung" schon [kurz] vorher).

Mit fhem "wechsle" ich dann die Programme je nach "Bedarf", ab da läuft es dann aber wieder autark.

Ich protokolliere mit fhem was so geht: Ventilstellung, Soll-, Ist-Temp etc.

EDIT: ich stelle auch schon mal per fhem höher oder tiefer. Dank der Automatik wird das aber dann beim nächsten Programm-Schaltpunkt wieder "korrigiert", so kann es nicht passieren, dass die Heizung z.B. nachts heiß durchläuft (ja klar, wenn das Programm zu früh wieder runter dreht, dann muss ich halt wieder "nachlegen": aber irgendwas ist ja immer ;)  )...

Man kann nat. auch den HKT nur die eingestellte Temp "halten" lassen und die Werte durch fhem vorgeben, gibt's ja auch Modul(e) dafür.
Aber dann bleibt die Heizung halt bei dem Wert, der gerade vorgegeben ist/war, wenn fhem mal nicht "will"...

EDIT: hast du auch Wandthermostate im Einsatz? (kann ich nur empfehlen, damit ist die Regelung/Steuerung/wie auch immer deutlich "angenehmer") Gepeert?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Frood42

Vielen Dank, das eröffnet ja mal wieder Abgründe, die sich da auftun.
Dass da etwas voreingestellt ist, habe ich jetzt nach einigen Tagen Betrieb auch festgestellt.
und mir scheint eben: Wenn man das Ding auf "Auto" stellt und mit ehem betreiben will, dann geht das immer durcheinander... also irgendwie immer abwechselnd die fhem Einstellungen und dann die vorprogrammierten.

Zitat
Da ist schon was vorbelegt ;)
Du kannst dir das doch auch anschauen im fhem-Device (also wenn per CUL_HM eingebunden / bei HMCCU: keine Ahnung)

Das habe ich auch erst jetzt gesehen. (Lesen ist echt schwer)
das sind die R_0_tempListSat und so, da sehe ich auch öfters die dubiosen 17 Grad, die sich eingestellt haben und ich mich so gewundert habe.

ZitatDank der Automatik wird das aber dann beim nächsten Programm-Schaltpunkt wieder "korrigiert"
Das scheint ganz klar die Erklärung für meine Fragen zu sein!!

Es gibt auch Foren Einträge, dass sich die Dinger bei Defekt immer auf 17 Grad stellen und man einen Firmware update machen muss.

Ich möchte die Dinger eigentlich immer ausschliesslich mit FHEM betreiben. Und ja, ich habe unzählige Wandthermostate, die ich aber ungern direkt Peeren möchte.
ich blde mir ein, dass ich die Logik zur Steuerung der Temperatur manuell besser programmieren kann unter Beachtung der Thermostaten in den verschiedenen Räumen.

Frood42

#3
Also man muss doch irgendwo sagen, dass man für eine Steuerung mit FHEM die Geräte auf "Manu" stellen muss - sonst geht das ja im Grunde gar nicht. Oder?

EDIT: Es könnte ja auch sein, dass man auf "Manu" die Regler nur manuell einstellen kann und gar nicht über FHEM... ?!
EDIT: Was nun tatsächlich bei einem Gerät auch so ist. Wenn man da in FHEM die "desired-temp" einstellt, dann springt das in FHEM wieder auf die, die am Gerät manuell eingestellt hatte zurück!! Also, die Änderung in FHEM wurde nach der manuellen am Gerät gemacht!

MadMax-FHEM

Zitat von: Frood42 am 15 Oktober 2021, 11:30:28
Also man muss doch irgendwo sagen, dass man für eine Steuerung mit FHEM die Geräte auf "Manu" stellen muss - sonst geht das ja im Grunde gar nicht. Oder?

Muss man ja nicht!
1. muss man das nicht auf manu stellen, um mit fhem zu steuern (siehe meine letzte Antwort ;)  ) und 2. warum muss/sollte alles haarklein wo stehen müssen, was man leicht ausprobieren kann?

ABER: egal wie der HKT verstellt wird (manuell über das Rädchen oder per set durch fhem oder CCU oder oder oder) er stellt halt beim nächsten Programmschaltpunkt (Tag/Uhrzeit) auf das was halt das Programm "vorgibt".

Also manu nur, wenn man "ausschließlich" "extern" steuern bzw. SOLL vorgeben will...

Zitat von: Frood42 am 15 Oktober 2021, 11:30:28
Edit: Es könnte ja auch sein, dass man auf "Manu" die Regler nur manuell einstellen kann und gar nicht über FHEM... ?!

Ausprobieren tut doch nicht weh ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

#5
Zitat von: Frood42 am 15 Oktober 2021, 11:25:32
Es gibt auch Foren Einträge, dass sich die Dinger bei Defekt immer auf 17 Grad stellen und man einen Firmware update machen muss.

Es gibt eine Fehler-Ventilstellung keine Fehler-Temperatur (meines Wissens).

Welche FW hast du denn?

Was ich so mitbekommen habe: zwischen Fw1.4 und FW1.5 (aktuell) hat sich wohl am Regelverhalten was geändert (hat aber nichts mit Wochenprogramm oder Vorgabe von fhem zu tun / "lediglich" das "Halten" der vorgegebenen [egal von wo] Temperatur)

Zitat von: Frood42 am 15 Oktober 2021, 11:25:32
Ich möchte die Dinger eigentlich immer ausschliesslich mit FHEM betreiben. Und ja, ich habe unzählige Wandthermostate, die ich aber ungern direkt Peeren möchte.
ich blde mir ein, dass ich die Logik zur Steuerung der Temperatur manuell besser programmieren kann unter Beachtung der Thermostaten in den verschiedenen Räumen.

Also ich kann nur sagen:

1. die Temp AM HKT ist doch nie nicht die Raumtemperatur (meist ist es dort wärmer)

2. durch Verbindung mit einem WDT ist (zumindest wo ich es nachvollziehen konnte) die "Regelung" (Ventilstellungen etz.) deutlich "angenehmer".

3. wird durch Verwendung von WDTs eben die Raumtemperatur gemessen und danach geregelt...

Naja, wenn du denkst eine Vorgabe von Soll besser hinzubekommen: viel Spaß!

Bzw. klar, wenn man keinen geregelten Tagesablauf (oder ein paar Verschiedene) hat, dann muss man halt irgendwie "ständig" das SOLL neu vorgeben...
Bei mir ist das einfach, ich habe 3 verschiedene Wochenprogramme und gut.
(zuhause z.B. Urlaub [Wohnung morgens und tagsüber warm / Büro erst mal "kalt"] / zuhause Home Office [klar Büro morgens warm :) Wohnug später ] und normal, also mit Mo-Fr im Büro [morgens mal warm, tagsüber "aus" und abends wieder warm)
Die schalte ich mittels fhem je nach Bedarf um und gut.
Und wenn doch nicht gut: es gibt das Drehrad und ich kann per fhem-Oberfläche nachregeln 8)

Wenn fhem nicht läuft, dann heizt der HKT im manu-Betrieb halt auf dem zuletzt vorgegebenen SOLL-Wert weiter...
...bei Automatik eben nicht. Sondern schaltet halt (schlimmstenfalls) nachts runter (sofern im Programm so eingetragen).

Nur damit das klar ist: du kannst den HKT nicht vorgeben WIE er regeln soll! Du kannst nur (auch in manu) nur SOLL vorgeben. Der HKT macht das dann selber (also mittels IST-Messung SOLL halten)...

...außer: du stellt den HKT auf ON und regelst dann mittels Ventil-Max-Stellung (das wird aber jedes mal ins Flash geschrieben!)...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Frood42

Das ist ja alles wirklich sehr interessant. Ich dachte schon, die Dinger sind kaputt.

Mittlerweile habe ich 5 Stück verbaut. Und es liegen noch welche rum die darauf warten eingebaut zu werden.
Alle haben von Haus aus FW1.5

In den einzelnen Räumen habe ich separate Temperatur Fühler, da die (wie Du sagst) am Regler selbst immer ein wenig zu viel messen.

Durch dieses zu viel messen ist mir - durch probieren - auch aufgefallen, dass es immer nur eine Soll-Temperatur ist und wenn das Ding meint dass es schon die Soll - Grad hat, dann dreht es den Hahn zu. Deswegen stelle ich die Soll-Temperatur immer etwas höher ein.

Bei mir werden die Soll-Temperturen in den einzelnen Räumen in Abhängigkeit von
- Sonneneinstrahlung
- Aussentemperatur
- Anwesenheit der Person(en)
- Ist-Temperatur im Raum
und natürlich des Datums und Uhrzeit gesteuert. Das ganze mit Threshold, dass es nicht immer toggelt.

Um das flexibler zu gestalten, steuere ich ich Abhängigkeit der Urzeit auch nur die DOIF "Regler" - die dann wiederum die einzelnen Heizung-Regler steuern.
So kann man immer auf dem Handy einfach die DOIF Regler (readingList) manuell ändern wenn man möchte.
Und diese DOIF Regler machen die ganze Logik, und zwar immer dann, wenn sie ein Temperatur Event "empfangen".

Im Moment halten die HKT wenigstens immer die Desired Temp, das ist schon mal ein riesen Fortschritt!! 


MadMax-FHEM

#7
Zitat von: Frood42 am 15 Oktober 2021, 12:12:55
In den einzelnen Räumen habe ich separate Temperatur Fühler, da die (wie Du sagst) am Regler selbst immer ein wenig zu viel messen.

Durch dieses zu viel messen ist mir - durch probieren - auch aufgefallen, dass es immer nur eine Soll-Temperatur ist und wenn das Ding meint dass es schon die Soll - Grad hat, dann dreht es den Hahn zu. Deswegen stelle ich die Soll-Temperatur immer etwas höher ein.

Naja durch direkte Verbindung (habe allerdings Homematic WDTs geht aber auch mit anderen: virtueller Tempfühler) zwischen WDT und HKT ist das eben nicht so...
Auch wenn man mal die Ventilstellungen mitloggt, sieht man, dass ein HKT alleine deutlich mehr am Ventil rumdreht (also auf/zu) als wenn er mittels WDT regelt...


Zitat von: Frood42 am 15 Oktober 2021, 12:12:55
Bei mir werden die Soll-Temperturen in den einzelnen Räumen in Abhängigkeit von
- Sonneneinstrahlung
- Aussentemperatur
- Anwesenheit der Person(en)
- Ist-Temperatur im Raum
und natürlich des Datums und Uhrzeit gesteuert. Das ganze mit Threshold, dass es nicht immer toggelt.

Sonneneinstrahlung
Aussentemperatur


ist doch Quatsch? Wenn ich 21 Grad haben will im Raum, dann regelt doch der HKT/WDT genau das, auch wenn die Sonne den raum zusätzlich aufwärmt (gut dann nat. erst langsam also durch nicht mehr zusätzlich heizen, weil abkühlen geht ja leider nicht ;)  ) oder eben draußen kälter ist und somit auch mehr Heizung not tut?
EDIT: gut außer nat. oh draußen ist es kalt, ich will mich wohler fühlen also SOLL etwas nach oben :) / Ich hatte auch mal ein Winterprogramm aber das hat sich nicht "gelohnt", ist wieder "verschwunden" ;)
da bringt es doch wenig die SOLL Temp runter zu drehen?
Weil wenn es schon zu warm ist wird es ja dadurch auch nicht plötzlich kälter...
...und wie geschrieben: HKT/WDT versuchen ja genau eine Wunschvorgabe zu halten :)

Ist-Temperatur im Raum

Macht doch auch WDT/HKT automatisch bzw. ist das doch genau die Aufgabe...

Anwesenheit der Person(en)

ja macht u.U. Sinn, habe ich ja auch, wenn ich gehe, dann wird (nach einiger Zeit: damit nicht bei kurzer Abwesenheit schon dauern rumgeschraubt wird) runter gedreht (und auf manu ;)  )


Zitat von: Frood42 am 15 Oktober 2021, 12:12:55
Um das flexibler zu gestalten, steuere ich ich Abhängigkeit der Urzeit auch nur die DOIF "Regler" - die dann wiederum die einzelnen Heizung-Regler steuern.
So kann man immer auf dem Handy einfach die DOIF Regler (readingList) manuell ändern wenn man möchte.
Und diese DOIF Regler machen die ganze Logik, und zwar immer dann, wenn sie ein Temperatur Event "empfangen".

Naja wenn du das schon hast ohne Fehler und Logik-Lücke ;)
Ich brauch das nicht so flexibel.

Sind wohl meine Tagesabläufe zu "konstant" :)
Und wie geschrieben: einfach nachsteuern, also höheres/niedrigeres SOLL kann ich auch einfach per klick in fhem machen...
Reguläre Abläufe aka Wochenprogramm bleibt (bei mir) eher (sehr) stabil...
...bzw. habe ich ja 3 davon :)

Damit komme ich gut durch...


Zitat von: Frood42 am 15 Oktober 2021, 12:12:55
Im Moment halten die HKT wenigstens immer die Desired Temp, das ist schon mal ein riesen Fortschritt!!

Naja das sollten sie schon immer (gut) tun.
Machen sie zumindest bei mir...

Evtl. war ja "durcheinander" bei der Vorgabe von SOLL...
("Streit" zwischen fhem und Automatik-Programm)

Anmerkung: nach einem Batteriewechsel neigen die HKTs dazu in Automatik zu gehen ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Thorsten Pferdekaemper

Zitat von: MadMax-FHEM am 15 Oktober 2021, 11:08:42
Kann man machen aber: wozu? Dann kann man gleich "dumme" Stellmotoren nehmen...
Das hätte ich gerne mal gemacht, da mir manchmal das Regelverhalten der HM-Teile nicht wirklich gefällt. Allerdings habe ich keine "dummen" (kabellose) Stellmotoren gefunden, die man (einfach) an FHEM anbinden kann. Hast Du da einen Tipp?
Gruß,
   Thorsten
FUIP

MadMax-FHEM

Zitat von: Thorsten Pferdekaemper am 15 Oktober 2021, 14:01:02
Das hätte ich gerne mal gemacht, da mir manchmal das Regelverhalten der HM-Teile nicht wirklich gefällt. Allerdings habe ich keine "dummen" (kabellose) Stellmotoren gefunden, die man (einfach) an FHEM anbinden kann. Hast Du da einen Tipp?
Gruß,
   Thorsten

Ja, klar, wenn man mit dem Regelverhalten unzufrieden ist...
...und Lust/KnowHow hat selber eine (bessere) Regelung zu implementieren...

Ich kenne nur die "alten" FHT, ich glaube das waren "nur" Stellmotoren mit (optionaler) abgesetzter Steuerung.
Soweit ich das gelesen habe (also: "hörensagen" ;)  ) waren die auch mit fhem steuerbar (statt offizieller "Zentrale")...

Bei den ZWave Spirit bin ich mir nicht sicher, ich glaube aber da ist auch eher Vorgabe von SOLL und Regelung dann "autark"...

Also kurz: nein kenne (leider) keine...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: MadMax-FHEM am 15 Oktober 2021, 14:09:45
Bei den ZWave Spirit bin ich mir nicht sicher, ich glaube aber da ist auch eher Vorgabe von SOLL und Regelung dann "autark"...
Die kennen einen "valve" Modus und es gibt auch einige User, die die Dinger zusammen mit PID20 nutzen und dann den Öffnungsgrad steuern.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Thorsten Pferdekaemper

Zitat von: MadMax-FHEM am 15 Oktober 2021, 14:09:45
Ja, klar, wenn man mit dem Regelverhalten unzufrieden ist...
Eigentlich (blödes Wort, ich weiß) bin ich mit dem Regelverhalten ganz zufrieden, mit im Wesentlichen einer Ausnahme: Wenn meine Heizung heißes Wasser gemacht hat oder aus anderen Gründen der Vorlauf ziemlich oben ist (z.B. ich will in einem Zimmer schnell aufheizen), dann heizen die Dinger unter Umständen (viel) zu viel, weil der Ventilöffnungsgrad sozusagen von meiner normalerweise recht niedrigen Vorlauftemperatur ausgeht. In so einem Fall hätte ich gerne versucht, die Ventile (fast) zuzumachen, wenn die Vorlauftemperatur hoch ist. Ich habe Temperaturfühler am Vorlauf im Keller, also könnte ich da reagieren, bevor sozusagen die Hitze da ist. Die HM-CC-RT-DN reagieren erst, wenn der Heizkörper schon knallheiß ist.
Wenn man dann sowieso schon dabei ist, dann könnte man auch die Wettervorhersage mit reinnehmen, so dass der Wintergarten nicht erst morgens mit viel Heizung aufgewärmt wird, wenn eine halbe Stunde später sowieso die Sonne draufknallt.
Solche Sachen kann halt der HM-CC-RT-DN nicht wissen.

Zitat
...und Lust/KnowHow hat selber eine (bessere) Regelung zu implementieren...
Lust/KnowHow habe ich glaube ich schon. Es fehlt da eher an der Zeit. Es ist übrigens auch gar nicht sooo schwierig. Die Grundlage liefert schonmal das PID20 Modul. Das ist schnell eingerichtet. Man muss es halt nur nach und nach "tunen".

Zitat
Also kurz: nein kenne (leider) keine...
So geht's mir auch und auch deshalb habe ich mir jetzt sogar noch neue HM-CC-RT-DN gekauft.

Gruß,
   Thorsten
FUIP

Thorsten Pferdekaemper

Zitat von: Beta-User am 15 Oktober 2021, 14:16:39
Die kennen einen "valve" Modus und es gibt auch einige User, die die Dinger zusammen mit PID20 nutzen und dann den Öffnungsgrad steuern.
Danke für den Tipp. Bald ist ja wieder Weihnachten und ich arbeite eh zu viel. Mal sehen...
Am coolsten wäre ja irgendein Deep Learning Teil. So nach dem Motto: Alle Readings, die FHEM hergibt, reinstopfen und mal machen lassen. Es könnte nur sein, dass die Lernphase ein paar Jahre dauert.
Gruß,
   Thorsten
FUIP

MadMax-FHEM

#13
Zitat von: Thorsten Pferdekaemper am 15 Oktober 2021, 14:21:21
Eigentlich (blödes Wort, ich weiß) bin ich mit dem Regelverhalten ganz zufrieden, mit im Wesentlichen einer Ausnahme: Wenn meine Heizung heißes Wasser gemacht hat oder aus anderen Gründen der Vorlauf ziemlich oben ist (z.B. ich will in einem Zimmer schnell aufheizen), dann heizen die Dinger unter Umständen (viel) zu viel, weil der Ventilöffnungsgrad sozusagen von meiner normalerweise recht niedrigen Vorlauftemperatur ausgeht. In so einem Fall hätte ich gerne versucht, die Ventile (fast) zuzumachen, wenn die Vorlauftemperatur hoch ist. Ich habe Temperaturfühler am Vorlauf im Keller, also könnte ich da reagieren, bevor sozusagen die Hitze da ist. Die HM-CC-RT-DN reagieren erst, wenn der Heizkörper schon knallheiß ist.

Naja, wenn es nur "manchmal" ist, dass man eingreifen will/muss: MaxValvePos eben verkleinern -> dann kann der HKT ja gar nicht "voll aufmachen" ;)

Darf man halt nicht vergessen, dass man das dann danach wieder zurückstellt...
...und: es wird halt eben ins Flash geschrieben (aber bei "manchmal" sollte das ja kein Thema sein / bzw. steuern manche im Forum wohl "genau so"...)...

EDIT: aber dann ist das ja mal die bessere Variante...
Zitat von: Beta-User am 15 Oktober 2021, 14:16:39
Die kennen einen "valve" Modus und es gibt auch einige User, die die Dinger zusammen mit PID20 nutzen und dann den Öffnungsgrad steuern.

[OT]
Ich wohne in einer Wohnung (zwar Eigentum aber trotzdem) und habe nicht auf alles/so viel Einfluss...
...ich finde die Regler schon mal deutlich besser als die "mechanischen" (mit Bimetall o.ä.), hatte vor vielen Jahren mal mit "Billigdingern" (15EUR inkl. Batterie bei Conrad :)  ) angefangen.

Fand die auch schon besser als die mechanischen, allerdings hat mich gestört, dass Programmänderungen immer per "Knopfkino" eingegeben werden mussten... :-\
Und einmal ging die Batterie leer und das Ding lief so (verm.) 2 Tage+ komplett durch und war danach auch kaputt (zu große Hitze)...

Daher dann der Umstieg zu: per PC programmierbar und auslesbar :)
[/OT]

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Na ja, wenn man die RT-DN schon hat und weiß, dass man erst mal wegen "zu heißen Wassers" gegensteuern muss, kann man ja auch einfach eine zu niedrige Soll-Temp vorgeben und die dann nach und nach erhöhen...
Die haben übrigens nach meinem Verständnis auch irgendein Register, über das die Geschwindigkeit der Adaption vorgegeben wird, und grade bei fw 1.5 gab's auch eine Diskussion dazu, dass die manchen zu langsam war bzw. die Lernkurve zu lange gedauert hat, bis sich das eingependet hatte. Ein Teil der Mitdiskutanten hat dann beschlossen, lieber auf 1.4 zurückzuzugehen (firmware sollte in dem betreffenden Thread zu finden sein und uU. auch die Registerbezeichnung).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors