hm-cc-rt-dn und controlMode

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

Vorheriges Thema - Nächstes Thema

Thorsten Pferdekaemper

Zitat von: Beta-User am 15 Oktober 2021, 14:37:14
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...
Das Problem stellt sich auch anders herum. D.h. im Endeffekt würde man die Solltemperatur über die Isttemperatur und die Vorlauftemperatur regeln. Der Regelkreis des RT selbst dauert aber auch wieder eine Weile. Das könnte unschön werden. Der Vorteil zur valveMaxPos-Technik ist aber, dass man das EEPROM nicht so quält. Andererseits scheinen bisherige Verfechter dieser Technik noch keine echten Probleme mit kaputten EEPROMS gehabt zu haben. Zumindest habe ich davon bisher nichts gelesen.
Interessant wäre dabei auch, dass man Thermostat (also das Ding an der Wand) und den RT wieder entkoppeln könnte, wodurch man dann beide Isttemperaturen nutzen kann.
Mal sehen, vielleicht experimentiere ich mal damit herum (...oder es gibt dann zu viele Beschwerden hier im Haus).

Mal kurz zurück on topic
Vielleicht mal wieder kurz zum Topic: Beim RT gibt es eigentlich zwei Wege, wie man als Anfänger zum einigermaßen zufriedenen Benutzer wird:
1. Geduld. Stell die Solltemperatur ein und lass das Ding mal zwei, drei Wochen machen. Als Kontrolle kann man mitten im Raum (!) die Temperatur messen und die Isttemperatur ignorieren, die das Teil anzeigt. Das passt dann im Mittel schon so grob.
2. Einen HM-TC-IT-WM-W-EU kaufen und nach FHEM-Anleitung peeren. (Also die Version hier: https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Steuerung_aller_Komponenten_durch_FHEM) Dann regelt der ganze Aufbau auf +/- 0,1K genau, bezogen auf die Stelle, an der der Wandthermostat hängt, steht oder liegt.

Gruß,
   Thorsten
FUIP

Beta-User

Ja klar, wenn man einen "echten" WT hat, müßte man über den gehen, was das ganze dann (zu?) träge macht. Ich habe zwischenzeitlich einfach einige BT-Thermometer rumfliegen und "virtualisiere" die, damit die RT's einen "abgesetzten Istwert" bekommen, da wo mehrere RT's vorhanden sind, sind die geteamt, so dass man "notfalls" auch manuell übersteuern kann.

Ich nutze während der Heizperiode übrigens die interne Automatik, und "füttere" die RT's aber nicht wie im Wiki (beim RT-DN) beschrieben über die CUL_HM-Technik, sondern über weekprofile (das auch mit HMCCUDEV "können" sollte, falls das hier eine Rolle spielt (die Info vom TE ist eher spärlich, aber er scheint CUL_HM zu haben...)). Auch ohne externe Thermometer war das Regelverhalten der RT's "solo" m.E. soweit ok, die kompensieren den "falschen" Messwert, wenn sie intern messen.

Das weekprofile im "Topic-Modus" ist übrigens klasse, bedarf aber auch "etwas Einarbeitung"... (und "versteht" sich dann auch mit WeekdayTimer, falls man das für Vorgabewerte für PID20 nutzen will).
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: Beta-User am 15 Oktober 2021, 17:06:45
Ja klar, wenn man einen "echten" WT hat, müßte man über den gehen, was das ganze dann (zu?) träge macht.
Daran läge es dann nicht. Soweit ich das mitbekomme sendet das Teil einen neuen Sollwert ziemlich sofort an den RT.
Gruß,
   Thorsten
FUIP