KNX/EIB OpenKNX Präsenzmodul: Mehrstufige Beleuchtung und/oder Grundbeleuchtung

[sleepless]

Hallo,

Hat einer eine Idee, wie man mit dem Modul eine erweiterte Beleuchtungsdauer (oder Grundbeleuchtung) realisieren kann?

Was ich suche als Beispiel lediglich "Soft" aus richtung 0 %:

Lampe aus - Präsenz erkannt - Lampe 100 Prozent - Keine Präsenz - Nachlaufzeit 2 min - Dimmen auf 30% - Nachlaufzeit 1 min - Dimmen 10 % - Nachlaufzeit 10min - Aus

Oder als "Soft start" und "soft aus":

Lampe aus - Präsenz erkannt - Lampe 30 Prozent - nach 60 s weitere Präsenz - Lampe 100 % - Keine Präsenz - Nachlaufzeit 2 min - Dimmen auf 30% - Nachlaufzeit 1 min - Dimmen 10 % - Nachlaufzeit 10min - Aus

Ich sehe da keine Möglichkeit "out of the Box" mit dem Präsenzmodul. Es gibt nur ein Wert, der benutzt werden kann, aber keine Verkettung oder sogar das andere extrem, eine "Grundbeleuchtung".

Danke euch für die Vorschläge

[mumpf]

So wie ich die Anforderung verstehe, kannst Du das mit einer Sequenz von Logikkanälen umsetzen. Ohne es jetzt ausprobiert zu haben:
PM schaltet über Kanal 1 auf 30%, bei AUS nichts.
Über den 2. Schaltausgang macht er schalten (EIN/AUS).
Logik 1: Bei PM-EIN -> Einschaltverzögerung 60s + Wenn zwischendurch AUS kommt, sofort schalten -> Ausgang: Bei EIN Dimmen auf 100%. Bei AUS macht er nichts.
Damit hast Du schon mal Dein verzögertes Einschalten.
Logik 2: Bei PM-AUS -> Ausgang: Bei AUS Dimmen auf 30%, bei EIN macht er nichts.
Logik 3: Bei PM-AUS -> Ausschaltverzögerung 60s + bei erneutem Einschalten sofort schalten -> Auagang: Bei AUS Dimmen auf 10%, bei EIN nichts
Logik 4: Bei PM-AUS -> Ausschaltverzögerung 10m + bei erneutem Einschalten sofort schalten -> Ausgang: Bei AUS Dimmen auf 0%, bei EIN nichts.
Das wäre die Ausschaltsequenz.
Alle Logikeingänge werden mit dem Schaltausgang vom PM verbunden und es läuft so, wie Du es möchtest.

Gruß, Waldemar

[sleepless]

Mega 😁

Eins bleibt noch: Die coole Funktion vom PM "Automatik übersteuern" wird dadurch gemäß den Verzögerungen überschrieben oder? Also wenn z.B. das Licht an ist - Befehl für Übersteuern - Licht aus - dann nach Verzögerung X licht wieder auf 30%

Ich müsste demnach noch eine UND-Logik dazwischen hängen, die mir das EIN/AUS vom PM an die ganzen Logiken unterbindet, wenn der PM übersteuert wird - korrekt so? Oder geht's auch ohne dem?

[sleepless]

-.-

[LostWolf]

Wir brauchen dringend mal eine Sammlung dieser ganzen Praxisfälle

[coko]

Wenn Du den Raumcontroller hast, dann könntest Du auch die Zustandsautomaten was für solche Umsetzungen verwenden.

[sleepless]

Entschuldige die Frage, aber das Modul Zustandsautomaten ist für mich noch nicht ganz klar und erfordert eine eingehendere Auseinandersetzung.
Könntest du mir bitte erklären, wie ich das mit dem Automaten umsetzen kann?

[mumpf]

Ich müsste demnach noch eine UND-Logik dazwischen hängen, die mir das EIN/AUS vom PM an die ganzen Logiken unterbindet, wenn der PM übersteuert wird - korrekt so? Oder geht's auch ohne dem?

In diesem Fall sollte es einfacher gehen. Die von mir vorgeschlagenen Logiken verzögern ja nur den EIN- bzw. den AUS-Pfad, aber nicht beides. Wenn man also im AUS-Fall die AUS-Verzögerungen alle auf EIN setzt, sind sie inaktiv. Für EIN entsprechend umgekehrt mit AUS inaktivieren.

Gruß, Waldemar

[coko]

Hattest Du die Beispiele im Einführungsthread Zustandsautomaten schon mal angesehen?
Speziell Beispiel zur Einführung: Virtueller Schaltaktor mit Sperre und Treppenhaus-Funktion

Könntest du mir bitte erklären, wie ich das mit dem Automaten umsetzen kann?

Schon mal auf die Schnelle skizziert (später gerne noch weitere Erklärungen), soweit ich das verstanden habe:

Lampe aus - Präsenz erkannt - Lampe 100 Prozent - Keine Präsenz - Nachlaufzeit 2 min - Dimmen auf 30% - Nachlaufzeit 1 min - Dimmen 10 % - Nachlaufzeit 10min - Aus

Zustand		A: Präsenz=1	B: Präsenz=0		T: Timeout		O1 Helligkeit
1	Lampe aus	2	-				AUS
2	Präsenz	-	3				100%
3	Präsenzende?	2			4 (nach 2 min)		30%
4	Nachlaufzeit	(? 2)	-		1 (nach 1 min)		10%

Lampe aus - Präsenz erkannt - Lampe 30 Prozent - nach 60 s weitere Präsenz - Lampe 100 % - Keine Präsenz - Nachlaufzeit 2 min - Dimmen auf 30% - Nachlaufzeit 1 min - Dimmen 10 % - Nachlaufzeit 10min - Aus

Zustand		Präsenz=1	Präsenz=0		Timeout		O1 Helligkeit
1	Lampe aus	2	-				AUS
2	Präsenzbeginn	-	?		3 (nach 60s)		30%
3	Dauerpräsenz	-	4				100%
4	Präsenzende?	(? 3)	-		5 (nach 2 min)		100%
5	Nachlaufzeit	(? 3)	-		6 (nach 1 min)		30%
6	Nachlaufzeit 2	(? 3)	-		1 (nach 10min)		10%

Einige Lücken in er Definition (siehe Fragezeichen) müssten noch befüllt werden.

[mumpf]

Ja, der Lösungsvorschlag von Cornelius ist hier sicher besser und übersichtlicher. Vor allem, weil Du für "Automatik übersteuern" ein weiteres Symbol einführen kannst und dann auch passend den dafür zuständigen Zustand setzen kannst.

Gruß, Waldemar

[sleepless]

Das klingt eher danach, den Präsenzmelder durch den Zustandsautomaten zu ersetzen statt ihn zu erweitern.
Ich finde es krass, was möglich ist. Aber irgendwie doch zuviel aufwand für etwas, was ein paar Klicks höher "fertig" ist und lediglich am ende etwas angepasst werden sollte.
Fang ich das Spiel so an, müsste die ganze Logik mit der Helligkeitsüberwachung auch noch in dem Automaten einbauen.

Ich fühle mich damit überrannt - will doch bloß nur ein PM um etwas erweitern und nicht gleich einen ganz individuellen Präsenzmelder herstellen. Mir fehlt das Interesse und der Sinn, etwas erneut zu bauen, was bereits vorhanden ist - oder um es anders auszudrücken: "Das Rad muss nicht neu erfunden werden".

Ich würde es so halten wollen: den DEA lediglich für die Erweiterung im Ein oder Auschaltverhalten zu benutzen. Das Grundlegende dann bei dem PM-Modul (Rad).

Wenn das nicht anders geht, bin ich auch gerne offen für eine "import" Vorlage.

mumpf
Das mit den Logiken klappt, lediglich nicht ein "Automatik übersteuern", da ich keine Unterscheidung im Ausgangsignal des PM habe, warum dort eine "0" kommt.

[sleepless]

So langsam verstehe ich das Teil. Zumindest das Grundlegende. Richtig unklar sind ist der Reiter "bedingte übergänge". Ich denke mal, die brauch ich erst mal nicht.

Ich müsste es so realsieren:

Zustand | Beschreibung | A=1 | A=0 | B=1 (Override) | T (Timeout) | O1
-------------------------------------------------------------------------------------------------------------------------------
1 | IDLE | 1 → bleibe 1 | 2 (nur wenn B=0) | 4 (sofort AUS) | - | -
2 | Nachlauf 30% | 1 → 1 | - | 4 | 3 (2 min) | 30%
3 | Nachlauf 10% | 1 → 1 | - | 4 | 4 (1 min) | 10%
4 | AUS | 1 → 1 | 4 | 4 | - | 0%

Leider gibt's in der Tabelle keine bedingung auszuwählen.
Alles funktioniert bis auf der Override, der in dem Zustand 1 wieder zu finden ist.

Siehe A=0 bei 1: 2 (nur wenn B=0)

B stellt den Override dar. Also, wenn der Taster als Umschalter eine "1" sendet.

Wie kann ich das also so lösen: (?)

Fall 1: Automatik AUS

A: 1 → 0
B: 0
→ Zustand 2 → Nachlauf läuft

Fall 2: Override AUS

A: 1 → 0
B: 1
→ sofort Zustand 4
→ KEIN Nachlauf

[coko]

So langsam verstehe ich das Teil. Zumindest das Grundlegende.

Cool, dass Du Dich da trotz anfänglicher Skepsis doch ran wagst. Da unterstütze ich dann natürlich sehr gerne. Und mir ist auch bewusst, dass das sicher ein Modul ist mit dem man sich etwas beschäftigen muss (insbesondere wenn man dier zugrundeliegenden Theorie bislang keinen Berührungen hatte). Also gerne weiter Fragen.

Hatte schon angefangen mit der Formulierung einer Anwort, Du warst Du etwas schneller. Daher erst mal nur zu Deinem vorletzten Beitrag. Auf den weiteren Antworte ich dann noch mal separat.

will doch bloß nur ein PM um etwas erweitern und nicht gleich einen ganz individuellen Präsenzmelder herstellen. Mir fehlt das Interesse und der Sinn, etwas erneut zu bauen, was bereits vorhanden ist - oder um es anders auszudrücken: "Das Rad muss nicht neu erfunden werden".

Schwierig. Wenn Du die Grenzen der Implementierung vom PM (oder auch einer anderen spezifischen Lösung) überschreitest, dann kannst Du halt nicht mehr einfach so ein Detail ergänzen, zumindest nicht ohne die dafür erforderlichen Informationen zur Verfügung zu haben. Evtl. könnte es auch möglich sein nur für Spezialfälle noch mal Werte nachzusenden und ansonsten erst mal die Ausgangswerte vom PM selbst zu verwenden.

Auf den zweiten Blick sehe ich übrigens schon eine Vereinfachung: Zustand 4 "Präsenzende?" ist womöglich gar nicht nötig, wenn der eigentlich nur die Nachlaufzeit abbildet. Das sollte natürlich intern im PM passiern und dann braucht es wahrscheinlich keine weitere Verlängerung. Man muss also unterscheiden zwischen pysikalischer Präsenzdetektion und dem daraus abgeleiteten Präsenzsignal (mit Nachlaufzeit).

[coko]

Richtig unklar sind ist der Reiter "bedingte übergänge". Ich denke mal, die brauch ich erst mal nicht.

Die solltest Du in der Tat vorsichtig zurückhaltend einsetzen, weil damit die Vorhersehbarkeit des resultierenden Automaten leidet. Das ist halt der Preis dafür, dass man auf diesem Wege Dinge erreichen kann die sonst nicht oder nur deutlich komplizierter möglich wären.
Zur Einführung verweise ich auf Funktionserweiterung: Bedingte Zustandsübergänge und folgende Beiträge.

Du hast in der Tabelle sogar schon an einer Stelle den Wunsch für einen Bedingten Übergang formuliert:

1 | IDLE | 1 → bleibe 1 | 2 (nur wenn B=0) | 4 (sofort AUS) | - | -

Die Tabelle kann man leider sonst nicht so gut lesen. Ist MD, kein Foren-Syntax?

Leider gibt's in der Tabelle keine bedingung auszuwählen.

Bedingte Übergänge sind mit "a>" bis "p>" in der Zustandsübergangstabelle verfügbar. Du brauchst dann noch einen LOG-Kanal zur Abbildug der Bedingung(en).
Ich würde hier aber überlegen, ob Du das wirklich brauchst, oder ob es hier nicht übersichtlicher ist die Zustände jeweils für den Fall mit/ohne Sperre abzubilden (also tendenziell zu duplizieren)