HM-CC-RT-DN: Regler schießt übers Ziel hinaus

[PatrickR]

Hallo zusammen!

Ich hoffe meine Frage ist nicht off-topic, da das Problem vermutlich unabhängig von der Implementierung in FHEM ist.

Ich habe seit einiger Zeit 8 HM-CC-RT-DN in Betrieb und musste feststellen, dass die Regler etwas über's Ziel hinausschießen, d. h. aus meiner Sicht unberechtigt das Ventil öffnen. Gut erkennen kann man das m. E. am folgenden Plot:
(http://i.imgur.com/toGNIbl.png)
Offenbar ist die gemessene Temperatur um 8Uhr über der gewünschten, dennoch wird das Ventil aufgerissen. Wie man sieht, pendelt die Temperatur dann ziemlich zuverlässig 2°C über dem gewünschten Wert ein.

Zum Aufbau: Ich setze die Ventile ohne externe Sensoren ein. Nimmt hier das Ventil ggf. eine Korrektur vor, um die Heizkörpernähe auszugleichen?

Gruß
Patrick

[Joachim]

Moin Patrick,

suche mal nach offset oder Temp offset.

Gruß Joachim

[PatrickR]

Hallo Joachim!

R-tempOffset steht auf 0.0K (Channel 4). Am liebsten hätte ich da jetzt 2.0K gelesen. Wäre natürlich eine Überlegung, da -2.0K auszuprobieren aber schön fühlt sich das nicht an.

Code Auswählen Erweitern


Internals:
   DEF        2223F604
   NAME       OG.WZ.Heizung
   NR         227
   STATE      T: 23.0 desired: 21 valve: 14 %
   TYPE       CUL_HM
   chanNo     04
   device     OG.WZ.Heizung_thermostat
   Readings:
     2014-01-02 21:53:56   R-boostPeriod   5 min
     2014-01-02 21:53:56   R-boostPos      80 %
     2014-01-04 14:01:00   R-btnNoBckLight off
     2014-01-02 21:53:56   R-dayTemp       21 C
     2014-01-04 14:01:00   R-daylightSaveTime on
     2014-01-04 14:01:00   R-decalcTime    11:00
     2014-01-04 14:01:00   R-decalcWeekday Sat
     2014-01-04 14:01:00   R-modePrioManu  all
     2014-01-04 14:01:00   R-modePrioParty all
     2014-01-02 21:53:56   R-nightTemp     17 C
     2014-01-04 14:01:00   R-noMinMax4Manu off
     2014-01-04 14:01:00   R-regAdaptive   on
     2014-01-04 14:01:00   R-reguExtI      15
     2014-01-04 14:01:00   R-reguExtP      30
     2014-01-04 14:01:00   R-reguExtPstart 30
     2014-01-04 14:01:00   R-reguIntI      15
     2014-01-04 14:01:00   R-reguIntP      30
     2014-01-04 14:01:00   R-reguIntPstart 30
     2014-01-04 14:01:00   R-showInfo      time
     2014-01-04 14:01:00   R-showWeekday   off
     2014-01-04 14:04:09   R-sign          off
     2014-01-02 21:53:56   R-tempMax       30.5 C
     2014-01-02 21:53:56   R-tempMin       4.5 C
     2014-01-04 14:01:00   R-tempOffset    0.0K
     2014-01-02 21:53:56   R-valveErrPos   15 %
     2014-01-02 21:53:56   R-valveMaxPos   100 %
     2014-01-02 21:53:56   R-valveOffsetRt 0 %
     2014-01-04 14:01:00   R-winOpnBoost   off
     2014-01-02 21:53:56   R-winOpnDetFall 1.4 K
     2014-01-04 14:01:00   R-winOpnMode    on
     2014-01-02 21:53:56   R-winOpnPeriod  15 min
     2014-01-02 21:53:56   R-winOpnTemp    12 C
     2014-01-04 15:14:47   ValvePosition   14 %
     2014-01-04 15:14:47   desired-temp    21
     2014-01-04 15:14:47   measured-temp   23.0
     2014-01-04 15:14:47   mode            auto
     2014-01-04 15:14:47   motorErr        ok
     2014-01-04 15:14:47   state           T: 23.0 desired: 21 valve: 14 %
     2014-01-04 14:01:00   tempListFri     set_  16:00 18.0 23:00 21.0 24:00 18.0
     2014-01-04 14:01:00   tempListMon     set_  16:00 18.0 23:00 21.0 24:00 18.0
     2014-01-04 14:01:00   tempListSat     set_  08:00 18.0 24:00 21.0
     2014-01-04 14:01:00   tempListSun     set_  08:00 18.0 24:00 21.0
     2014-01-04 14:01:00   tempListThu     set_  16:00 18.0 23:00 21.0 24:00 18.0
     2014-01-04 14:01:00   tempListTue     set_  16:00 18.0 23:00 21.0 24:00 18.0
     2014-01-04 14:01:00   tempListWed     set_  16:00 18.0 23:00 21.0 24:00 18.0
     2014-01-04 14:01:00   tempList_State  set


Patrick

P. S.: Werde das Gefühl nicht los, dass Computer das Foren-Captcha leichter lösen können als ich... :/

[Joachim]

aber schön fühlt sich das nicht an.

soll auch nicht schön sein, sondern für vernünftige Temperatur sorgen, also anpassen, bis es gefällt.

[PatrickR]

Hallo zusammen!

tempOffset war leider nicht die Lösung. Es korrigiert scheinbar die measured-temperature. D. h. measured und desired zeigen nun den gleichen Wert an, der Regler reagiert aber sofort auf diese vermeintlich zu tiefe Temperatur und reißt wieder den Hahn auf.

Patrick

[Mr. P]

Hej Patrick,

das Problem hab ich bei mir auch. Hab den Offset schon auf 2.5K und um die Zieltemperatur von 23°C zu erreichen, muss ich immer noch die desired-temp auf 21°C einstellen.
Hatte schon den Verdacht, dass hier einer der Gründe versteckt ist, weshalb die Firmwareversion 1.0 nicht mehr aktuell ist und mittlerweile V1.4 zur Verfügung steht.
Wenn auch nicht besonders schön, aber solange man es weiß, ist es kein Problem.

[chris1284]

sehr komisch. deine desired ist 21 und er regelt scheinabr auf 22-23 grad.
evtl ist der motor falsch "kalibriert" so das zb das ventil auf 0% steht aber real nicht wirklich zu ist und er weiter heizt

[PatrickR]

Das Problem scheint bei ELV schon bekannt zu sein, s. z. B. http://www.elv.de/topic/temperaturdifferenz.html. Erschreckend ist hier, wie man dem Kunden mit der leider weit verbreiteten Support-Beschäftigungstherapie begegnet (warten, Vorlauftemperatur etc.).

Man könnte dem Problem jetzt durch eine Korrektur de offsets in Kombination mit einer Korrektur der Anzeige(!) der measured-temperature in FHEM begegnen, aber das wäre schon eine arg übertriebene Lösung für einen Produkt-Bug.

@chis1284:
Mit der Kalibrierung kann es m. E. nichts zu tun haben, siehe das Diagramm bei 8:00Uhr. Measured liegt hier über desired, valve 0%. Es gibt hier absolut keinen Grund, an diesem korrekten Zustand etwas zu ändern; dennoch dreht das Ventil auf.

Patrick

[Mr. P]

Hej Patrick,

den Thread kannte ich schon, damals war er allerdings noch nicht so lange wie heute.
Hab auch gerade gesehen, dass du auch einen Beitrag beigesteuert hast. Auf die Antwort bin ich schon einmal gespannt.
Befürchte aber, dass wenn ein Firmwareupdate etwas bringen würde, etwas in der Art zurück kommt, wie: entweder einschicken oder CCU2 kaufen, denn mit etwas anderem funktioniert ein Update zu Hause (im Moment) nicht.
Aber am meisten würde mich einmal das Changelog der einzelnen RT-Updates interessieren... scheint nur leider nirgends bekannt zu sein. :-/

[Blockmove]

Ich hab hier genau ds selbe Thema mit 3 Reglern

Manchmal fragt man sich schon, wie EQ3 entwickelt, testet und Qualitätssicherung betreibt.

Gruß
Dieter

[martinp876]

Hi Dieter,

Meine Interpretation:
a) da der Fühler direkt am HK hängt wird die temp 1,5 Grad über der eingestellten gehalten.
b) der RT reagiert auf den Abstand zwischen soll und ist (regeldifferenz). Wenn die sich Ändert muss nachgeregelt werden. Je schneller die Änderung umso schneller die Anpassung.
- wenn du die Soll-temp hoch drehst ist dies eine schnelle Änderung der Differenz - und wird mit massiver regelung beantwortet. Das kann zu Überschwingern führen.

c) der RT muss auch Änderungen der vorlauf-temp berücksichtigen, ohne diesen und dessen Änderungen zu kennen

d) du kannst die Aggressivität der Regelung auf Änderungen  einstellen anhand der Regelparameter in den Registern. Leider beschreibt das eQ3 nicht. Fraglich ist, was intern und extern bedeutet - die Anderen Parameter kann man sich zusammenreimen.

Es ist unschön, dass nicht genau auf den Sollwert geregelt wird - aber bei aktivem HK evtl angebracht. Faktisch ist es sicher so, dass die wirkliche Raumtemp mehr von der RT-temp abweicht, je mehr der HK heizt, also das Ventil aufgedreht ist.

Ich werden einmal an den Regelparametern spielen - vielleicht kann aber jemand etwas dazu sagen oder diese beschreiben?

Gruss Martin

[franky08]

Hallo, ich habe bei mir, in einem Raum 2 RT-DN mit einem externen Fühler gepeert. Da mich die Regelkurve des RT-DN auch genervt hat.
Mit einem externen Fühler (bei mir ein WDS10-TH-O (ist zwar für Außen)) wird die Regelkurve wesentlich flacher und die Abweichung von der Solltemperatur beträgt im Schnitt 0,5 bis 1°C.(http://sz_heizung_links_temperatur

[Blockmove]

Was mich etwas nervt ist eigentlich, dass es noch den Parameter "Offset" gibt.
Damit sollte der Ausgleich zwischen Regler Ist-Temperatur und tatsächlicher Raumtemperatur erfolgen.
Wenn - wie bei mir - Offset 0 eingestellt ist, dann erwarte ich eigentlich, dass das Ziel der Regelung Ist = Soll ist.

Gruß
Dieter

[martinp876]

Offset 'kalibriert', wenn ich es richtig verstehe - den Tempfühler. Sehen kann man am RT nichts, den wenn quasi 20C gemessen werden wird 1 Grad addiert und mit 21C gearbeitet - incl Anzeige. Der Raum wird dann 1Grad wärmer oder kühler. Sehen kann man es nur mit einem separaten Thermostat.
Gedacht ist es wohl primär um den Unterschied 2er RTs im gleichen Raum auszugleichen, die ortsabhängig verschiedene Temperaturen messen und daher ungleich arbeiten.
Ich habe in einem Raum einen hohen und einen niedrigen HK - der Fühler ist 1m höher angebracht - da kann man korrigieren...

[PatrickR]

Augenscheinlich gibt es doch im Gerät zwei Offsets:
1.) tempOffset (einstellbar): Kalibrierung Messfühler mit Auswirkung auf die ausgegebene Ist-Temperatur und damit auf die Regelung.
2.) "Regelungsoffset" (hartkodiert auf ca. 2.0K, ggf. automagisch angepasst): Differenz zwischen eingestellter "desired temperature" und der Zieltemperatur der Regelung.
Was uns somit noch zum Glück fehlt, ist eine Möglichkeit auf den Regelungsoffset Einfluss zu nehmen. Alternativ könnte man ihn einfach wie von Dieter vorgeschlagen auf 0 regeln. Dann würde man tempOffset manuell so einstellen, dass die Temperaturdifferenz zwischen Ort der Wunschtemperatur (Raummitte?) und dem Ventil ausgeglichen wird.

Dieser Abstand zwischen den Kurven ist auf jeden Fall mehr als nervig.

Grüße
Patrick

[Thorsten Pferdekaemper]

Hi,
jetzt muss ich doch auch mal meine Erfahrungen einbringen. Das hier ist was meine RTs bisher heute getrieben haben:
(http://pferdekaemper.com/tmp/RT_Logs20140105.jpg)
Der obere Plot (Küche) ist von einem RT mit externem Temperatursensor, der untere Plot (Schlafzimmer) ist von einem ohne. Tatsächlich schafft der mit externem Sensor eine genauere Regelung, aber er hatte auch ein paar Tage mehr Zeit zum Lernen. (Keine Ahnung, ob das wirklich einen Unterschied macht.)
Ich kann da nichts von einem Offset sehen. Wenn man eine Ausgleichsgerade durch den unteren Istwert legen würde, dann käme da vielleicht ein halbes K Differenz raus, aber keine 2K wie von anderen berichtet. Ich denke eher, dass der Regler das ganz gut macht und nur mein Heizkörper zusammen mit der aktuellen Vorlauftemperatur etwas überdimensioniert sind. (Zumindest bei den aktuell warmen Temperaturen.)
Gruß,
    Thorsten   

[PatrickR]

@Thorsten:
Interessant. Welche Firmware-Version hast Du? Hast Du irgendwelche Offsets/Einstellungen geändert?

Gruß
Patrick

[Thorsten Pferdekaemper]

Hi,
die RTs haben beide Firmware 1.0. Ich habe keine Einstellungen geändert, dazu gab es bisher keinen Grund. Ich arbeite nur mit tempListXxx und partyControl. Manchmal setze ich auch die desiredTemp direkt per Web-Frontend oder am Stellrad.
Gruß,
   Thorsten

[jab]

Ich habe das gleiche Bild. Mit internem Sensor ist er immer etwas drüber. Sobald er einen externen Sensor hat nicht mehr. Allerdings funktioniert das mit dem internen Sensor bei mir in der Praxis recht gut. Der Raum ist halt etwas kälter als das Thermostat an der Heizung.

Die Regelparameter passt der RT ja selbstständig an. R-reguExt ist der externe Temperatur Sensor und R-reguInt der interne. Zumindest ist R-reguExt nur an dem RT nicht mehr gleich den Defaultwerten wo ich einen externen Sensor habe.

Die Registernamen sind für mich auch relativ selbsterklärend. Das ganze ist ein PI-Regler (http://de.wikipedia.org/wiki/Regler#PI-Regler):
I - Integralanteil = Summer der Abweichung über die Zeit
P - Proportionalanteil = linear Teil also die aktuelle Abweichung

Damit haben wir R-reguXXXP und R-reguXXXI erklärt. Bleibt noch R-reguXXXPstart. Da würde ich vermuten, dass sie für eine Sprungantwort also wenn man den Sollwert ändert einen anderen P Anteil eingebaut haben. PI Regler sind nämlich ansonsten relativ langsam bei Sprüngen.

Da die Ableitung im Differenzialteil unendlich ist kann man das  auch nicht mit einem PID Regler machen und sie haben sich für diese Lösung entschieden. Ich hoffe das erklärt es halbwegs.

[PatrickR]

Hallo zusammen!

Danke für die Infos.

Schade nur, dass man dem Nutzer keine Möglichkeit gibt, diese interne Differenz zu beeinflussen. Bei mir ist nämlich die am Thermostat gemessene Temperatur nahezu (0,5K) identisch mit der Temperatur am anderen Ende des Raums. Das könnte daran liegen, dass die Thermostate an meinen Heizkörpern unten angebracht sind.

Da ich aber ohnehin die Luftfeuchtigkeit messen möchte und daher Sensoren benötige, wird sich der Designbug künftig von selbst erledigen.

@Thorsten:
Im Schlafzimmer hattest Du nie einen externen Sensor am Thermostat?

Patrick

[Thorsten Pferdekaemper]

Hi,
@ jab: Bei mir sind die Ext und Int Werte gleich:

Code Auswählen Erweitern

     2014-01-05 19:04:14   R-regAdaptive   on
     2014-01-05 19:04:14   R-reguExtI      15
     2014-01-05 19:04:14   R-reguExtP      30
     2014-01-05 19:04:14   R-reguExtPstart 30
     2014-01-05 19:04:14   R-reguIntI      15
     2014-01-05 19:04:14   R-reguIntP      30
     2014-01-05 19:04:14   R-reguIntPstart 30

Das ist von dem RT, der mit dem externen Sensor zusammenhängt. Ich glaube auch, dass das die Defaultwerte sind. (Ja, ich habe gerade getConfig gemacht...)
Möglicherweise hängt das tatsächlich mit der Firmware-Version zusammen. Welche Version haben Deine RTs?

@PatrickR: Nein, der im Schlafzimmer war schon immer Einzelkämpfer.

Gruß,
   Thorsten

[PatrickR]

@jab, @Thorsten:
Die Werte sehe ich auch (V1).

@jab:
Schade, hatte gehofft, der externe Sensor würde als kurzzeitiger Mentor für das Ventil taugen :/

Grüße
Patrick

[jab]

Hi,

ich habe Firmware 1.0 und 1.1. Bei beiden sind die aber angepasst. Das dauert aber einige Tage oder Wochen. Die Regler sind auch merklich besser geworden bei mir.


Gruß,
Jan

[Thorsten Pferdekaemper]

Hi,
ok, wenn das Wochen dauern kann dann hatten meine RTs noch nicht so richtig die Gelegenheit zum Lernen.
Ich habe gerade einen ins Bad eingebaut, der scheint noch nicht so ganz begriffen zu haben dass 25 größer ist als 23. Na mal sehen, ob er's noch kapiert.
Gruß,
   Thorsten

[Samsi]

Wenn die Temperatur übers Ziel hinaus geht, würde ich es auch mal mit dem valveMaxPos und valveOffset probieren, mit dem max kann man ja verhindern das es zu weit auf geht.
Und mit dem valveOffset könnte man dann noch den Regelungsbereich senken oder anheben.

Bei mir funktioniert es aber auch ohne Anpassung recht gut. Ich habe deshalb bisher nur das tempOffset angepasst.

[peterk_de]

Also ich habe dahingehend auch schon viel versucht und mit den Regelparametern herumgespielt. Auch ganz systematisch und über einen längeren Zeitraum, da mich sowohl in einem kleinen als auch einem großen Raum immer eine stark überschießende Regelung störte.

Trotz externem Temp-Sensor springt das Ventil häufig zwischen (fast) ganz offen und ganz zu, obwohl kaum eine Regelabweichung vorliegt. Das führt dann zu sinnlos glühenden Heizkörpern (unser Vermieter bevorzugt eine sündhaft steile Heizkurve statt einem ordentlichen hydraulischen Abgleich) und kann von meinem Gefühl her nicht sonderlich gut für unsere nächste Nachzahlung sein. Auch schwankt die Temperatur dadurch im kleinen Raum (Bild) immer zwischen Sollwert und Sollwert + 2K (Periodendauer so ca. 2 Stunden); im großen ist es nur 1K aber dennoch spürbar.

Das tritt mit adaptiver Regelung genauso auf wie mit manuell veränderten Regelparametern. Ich habe die nun mehrmals auf verschiedene Extreme gesetzt (z.B. entweder P,  I oder Pstart maximal, die anderen jeweils minimal) und beobachtet, aber ehrlichgesagt überhaupt keinen Unterschied in der Regelung bemerkt. hat da jemand andere Beobachtungen gemacht?

Meine Notlösung war nun erstmal im kleinen Raum die ValveMaxPos auf 50% herunterzusetzen. Siehe Bild. Aufheizen dauert nun n bissel länger, aber es schwankt nicht mehr ganz so arg. Toll ist das natürlich noch nicht. Ich meine, warum heizt der 10:30 fast volle Suppe (vom erlaubten) an, obwohl noch fast Solltemperatur anliegt? Oder ist die Vorlauftemperatur nahe dem Siedepunkt Schuld an diesem Dilemma?

Parameter des Thermostaten auf dem Bild stehen seit 2 Wochen auf Adaptive und sehen aktuell wie folgt aus:

R-regAdaptive on
R-reguExtI 11
R-reguExtP 26
R-reguExtPstart 5
R-reguIntI 10
R-reguIntP 25
R-reguIntPstart 5
R-valveMaxPos 50%

[Blockmove]

Hat eigentlich jemand schon geschaut wie es mit der aktuellen Firmware (1.3 oder 1.4) aussieht?
Meine Regler sind noch Version 1.0.

Gruß
Dieter

[Thorsten Pferdekaemper]

Hi,
jetzt hab' ich auch so einen (siehe Anhang).
Man muss dazu aber sagen, dass der ganz neu eingebaut ist. Außerdem ist der Raum sehr klein (ca 4qm) und die Heizung wahrscheinlich etwas überdimensioniert.
Da keiner meiner Regler mehr als 20% Öffnung braucht um die Soll-Temperatur zu halten habe ich jetzt mal am Vorlauf der Heizanlage gespielt und dort mal die (fiktive) Soll-Raumtemperatur kräftig nach unten gestellt. Mal sehen...
Gruß,
    Thorsten

[Blockmove]

Die Raumgöße spielt keine bzw. nur eine geringe Rolle.
Einfluss hat, so wie ich es sehe, die Solltemperatur.
Im Schlafzimmer hab ich 16/18° als Soll-Temp und hier ist die Abweichnung bei ca. 0,5°.
Beim Kinderzimmer sind es 18°/21° und hier ist die Abweichung ca. 1,5°

Naja, mal beobachten.
An die Regelgenauigkeit eines FHT80b kommen die neuen Homematic-Regler nicht hin.
Aber dafür sind sie deutlich leiser und die Boost-Funktion ist auch sehr praktisch (Bad)

Gruß
Dieter

[PatrickR]

Ich glaube, um die Verwirrung im Zaum zu halten sollten wir nicht zwei Probleme vermischen:

a.) (Aufhänger des Threads): Regelung stellt zielgenau eine Zieltemperatur (teilweise 2°C) über der eingestellten Solltemperatur ein
b.) Diverse Probleme in Zusammenhang zu hohen/zu niedrigen Ventilstellungen.

Meine Reklamation bei ELV hat bislang keine Früchte getragen bis auf einen Textbaustein im Umfang von Goethe's Faust. Der für das Problem relevante Teil ist überschaubar:

IST-Temperaturmessung am Heizungssteller:

[...] Bei einem direkt Vergleich von Soll- und Ist-Temperatur kann nur
eine separat gemessene Ist-Temperatur aus dem Raum herangezogen werden.

Dieses resultiert daraus, dass die Heizungssteller über eine
Geräteinterne Temperatur-Korrektur verfügen, die je nach gemessener
Ist-Temperatur vom Heizungssteller selbst, neu berechnet wird. Diese
Funktion ist notwendig, um der gemessenen Temperatur am Heizungskörper
entgegen zu wirken, da die Temperatur direkt am Heizkörper höher ist als
die mitten im Raum. Dieses Verfahren hat sich beim Hersteller eQ-3 durch
Feldtests sowie Simulationen bewährt.

Zusammenfassend ist es wie befürchtet. Ich habe darum gebeten mir diese Korrektur näher zu erläutern, auch im Hinblick auf einen Einfluss des Nutzers, eine sich ggf. selbsttätig in Wohlgefallen auflösende Adaptivität (wie auch immer das gehen soll ohne zuverlässigen Referenzwert) und etwaige Firmware-Updates.

Patrick

[disaster123]

Hallo,

ich habe genau das gleiche Problem. Alle meine 8 HM Thermometer zeigen mir genau die Temp an, die mir auch ein externes Thermometer anzeigt - sind also korrekt.

Leider regeln aber alle 8 HM immer 1,5 - 2K über meine gewünschte Temp. Alle Räume sind also zu warm ;-(

Gibt es irgendwelche News diesbzgl?

Allerletzte Idee ist, dass man ein Offset in FHEM integriert, welches die desired Temp "korrigiert".

[PatrickR]

Um es kurz zu machen:

Das Problem besteht nach wie vor. eq3 betrachtet das Verhalten als erwünscht, denn am Ventil sei es üblicherweise wärmer als im Raum. Dass das in der Praxis nicht stimmt, konnten wir mehrfach sehen. Insofern würde ich nicht davon ausgehen, dass der (beabsichtigte) Bug auf dem Weg der Einsicht behoben wird.

Ich setze inzwischen HM-TC-ITs ein, wodurch das Problem nicht auftritt.

Patrick

[disaster123]

Also doch eine desired offset Korrektur in FHEM?

[martinp876]

was hältst du vom Offset, der im RT einstellbar ist?

[PatrickR]

was hältst du vom Offset, der im RT einstellbar ist?

Der wirkt sich leider nicht nur auf die Differenz zur desired-temperature sondern auch auf die übermittelte measured-temperature aus. D. h. man transformiert ein Problem in ein anderes. Nimmt man mal als gegeben an, dass eq3 auf Grund höherer Einsicht den Designfehler nicht behebt, dann hätte man drei Möglichkeiten:

1.) Übermittlung einer korrigierten desired-temperature von FHEM an den RT.
2.) Verwendung des Offsets und Korrektur der measured-temperature in FHEM. (Geht das evtl. schon?)
und der Vollständigkeit halber:
3.) Kauf weiterer Hardware, z. B. TCs.

Bleibt zu klären, ob 1 oder 2 die weniger schreckliche Lösung ist. In meinem Fall habe ich mich für 3 entschieden, da ich durch die Luftfeuchtemessung einen tatsächlichen Mehrwert gegenüber der Variante ohne TCs habe.

Patrick

[Bennemannc]

Hallo,

2) geht mit userReadings - da kannst Du beliebige original Readings manipulieren und als "eigenes" Reading ausgeben und auch Loggen lassen.

Ich finde das auch nicht so klasse - 1,5 Grad über soll und das Ventil ist immer noch 20% auf. Aber egal - solange meine bessere Hälft nicht klagt das es zu kalt ist, ist alles im grünen Bereich.

Gruß Christoph

[disaster123]

2 hat aber das Problem das zumindest in meinem Fall der Graph zwar schön aussehen würde die Temperatur dann aber schlichtweg falsch wäre.

1 wäre die Einzige Lösung. Korrigiert senden und korrigiert Empfangen.

[PatrickR]

2 hat aber das Problem das zumindest in meinem Fall der Graph zwar schön aussehen würde die Temperatur dann aber schlichtweg falsch wäre.

Inwiefern?

[disaster123]

Weil die measured Temp bei mir korrekt ist ich will Sie also nicht korrigieren. Aber die Desired wird so behandelt als wäre Sie 1,5-2K über dem was ich eingestellt habe.

[Bennemannc]

Hallo,

ich muss jetzt mal eine Lanze für EQ-3 brechen. Die versuchen mit einer Reglelkurve möglichst alles abzudecken - Altbau (zugig, ggf. schlecht gedämmt), Neubau (luftdicht, gut gedämmt), Heizkörper (berechnet oder wie früher Daumenwert) - das ganze dann noch mit einer Temperturmessung in Heizkörpernähe, das ist unmöglich alles genau zu treffen.

Ich fahre nach Tages/Wochenplan. Dabei habe ich Nacht (für abgesenkt) und Tag (für "ich will es warm haben"). Welche desired Temperatur ich für diese "Zustände" vorgeben muss ist doch eigentlich zweitrangig. Wenn ich den Regler einmal eingestellt / auf meinen Raum abgestimmt habe, kann ich zwischen den beiden Zuständen wählen - oder selber noch etwas eigenes einstellen - was will ich mehr.
Bei mir (Altbau und Türen immer etwas offen wegen Katzen) ist es nie gleichmäßig warm im Raum. Ich habe etwas mit dem offset rumgespielt bis es passte und gut ist.
Wie schon gesagt - manchmal meine ich auch, dass das Ventil weiter zu sein müsste (Überregelung) aber im allgemeinen passt es.

Gruß Christoph

PS: auch die "desired" Temperatur sollte man mit userReadings manipulieren können - wobei man dann nur der "angezeigten Wert" anders ist. Der Wert, der dem Regler mitgeteilt wird bleibt gleich. userReadings my_desired{ReadingsVal("Thermostat","desired",0) -1} und my_desired im stateFormat anzeigen statt desired.

[strauch]

Ich hab das auch gerade mal ins ELV Forum geschrieben. Meiner Meinung nach müssten die, die Ventilöffnung mit in den Offset einberechnen. Ich hatte den Fall, das die Desired Temp auf 16°C war. Da aber die Sonne aufs Zimmer kanllte wurde der Raum 22.5°C warm. Dann wechselte die Desired Temp auf 21°C und das Ding fing an zu heizen. Und jedem sollte klar sein, das der Raum deutlich über den 21°C war, da der Heizkörper ja kalt war spielt die nähe zu eben jenem keine Rolle.

Hier sollte der Offset steigen, bei größerer Ventilöffnung und sinken bei kleinere Ventilöffnung.

Zudem hätten die ja auch wenn man schon die Regelung einstellen kann, auch Profile anbieten können in der CCU für Altbau, Neubau etc. Bei einem Zuginge Altbau ist der Offset mit Sicherheit höher als in einem Neubau.

Ich glaube die haben das alles komplizierter gemacht als es sein müsste. Ich hab mir jetzt einfach so beholfen das ich auf 20°C desired Temp runter bin, damit ist der Zimmerbewohner Glücklich. Ich weiß auch das ich bei einem Honeywell in einem Altbau schon mal auf 23°C gegangen bin. Aber in Zeiten von immer mehr renovierten bauten, macht dieser hohe Offset in meinen Augen keinen Sinn.

[martinp876]

Dann wechselte die Desired Temp auf 21°C und das Ding fing an zu heizen.

klar

Dann wechselte die Desired Temp auf 21°C und das Ding fing an zu heizen.

irrelevant.

Also erst einmal, dass eQ3 1,5Grad zu hoch einstellt ist unschön. Mit offset lässt es sich korrigieren,aber nur insoweit, dass der Gemessene wert geändert wir.

In deinem Fall hattest du 22,5Grad, desired hat sich von 16 auf 21 geändert. Der RT sieht eine Differenz von +6,5Grad, die sich schlagartig auf 1,5 ändert. Baut man nun noch die 1,5 dazu ist es ein Sprung von +5 nach 0. Der Regler strebt einen stabilen Zustand an, was hier nicht gegeben ist. Es wird vermutet, dass sich die Änderung "fortsetzt", also besteht dringend Handlungsbedarf - man muss gegensteuern. Je größer der Sprung, desto heftiger die Reaktion.

Das passiert jeden Morgen bei mir, je nachdem wie heftig der Tempunterschied ist.
Der Regler unterscheidet nicht zwischen Änderungen vom Soll oder vom Ist wert, nur die geschwindigkeit und die absolute differenz.

Die andere Anmerkung, dass der regler 20% offen ist obwohl er +1,5Grad hat ist auch 'logisch'. Nun, die 1,5Grad ist leider so, aber ansonsten ist der Regler auf "Soll" - und das hat er erreicht, indem das Ventil auf 20% steht. Wir haben einen Stabilen Zustand auf Sollwert - das Ventil bleibt wo es ist.

Ein Attribut zur änderung des Sollwert muss ich mir überlegen. Einige Readings beeinflussen auch den Slider.... Mit den FHEM Offset würden dann der RT und die FHEM Anzeige auseinander laufen. Es müssten alle templisten überarbeitet werden - wie sollen die dargestellt werden? - da hängt mehr dran, als ein User reading, will man es wirklich und komplett durchziehen.

[Bennemannc]

Hmm,

ich war immer davon ausgegangen, das eine Regelung einen Vergleich zwischen Soll- und Istwert macht und bei Abweichungen nachreguliert. Wenn die allerding, unabhängig von der Solltemperatur, noch eine Anstieg oder Abfall berücksichtigen .... normalerweise müsste man doch dann die gespeicherten Werte bei einer Sollwertänderung löschen, da sie nicht mehr relevant für das weiter Regelverhalten sind.

Ich würde an Fhem an dieser Stelle nichts ändern. Es ist zwar nicht unbedingt schön, aber da sehe ich eher EQ-3 in der Pflicht nachzubessern.

Gruß Christoph

BTW. kommt man an die gespeicherten Werte (Anstieg / Abfall) dran ? Dann könnte man ja bei einer Sollwertänderung dort angreifen und gegensteuern. Gerade jetzt in der Übergangszeit stört es mich schon, wenn das Ventil bei einer Sollwertänderung auffährt obwohl der Sollwert bereits überschritten ist.

[Joachim]

Moin Bennemannc,
EQ3 wird daran nichts ändern, denn die sehen es als future, und nicht als Fehler, denn der Regler ist ein PI-Regler der versucht, zu erahnen, was passiert. Aus Erfahrung weiß ich, dass es meist schief geht, wenn Technik versucht, mitzudenken.

Gruß Joachim

[Bennemannc]

Hallo Joachim,

Aus Erfahrung weiß ich, dass es meist schief geht, wenn Technik versucht, mitzudenken.

Wobei die meisten Sollwertänderungen - zumindest in meinem Fall - dem Regler ja schon bekannt sind (Wochenprogramm). Da sollte es doch für die Technik einfach sein "mitzudenken", denn in dem Fall weiß sie ja schon vorher was passiert. 

Gruß Christoph

[Joachim]

Im Prinzip ja, aber.....

[martinp876]

Da sollte es doch für die Technik einfach sein "mitzudenken", denn in dem Fall weiß sie ja schon vorher was passiert.

macht es schon. In deinem Beispiel ist die Regeldifferenz auf 0 gegangen (die 1,5Grad muss man hinnehmen...) und das ist in jedem Fall bedenklich.
Man kann die Regelparameter beeinflussen, die sind in Registern hinterlegt (nicht aber die Historie...)
Du könntest probieren, den Sprung kleiner zu machen, also 2-stufig...

[Bennemannc]

Hallo Martin,

also so groß ist der "Sprung" nun auch wieder nicht. Um 15:00 wird die Solltemperatur von 18° auf 21,5° angehoben. Das veranlasst das Ventil ca. 20% auf zu machen - unabhängig davon, das es im Raum bereits 22,5° oder mehr sind (Südseite mit vielen Fenstern).
Wieso interessiert es die Reglung mehr, das die Differenz zwischen Soll- und Isttemperatur von +6,5 auf +1,5 gesunken ist - meiner Meinung nach sollte der Vergleich Soll / Ist Vorrang haben. Ich bin immer noch im Plus, also warum sollte ich da weiter ins Plus nachsteuern?
Kann man die Steuerung träger machen ? - vielleicht bring das ja etwas. Dann würde in meinem Fall nicht so wahnsinnig übersteuert.

Gruß Christoph

[martinp876]

nun - lange her, das sich einmal regler berechnet habe.

Das ist eine Regelung, auch noch eine recht 'komplexe' - ist wohl nicht nur ein PI sondern ein PID regler.
Man könnte evtl dinge auch anders lösen, hier also erst einmal wie ich den Regler sehe (nicht was ich mir wünsche)
1) der Regler regelt bei Internem Fühler auf +1,5 Grad (oder so).
2)den regler interessiert ausschließlich die Regeldifferenz. Der Regler selbst bekommt wahrscheinlich garkeinen anderen Wert.
da mit ist 3) die regeldifferenz nicht von 6,5 auf 1,5 gesunken sondern von 5 auf 0.
Die Regeldifferenz IST der soll-ist vergleich.

Stelle dir den Regler auch so vor: Du willst hinter einem Laster her fahren, Abstand 50m, der hat gerade 80 drauf du kommst mit 120 an. Du musst bremsen, bevor du auf 50m ran bist, sonst krachts.
Nun hast du es geschafft, der Laster beschleunigt jetzt (was du nicht weisst) und der Anstand vergrössert sich. Je nach Änderungsgeschwindigkeit des Abstands musst du beschleunigen. Also je schneller sich der Abstand ändert desto heftiger musst du auf das Gas.
Das ist gängige Praxis in der Regelwelt - die genaue Parametrisierung ist jetzt die kunst. Dazu brauchst du eigentlich etliche Parameter: Wie träge ist die Heizung, wie groß/träge ist der Raum sind die wesentlichen. Die Trägheit der Heizung wird beeinflusst von der vorlauftemperatur, die der RT nicht kennt... wenn türen offen stehen oder manchmal nicht ändert dies alles eine präzise Regelung.

Der RT erlaubt das ändern des P (proportional) und I (integral) Anteils der Regelung. Per default steht der Regler auf adaptive regelung - eQ3 versucht also P und I zu optimieren, aus dem Verhalten des Systems. Ob dies klappen kann, kann ich nicht sagen - z.B. die Änderung der Vorlauftemp könnte dies bereits zu nichte machen.

Du kannst also adaptiv abschalten und es selbst machen.

Nächstes Problem: Es gibt die Werte für intern und extern. Ich kann nur raten, was es bedeutet: Interner oder externen Fühler. Es werden schon keine 2 gekoppelten PI regler sein...

Wenn du also nun den Internen her nimmst kannst du die Regelung einstellen (so sagen die Werte).

Zumindest den ersten Step der Sprungantwort kannst du ausmessen. Ist aber zeitaufwändig... Thermostat in konstanter temp lagern (ohne heizkörper) und einen fixen tempSprung draufgeben => reaktion des Ventils aufzeichnen.
Alles zurück, parameter ändern, noch einmal ein sprung.
Das kannst du auch automatisieren - mit FHEM at kannst du die desired-temp hin und her schalten und die ganze nacht aufzeichnen Auch die P/I werte kannst du automatisch ändern. Wenn du das Script hast kannst du alles in einer Nacht messen.
Wenn dein Keller konstante temp hat (10 Grad) kannst du eine Tabelle machen: von 4 auf 8, 5 auf 9, 6 auf 10, 4 auf 10, .....
Das ganze bei unterschiedlichen Werten für P und I.
Die Tabelle ist sicher interessant...

Schwerer ist es dann, die weitere Regelung auszumessen - das dauert ohne simulation wirklich lang, da ist dein HK und der ganze Raum beteiligt... das ist sehr träge.

Gruss Martin

[Bennemannc]

Hallo Martin,

also bei mir wird der Regler sich schon wegen der Witterungsgeführten Vorlauftemperatur den Nacken brechen. Das kann er nicht erkenne - er weiß die Außentemperatur ja nicht.
Wie kann man da adaptive Verhalten abstellen und P und I selber anpassen?

Gruß Christoph

[frank]

Wie kann man da adaptive Verhalten abstellen und P und I selber anpassen?

nach hmconfig.pm solltest du eventuell diese register haben:

regAdaptive -> adaption an/aus?

reguIntI -> intern i-anteil?
reguIntP -> intern p-anteil?
reguIntPstart -> vielleicht p-anteil nach sollwertsprung?

einfach mal mit rumspielen!

gruss frank

[Bennemannc]

Hallo,

das wäre doch mal ein Fall für eine Rundfrage:
Wer hat welche Werte in diesen Registern und wie zufrieden ist man mit diesem Regelverhalten ? - ach ja FW Version nicht zu vergessen.
Vielleicht könnte man auf diese Weise eine Tabelle zusammenstellen und "vernünftigere" Werte ermitteln, die bei ungewünschtem Verhalten manuell eingetragen werden können.

Gruß Christoph

[Puschel74]

Hallo,

nur mal so als kleine Randbemerkung:

Die Parameter für P und I-Anteil eines anderen Reglers werden hier nichts bringen.

Andere Vorlauftemperatur, andere Raumgröße, andere Heizkörpergröße, ...
Um die Werte vergleichen zu können müssten diese zwingend bei den selben örtlichen Gegebenheiten aufgenommen werden.
Und selbst dann wird es schwierig alle Störgrößen konstant zu halten.

Ein Vergleich mit anderen Reglerwerten wird dich daher nicht glücklich machen - leider.

Im grossen und ganzen kann man aber sagen das die adaptive Regelung idR passende Werte für P und I findet.
Ok. In der Firma halte ich nicht viel davon da ich eine Anlage selten so lange in die Finger bekomme um mit einer adaptiven Regelung wirklich was bewirken zu können.
Dafür wird der Regler erstmal nach "Gefühl" eingestellt und dann geschaut wie sich der Regler in der gesamten Anlage verhält.

http://de.wikipedia.org/wiki/Regelungstechnik

Es gibt auch Verfahren um einen Regler zu optimieren.
http://de.wikipedia.org/wiki/Faustformelverfahren_%28Automatisierungstechnik%29

Da darf sich aber gerne jeder selbst austoben 
Aber Vorsicht: Man kann sich schnell "zu Tode optimieren" 

Grüße

[strauch]

Die Parameter für P und I-Anteil eines anderen Reglers werden hier nichts bringen.

Vielleicht doch. Ich hab zwei Regler mit Firmware 1.0 und 2 mit Firmware 1.1. Die mit 1.0 haben als Werte 18 und 33 und die mit 1.1 haben 15 und 30..... also viel scheint da sich nicht zu adaptieren. Die Räume sind schon sehr unterschiedlich, der eine ist unterm Dach und eh immer zu warm. Das andere ist ein Bad mit RTL Bodenheizung.....

Vorallem ist für mich ja nicht mal die Regelung das Problem. Sondern das zu hohe ansetzten der Temperatur. Egal was ist, wenn ich eh 1,5°C über dem Soll bin, brauche ich nicht anspringen. Ich hab das Problem gelöst in dem ich es einfach kälter eingestellt habe und gut ist. Also das Problem ist ja doch eher trivial.

[Puschel74]

Hallo,

Vielleicht doch.

Aber wenn dann nur rein informativ.

Also das Problem ist ja doch eher trivial.

Jep, und hat aber nichts mit dem Regelalgorithmus an sich zu tun.
Ich denke mal nicht das eQ3 das Rad neu erfindet und einen eigenen Algorithmus für ihre Regler schreibt.

Theoretisch! sollte ein I-Anteil dazu führen das der Regler nach einer endlichen Zeit wirklich anfängt das Ventil zu schliessen.
Eine ständige Regelabweichung als Ergebniss gibt es eigentlich nur bei einem reinen P-Regler.
Und sowas werden die wohl hoffentlich nicht programmiert haben 

Grüße

[martinp876]

Zu beachten ist, dass man die P und I werte nur ändern kann, wenn regAdaptive auf offDeter steht. Was letztendlich logisch ist.

reguExt ist "voraussichtlich" nicht relevant in diesem Fall

7: reguIntI         |  10 to 20   
7: reguIntP         |  25 to 35   
7: reguIntPstart    |   5 to 45     

da die Wertebereiche begrenzt sind und 0 nicht zulässig ist wohl auch immer ein I-Anteil vorhanden.

Da das Ziel hier eigentlich war, die Antwort auf eine regeländerung abzuschwächen sollte man dies einfach testen. Das ist schließlich der einfache Teil, das lässt sich mir einen Thermostat im Keller prima erreichen.
Das gesamte Regelverhalten über den Bereich zu optimieren - da stimme ich Puschel74 zu - ist eine komplexe Angelegenheit. Da hat man erst einmal etwas zu tun.


Gruss Martin

[disaster123]

So ich habe 10_CU_HM.pm nun so umgebaut, dass man ein festes Offset für desired angeben kann. Ich werde die nächsten Tage mal testen ob alles funktioniert wie gedacht und dann gerne hier die Version veröffentlichen.

PS: warum nutzt FHEM nicht perltidy die Formatierung ist gewöhnungsbedürftig.

[martinp876]

kannst du erklären, was du alles berücksichtigt hast? Nur desired-temp ist nicht hinreichend - du hast sicher mehr gemacht.

[Thorsten Pferdekaemper]

So ich habe 10_CU_HM.pm nun so umgebaut, dass man ein festes Offset für desired angeben kann.

Hi,
ich glaube, dass ein fester Offset das "Problem" nicht ausgleichen kann. Ich habe mehrere RTs am Laufen, zum Teil mit unterschiedlicher Solltemperatur. Der im Bad steht oft auf 22° und scheint erst bei ungefähr 24° zufrieden zu sein. Ein anderer steht zurzeit auf 17.5° soll. Ist ist 18.7° und er zeigt keine Anstalten, das Ventil zu öffnen. Momentan ist es sowieso warm, aber ich glaube mich zu erinnern, dass bei 17° soll die RTs nur sehr wenig zu hoch regeln.
D.h. der Offset scheint von der eingestellten Solltemperatur (oder von der Ist-Temperatur?) abhängig zu sein.
Gruß,
    Thorsten

[disaster123]

Ich werde es mal eine Woche lang testen. Falls es klappt, poste ich den Code gerne. Berücksichtig ist alles was mit desired zu tun hat. Egal ob set oder get und egal ob templist, manuel oder auto.

[martinp876]

Register sind also berücksichtigt.
Das sind
dayTemp  |  15 to 30C     | comfort or day temperatur
nightTemp|   5 to 25C     | lower or night temperatur
tempMax  |  15 to 30.5C   | maximum temperatur
tempMin  | 4.5 to 14.5C   | minimum temperatur
winOpnTem|   5 to 30C     | lowering temp whenWindow is opened
WinOpnTemp der gepeerten SC/RHS
und die Templisten.

Bin gespannt - du manipulierst demnach die Register-Darstellung in den Readings?

Ausserdem die Kommandos
controlManu [on|off|5.0..30.0]
controlParty <temp> <startDate> <startTime> <enddate> <endTime>
desired-temp [on|off|5.0..30.0]
tempList... [prep|exec] HH:MM temp ...

incl Änderung der Slider Bereiche?

Die Darstellung am RT selbst ist dann natürlich nicht geändert - auch die Eingabe von dort (manuell).

Bei Attribut-eingabe werden alle Readings upgedated?

Wie verhält es sich mit den templist files?
Werde es mir ansehen, wenn du so weit bist.

[disaster123]

Hui Sagen wir mal so. Ich meine fast alles erfasst zu haben. Es fehlt garantiert etwas. Manipuliert wird beim speichern / senden in die Register.

Korrekt - die  Anzeige am Thermostat passt dann leider nicht.

[martinp876]

Manipuliert wird beim speichern / senden in die Register.

hm - wenn du also ein regset machst wird ein manipulierter Wert geschrieben?

Was passiert beim Ändern des Attributs?  Da müssen alle Darstellungen upgedated werden - register und readings.
Auch zu berücksichtigen sind groups - RT-groups und TC peerings. Das Attribut kann hier auch eingegeben werden - also sollte es funktionieren....
Es hängt einiges dran, wenn man es wasserdicht machen will. Und auch in der einfachen Fassung erwarte ich einige Eingriffe in die vorhandenen Mechanismen.
Trivial ist es nur oberflächlich.
Vielleicht sind da noch Anregungen für dich. Um es zu veröffentlichen muss es ein klares und verständliches Verhalten haben - in diesem Fall für ALLES was mit temp des RT zu tun hat - das ist eben nicht wenig.
Und es darf das allgemeine SW-konzept nicht über den Haufen werfen.
Die Alternative ist immer noch, 1,5Grad weniger "denken". Das geht immer.

Wie gesagt - bin gespannt.

Gruss Martin

[disaster123]

OK es funktioniert nicht das Offset ist tatsächlich dynamich und somit auch wenn ich es dann mit -1.5 definiere stimmt es bei manchen und dann bei anderen nicht...