HmIP-eTRV-B Thermostat Wochenprogramm ignoriert Programme

[Germa]

Die Direktverknüfung des Fenster-Drehgriffsensors (HMIP-SRH) mit dem Heizungsthermostat (HMIP-e-TRV-B) ist eine feine Sache. Man öffnet das Fenster, die Heizung geht aus - und umgekehrt. Kombiniert mit den Wochenprogrammen des Thermostats hat man so die meisten Anwendungsfälle abgedeckt.

Für meinen speziellen Fall bekomme ich es aber nicht hin:
Wir schlafen bei gekipptem Fenster - fast immer. Heizung bleibt aus. Automatik-Wochenprogramm 2 bei Anwesenheit und Außentemperatur unter 18 °C startet dann bei geschossenem Fenster um 9 Uhr mit Heizen. So weit so gut ...
Nun kommt man spät nach hause und möchte bis 10 Uhr schlafen. Draußen ist es ab 7 Uhr laut, also steht man auf, schließt das Fenster und legt sich wieder hin. Schön leise, schön kühl. Da das Fenster geschlossen ist, fängt es ab 9 Uhr an, warm zu werden. Blöd.

Folgende Idee also: Nachts wird über einen Tastendruck die Nachtruhe aktiviert, macht die Lichter alle aus usw. und setzt einen Hilfszähler (Zaehler_Schlafz) auf 0. Das Fenster wird gekippt, man geht schlafen. NUR, wenn das Fenster ganz auf war, also Lüften nach dem Schlafen (Zaehler-Schlafz = 1) UND wird dann geschlossen, wird Zaehler-Schlafz = 2 gesetzt. Also, wenn der Zähler auf 2 steht, wird das Thermostat auf Auto-Modus gestellt und folgt dann dem Wochenprogramm. Wenn der Zähler <2 steht, ist das Thermostat im manuellen Modus.

und dies wird dann im Programm benutzt:

Klappt nicht. Mal geht es, mal fängt bei Zähler = 0 und 9 Uhr das Thermostat an zu heizen. Hab schon alles mögliche getestet.
Hat jemand ne Idee oder einen Fehler entdeckt?

Der letzte Versuch war, zusätzlich zum Ändern des "Modus Auto/Manu/Urlaub" auf 1 auch den "Modus für Solltemperatur" auf 1 zu stellen. Wo wäre denn da der Unterschied im Verhalten? Insbesondere die Aussage dazu hier viewtopic.php?f=58&t=70688:

== DP "CONTROL_MODE" | write | hiermit muss der Modus gesetzt werden

<Modus für Solltemperatur>

== DP "SET_POINT_MODE" | read, write, event | hiermit kann der aktive Modus ausgelesen werden

Obwohl beim DP "SET_POINT_MODE" "write" in der Doku angegeben ist habe ich es noch nie geschafft da was reinzuschreiben.
Entweder ist das buggy oder ich mache was falsch. M.E. sollte <Modus für Solltemperatur> nicht im DANN auftauchen/benutzt werden.

Grüße, Baxxy
[/quote]

konnte ich nicht so richtig nachvollziehen

[Xel66]

Mach doch einfach ein Programm, welches durch das Schließen des Fensters in dem Zeitfenster von 7 bis 10 Uhr (nur prüfen) auf manuell stellt und ggf. nach dem Aufstehen (ggf. verzögerte Ausführung) wieder auf Automatik. Das Ganze kann man noch mit Zusatzbedingungen (beim Schließen war Automatikbetrieb aktiviert) garnieren, um die Steuerung für den Zeitraum außerhalb der Heizperiode zu deaktivieren. Das mit Deinem Zähler habe ich nicht so nachvollziehen können.

Gruß Xel66

[Germa]

ja, so meine ich, habe ich das gemacht. Der Zähler sorgt einfach nur dafür, dass, wenn das Fenster ganz offen war, bevor es geschlossen wurde, dann fang an zu heizen

[Baxxy]

Modus AUTO/MANU/URLAUB ist schon die richtige Option und sollte funktionieren.
Bist du sicher das dein Programm jeweils im korrekten DANN landet?
Bau doch mal in jedes DANN eine SysVar oder Alchy's "Auslöserscript" zwecks Protokollierung ein.

[Germa]

o.k., habe Alchys Script mal eingebaut und auch die Zähler-Var mal protokolliert gestellt.
Werde berichten.

[Xel66]

Ich würde die Griffstellungen in einer (3-fach)Mehrfachauswahl mit einer Verzögerung von z.B. einer Minute nachziehen. So kann man auf eine bestimmte Griffstellung triggern (z.B. Fenster geschlossen) und in der gleichen Bedingung auf den letzten gespeicherten Wert (z.B. vorher gekippt) prüfen und daraus dementsprechende Aktionen ableiten. Durch die Verzögerung werden "Zwischenstellungen" übersprungen (z.B. beim Wechsel von "gekippt" auf "geschlossen" wird "offen" übersprungen). Ist vielleicht zuverlässiger, als drei Stellungen mit zwei Integerzahlen abzubilden. Kann man auch so machen, allerdings sollte man dann alle drei möglichen Zustände abbilden und auch mit Verzögerungen arbeiten.

Nebenbei ist Dein Programmkonstrukt "ungünstig". Du Triggerst u.a. auf Komplementärzustände (kleiner/gleich 18°C und größer 18°C bei der Außentemperatur) in unterschiedlichen WENN/SONST WENN. Somit dürfte sich das Programm verhalten wie "bei Aktualisierung" und ständig bei jeder Übermittlung eines der verknüpften triggernden Sensoren eine Bedingungsprüfung durchführen. Ergibt dann eine Prüfung ein WAHR, wird auch noch das Thermostat angefunkt. Meines Erachtens ein lustiger Duty Cycle-Treiber.

Gruß Xel66

[Germa]

Ich würde die Griffstellungen in einer (3-fach)Mehrfachauswahl mit einer Verzögerung von z.B. einer Minute nachziehen. So kann man auf eine bestimmte Griffstellung triggern (z.B. Fenster geschlossen) und in der gleichen Bedingung auf den letzten gespeicherten Wert (z.B. vorher gekippt) prüfen und daraus dementsprechende Aktionen ableiten. Durch die Verzögerung werden "Zwischenstellungen" übersprungen (z.B. beim Wechsel von "gekippt" auf "geschlossen" wird "offen" übersprungen). Ist vielleicht zuverlässiger, als drei Stellungen mit zwei Integerzahlen abzubilden. Kann man auch so machen, allerdings sollte man dann alle drei möglichen Zustände abbilden und auch mit Verzögerungen arbeiten.

Das mit dem "Überspringen des offen" ist auch einer meiner Verdachtsfälle. Muss ich mal in mich gehen, wie ich das hinbekomme. Erstmal sehen, was die Tests mit Alchys DANN-Script ergeben. Die Verzögerungen minutenweise habe ich ja eigentlich schon drin (habe ich nur auf 1 - 2 Sekunden verkürzt, damit die Fehleranlanalyse nicht so ewig dauert.)

Nebenbei ist Dein Programmkonstrukt "ungünstig". Du Triggerst u.a. auf Komplementärzustände (kleiner/gleich 18°C und größer 18°C bei der Außentemperatur) in unterschiedlichen WENN/SONST WENN. Somit dürfte sich das Programm verhalten wie "bei Aktualisierung" und ständig bei jeder Übermittlung eines der verknüpften triggernden Sensoren eine Bedingungsprüfung durchführen. Ergibt dann eine Prüfung ein WAHR, wird auch noch das Thermostat angefunkt. Meines Erachtens ein lustiger Duty Cycle-Treiber.

Gruß Xel66

Du meinst, statt der letzten Bedingung sollte ich besser nur ein "SONST" benutzen? Hatte ich mal so, dann aber mehrfach gelesen, dass man SONST so gut wie möglich vermeiden soll.

Wie wäre es denn besser umzusetzen? Die Idee ist ja eigentlich simpel:
- Wenn ich weg bin und es ist kalt, mach Wochenprogramm 1
- Wenn ich da bin und es ist kalt, mach Wochenprogramm 2
- wenn es warm ist oder Zähler = 0, mach Manuellen Modus mit 6 Grad

[Xel66]

Du meinst, statt der letzten Bedingung sollte ich besser nur ein "SONST" benutzen?

Nein, ich meinte genau das, was ich geschrieben habe. Du benutzt ein und den gleichen Tiggerwert mit komplementären Zuständen innerhalb eines Programms. Die Prüfung auf "bei Änderung" scheint aber entgegen den Ausführungen im Handbuch ein Bestandteil des Programms selbst zu sein und nicht vorher als Trigger geprüft zu werden. Durch die mehrfache und gegensätzliche Nutzung wird die Bedingungsprüfung bei jeder Übermittlung eines Wertes getriggert und festgestellt, ob und in welche Richtung sich der Wert über eine definierte Grenze geändert hat. Das Programm verhält sich eben wie "bei Aktualisierung".

Und ja, auch hier wäre ein SONST kontraproduktiv, denn im Moment ist bei jeder Übermittlung eines Messwertes (Außen- oder Raumtemperatur) eine der Bedingungen WAHR und eines der DANN wird ausgeführt (passiert statistisch zwei mal pro drei Minuten). Ein SONST würde hier an der Stelle nicht viel ändern, würde aber auch ggf. ausgeführt, wenn keine der vorher in dem WENN oder SONST WENNs definierten Bedingungskombinationen bei der Prüfung ein WAHR ergibt. Gegensätzliche Trigger und gegensätzliche Aktionen werden besser in separaten Programmen angelegt, besonders, wenn in den Aktionen gefunkt wird. Das hat was damit zu tun, wie die CCU Programme triggert und abarbeitet.

- wenn es warm ist oder Zähler = 0, mach Manuellen Modus mit 6 Grad

Es gibt in Deinen Screenshots aber keine Funktion, die den Zähler auf 0 stellt (nur 1 oder 2). Es sei denn, Du verheimlichts uns was. Die Minute war nur ein Beispiel und sollte eine laaaangsaaaame Betätigung des Drehgriffes überbrücken. Außerdem muss diese Funktion nur längerfristige Status abbilden.

Gruß Xel66

[Germa]

Gegensätzliche Trigger und gegensätzliche Aktionen werden besser in separaten Programmen angelegt, besonders, wenn in den Aktionen gefunkt wird. Das hat was damit zu tun, wie die CCU Programme triggert und abarbeitet.

o.k., mache ich. Man versucht ja immer, das Ganze so kompakt wie möglich zu halten, ansonsten hat man plötzlich 300 statt 150 Programmen und das macht bei der Übersichtlichkeit schon einen Unterschied, aber so, wie Du das erklärst, klingt es logisch!

Es sei denn, Du verheimlichts uns was.

Nee, nix verheimlicht
Im ersten Post hatte ich geschrieben "Nachts wird über einen Tastendruck die Nachtruhe aktiviert, macht die Lichter alle aus usw. und setzt einen Hilfszähler (Zaehler_Schlafz) auf 0."

[Germa]

Genauere Tests heute haben schon beim Programm "Zaehler Schlafz setzen" Fehler gezeigt. Fenster kurz aufgemacht mitten am Tag (Zähler wird von 2 auf 1 gesetzt), 5 Sekunden später Fenster wieder zu, Zähler bleibt auf 1 ......

Bin ich da wieder bei meinem geliebten Thema "unerklärliche Verzögerungen" gelandet ?! .....
viewtopic.php?f=19&t=69590&start=60#p699796