Max-Thermostat regelt Ventil auf trotz Ist-Temperatur über Soll-Temperatur

Begonnen von shorty81, 25 Oktober 2013, 22:53:37

Vorheriges Thema - Nächstes Thema

shorty81

Hallo,
habe heute festgestellt, dass einige meiner Max-Thermostate (kein Plus) das Ventil aufdrehen, obwohl die gemeldete Ist-Temperatur über(!) der Soll-Tmeperatur liegt. Siehe Beispiel zwischen 10.00 und 19.00 Uhr.

Kann jemand das nachvollziehen oder hat ähnliches festestellt?

Viele Grüße
Chris
Raspberry Pi 2 Model B, CUL866, CUL433, JeeLink, HMLan, Homematic, Homebridge via Siri, Philips HUE, Max-Thermostate, Max-Fensterkontakte, AVM 546E, WS1600, RSL, Intertechno, IT+, Elro

Joachim

Moin Chris,
wie misst du die ist Temperatur?
offset eingestellt?

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

shorty81

Hi Joachim,
im Beispiel des Wohnzimmerthermostate ist measurementOffset -1.0
Aber das sind ja teils 3 Grad Unterschied, und das Thermostat regelt trotzdem das Ventil auf 10/15 %
VG
Chris

Raspberry Pi 2 Model B, CUL866, CUL433, JeeLink, HMLan, Homematic, Homebridge via Siri, Philips HUE, Max-Thermostate, Max-Fensterkontakte, AVM 546E, WS1600, RSL, Intertechno, IT+, Elro

John

Hallo Chris,
beide Kurven sind meiner Meinung nach erklärbar.

Vermutlich ist für dich die erste Kurve OK, aber warum verhält sich die 2 komplett anders und "unlogisch".

Eine mögliche Erklärung:
Die Thermostate sind als PI-Regler ausgeführt. (laut Hersteller)
Regelausgang=Ventilstellung (%) = P-Anteil + I-Anteil

Der P-Anteil ist direkt proportional zur Regeldifferenz. (Sollwert-Istwert)

Wir betrachten die 2. Kurve an der Stelle, wo du den Sollwert zum ersten mal auf 15 Grad setzt.
Hier wird  die Regeldifferenz praktisch 0, also ist auch der P-Anteil= 0.
(war vorher vermutlich auf <=-40%)

Demzufolge ist der Regelausgang identisch mit dem I-Anteil= ca. 40%.
Vermutlich hat der Hersteller wohl ein AntiWindup eingebaut.
(I-Anteil wird nicht mehr verändert, wenn der Reglerausgang den möglichen Stellbereich über oder unterschreitet, was zuvor der Fall war)

Der Wert des  I-Anteils muss in der Vorgeschichte begründet sein, die wir auf dem Diagramm nicht mehr erkennen können.


John






CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

shorty81

Hi John,
puhh... ich verneige mich in Demut vor so viel Fachwissen - und nehme mir das verlängerte Wochenende frei um das selber gedanklich zu durchdringen ;)
Da fehlt mir einiges an Hintergrundwissen.

Aber mein Problem scheint ja zumindest erklärbar und nicht unnormal zu sein. Das beruhigt.

Allerdings geht dabei ja schon einiges an Energie unnötig flöten, oder?!

Danke und viele Grüße
Chris
Raspberry Pi 2 Model B, CUL866, CUL433, JeeLink, HMLan, Homematic, Homebridge via Siri, Philips HUE, Max-Thermostate, Max-Fensterkontakte, AVM 546E, WS1600, RSL, Intertechno, IT+, Elro

John

Man kann vermutlich mit exotischen Bedingungen bei jedem Regler ein kurzfristig unsinniges Verhalten erzeugen.

Aber die Prognose ist gut:
Der I-Anteil wird sich mit der Zeit in einen vernünftigen Bereich einpendeln.

Wenn du den Sollwert etwas über den Istwert genommen hättest, wäre das Verhalten schon etwas plausibler.
Ein grosser Sollwertsprung ist für den Regler meist schwieriger zu beherrschen als der sich langsam verändernde Istwert.

Anders als der P-Anteil integriert der I-Anteil die Regelabweichung über die Zeit.
Er ist zwar für das Öffnen des Ventils verantwortlich gewesen, wird es aber nach und nach weiter schliessen, bis die Regeldifferenz 0 wird
oder die untere Stellbereich erreicht ist (0%).
Dann wirds auch wieder plausibel.

Ich hab mich vor kurzen mit dem Thema befasst und einen PID-Regler unter FHEM entwickelt der seinen Namen verdient.
http://forum.fhem.de/index.php/topic,14154.msg101571.html#msg101571


John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

shorty81

Beeindruckend, da muss ich noch viel lesen bis (falls) ich das jemals blicke.

Aber für mich heißt das eigentlich nur abwarten und dann sollte sich als wieder einpendeln. Verstehe ich das richtig?
Danke für die Hilfe!
Raspberry Pi 2 Model B, CUL866, CUL433, JeeLink, HMLan, Homematic, Homebridge via Siri, Philips HUE, Max-Thermostate, Max-Fensterkontakte, AVM 546E, WS1600, RSL, Intertechno, IT+, Elro

shorty81

Moin,
der einfachste/schnelleste Weg für mich wäre dann doch, das entsprechende Thermostat auf Werkseinstellungen zu setzen und neu in FHEM einzurichten, dann sollte der Speicher bezüglich P und I doch gelöscht sein. Oder sehe ich das falsch?
VG
Chris
Raspberry Pi 2 Model B, CUL866, CUL433, JeeLink, HMLan, Homematic, Homebridge via Siri, Philips HUE, Max-Thermostate, Max-Fensterkontakte, AVM 546E, WS1600, RSL, Intertechno, IT+, Elro

John

Der P-Anteil hat normalerweise keine speichernden Anteil da er ja direkt von der Regeldifferenz abhängt.
Der I-Anteil hingegen schon, hier wirkt sich  Factory-Reset wohl aus.

Allerdings werden vermutlich der P-Faktor und I-Faktor adaptiv sein, so dass ein FactoryReset auch Wirkung auf den P-Anteil haben kann.
Bei einem normalen PID-Regler werden diese Faktoren einmalig festgelegt.
Adaptive Algorithmen veruschen diese zu optimieren.

Hintergrund:

P-Anteil = Regelabweichung * p-Faktor

Vermutlich wird sich der Regler auch ohne weitere Massnahmen über die  Zeit wieder einrenken.

Du solltest ihm nur keine unmöglichen Aufgaben geben wie z.B.:

Heizung in der Nacht komplett abschalten und gleichzeit Sollwert des Thermostats so legen, dass es nachheizen will.
Dann kann es nicht anders als den I-Anteil bis zu Anschlag hochzufahren.
Es hat jedoch keine Wirkung, da effektiv keine Wärme nachgeführt wird.

Die Sollwertvorgabe sollte also möglichst synchron mit der Zeitsteuerung der Heizung selbst laufen.

John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

shorty81

Hi John, danke für den Tipp.
Allerdings läuft die Heizung bei mir an sich durch sobald die Außentemperatur unter 18 Grad liegt. Insofern sollte es eigentlich keine unmöglichen Aufgaben wie beschrieben geben.
Ich frage mich halt, woher dieses Verhalten kommt, und vermute jetzt, dass das häufige Umstellen der Solltemperatur zwischen 4.5 Grad und 30 Grad (zu Testzwecken, zum Ausprobieren) den Regler zu seinem aktuellen Verhalten gebracht hat?!

Versuche es heute Nacht mal mit Werkseinstellung und Neueinrichtung in FHEM und lasse mich überraschen ;)

VG
Chris
Raspberry Pi 2 Model B, CUL866, CUL433, JeeLink, HMLan, Homematic, Homebridge via Siri, Philips HUE, Max-Thermostate, Max-Fensterkontakte, AVM 546E, WS1600, RSL, Intertechno, IT+, Elro

Tom_S

hallo,

das Verhalten tritt bei mir auch auf. Wenn die Solltemperatur im Bad höher eingestellt ist und ie ärmepumpe noch nicht heizt (Übergangszeit). Danach wir das Bad zu warm. Das einpendeln dauert dann sehr lange. Einen Reset auf Werkseinstellung brauchst du nicht zu machen. Wenn du kurzeitig die Batterien entfernst, fährt der Regler auf InS. Danach regelt er neu ein.

mfg Tom_S
RaspberryPI2 + pilight, 3x AVR-NetIO, LW12, LW12HX, LW12FC; MAX-Lan, ESP8266, Arduino, H801, Neopixel, Solaredge, Modbus

maplemaple

Guten Abend,

genau das Problem habe ich auch. In dem Thread "Fehler bei Berechnung von measuredTemperature ?" wurden schon einige Sachen besprochen, ich denke das hängt doch miteinander zusammen. Sieht bei mir im Plot ähnlich aus.

Mathias