Aktualisierungszeit beim Homematic hm-cc-rt-dn ändern

Begonnen von Ruggy, 13 Januar 2020, 12:43:25

Vorheriges Thema - Nächstes Thema

Ruggy

Hallo,
habe drei homematic hm-cc-rt-dn im Wohnzimmer welche uber ein externes Thermometer die Temperaturwerte bekommen.

Leider machen diese mehrmals am tag komplett auf (wenn zu kalt) und heizen für ca. 1 Stunde (bis eingestellte Temperatur erreicht) und schließen dann wieder komplett.

Wie kann man diese Schwankungen vermeiden.
Kann man einen Zeit einstellen, nachdem das homematic hm-cc-rt-dn erneut die Temperatur abfragt?
Kann mir vorstellen, dass der Abstand von Abfrage zu Abfrage zu groß ist und deshalb diese Sprünge entstehen.

Oder liegt es an etwas anderes?

Vielen Dank
Viele Grüße

Beta-User

Zitat von: Ruggy am 13 Januar 2020, 12:43:25
Wie kann man diese Schwankungen vermeiden.
Soweit mir bekannt, gibt es keine bessere Methode Schwankungen/Übersteuern zu vermeiden wie die Verwendung eines (virtuellen) Wandthermostats.

Die erste Frage wäre aber, ob die Firmware auf den Dingern aktuell ist (sollte >= 1.4 sein)?
In 1.5 hat eQ-3 das Verhalten nochmal geglättet, aber diese firmware ist nicht mehr über den update-Kanal zu haben, und einigen Usern hier war das "too much".

ZitatKann man einen Zeit einstellen, nachdem das homematic hm-cc-rt-dn erneut die Temperatur abfragt?
Es wird nicht abgefragt, sondern der virtuelle Sensor sendet seinen Wert regelmäßig raus; im Wiki steht, wie man die Zeiten etwas beeinflussen kann, wenn es nicht bei den RT's ankommt (das scheint hier aber nicht das Problem zu sein).
ZitatKann mir vorstellen, dass der Abstand von Abfrage zu Abfrage zu groß ist und deshalb diese Sprünge entstehen.
Ergo: Nope, das ist vermutlich nicht die Ursache.

ABER:
- Kommen nicht alle aktualisierten Zwischenwerte auch beim RT an, springt der auf den internen Sensor (nach ca. 10 Minuten), was zu Problemen führen kann. Analyse über Vergleich des internen Sensors mit dem externen. Ist der Wert gleich, kam alles an (link ist im Wiki mit erweiterten Testmöglichkeiten);
- Wird der Sensorwert zu selten aktualisiert, und kommt dann ein Sprung, regelt der RT nach...
=> Intervall prüfen, in dem der echte Sensor mißt.

Bitte mal ins Wiki (zum RT) schauen, ich habe das jüngst überarbeitet, vielleicht wird der Mechanismus dann klarer. Feedback ist willkommen, gibt auch einen Thread im Wiki-Bereich des Forums dazu.
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

MadMax-FHEM

Kann mich nur anschließen.

Die Zeit wann der HKT "aufwacht" und dann gerne Daten hätte bzw. seine sendet steckt FEST in der FW.
Änderungen kann nur eq3 machen (oder du, solltest du den FW-Code inkl. Entwicklungsumgebung haben ;)  )...

Was du tun könntest, wenn das max. öffnen "zu schlimm" ist (und das tatsächlich keine anderen Ursachen etc. hat), du kannst die max. Öffnung einstellen (Register).

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)

Morgennebel

Zitat von: Beta-User am 13 Januar 2020, 12:54:41
In 1.5 hat eQ-3 das Verhalten nochmal geglättet, aber diese firmware ist nicht mehr über den update-Kanal zu haben, und einigen Usern hier war das "too much".

Meine neulich gekauften HM-CC-RT-DN kamen mit FW1.5 ab Werk. Mag ich sehr. Hab inzwischen alle aktualisiert und hab die Datei auch noch. Das Regelverhalten ist viel ruhiger und leiser geworden...

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Beta-User

Zitat von: Morgennebel am 13 Januar 2020, 14:18:19
Meine neulich gekauften HM-CC-RT-DN kamen mit FW1.5 ab Werk. Mag ich sehr. Hab inzwischen alle aktualisiert und hab die Datei auch noch. Das Regelverhalten ist viel ruhiger und leiser geworden...
Interessant, dass die das ausliefern... Meine sind auch alle auf 1.5 und ich konnte die Kritik nie so recht nachvollziehen, bei mir war und ist das ok, was die RT's so zusammensteuern.

Zitat von: MadMax-FHEM am 13 Januar 2020, 13:57:04
Was du tun könntest, wenn das max. öffnen "zu schlimm" ist (und das tatsächlich keine anderen Ursachen etc. hat), du kannst die max. Öffnung einstellen (Register).
Eine weitere Idee habe ich noch (experimentell): Die erlaubte Durchflussmenge für diesen Heizkörper erhöhen, damit schneller warmes Wasser in den HK fließt (also: den hydraulischen Abgleich ändern). Der RT sollte sich das nach einiger Zeit merken und nicht mehr ganz so heftig nachregeln...
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

Ruggy

Zitat von: Beta-User am 13 Januar 2020, 12:54:41Die erste Frage wäre aber, ob die Firmware auf den Dingern aktuell ist (sollte >= 1.4 sein)? 
Firmware ist die 1.4. Also werde ich versuche diese upzudaten. muss ich nach dem update in FHEM wieder etwas anpassen? bei Thermostat oder ext. virtuellen Thermometer...?

Zitat von: Morgennebel am 13 Januar 2020, 14:18:19
Hab inzwischen alle aktualisiert und hab die Datei auch noch.

Hab mich noch nicht beschäftigt wie ich updaten muss. brauche anscheinend eine Datei. würdest du diese evtl zur Verfügung stellen? erfolgt das update über funk oder muss ich die Thermostate irgendwie anschließen?

Gruß

Beta-User

Die update-Datei wird (via FHEM) "verfunkt", du mußt danach nichts weiter tun, es bleibt alles, wie es ist, nur das Reading bzw. Internal ändert sich (und hoffentlich das Regelverhalten in die gewünschte Richtung).
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