FHEM Forum

Hallo liebe FHEM Gemeinde!

Ich habe schon viel hier im Forum gelesen, aber dies ist mein erster Post, also seid bitte nachsichtig falls ich aus Unwissenheit eine Etikette verletze  ;)

Ich habe ein Setup mit CUL868 und einigen HM-CC-RT-DN Thermostaten, dazu ein JeeLink und LaCrosse Temperatursensoren.

An sich funktioniert das Zusammenspiel sehr zufriedenstellend, es gibt aber einen Raum, bei dem der RT-DN maßlos übersteuert, und den ich deswegen per PID20 regele.
Um keine neue Hardware anschaffen zu müssen, habe ich das folgendermaßen realisiert:

• der PID20 nimmt die desired-temp vom RT-DN und die measured-temp vom LaCrosse Sensor, und berechnet eine sinnvolle Ventilstellung
• ein virtueller Temperatursensor gaukelt dem RT-DN eine konstante Temperatur von 12°C vor, so dass der RT-DN eigentlich immer heizen will
• hin und wieder (je nach Zeit- und Wertdifferenz) sende ich dem RT-DN eine neue valveMaxPos

Dieses Setup funktioniert seit Wochen absolut hervorragend, bis auf eine Sache:
Die Idee war eigentlich, dass der RT-DN nach wie vor verwendet werden kann, um Wochenprogramm, Modus und desired-temp einzustellen. Nur die Regelungslogik wird ihm abgenommen.
Das Problem ist nun, dass manuelle Änderungen der desired-temp (durch drehen am Stellrad) im auto-Modus scheinbar vergessen werden, sobald eine neue valveMaxPos gesendet wird. Er springt dann wieder zurück auf die Temperatur die nach TempList eingestellt ist. Im manual-Modus bleibt er hingegen auf der eingestellten Temperatur.

Ein ähnliches Verhalten wurde auch schon beim TC festgestellt: http://forum.fhem.de/index.php/topic,34250.msg266797.html#msg266797

Jetzt ist die Frage: Ist das ein Problem in FHEM (evt. sendet er mehr als er müsste, vielleicht kann man da was dran machen), oder ist das ein Firmware Problem im RT-DN? Dann würde ich überlegen mal den Hersteller anzuschreiben.

Ich bin dankbar für jeden Ratschlag!

Mein Post bezog sich in dem von dir genannten Thread auch auf den von dir genannten HM-CC-RT-DN.

Beim Bedienen des Homematic Konfigurator konnte ich ähnliches fest stellen, daher vermute ich ein Firmwareproblem/-feature.

Schreiben von valveMaxPos muss blockiert werden, solange die neue desired-temp nicht in den Heizplan (tempList) übernommen und per getConfig auch verifiziert wurde. Alles andere frustriert auf Dauer. Code etc. liegen rum, sind jedoch nicht Out-Of-The-Box und für mich als normalerweise Nicht-Perl-Schreiber in entsprechendem Zustand.

Ich mache übrigens ähnliches wie du ;) Eigentlich reicht es valveMaxPos so zu regulieren, dass measured max. 1 Grad über desired liegt da der HM-CC-RT-DN stets 1-2 Grad über desired heizen will. Aber das sind in diesem Thread andere Probleme.

Bist du Perlbewandert?

Gut zu wissen dass ich nicht der einzige mit diesem Problem bin. Und danke für das mitteilen deiner Erfahrungen!

Ich würde mich schon als einigermaßen perlbewandert bezeichnen, jedenfalls habe ich keine Probleme den existierenden Code zu verstehen und anzupassen ;)
Zu gegebener Zeit (wenn bei mir alles stabil läuft) werde ich auch noch einige Patches einreichen, z.B. für eine sinnvollere D-Wert Berechnung im PID20.

Die neue desired-temp in den Heizplan zu übernehmen wäre sicherlich eine Option, allerdings ist ja dann der Heizplan dauerhaft verstellt. Beziehungsweise muss später wieder zurückgesetzt werden.
Vielleicht könnte man auch einfach in den manual-Modus wechseln, sobald man erkennt dass die desired-temp verstellt wurde. Und zum nächsten programmierten Zeitpunkt im Heizplan stellt man wieder auf auto-Modus zurück.
Soweit ich bisher beobachten konnte bleibt die desired-temp im manual-Modus unverändert beim Setzen von valveMaxPos.

Wenn ich so drüber nachdenke gefällt mir die letzte Option eigentlich ganz gut, ich denke das werde ich demnächst mal testen :)

Zitat von: Trebxson am 11 März 2015, 22:52:53
Eigentlich reicht es valveMaxPos so zu regulieren, dass measured max. 1 Grad über desired liegt da der HM-CC-RT-DN stets 1-2 Grad über desired heizen will.

Stimmt, das könnte sogar reichen. Dann spart man sich den virtuellen Temperatursensor. Falls es nicht reicht kann man immernoch ein Offset im RT-DN einstellen, dann sollte es allemal reichen.
Aber wie du ja schon geschrieben hast ist das ja momentan garnicht das Problem ;)

> virtuellen Temperatursensor

Da spart man sich auch den Traffic.

Ja, manual geht auch. Die tempList gefiel mir besser, da es so folgende Fälle versorgt:

• am HM-CC-RT-DN auto + Temp einstellen -> Planmäßig neue Temperatur
  
• am HM-CC-RT-DN manu + Temp einstellen -> Ausnahmsweise andere Temperatur
  
  Sag bescheid, wenn ich Code aufhübschen und anhängen soll.
  
  PID20 hab ich mal gelesen, dachte der HM-CC-RT-DN hat selbst soetwas und kommt damit nicht zurecht. Ich werd mich da auch mal einlesen. Momentan habe ich ganz gute Werte. Was mir fehlt ist die Erfahrungen aus dem Vortag in die neuen Werte einzubeziehen. Da sind je Uhrzeit durchaus brauchbare parallelen.