Funk-Heizkörperthermostat HM-CC-RT-DN Verzögerung für WindowRec

[AndyMu]

Hallo *,

ich habe an der Terrassentür einen HM-SEC-RHS installiert, der gepeert ist auf das WindowRec eines Thermostaten.
Jetzt machen wir öfter die Tür nur kurz auf, um die Katze rein- und rauszulassen.

Ich habe noch keine Möglichkeit gefunden, an einem der beiden Systeme eine Verzögerung zu programmieren, um die Umschaltung auf die Absenktemperatur um x Sekunden zu verzögern.
Gibt es da einen Parameter, oder muss ich mir was über notify/doif basteln?

Danke!

[Beta-User]

Am Fensterkontakt sollte es ein Register geben für das Verzögern der Message. MsgDelay? oder so ähnlich. Da gehört ein Wert in sec rein.

[AndyMu]

Besten Dank, aber verzögert dass dann nicht auch die Statusmeldung an FHEM?
Eine Verzögerung per Peer/Kanal kann ich leider nicht sehen.

[Beta-User]

Ja, es gilt alles oder nichts...
Dann bleibt nur der Weg über FHEM, wenn es anders sein soll.

[t1me2die]

Da würde ich mich glatt mal mit einklinken, wie schaut der "set" Befehl dann genau aus um einen Fensterkontakt um Beispielsweise um 30Sekunden zu verzögern?

Gruß
Mathze

[MadMax-FHEM]

Da würde ich mich glatt mal mit einklinken, wie schaut der "set" Befehl dann genau aus um einen Fensterkontakt um Beispielsweise um 30Sekunden zu verzögern?

Gruß
Mathze

Code Auswählen Erweitern

set DeviceName regSet eventDlyTime 30

Sollte das machen...

Gruß, Joachim

[dkreutz]

Da würde ich mich glatt mal mit einklinken, wie schaut der "set" Befehl dann genau aus um einen Fensterkontakt um Beispielsweise um 30Sekunden zu verzögern?

Welchen Fensterkontakt meinst Du genau? In der ursprünglichen Fragestellung geht es um den Funk-Fenster-Drehgriffkontakt HM-Sec-RHS.

Bei dem "optischen" Fensterkontakt HM-Sec-SCo ist das Register eventDlyTime nicht vorhanden (zumindest bei mir nicht).
Beim "magnetischen" Kontakt HM-Sec-SC-2 vermutlich auch nicht (vielleicht kann das jemand nachsehen, der so einen hat?)

[MadMax-FHEM]

Habe bei beiden geschaut und beide haben das Register.

Evtl. bei expert andere Einstellung um alles zu sehen oder get DeviceName regList...

Gruß, Joachim

[dkreutz]

Evtl. bei expert andere Einstellung um alles zu sehen oder get DeviceName regList...

Argh, darüber (vermeintlich fehlende Registerwerte) bin ich kürzlich schon einmal gestolpert - Danke für den Hinweis.

[alanblack]

Ich denke, dass Du mit

Code Auswählen Erweitern

set DeviceName regSet eventDlyTime 30
nicht glücklich wirst, da sowohl Open- als auch Close-Event zwar später kommen werden, aber AFAIK nicht wegfallen, wenn sie obsolet wären.
Genau Dein Szenario (nur mit Hund) hat mich dazu gebracht, die Fenstersensoren nicht zu peeren.

[AndyMu]

@all
Danke für die Rückmeldunge, das was alanblack angesprochen hat, ist genau das Problem.
Dann wird es wohl darauf hinauslaufen, mit einem notify bzw. DOIF zu arbeiten und kein direktes Peering zu verwenden.

[MadMax-FHEM]

Was alanblack geschrieben hat ist so nicht (ganz) richtig.

Habe es eben ausprobiert:

eventDlyTime auf 10s

Tür auf und unter 10s wieder zu -> es wird nur (wenn überhaupt) der dann aktuelle Zustand gesendet, also zu.

EDIT: noch mal verifiziert, habe event-on-change-reading raus, dann kommt der Zustand aber auch nur der letzte. Also wenn Tür auf war und geschlossen wird und dann unter 10s wieder auf kommt "open". Ein "closed" kommt nur, wenn die Tür nach 10s immer noch geschlossen ist. Aber klar: alles verzögert... Mit event-on-change-reading kommt nix also zumindest nichts was fhem oder irgendwelche Notify verwirren könnte.

EDIT2: werde das auch noch mal mit einem gepeerten FS-Kontakt testen... Eben geschehen: selbes Verhalten und der gepeerte Wandthermostat kriegt von alledem nichts mit (es kommt ja auch nur der letzte Zustand in dem Fall closed weil: zu - auf - zu [unter 10s])...

Was kommt ist ein battery und der trigger_cnt zählt um 2 hoch...

EventMonitor (2x auf und unter 10s wieder zu):

Code Auswählen Erweitern


2018-10-26 15:32:57 CUL_HM Tuer_SchlaZi battery: ok
2018-10-26 15:32:57 CUL_HM Tuer_SchlaZi trigger_cnt: 44
2018-10-26 15:32:58 CUL_HM Tuer_SchlaZi battery: ok
2018-10-26 15:33:41 CUL_HM Tuer_SchlaZi battery: ok
2018-10-26 15:33:41 CUL_HM Tuer_SchlaZi trigger_cnt: 46
2018-10-26 15:33:42 CUL_HM Tuer_SchlaZi battery: ok


Natürlich wird so kein Event mehr sofort verschickt...

Gruß, Joachim

[alanblack]

Was alanblack geschrieben hat ist so nicht (ganz) richtig.
[...]
Natürlich wird so kein Event mehr sofort verschickt...

Ja, sorry! Ich hatte eine Sache von damals unerwähnt gelassen: Ich wollte den evtl. geschlossenen Rolladen natürlich gleich automatisch geöffnet, die Heizung aber nur bei Öffnungszeit ab 1 Minute heruntergeregelt bekommen. Das war nicht mit evtDlyTime möglich.
Wenn ein derartiger Spagat nicht erforderlich ist, reicht dieses Setting doch aus.

[AndyMu]

Gut, das Problem habe ich, zumindest an einer Türe, schon.
Es soll das Terrassenlicht, abhängig von der Helligkeit, schon sofort eingeschaltet werden. Die Heizung aber soll x Sekunden verzögert reagieren.
Deshalb bräuchte ich den Delay eher beim WindowRec als beim auslösenden Gerät.

Da es das aber so anscheinend nicht gibt, bleibt nur eine FHEM-Lösung.

[esk]

Hi,

ich habe das so gelöst:
KU_FK_Tuer ist mein HM-SEC-SC-2 an der Terassentür, WZ_HZ_Term ist ein HM-TC-IT-WM-W-EU der dann 4 verteile Heizkörper steuert. Das sollte aber mit einem Heizköper direkt ähnlich funktionieren.
HeizkoerperMode ist mein globaler "Schalter" für den "Sommerbetrieb"
Durch das wait wird das "Tür auf" erst nach nach 60s geschickt. "Tür closed" wird aber sofort gesendet.

Code Auswählen Erweitern


# schaltet Heizung Wohnzimmer Termostat an/aus wenn Terassen tür >60s offen
define doif_KU_Tuer DOIF ([KU_FK_Tuer] eq "open" and [HeizkoerperMode] ne "off") (set WZ_HZ_Term_Climate controlMan
    DOELSEIF ([KU_FK_Tuer] eq "closed" and [HeizkoerperMode] ne "off") (set WZ_HZ_Term_Climate controlMode auto)
attr doif_KU_Tuer wait 60:60


esk