Virtuelle Leuchte (17000210) entprellen?

[leSasch]

Hallo zusammen,

ich nutze sehr gerne den LBS "Virtuelle Leuchte (17000210)" - gefällt mir sehr gut.
Leider sind einige meiner Bewegungsmelder äußerst empfindlich - sie interpretieren "Licht aus" als Bewegung und geben dem LBS damit erneut den Befehl, das Licht anzuschalten.
Das resultiert dann in "Licht an, ganz kurz aus, sofort wieder an, ganz kurz aus, ..." und so weiter.
Schön wäre es, wenn der LBS sich selbst entprellen könnte.
Zum Beispiel, wenn er über Status E das Licht ausschaltet, er für eine kurze Zeit keine Kommandos über den Eingang E (E5) annimmt.
Oder weiß jemand eine bessere / einfachere Lösung?

Grüße,
Sascha

[DirtyHarry]

Viele der von mir bisher genutzen KNX-BWM bieten die Möglichkeit die Rückmelde-GA mit anzugeben und nach dem Abschalten der Leuchte eine Totzeit zu starten, in der eine erkannte Bewegung ignoriert wird.

Ob deine das bieten, kannst du ja mal in der ETS schauen oder das Technische Handbuch lesen.


Eine Alternative in Edomi wäre die GA über ein Tor/Sperre zu führen. Beim Abschalten sperren und zeitverzögert wieder freigeben. Nachteil: Zuverlässiges und zeitnahes schalten nur über sehr kurze Nachlaufzeiten im BWM zu erreichen...

[leSasch]

Danke für die Antwort. Die Sperre im BWM zu nutzen, wollte ich eigentlich vermeiden, weil mir das "Dumme KNX-Devices"-Paradigma ziemlich zusagt (siehe gaert).
Was meinst Du mit sehr kurzen Nachlaufzeiten im BWM?
(schlimmstenfalls wird man wohl den LBS erweitern müssen, was in dem Fall nicht völlig trivial ist)

[DirtyHarry]

Naja, der BWM schaltet ein und macht dann erst mal gar nichts, bis seine Zeit abgelaufen ist. Wird nun das EIN-Telegramm unterdrückt, denkt der BWM das Licht ist ein und sendet auch bei erneuter Bewegung kein Signal (ist die Rückmelde-GA auf dem BWM, sollte das wiederum aber funktionieren). Steht die Zeit auf 5 Minuten, darf mind. 5 Minuten keine Bewegung sein, da er sonst kein erneutes EIN-Signal sendet. Zyklisches Senden würde dieses Problem zwar halbwegs beheben, jedoch in deinem Fall wieder zu deinem ursprünglichen Problem führen (nur halt um die Zykluszeit versetzt).
Je häufiger mit neuen Bewegungen zu rechnen ist, desto kürzer muss die Zeit sein. Im Umkerschluss führt aber eine kürzere Zeit und viel Bewegung zu mehr Telegrammen, was dann bei entsprechender Menge an BWM schnell zu Problemen führen kann (Stichwort Buslast).

Das "Dumme KNX-Devices"-Paradigma ist nicht so meine Sache. Wenn man das für sich selbst so macht und damit leben kann, dass bei Ausfall der zentralen Intelligenz eben gar nichts mehr geht, dann kann man das so machen. Aber bei einem Kunden, der sich selbst dann nicht helfen kann, ist das ein Nogo (außer er hätte es explizit angefordert unter Kenntnis der Nachteile). Deshalb bleibe ich soweit irgendwie möglich bei Grundfunktion im KNX, Komfort im Server.