HMUARTGW und HM-SEC-RHS: status falsch, wenn Türgriff von Zu->Kipp od Kipp->Zu

[budy]

Moin,

ich habe schon seit einiger Zeit ein Problem mit meinen HM-SEC-RHS und meinen HMUARTGWs. Wenn ich den Türgriff und damit den/die HM-SEC-RHS über zwei Zustände bewege, also Zu direkt nach Kipp, oder Kipp nach Zu, dann kommt in meinem FHEM nur der Zustand Offen an, der tatsächliche Zustand Kipp aber nicht.

Dazu muss ich beim drehen des Griffs eine kleine Pause einlegen, dann funktioniert das. Das Problem hatte ich mit meinem alten HM-LAN GW nicht, da war es egal, wie schnell man den Griff bewegt.

Hat jemand eine Idee, wie ich dem Problem auf die Schliche kommen kann?

[frank]

zb eventDlyTime setzen

[budy]

Oh Mann... danke! Ich frage mich, ob das wohl ab Werk auf 0 steht. Ich kann mich gar nicht daran erinnern, das mal irgendwie geändert zu haben.

[Otto123]

Oh Mann... danke! Ich frage mich, ob das wohl ab Werk auf 0 steht. Ich kann mich gar nicht daran erinnern, das mal irgendwie geändert zu haben.

Kann dich beruhigen, meiner ist "aus der Tüte"

1:         eventDlyTime     :0 s

Du hast nichts falsch gemacht.

Gruß Otto

[frank]

am besten ein template für die register zusammen klicken, dann muss man sein gedächnis nicht strapazieren.
ausserdem sagt hminfo configcheck bescheid, wenn sich was verstellt. soll bei den dingern ja nicht selten passieren.

folge dem link in meiner sig

[Pfriemler]

Mit eventDlyTime =0 hatte ich davor auch ständig fehlerhafte Zustände.
Ich kombiniere den RHS zusätzlich mit einem SCo (und kann damit entriegelte, aber im Rahmen angelehnte Fenster/Türen erkennen). Hier musste ich eventDlyTime noch etwas länger machen, weil es bei der normalen zügigen Bedienung ständig Funkkollisionen zwischen SCo und RHS gab...

[budy]

Mit eventDlyTime =0 hatte ich davor auch ständig fehlerhafte Zustände.
Ich kombiniere den RHS zusätzlich mit einem SCo (und kann damit entriegelte, aber im Rahmen angelehnte Fenster/Türen erkennen). Hier musste ich eventDlyTime noch etwas länger machen, weil es bei der normalen zügigen Bedienung ständig Funkkollisionen zwischen SCo und RHS gab...

Jo, das mache ich im EG auch und ich habe mir auch schon überlegt, ob ich den Delay noch höher setzen muss... aber ich fand drei Sekunden schon ganz üppig. Am Ende könnte man auch zufällig nach dem Entriegeln noch zwei Sekunden warten und dann feuern der SCo und der RHS auch gleichzeitig...

...allerdings dachte ich auch immer, dass die "S"-Geräte auf ein Ack von der CCU warten und ggf. nochmals senden.