Funk-Heizkörperthermostat - Verzögertes Einstellen der Fenster-Auf-Temperatur möglich?

[mademyday]

Hallo!

Ich habe diverse Funk-Heizkörperthermostate HM-CC-RT-DN, die mit den jeweiligen zugehörigen Funk-Tür-/ Fensterkontakten HM-Sec-SC-2 direkt verknüpft sind, so dass Lüften (Fenster auf) zum Absenken der Soll-Temp. bei den Thermostaten führt - alles wie es soll.

Nur ist ein Fenster kein Fenster sondern eine Terrassentür, die man zum Rein-Raus-Gehen öffnet und einige Sekunden später (auch mal ~ 20 Sek., bis man draußen alles abgestellt und die Hände frei hat) wieder schließt - was leider auch zu einer sofortigen Absenkung (Ventilstellung wird hörbar angepasst) - und anschließend leicht verzögerten wieder Anhebung der Soll-Temp. führt.

Kann man das irgendwie verhindern, gibt es eine Einstellung, dass das TFK-Öffnen nicht sofort zum Temp.absenken führt?

Die TFK-Zustandsmeldung solange verzögern dass ein Türauf und wieder zu überhaupt nicht gemeldet wird wäre keine Lösung, da der Sensor auch zur Einbruchsmeldung dienen soll.

Eine Idee wäre, die Direktverküpfung zu löschen und ein HM-Programm mit der Funktion nachzubauen, aber geht das auch durch irgendeine Konfigurationseinstellung einfacher?

[Bratmaxe]

Ist mir nicht bekannt, nur das generelle Verzögern kannst du einstellen, was dann natürlich auch für die Alarmmeldung gelten würde.

[Xel66]

Ich habe eine Systemvariable vom Typ Zahl angelegt, an das Thermostat gebunden (damit es dort im WebUI mit dargestellt wird) und speichere in dieser die aktuelle Solltemperatur beim Öffnen der Tür. Dann senke ich mit einer Verzögerung von einer Minute die Solltemperatur auf 12°C ab. Beim Schließen der Tür wird dann wieder die vorher gespeicherte Solltemperatur gesetzt. Ich benutze dieses an der Haustür um die Heizung im Flur verzögert abzusenken. Mit zusätzlichen Abfragen könnte man das noch verfeinern, um nicht unnötigerweise die Solltemperatur zu setzen. Aber ich habe keine DutyCycle-Probleme (einstellig), darum lasse ich es so.

Gruß Xel66

[schnurzel59]

Hallo mademyday,
ich weiß ja nicht, was eine Tür-offen-Meldung für eine Alarmaktivität veranlasst, aber generell kann ja der TFK nicht zwischen gut und böse unterscheiden. Das heißt, wenn bei Anwesenheit der Alarm ständig scharf wäre, müsste das Signal für das erlaubte öffnen der Tür verzögert werden, damit Du raus kannst. Dann macht das Heizkörperventil auch nicht sofort zu. Allerdings bemerkst Du natürlich auch kein unbefugtes Eintreten. Bei Sofortauslösung dagegen gibt es Alarm wenn Du raus gehst, Heizung wird sofort abgedreht, aber dafür wird ein Einbrecher sofort bemerkt.
Folglich muß bei Anwesenheit der Alarm abgeschaltet sein, somit stört es auch nicht, wenn durch die Verzögerung keine sofortige Alarmmeldung erfolgt. Sonst könnte ja auch Niemand ein Fenster öffnen, ohne Alarm auszulösen. Bei Abwesenheit brauchst Du keine Verzögerung. Tür kann ja nur vom Einbrecher geöffnet worden sein. Meiner Meinung nach sollte keine Direktverknüpfung zum Thermostat bestehen und entsprechende Aktivitäten von der Anwesenheit bzw. der Scharfschaltung des Alarmes abhängig gemacht werden. Für das zwischenspeichern und wieder einstellen der Solltemperatur hat ja Xel66 bereits eine der Möglichkeiten beschrieben. Ich gehe mal davon aus, das die Terrassentür von außen keine Klinke hat. Oder?
Tür auf und wieder zu macht, egal wie lange, eben bei Dir und beim Einbrecher Alarm oder bei beiden nicht. Kommt also auf die jeweiligen Gegebenheiten an.
Gruß
Martin

[mademyday]

danke für die schnellen Antworten, es sieht wohl aus wie befürchtet: muss man wohl in einem Programm nachbauen

Ich habe eine Systemvariable vom Typ Zahl angelegt, an das Thermostat gebunden (damit es dort im WebUI mit dargestellt wird)

ich glaub daran scheitere ich gerade, also nicht am Anlegen sondern am "an Thermostat gebunden" - kann mir da jemand auf die Sprünge helfen?

Deswegen fehlt mir wohl an dieser Stelle die Auswahlmöglichkeit der Variable?!

[Xel66]

Beim Anlegen der Systemvariable hast Du rechts eine Auswahloption mit Kanal. Dort kannst Du dann das betreffende Thermostat im Dialog auswählen. Zukünftig wird die diese Systemvariable samt Inhalt auch zusammen mit dem Gerät in der Bedienmaske der WebUI dargestellt. Auch die Auswahl der Systemvariable für die Einbindung in Programme erfolgt nicht mehr über "Systemzustand" sondern über den Gerätedialog. Erst wird in Programmen das Gerät und dann die Systemvariable ausgewählt. Klingt kompliziert, ist es aber nicht mehr, wenn man es ein Mal gemacht hat. Die Auswahl erfolgt dann genau so, als ob Du die Solltemperatur oder die Isttemperatur eines Thermostaten als Trigger oder als Ziel für ein Programm nutzen wolltest. In dem Dropdownfeld wird Dir die Systemvariable mit angeboten. Über "Systemzustand" ist sie nicht mehr auswählbar.

Für das Stetzen z.B. der Systemvariable mit der Solltemperatur wählst Du als Ziel im DANN zuerst, das Thermostat, dann die Systemvaiable an. Dahinter ist noch ein "weißes Blatt". Dort klickst Du drauf, wählst Geräte und dann das gleiche Thermostat und im folgenden Dropdown dann die Solltemperatur. Schon wird beim nächsten Ausführen des DANN die Solltemperatur in die gebundene Systemvariable geschrieben. Ganz ohne Script, nur unter Benutzung der Möglichkeiten der WebUI. Beim Setzen der Solltemperatur für das Schließen des Fensters geht es genau andersherum. Thermostat auswählen, Solltemperatur auswählen, weißes Blatt, Gerät/Thermostat wählen, Systemvariable wählen, mit OK schließen.

Gruß Xel66

[Gluehwurm]

Im WebUI-Handbuch (Systemkonfiguration -> Systemvariable) wird erklärt, was die Einstellung in der Spalte "Kanalzuordnung" bewirkt/möglich macht.

Gruß
Bruno

[mademyday]

<-- s. Bild dort

ich glaub ich hab wieder ein Verständnisproblem mit der HM-Logik: wie kann das Programm aus dem Screenshot wie gewüscht funktionieren und stellt die Soll-Temperatur nur dann auf 12Grad runter, wenn die Tür >= 1 Min. auf steht?

Wenn die Tür aufgeht wird das Programm ausgelöst. Angenommen die restlichen wenn-Bedingungen treffen auch zu, dann wird dieser Wenn-Aktivitätszweig ausgelöst, d.h. sofort die aktuellen Werte gesichert und ein "Verzögerungs-Timer" gestartet (1 Minute) - soweit so klar

Wenn nun die Tür (gleich) wieder geschlossen wird (und wieder der Rest an Bedingungen passt) wird der "sonst, wenn"-Zweig ausgeführt - ABER: der tickende Verzögerungstimer der vorherigen Wenn-Aktivität doch nicht abgebrochen - oder? Das (das Abbrechen des Verzögerungstimers) passierst doch nur, wenn genau die (wenn-)Aktivitäten, die den Timer urspünglich gestartet hatten, erneut gestartet werden soll und nicht Aktivitäten aus einem anderen/beliebigen Aktivitäts-Programmzweig, oder nicht?

Lt. WebUi-Handbuch "Ist die Box checked, werden alle noch zur Ausführung anstehenden Aktivitäten für alle im Feld „Aktivität: Dann...“ angegebenen Kanäle und Systemvariablen gelöscht." (Abschnitt 20.2.1.3, Aktivitätsfeld „Aktivität: Dann...“ bearbeiten)

[Gluehwurm]

... Lt. WebUi-Handbuch "Ist die Box checked, werden alle noch zur Ausführung anstehenden Aktivitäten für alle im Feld „Aktivität: Dann...“ angegebenen Kanäle und Systemvariablen gelöscht." (Abschnitt 20.2.1.3, Aktivitätsfeld „Aktivität: Dann...“ bearbeiten) ...

Nur die Aktivitäten des gleichen Datenpunkts, wenn Du also der Solltemperatur nicht "sagst", wonach sie sich bei SonstWenn richten soll, bleibt das bei den 12°. Schaltet (im Auto-Modus) dann erst beim nächsten Schaltpunkt um.

Solltemperatur ist an dieser Stelle vermutlich eh falsch.

[mademyday]

also ist das so gemeint?

..., werden (nur!) für die Kanäle und Systemvariablen, die im Feld „Aktivität: Dann...“ angegebenen sind (und somit durch diese Aktivität verändert werden sollen) alle noch zur Ausführung anstehenden Aktivitäten/Verzögerungen gelöscht, egal in welchem Aktivitäts-Zweig (dann/sonst, wenn/sonst) sie ursprünglich gestartet wurden