HM-SEC-RHS mit HM-TC-IT-WM-W-EU

[martinp876]

danke.
delay ist dann der falsche Begriff - es ist ein Filter.
werde ich im Kommentar so eintragen

[justme1968]

ich finde filter passt nicht.

das würde passen wenn man beim rhs z.b. tiltet heraus filtern und nur noch open und closed durch lassen würde.

hier wird ja die verzögerung angegeben die gewartet wird bis der aktuelle zustand gesendet wird. also passt delay gut.

[Prof. Dr. Peter Henning]

Verhalten ist tatsächlich so, wie von justme beschrieben. Allerdings: ein Filter erzeugt keine Verzögerung. Verzögerung alleine trifft es zwar auch nicht ganz wegen des Neustarts - aber mit ein paar zusätzlichen Kommentaren ist das ok.

LG

pah

[forum-merlin]

Hallo FHEM Freunde,

ich habe auch eine ähnliche Konstellation.
1x HM-TC-IT-WM-W-EU
1x HM-SEC-SC
2x HM-CC-RT-DN

Noch hält sich der Thread ja in Grenzen und ich habe alles gelesen. Auch den Wiki Artikel zum DN wo das Peeren mit den SC´s und TC erwähnt ist. Stichwort

Aber trotzdem bin ich jetzt nicht sicher wie ich vorgehen soll...

Ich habe nämlich eine Kombination aus den hier genannten Szenarien und NOCH NICHTS miteinander gepeert, sondern alles einzeln in FHEM eingebunden.

Ich habe auch zwei Katzen die ich mal eben rauslassen möchte, aber die Stellmotoren nicht gleich sofort loslaufen sollen.
Meine Verzögerungszeit soll aber 5 MINUTEN betragen und nicht 3 Sekunden.

Ich habe aktuell Zeitprofile in den beiden DN´s, und auch im TC
Der SC zeigt mir aktuell nur in FHEM an ob die Tür auf ist oder zu.

Könnt Ihr eine kurze Zusammenfassug posten was nun wie gepeert werden muss?
- Kann ich den SC nun mit dem TC UND den DN´s peeren oder nicht?
- Ist eine Lösung in Sicht warum der TC nicht sofort die Desired Temp an den DN sendet, bzw. dieser diese nicht sofort annimmt?
- Was soll ich jetzt mit dem burstXmit machen? setze ich den nun für die DN´s, den TC oder den SC?
- Und muss ich jetzt beim peeren mit dem TC ein "single" oder ein "single set" machen?


Ziel ist es:
- die Temp am HM-TC-IT-WM-W-EU manuell einzustellen wenn mir danach ist, und die beiden DN´s reagieren sofort darauf.
- Aber es sollen auch die Zeitprofile ziehen. schließlich kann ich ja auch mal kurz auf 26 Grad gestellt haben und dann vergesse ich es und dann bollter die HZG weiter. Da soll dann das Zeitprofil seinen Dienst tun.
- Wenn zu irgendeiner Zeit (egal ob manuell eingestellt oder Zeitprofil) die Tür auf geht, soll nach 5 Minuten auf 16 Grad gestellt werden. Und wenn die Tür wieder länger als 5 Minuten zu, dann wieder auf vorherige oder zeitgesteuerte Temp. zurückstellen.



Fazit:
aktuell weiss ich nicht was ich mit wem peeren soll, und ob ich was am burst für die DN´s , für den SC, oder für den TC ändern soll.



Danke Euch!

Gruß

der Merlin

[martinp876]

hier wird ja die verzögerung angegeben die gewartet wird bis der aktuelle zustand gesendet wird. also passt delay gut.

das habe ich anders von dir verstanden. Ein Delay würde wohl auch keinen sinn machen.
Also Frage:
Du stellet Filter auf 20sec
dann änderst du den Zustand im Abstand von 10sec den Zustand des Fensters, 20mal. Nach 200sec bist du fertig.
=> wenn es ein Delay ist bekommst du 20 trigger, den letzten nach 210sec (190+20)
=> wenn es ein Filter ist bekommst du einen Trigger nach 210sec. Kürzere events werden GEFILTERT

Ich habe verstanden, dass nur ein Trigger kommt und somit die Katze ohne Absenken der Heizung raus darf.

Allerdings: ein Filter erzeugt keine Verzögerung.

puh - durchschnaufen.
wo kommt dass den her? Echtzeitfilter erzeugen eigentlich immer eine Verzögerung. In Regelkreisen fängt man das ab. Hier haben wir keinen regelkreis sondern nur die Meldung. Die wird um die Filterzeit verzögert.
Akademisch könnte man behaupten, das Event ist nicht "fenster auf" sondern "Fenster auf für 20sec". Damit tritt der Event erst nach der Filterzeit auf... der Filter erzeugt keine Verzögerung.
Praktisch verstehen das aber nur Theoretiker. Für Anwender heisst es, der Filter
- filtert ereignisse die kürzer sind
- verzögert die Meldung um die Filterzeit

Um es in einer Zeile zu beschreiben
"filters short events, causes reporting delay"

Meine Verzögerungszeit soll aber 5 MINUTEN betragen und nicht 3 Sekunden.

beachte den mit dem Filter einhergehenden Delay. Deine Heizung wird also ggf die temp absenken, aber erst wenn das Fenster 5min offen ist.

- Kann ich den SC nun mit dem TC UND den DN´s peeren oder nicht?

kannst du

- Ist eine Lösung in Sicht warum der TC nicht sofort die Desired Temp an den DN sendet, bzw. dieser diese nicht sofort annimmt?

ich habe noch keine gefunden. An anderen stellen wird (m.E.) von FHEM erwartet, dass externe tirgger (fensterkontakte) an alle gemeldet werden -also alle entsprechend zu peeren sind. Leider habe ich keineKontakte zu HM um das zu diskutieren.

- Was soll ich jetzt mit dem burstXmit machen? setze ich den nun für die DN´s, den TC oder den SC?

bursXmit ist ein Kommando - wo willst du das setzen?

- Und muss ich jetzt beim peeren mit dem TC ein "single" oder ein "single set" machen?

kommandref sollte klarmachen, dass set default ist. Was ein Default ist, ist klar?

[justme1968]

hallo martin,

es kommt ein event nach 210sec.

ich bin aber trotzdem der meinung das filter das verhalten nicht beschreibt und verzögerung besser ist. besonders wenn man die randbedingung es gibt nur ein event betrachtet. das hat eine erst mal unbekannte lange und es wird nach einer verzögerung gesendet. jedes event das vorher passiert setzt den zähler zurück. am ende der verzögerung wird ein mal der aktuelle zustand gesendet.

send current state once after n seconds of inactivity wäre mein vorschlag.

die logik ist genau so wie bei den cyclic info messages. hier wird alle 24 stunden automatisch ein mal gesendet wenn es in den letzten 24 stunden nicht schon eine andere übertragung gegeben hat. eine übertragung egal wie getigert setzt den timer zurück und er fängt von vorne an zu laufen.

die verzögerungen in realen filter sind aber (unerwünschte) nebeneffekte und es wird versucht diese zu minimieren.

gruss
  andre

[Prof. Dr. Peter Henning]

Sehe ich auch so wie justme

Ein Filter hält ein paar Dinge zurück, andere nicht. Dass dabei - wegen der notwenigen "Bearbeitungszeit" - eine Latenz entsteht, ist ja ganz richtig.

Trifft aber hier nicht, denn sprechen ja hier nicht von einer Filter-Latenzzeit, sondern von einer einstellbaren Verzögerung.

Und das mit dem "current state" ist etwas irreführend, weil zum Zeitpunkt des Timerstarts "current" etwas anderes sein kann, als später. Mein Vorschlag:

eventDlyTime = 0 s  => send new state immediately
eventDlyTime = x s => send new state after x seconds if not changed again (in this period)

Betreffend die 5-Minuten-Katze: Innerhalb eines so langen Zeitraums merken eventuell die RT schon den Temperaturabfall und steuern das Ventil zu. Müsste man mal testen.

LG

pah

[martinp876]

besonders wenn man die randbedingung es gibt nur ein event betrachtet.

es gibt 10 Events, die FW sieht alle. Es wird aber nur eins gemeldet, die FW unterdrückt gezielt die anderen (filtert?).

das hat eine erst mal unbekannte lange

es sind schlicht mehrere

und es wird nach einer verzögerung gesendet.

es wird sofort nach erkennen gesendet. Die Erkennung dauert nur. Peter ist mit der Beschreibung einer Latentz da schon richtig. Ein Parameter des filters.

Trifft aber hier nicht, denn sprechen ja hier nicht von einer Filter-Latenzzeit, sondern von einer einstellbaren Verzögerung.

eine verzögerung macht was sie sagt - verzögert ereignisse, schlickt aber keine.
Das ist hier weder der Fall noch gewünscht. gewünscht ist, dass die Zeit ereignisse unterdrückt (das machen Filter).

Ein Filter hält ein paar Dinge zurück, andere nicht.

korrekt. Hier sind es ereignisse, die eine bestimmte Zeit unterschreiten. Andere werden weitergeleitet. Sonstige parameter werden nicht berücksichtigt.

eventDlyTime = 0 s  => send new state immediately
eventDlyTime = x s => send new state after x seconds if not changed again (in this period)

zu lang - passt nicht in eine Zeile. Text gut für wiki, hier bitte kürzer.
0 ist eh kein sonderfall.
schöne Umschreibung eines glitch-filter für nicht-techniker. Professionell würde ich diesen Text ablehnen.

Betreffend die 5-Minuten-Katze: Innerhalb eines so langen Zeitraums merken eventuell die RT schon den Temperaturabfall und steuern das Ventil zu. Müsste man mal testen.

wird sicher so sein - wird aber nicht empfohlen.
- die eingebaute erkennung ist deutlich schneller - reagiert auf temp-abfall. Hängt also von der temp-differenz ab
- wenn es nach 5min das nicht merkt wäre es sinnlos
- verwendet man externe Sensoren (SCI/RHS) sollte man die interne erkennung abschalten. Diese ist nur ein Notbehelf, will man keine externen kaufen. gemischt wird es zu Problemen führen - insbesondere beim Wiedereinschalten

send current state once after n seconds of inactivity wäre mein vorschlag.

send state if stable for n seconds
filter events shorter then n sec
send new state after x seconds if not changed again
send state after x sec if unchanged
send state after x sec if stable
send state if changes and stable for x sec

kein once, kein current kein new. Sollte klar sein, dass der zustand nicht mehrfach kommt und auch, dass kein alter gesendet wird.

man kann das ganze gerne mit prosa in wiki hinterlegen, für User, die sich unter einem glitchfilter nichts vorstellen können.

Gruss
Martin

[Prof. Dr. Peter Henning]

Martin,

das Ereignis ist "Tür öffnen", nicht "Tür öffnen für 10 Sekunden". Das macht den Unterschied in der Sichtweise.

Sieh mir nach, dass ich nicht weiter in die Diskussion einsteige, das führt zwischen uns beiden zu nichts.

LG

pah

[martinp876]

da hast du recht. Ich habe schon etliche debounce filter gebaut, die genau so funktionieren.
Wenn ich "Tür öffnen für 10 Sekunden" habe will muss ich sie nach 10 sec wieder zu machen.
Das Event ist auch nicht "Tür öffnen" - zumindest beschreibt es das nicht hinreichend.
Das Event ist "Tür wurde vor 10 sec geöffnet und dann nicht mehr bewegt". Das beschreibt das Event. Es wird hier implizit, aber nicht explizit klargestellt, dass kurze Ereignisse zu gar keinem trigger führen. Möglich, dass die Tür schon seit Stunden im Wind schaukelt (ok, unwahrscheinlich). Da bekomme ich nichts mit.
Und wenn die tür nach 9 sec wieder zu ist bekomme ich auch keinen delayed trigger.

Selbst rein Akademisch betrachtet kann ich delay weder als Idee hinter der Funktion noch Erklärung des Verhaltens gelten lassen - hast es ja selbst relativiert. Delay ist nur ein technisch nicht abwendbarer schmutzeffekt des Filters (seine Latenz)

sorry, wenn du es anders siehst. ich habe so etwas einfach schon zu oft in Produkte eingebaut - hat nie jemand anders bezeichnet. Auch keine Doktoren.

Gruss Martin

[Prof. Dr. Peter Henning]

Du fängst schon wieder an, über akademische Titel herzuziehen.

Schade, das beendet hier die fachliche Diskussion.

LG

pah

[forum-merlin]

Hallo Freunde...

Kann ich nochmal kurz auf das Thema hier zurückkommen?
Sorry wenn ich hier nachhake.

Kann jemand bitte die ganze Soße auf die wichtigen Fakten einkochen und alle Facts bestätigen oder korrigieren?

LEGENDE
HM-TC-IT-WM-W-EU =    TC = WandThermostat
HM-Sec-RHS =       RHS = Türkontakt
HM-Sec-SC-2 =
HM-SEC-SC =
HM-CC-RT-DN =       RT = HeizungsThermostat


PEERING
- soll man nun TC nun mit RT UND mit RHS peeren?
- soll man RHS nur mit TC peeren?
- soll man nur RHS und TC peeren?
- Was ist jetzt mit dem burstXmit Setting? Ist das nun nötig zu disablen um die Meldungen v

ZEITPROFILE
- werden die nun NUR in den RT´s gesetzt?
- werden die in RT und in TC gesetzt?
- werden die nur in den TC´s gesetzt?

KNOWN ISSUES
- Ist es bestätigt dass der TC nicht sofort die Desired Temp an den DN sendet, bzw. dieser diese nicht sofort annimmt?
Wenn ja, ist dafür eine Lösung in Sicht?
- hängt das mit dem burstXmit zusammen?


BURSTXMIT
...auch wenn es auf die Batterielaufzeit geht...
- ist es ratsam bei den RT´s UND beim TC UND beim RHS den burstXmit zu setzen?
- wo setze ich den am geschicktesten?

COMMANDREF
- ist beim peeren mit dem TC nun der richtige Befehl der mit "single" oder der mit "single set" ?


ANFORDERUNG (meine jedenfalls)
- die Temp am HM-TC-IT-WM-W-EU manuell einzustellen wenn mir danach ist, und die beiden DN´s reagieren sofort darauf.
- Aber es sollen auch die Zeitprofile ziehen. Schließlich kann ich ja auch mal kurz auf 26 Grad gestellt haben und dann vergesse ich es und dann bollert die HZG weiter. Da soll dann das Zeitprofil seinen Dienst tun und es zur eingestellten Zeit wieder runter drehen.
- Wenn zu irgendeiner Zeit (egal ob manuell eingestellt oder Zeitprofil) die Tür auf geht, soll nach 5 Minuten auf z.B. 16 Grad gestellt werden. Und wenn die Tür wieder länger als 5 Minuten zu, dann wieder auf vorherige oder zeitgesteuerte Temp. zurückstellen.



Danke Euch

Gruß

der Merlin

[esskaa]

Hallo zusammen,

auch wenn das Thema hier schon länger tot liegt, so habe ich mich erst kürzlich damit befasst. Da ich erst jetzt die HM-SEC-RHS einsetze.

Um meinen Senf zu Delay/Filter beizutragen:
Die Funktion ist meiner Meinung nach ganz klar ein Filter, denn es werden alle ungewünschten Events gefiltert.
Die Katze finde ich ein unglückliches Beispiel. Wenn ich die Katze rauslassen will dann ist mein gewünschtes Event eigentlich: closed, bzw. gar keins. Da ich nicht will das die Heizung auf ein solch kurzes Event reagiert. Dennoch sendet der RHS zumindest ein Event: closed.

Wenn ich nun aber das Öffnen eines Fensters auf Kipp betrachte, sieht die Situation anders aus. Mein gewünschtes Event: tilted. Die Information, dass ich vorher aber den Status open hatte interessiert mich nicht. Auch wenn ich ein unentschlossener Mensch bin und mich zwei Mal um entscheide ob ich das Fenster nun ganz öffnen möchte oder nur kippen, ist der Heizung egal. Also lasse ich sie weg oder anders gesagt: Ich filtere die unerwünschten Events.

Ein Delay (zu Deutsch: die Verzögerung) macht genau das was der Name sagt. Verzögern. Stelle ich nun ein Delay von 5 Sekunden ein, kommen alle Events einfach 5 Sekunden verzögert.
Just my 2 cents.

Nun aber zum Peeren:

Ich habe den RHS mit TC UND RT gepeert.

Mir ist aufgefallen das wenn ich den RHS nur mit dem TC peere, der TC keinen Burst an den RT sendet. Laut config (im FHEM und allen Devices) ist eigentlich alles richtig eingestellt. Dennoch sendet der TC die Daten erst bei der normalen Abfrage des RT. Warum ist mir ein Rätsel, da eine Temperaturänderung am TC sofort an den RT geht.

Etwa eine Woche läuft das ganze nun schon und ich kann keine Unstimmigkeiten feststellen können.

Meine Empfehlung:

Erst nur den RHS und den TC peeren und alles in Ruhe testen. Sollte einem dann die Reaktionsgeschwindigkeit des RT zu langsam sein, dann auch den RT peeren.

LG,
EssKaa