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

Begonnen von PatrickR, 04 Januar 2014, 15:11:30

Vorheriges Thema - Nächstes Thema

disaster123

#30
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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

disaster123

Also doch eine desired offset Korrektur in FHEM?

martinp876

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

PatrickR

Zitat von: martinp876 am 24 April 2014, 07:59:44
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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

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
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

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

Zitat von: disaster123 am 24 April 2014, 08:23:08
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?
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

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.
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

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.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

martinp876

ZitatDann wechselte die Desired Temp auf 21°C und das Ding fing an zu heizen.
klar
ZitatDann 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

#42
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.
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

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
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

Bennemannc

Hallo Joachim,

ZitatAus Erfahrung weiß ich, dass es meist schief geht, wenn Technik versucht, mitzudenken.
;D
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
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF