Fenster<->Heizkörper mit Zeitverzug?

[curt]

Fenster auf -> Heizkörper aus. Das funktioniert bei mir ganz prima. Code unten.

Ein Sonderfall kommt wegen der aktuellen Brennstoffsituation (Flüssiggastank!) ins Auge, da funktioniert es nicht so einfach - bzw. ist diese einfache Lösung kontraproduktiv:
Von großen Wohnzimmer gibt es eine Tür zur Terrasse. Im Frühjahr wird die natürlich immerzu benutzt: Tür auf, Tür zu, teilweise im Sekundentakt. Das führt im bisherigen Modell dazu, dass bei jedem "Tür-zu" der Thermostat des Heizkörpers und damit die Heizung angestellt wird. Regelungstechnisch ist das die Katastrophe, da wird eher mehr als weniger verbraucht.

Ich stelle mir das anders vor: Tür geht auf -> Heizkörper aus. Tür geht zu -> Heizkörper bleibt aus, aber soll nach (sagen wir) 5 Minuten angehen. Jetzt kommts: Das soll aber nur gelten, wenn in diesen 5 Minuten die Tür immer geschlossen bleibt.

Wie würde man das denn elegant bewerkstelligen? Ich bitte um Hilfe und Hinweise.

Beispiel Fenster Kinderzimmer ("Kinderzimmer" ist der Melder des Fensters, Thermostat_Kinderzimmer ist selbsterklärend):

Code Auswählen Erweitern


define Kinderzimmer_doif DOIF ([Kinderzimmer:status] =~ "open") \
{fhem("set Thermostat_Kinderzimmer tmOff;;sleep 3;;set Thermostat_Kinderzimmer tmOff;;sleep 3;;get Thermostat_Kinderzimmer thermostatMode;;")} \
DOELSEIF ([Kinderzimmer:status] =~ "closed") \
{fhem("set Thermostat_Kinderzimmer tmHeating;;sleep 3;;set Thermostat_Kinderzimmer tmHeating;;sleep 3;;get Thermostat_Kinderzimmer thermostatMode;;")}
attr Kinderzimmer_doif room 97 Heizung


[Nobbynews]

Wie diese Verhalten bei einem DOIF eingestellt wird, kann ich nicht sagen.
Ich glaube auch nicht, dass in dieser Situation jedesmal der Brenner anspringt.
Zunächst werden die HK doch von der "Restwärme" im Heizkreislauf versorgt. Und eine kurzes Öffnen der Tür dürfte die Raumtemperatur nicht signifikant absenken. Erst wenn die Vorlauftemperatur zu niedrig wird, dürfte der Brenner anspringen.
Zudem verbrauchen die restlichen HK im Gebäude parallel zur Terrassentür auch noch Wärme. Dadurch wird der Brenner vermutlich hauptsächlich im Startverhalten beeinflusst.
Ätzend fänd' ich eher den Batterieverbrauch, insbesondere bei den ZWaves.

Das Problem habe ich bei meinen Fenstern jeweils mit einem watchdog Pärchen gelöst.

Terrassentür 30s offen:

Code Auswählen Erweitern

defmod wd_F_Wohnen_open watchdog Terrasse:on 00:00:30 Terrasse:off {\
fhem ("set cm fakeSC HK_Wohnen 1");;\
fhem ("set cm fakeSC HK_Essen 1");;\
my $TempKueche = ReadingsNum("wdT_Kueche","currValue",10)-3;;\
fhem ("set HK_Kueche desired-temp $TempKueche");;\
Log 1,"wd_F_Wohnen_open";;\
}
attr wd_F_Wohnen_open autoRestart 1
attr wd_F_Wohnen_open room 08_Heizung

Terrassentür 1min geschlossen:

Code Auswählen Erweitern

defmod wd_F_Wohnen_close watchdog Terrasse:off 00:01:00 Terrasse:on {\
fhem ("set cm fakeSC HK_Wohnen 0");;\
fhem ("set cm fakeSC HK_Essen 0");;\
fhem ("set HK_Kueche desired-temp ".ReadingsNum("wdT_Kueche","currValue",10));;\
Log 1, "wd_F_Wohnen_close";;\
}}
attr wd_F_Wohnen_close autoRestart 1
attr wd_F_Wohnen_close room 08_Heizung

Edit: Warum wird der HK jeweils 2* auf tmOff bzw. tmHeating gesetzt und dann thermostatMode abgefragt, aber nicht ausgewertet?

[curt]

Wie diese Verhalten bei einem DOIF eingestellt wird, kann ich nicht sagen.

Meine ganz thoretische Idee war, dass es ein dummy-Device gibt, was ab 300 Sekunden runterzählt - und fallweise wieder auf 300 Sekunden gestellt wird. Dabei weiß ich nicht einmal, ob es so eine Art Countdown gibt. Und wie man das dann real umsetzt.

Zunächst werden die HK doch von der "Restwärme" im Heizkreislauf versorgt. Und eine kurzes Öffnen der Tür dürfte die Raumtemperatur nicht signifikant absenken. Erst wenn die Vorlauftemperatur zu niedrig wird, dürfte der Brenner anspringen.

Genau das will ich im Grenzbereich vermeiden - dass wegen des Ping-Pongs der Brenner anspringt während draußen die Frühlingssonne scheint.

Ätzend fänd' ich eher den Batterieverbrauch, insbesondere bei den ZWaves.

Ich frage ja nun alle 30min die Stati ab. Und einmal am Tag werden alle Ventile aufgefahren und zugefahren (ich habe Thermostatventile mit nur 2mm Spiel und starker Federspannung). Je nach Ventil muss ich einmal in Jahr oder zweimal im Jahr wechseln, das scheint mir ok.

Das Problem habe ich bei meinen Fenstern jeweils mit einem watchdog Pärchen gelöst.

Das habe ich leider nicht verstanden, was passiert da? Zudem fehlt das sicher ein Stück Code, fakeSC ist ein Device? Oder wie muss ich das verstehen?

Edit: Warum wird der HK jeweils 2* auf tmOff bzw. tmHeating gesetzt und dann thermostatMode abgefragt, aber nicht ausgewertet?

Die Kommandos werden mit dem Abstand zweimal geschickt, da auch mal ein Kommando verloren gehen kann. Die Abfrage von thermostatMode dient dazu, dass das alles in den Readings auch vorhanden ist: Mein Suer-Frontend ist FTUI, da will ich den Stand der Dinge sehen.

[Beta-User]

Hmm, bin auch eher skeptisch, ob es sinnvoll ist, unmittelbar bei jeder Öffnung zu reagieren und habe dazu folgende Lösung im Einsatz - "leider" ist die CUL_HM-spezifisch, weil alle realen Kontakte eines Raumes/einer Gruppe von Heizkörpern jeweils zu einem "virtuellen" Device zusammengefasst werden. Den Teil müßte man auf ZWave anpassen. Was wie zusammengehört, ist über Attribute (userattr) festgelegt, und z.B. auch, wie lange gewartet werden soll, bis die "ist offen"-Reaktion erfolgen soll.

Ein notify für alle relevanten Fenster und Türen:

Code Auswählen Erweitern

defmod n_FK_TK_notify notify Fenster_.*:open|Fenster_.*:closed|Fenster_.*:tilted|Dachfenster_.*:open|Dachfenster_.*:closed|Terrassentuer_.Z:open|Terrassentuer_.Z:closed|Balkontuer:open|Balkontuer:closed|Haustuer:closed|Haustuer:open { myWinContactNotify ($NAME, $EVENT) }

Das ruft immer denselben Code auf, egal, ob geöffnet oder geschlossen gemeldet wird. Zuerst der "Initialcode":

Code Auswählen Erweitern

sub myWinContactNotify {  #three parameters, last (timeout) is optional
  my $window = shift;
  my $event  = shift // return;
  my $timeout = shift // 90;
  my @virtuals = devspec2array("TYPE=CUL_HM:FILTER=model=VIRTUAL:FILTER=myRealFK=.*$window.*");
  for my $virtual (@virtuals) {
    my $myreals = AttrVal($virtual,'myRealFK','');
    if ($event =~ /open|tilted/) {
      $timeout = AttrVal($virtual,'myTimeout',$timeout) if $timeout == 90;
      my $checktime = gettimeofday()+$timeout;
      InternalTimer($checktime,'myTimeoutWinContact',$virtual);   
    } else {
      my @wcs = split(',',$myreals);
      my $openwc = 0;
      for my $wc (@wcs) {
        $openwc++ if (ReadingsVal($wc,'state','closed') ne 'closed');
        last if $openwc;
      }
      CommandSet (undef,"$virtual geschlossen") if !$openwc;
    }
  }
  return;
}


Und dann der intern verzögert aufgerufene "ist noch offen?"-Code:

Code Auswählen Erweitern

sub myTimeoutWinContact {
  my $name = shift // return;
  return if !ReadingsVal('Heizperiode','state','off') eq 'on';
  my $myreals = AttrVal($name,'myRealFK','');
  my @wcs = split(',',$myreals);
  my $openwc = 0;
  for my $wc (@wcs) {
    $openwc++ if ReadingsVal($wc,'state','closed') ne 'closed';
    last if $openwc;
  }
  CommandSet (undef,"$name offen") if $openwc;
  return;
}


Wie man vielleicht sieht, wird dabei als erstes berücksichtigt, ob generell überhaupt geheizt wird (Heizperiode), sonst passiert in der Hinsicht gar nichts...

Muss mal wieder meine Graphen anschauen, aber soweit ich mich entsinne führt die Konstruktion nicht dazu, dass jeweils erst mal das Ventil geöffnet wird, wenn irgendwo kurzzeitig Frischluft kommt. Das scheinen die Homematics bis zu einem gewissen Grad auch erst mal zu ignorieren.

(Mein ZWave-Thermostat ist in einem Raum verbaut, der keinen Fensterkontakt hat/braucht.)

[Nobbynews]

Ich frage ja nun alle 30min die Stati ab.

Ne ne, ich meinte den Batterieverbrauch bei jedem Öffnen und Schließen der Tür im Sekundentakt.

Das habe ich leider nicht verstanden, was passiert da? Zudem fehlt das sicher ein Stück Code, fakeSC ist ein Device? Oder wie muss ich das verstehen?

Ok, da habe ich mich vielleicht zu oberflächlich ausgedrückt.
Das heißt nicht anderes als:
Tür wird geöffnet und ist nach 30s nicht wieder geschlossen -> HK runter
Tür wird geschlossen und wurde 1m nicht geöffnet -> HK hoch

fakeSC ist ein virtuelles device und dient dazu, einem MAX! Thermostaten einen nicht MAX! Fensterkontakt unterzujubeln.

Hier mal die entsprechenden Beispiele für einen ZWave

Code Auswählen Erweitern

defmod wd_F_Kueche_open watchdog Fenster_Kueche:on 00:00:10 Fenster_Kueche:off {\
fhem ("set HK_Kueche tmOff");;\
Log 1,"wd Fenster_Kueche open";;\
}

Code Auswählen Erweitern

defmod wd_F_Kueche_close watchdog Fenster_Kueche:off 00:01:00 Fenster_Kueche:on {\
fhem ("set HK_Kueche tmHeating");; \
Log 1,"wd Fenster_Kueche close";;\
}

[Nobbynews]

Hmm, bin auch eher skeptisch, ob es sinnvoll ist, unmittelbar bei jeder Öffnung zu reagieren

Das ist mit Sicherheit auch schon fast eine philosophische Frage und muss jeder für sich selbst beantworten.
Meine 3 Frauen vergessen halt öfter mal das Fenster wieder zu schließen......
Daher habe ich bei den überwachten Türen ja auch größere Zeitintervalle definiert.
Terrasse 30s (sollte für rein/raus) dicke reichen und für die Haustür sogar 45s wg. Post aus Briefkasten holen, mal kurz was ins Auto bringen etc.
Die 10s bei den Fenstern habe ich eingentlich nur gewählt um beim Wechsel von offen auf gekippt keine Reaktion auszulösen.
Die Heizperiode überprüfe ich nicht jedesmal, sondern steuere das über einen dummy mit zugehörigem notify. Damit werden die entsprechenden watchdogs auf active/inactive geschaltet. Dafür heißen die ja auch alle einheitlich wd_F_*. Eine Zeile und alles ist erledigt.

[Beta-User]

Das ist mit Sicherheit auch schon fast eine philosophische Frage und muss jeder für sich selbst beantworten.

...sicher...

Meine 3 Frauen vergessen halt öfter mal das Fenster wieder zu schließen......

Allerdings scheine ich mich missverständlich ausgedrückt zu haben: Mein notify reagiert auf jede Fenster/Tür-Meldung von einem echten Kontakt. Es wird dann nur geschaut, ob es einen zugehörigen "virtuellen" gibt, und wenn ja (und "offen"), wird ein Timer gestartet.

Meine ganz thoretische Idee war, dass es ein dummy-Device gibt, was ab 300 Sekunden runterzählt - und fallweise wieder auf 300 Sekunden gestellt wird. Dabei weiß ich nicht einmal, ob es so eine Art Countdown gibt. Und wie man das dann real umsetzt.

Ziemlich genau diesen Mechansimus bildet (u.A.) ein "watchdog" ab. Man kann sowas auch anders lösen, eben mit einem InternalTimer()-Aufruf in Perl, einem FHEM-sleep, einem DOIF-wait oder z.B. auch einem "monitoring"-Device (letzteres erzeugt dann aber nur Events, auf die man wieder reagieren könnte).

Mein eher komplexer Code ist vor dem Hintergrund entstanden, dass fast in allen Räumen mehrere Fenster(-kontakte) vorhanden sind, und mit einem watchdog kann man sowas mAn. eher schlecht abbilden, weil der afaik in der 2. (späteren/aufhebenden) Bedingung nicht ohne weiteres "sind alle zu?" abfragen kann.

Daher habe ich bei den überwachten Türen ja auch größere Zeitintervalle definiert.

Die jeweiligen Zeitinervalle sind bei mir (so nicht auf "default" 90 Sekunden) per Attribut (am virtuellen Kontakt) konfigurierbar.

Die 10s bei den Fenstern habe ich eingentlich nur gewählt um beim Wechsel von offen auf gekippt keine Reaktion auszulösen.

Bei den Homematic-Drehgriff-Sensoren läßt sich konfigurieren, dass erst kurz gewartet wird, ob nicht weitergedreht wird. So ist das hier bei mir gelöst. (Die Dinger sind nur leider vergesslich, aber das ist ein anderes Thema).

Die Heizperiode überprüfe ich nicht jedesmal, sondern steuere das über einen dummy mit zugehörigem notify. Damit werden die entsprechenden watchdogs auf active/inactive geschaltet. Dafür heißen die ja auch alle einheitlich wd_F_*. Eine Zeile und alles ist erledigt.

Da diese Prüfung vergleichsweise selten stattfindet, fällt das nicht weiter ins Gewicht. Ist mir persönlich lieber wie "Aktivierungs-Orgien" (ich mag das rote Fragezeichen einfach nicht...)

Die Kommandos werden mit dem Abstand zweimal geschickt, da auch mal ein Kommando verloren gehen kann.

Soweit ich das mit meinem einen ZWave-Thermostaten beurteilen kann, kommt das Verlorengehen praktisch nicht vor. Häufiger sind aber Hinweise zu finden, dass es über 15 Sekunden gedauert hat, bis tatsächlich zugestellt werden konnte. Das ist etwas unschön... Ist das bei deiner Konstruktion besser?

Das Abfragen könnte man sich vermutlich mit "setReadingOnAck" (oder so) sparen (obwohl damit "nur" gesagt ist, dass das Kommando angekommen ist, nicht, ob es auch ausführbar war ("setze die Solltemperatur auf 200 Grad" würde auch ein Ack erhalten).

Tendenziell würde ich für ZWave vermutlich einen WeekdayTimer dazwischenklemmen und in dem die "echten Fensterkontakte" hinterlegen (aber mit dem dafür dort bereits vorgesehenen Attribut). Muss mal schauen, ob ich dazu komme, den Code entsprechend zu erweitern.

[Nobbynews]

Da diese Prüfung vergleichsweise selten stattfindet, fällt das nicht weiter ins Gewicht. Ist mir persönlich lieber wie "Aktivierungs-Orgien" (ich mag das rote Fragezeichen einfach nicht...)

Das Umschalten über set active/inactive erzeugt bei watchdog kein rotes Fragezeichen.

[Beta-User]

Das Umschalten über set active/inactive erzeugt bei watchdog kein rotes Fragezeichen.

Ah, ok.

Wie gesagt: watchdog scheint mir unabhängig von allem anderen für meine tatsächlichen Gegebenheiten nicht das passende Tool zu sein, und wenn der watchdog dann nur "per Reading" deaktiviert wird, ist die erzeugte Last dann mit "meiner" Lösung effektiv ähnlich hoch (es wird bei watchdog dann auch "nur zusätzich" auf einen Reading-Wert geprüft, dann halt am watchdog selbst, siehe aktuell Zeile 190 im watchdog-Code).

[rudolfkoenig]

Waere Folgendes eine Moeglichkeit oder uebersehe ich etwas?

Code Auswählen Erweitern

define hz_wd watchdog tuer:open tuer:closed sleep 300 hz_sleep;; set heizung an
attr hz_wd autoRestart 1
define hz_ntfy tuer:open cancel hz_sleep;; set heizung aus


[juemuc]

Hallo zusammen,
das Problem sollte recht einfach mit dem "wait-Attribut" im "doif" zu lösen sein.
Viele Grüße
Jürgen

[Thyraz]

Denke auch. Dazu muss am DOIF außer setzen des Wait-Attributs wahrscheinlich gar nichts geändert werden.
Wird ein anderer Pfad im DOIF wahr, während ein Timer läuft wird dieser abgebrochen.

[curt]

Denke auch. Dazu muss am DOIF außer setzen des Wait-Attributs wahrscheinlich gar nichts geändert werden.
Wird ein anderer Pfad im DOIF wahr, während ein Timer läuft wird dieser abgebrochen.

Ich muss da nachfragen, vielleicht habe ich es noch nicht richtig verstanden:
Das attr wait (bei dem doif im ersten Beitrag des Threads) habe ich gefunden, da habe ich einfach mal 120 reingeschrieben. Aber reicht das so? Da steht ja, dass man mehrere Werte (für jede Teildirektive) angeben kann - oder muss?

Und wie kann ich das eigentlich prüfen, kann ich irgendwie sehen, ob das funktioniert? verbose auf 5 oder so irgendwie?

P.S: Danke an alle, die geantwortet haben.

Nachtrag, zu beantworten:

Soweit ich das mit meinem einen ZWave-Thermostaten beurteilen kann, kommt das Verlorengehen praktisch nicht vor. Häufiger sind aber Hinweise zu finden, dass es über 15 Sekunden gedauert hat, bis tatsächlich zugestellt werden konnte. Das ist etwas unschön... Ist das bei deiner Konstruktion besser?

Der Hinweis, alles zweimal zu senden, kam aus der Ecke von Leuten, die ZWave-Thermostate haben und FTUI als Frontend nutzen. Ich habe acht Thermostate und so einiges andere ZWave-Gerödel. Lange Übertragungszeiten (15sec) habe ich nicht. Aber tatsächlich geht ab und an ein Telegramm verloren, das ist zu beobachten. Ich führe das auf meine örtliche Situation zurück, hier funkt alles und jedes und jeder Nachbar auch noch.

Irgendwo war noch die Frage nach Schaltverzögerung ZWave-Thermostat vs. HomeDings. Also rein gefühlt ist die Schaltverzögerung bei 2..3sec. Das ist zu wenig für das Problem "Tür auf - Tür zu".

[Beta-User]

Das attr wait (bei dem doif im ersten Beitrag des Threads) habe ich gefunden, da habe ich einfach mal 120 reingeschrieben. Aber reicht das so? Da steht ja, dass man mehrere Werte (für jede Teildirektive) angeben kann - oder muss?

Zu DOIF kann ich wenig sagen, aber die de-Doku ist sehr umfassend, da sollte was dazu zu finden sein (bei der Attributbeschreibung). Nach meinem "aus dem Kopf"-Verständnis kann man "Teildirektiven" bilden durch entsprechende Klammersetzung, aber man muss das nicht.

Und wie kann ich das eigentlich prüfen, kann ich irgendwie sehen, ob das funktioniert? verbose auf 5 oder so irgendwie?

Es sollte beim Zieldevice ja was stattfinden, das auch per Event-Monitor zu sehen sein sollte.

Nachtrag, zu beantworten:Der Hinweis, alles zweimal zu senden, kam aus der Ecke von Leuten, die ZWave-Thermostate haben und FTUI als Frontend nutzen.

Schon. Die "frag es sicherheitshalber nochmal ab"-Diskussion kenne ich auch, bin aber unschlüssig, ob die (in dem Zuge entstandene) setReadingOnAck-Option nicht zumindest die Rückfrage erübrigen sollte.

Ich führe das auf meine örtliche Situation zurück, hier funkt alles und jedes und jeder Nachbar auch noch.

Verlorene Messages in Richtung auf Jalousie-Aktoren kenne ich auch, allerdings nur, wenn ich die Befehle nicht gg. dem per Homematic angefunkten Teil verzögere. Ansonsten scheint (!) das gut zu laufen. Kann also durchaus sein, dass "stark befunkte Bereiche" einer gesonderten Behandlung bedürfen. Bin aber skeptisch, inwiefern "noch mehr Funk" hilfreich ist (oder kontraproduktiv).

Irgendwo war noch die Frage nach Schaltverzögerung ZWave-Thermostat vs. HomeDings. Also rein gefühlt ist die Schaltverzögerung bei 2..3sec. Das ist zu wenig für das Problem "Tür auf - Tür zu".

Bei den Homematics läßt sich das einstellen, allerdings bin ich auch in einem Bereich, der kurzes Tür auf/zu trotzdem mit zwei Events quittiert. Macht aber nichts, weil mein "Verzögerungscode" eh' erst später die dann geltenden Rahmenbedingungen checkt (afaik macht das DOIT mit wait ähnlich).

Tendenziell würde ich für ZWave vermutlich einen WeekdayTimer dazwischenklemmen und in dem die "echten Fensterkontakte" hinterlegen (aber mit dem dafür dort bereits vorgesehenen Attribut). Muss mal schauen, ob ich dazu komme, den Code entsprechend zu erweitern.

Habe mal was reingeknödelt, Ergebnis siehe https://forum.fhem.de/index.php/topic,97430.msg1220426.html#msg1220426.

[juemuc]

Hallo Curt,

die Doku sollte Deinen Fragen recht gut beantworten.
Du musst den Parameter natürlich für den betroffenen DOIF-Zweig setzen. Prüfen kannst Du es dann anhand der Readings.

Viele Grüße
Jürgen

PS.: Es gibt auch einige Beispiele für die Überwachung der Waschmaschiene, wo der Schwellenwert x Minuten unter einem definierten Wert sein muss, bevor die Ausgabe "Waschmaschine ist fertig" kommt.