Präsenzmelder - Dimmaktor - Szenen

[rspecht]

Hallo Leute,

ich bin gerade am "aufhübschen" meiner Installation.
Im Moment ist die Steuerung der Dimmaktoren dran. Ich möchte die Helligkeit des Wohnzimmers über Szenen regeln (falls dies geht).
Die geschalteten Lampen und Rolläden sind schon enstrechend eingebunden und gehen. Nun ist das dimmbare Hauptlicht dran.

MDT Glastaster wählt die Szene
Busch Jäger Präsenzmelder erkennt wer da ist
MDT Dimmaktor steuert das Licht

Hier mein aktueller Aufbau:
Erklärung zum Bild: graue Gruppen sind nur zum Test, haben keinen Sender außer FHEM
Von Links nach Rechts: Ereignis, Aktor, Gruppe, FHEM
img.png

Wenn ich nun die Szene ändere dimmt mein Licht auf den im Aktor hinterlegten Wert - egal ob der Präsenzmelder was sagt oder nicht.
Dadurch kommt es halt auch vor dass das Licht schaltet und der Präsenzmelder nie einschaltet und somit auch nie Ausschaltet und das licht so lange leuchtet bis jemand im Dunkeln durch den Raum geht und den Melder triggert.

Wie gehe ich so etwas an? Die Helligkeitsvorwahl kann ich auch gerne über FHEM abbilden.
Nur die Funktion: Licht an/aus sollte auch ohne FHEM gegeben sein.

Hier noch die Szeneneinstellung vom Dimmaktor:
2019-09-08 10_59_20-ETS5™ - HochstaetterWeg7 (1).png

Vielen Dank im Voraus

[rspecht]

Hallo,
ich nochmal: habe ich das evtl. falsch gepostet und es ist in "KNX Einsteiger" falsch aufgehoben?
Oder ist meine Frage zu wirr?

Gruß

[gbglace]

Ich versuche mal zu verstehen was du vorhast.

Es gibt einen Zustand in dem bei Anschalten des Lichtes eine definierte Dimmstufe gelten soll.
Wieviele solcher Ziel-Dimmstufen hast Du denn in Deinem Konzept vorgesehen?

Es gibt dazu insgesamt mehrere Ansätze.
Wenn der PM eine mächtige Applikation hat wäre es zu bevorzugen Befehle an den Aktor nur vom PM aus zu senden. Der Wechsel von Zieldimmwert sollte daher im PM eingestellt werden.
Sofern Du nur zwei Dimmstufen hast lässt sich sowas meist mit einem Tag/Nacht Modus realisieren. Hier werden dann je Modus im PM die entsprechenden Dimmwerte hinterlegt, die der PM bei Bewegungserkennung an den Aktor sendet.
Offen ist dann noch das Verhalten, wenn während einer aktiven Bewegungsphase der Modus wechselt. meist ändert der PM dann erst bei einem erneuten EIN den Zielwert.
Manche PM ermöglichen auch via Funktionsblöcke mehrere Kanäle zu definieren, die mit jeweils entsprechenden Dimmwerten konfiguriert werden. Der Szenenaufruf / Moduswechsel führt dann dazu, das der jeweilige Funktionsblock aktiviert wird und die übrigen gesperrt werden.

Weiters wäre zu prüfen ob der PM ein KO hat in dem man den Dimmwert der bei Präsenzerkennung gesendet wird definieren kann. Dann würde die Szene den Zielwert an den PM senden und der würde dann bei Bewegungserkennung entsprechend schalten. Hier aber auch das gleiche Problem, Moduswechsel bei laufendem Bewegungsfenster.

Als letztes ginge dann natürlich noch (je komplexer desto wahrscheinlicher / notwendiger wird es) den PM auf die reine Funktion Bewegung ja/nein zu reduzieren und alles andere in einer Logik in z.B. FHEM abzubilden.

Sofern bei Start der Szene nicht nur der Zieldimmwert definiert werden soll sondern auch direkt entsprechend EIN-geschalten werden soll unabhängig einer Bewegung vom PM, dann muss der Status des Aktors mit an den PM gehen, damit dieser Kenntnis vom Zustand AN hat. Allerdings hat man dann hier meist auch den Effekt das der PM dann mit dem zählen der Nachlaufzeit beginnt und damit auch ausschaltet, was bei einem Szenenauslösen ggf. so nicht gewollt ist, weil dann müsste man das Licht auch nicht einschalten bei Szene. Geht man wiederum bei Auslösen auf eine Sperre des PM und gibt den Dimmwert direkt an den Aktor hast wieder das Problem, wann ist die Sperre vorbei und der PM darf wieder schalten.

Die Szene im Aktor direkt ansprechen macht daher am wenigsten Sinn.

Ich würde versuchen 3 Funktionsblöcke im PM zu definieren die je einen Zieldimmwert haben und die jeweils sperren / entsperren. Bei erkannter Bewegung hast dann die entsprechende Helligkeit. Da BJ verschiedene Melder hat, kann ich nicht sagen ob die Applikation das hergibt.

[Gast1961]

Dadurch kommt es halt auch vor dass das Licht schaltet und der Präsenzmelder nie einschaltet und somit auch nie Ausschaltet und das licht so lange leuchtet bis jemand im Dunkeln durch den Raum geht und den Melder triggert.

Du könntest einen zusätzlichen PM-Kanal so konfigurieren, daß er helligkeitsunabhängig die Präsenz erkennt, bei Beginn Präsenz nichts sendet und bei Ende der Präsenz das Licht ausschaltet. Das dann als zusätzliche Abschaltfunktion auf den Aktor (oder als Szene), neben der ohnehin vorhandenen PM-Funktion. Das ist dann quasi die Fallback-Lösung, die im Normalfall gar nicht nötig wäre, aber bei deinen Sonderfällen greift.

Das ganze würde ich aber mit verlängerter Nachlaufzeit machen, damit dieser Kanal nicht irrtümlich abschaltet.

[gbglace]

Auch ne gute Idee.

[rspecht]

Wieviele solcher Ziel-Dimmstufen hast Du denn in Deinem Konzept vorgesehen?

Aus, 100%, 50%, 20% wäre cool, also 3 oder 4 - je nachdem wie man "Aus" zählt.

Wenn der PM eine mächtige Applikation hat wäre es zu bevorzugen Befehle an den Aktor nur vom PM aus zu senden. Der Wechsel von Zieldimmwert sollte daher im PM eingestellt werden. ....
Weiters wäre zu prüfen ob der PM ein KO hat in dem man den Dimmwert der bei Präsenzerkennung gesendet wird definieren kann.

Der PM kann ein Byte senden, aber nur statisch einstellen.

Als letztes ginge dann natürlich noch (je komplexer desto wahrscheinlicher / notwendiger wird es) den PM auf die reine Funktion Bewegung ja/nein zu reduzieren und alles andere in einer Logik in z.B. FHEM abzubilden.

Das bietet mir leider keine Fallback Lösung falls der Raspi mal aussteigt.

Sofern bei Start der Szene nicht nur der Zieldimmwert definiert werden soll...

Nein, reine PM Steuerung ist gut.

Ich würde versuchen 3 Funktionsblöcke im PM zu definieren die je einen Zieldimmwert haben und die jeweils sperren / entsperren.

Das ist wohl eine gangbare Lösung - dann leider nur durch ETS zu ändern.

Ich habe gerade gesehen dass die PMs ein "Tor" in der Logikfunktion haben.
Damit wäre es doch abbildbar - nur wie "wandele" ich die Szene von 0...3 auf 4 einzelne Schalt-Bits? Das Problem habe ich ja auch wenn ich die Lösung mit 3 Präsenzkanälen angehe. Wenn ich das in FHEM Abbilde kann ich wieder nicht autark schalten. Einen Startwert bekomme ich so leider auch nicht rein.

Tor: Mit der Applikation „Tor“ lassen sich bestimmte Signale filtern und der Signalfluss vorübergehend sperren. Die Funktion besitzt drei Kommunikationsobjekte: „Steuereingang“, „Eingang“ und „Ausgang“. Das Eingangs- bzw. Ausgangsobjekt kann unterschiedliche Größen annehmen.
...
Die Steuerung kann vom „Eingang zum Ausgang“ oder auch vom „Ausgang zum Eingang“ erfolgen, sofern der Steuereingang dies zulässt. Die Freigabe über den Steuereingang kann über ein EIN- oder ein AUS-Telegramm erfolgen.
Wird zum Beispiel die Einstellung „Steuereingang“ auf „EIN-Telegramm“ gesetzt, werden nur Telegramme vom Eingang an den Ausgang geleitet, wenn vorher der Steuereingang ein EIN-Telegramm empfangen hat.
Zudem ist es möglich, Signale über die Einstellung „Filterfunktion“ zu blocken. Entweder wird „nichts ausgefiltert“ oder es wird das Signal „EIN ausgefiltert“ bzw. das Signal „AUS ausgefiltert“. Diese Funktion wird z. B. immer dann notwendig, wenn von einem Sensor nur das EIN-Telegramm interessant ist und dieser in seinem Applikationsprogramm keine Filterfunktionalität anbietet.

Alternativ finde ich die Lösung von 6ast auch gut - zusätzlich könnte ich doch auch Fhem "sagen" dass es schaut wie der Zustand des Aktors "vorher" war und dann direkt wieder ausschalte. Aber das ist schon gebastel. Schön wäre wirklich sowas wie die Tor-Logik vom PM nur mit fixen Werten und Gruppensteuerung. Kann so etwas ein Logikmodul?

Vielen Dank euch 2 - das ist schon eine große Hilfe

[gbglace]

Ein Logikmodul, kann sowas, aber warum ein Logikmodul wenn eh schon ne 24/7 Logikengine vorhanden ist. Ggf einfach in der Richtung was stabileres als nen RPi suchen.