OpenKNX Präsenzmodul: Mehrstufige Beleuchtung und/oder Grundbeleuchtung

[sleepless]

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

Sorry, hab mir die woanders zusammen gestellt, bevor ich in den Einstellungen drauf los bin. Ich hoffe, so geht's besser zu lesen.

Bildschirmfoto 2026-05-01 um 00.19.14.png

A (Welcher nachher zu einer Kombo wird, also A/B) wird mit dem 2. Ausgang des PM's belegt.
B wird mit dem Taster als Umschalter belegt, der gleichzeitig auch am PM Eingang "Automatik übersteuern" hängt.

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).

Die habe ich gesehen, hab dazu aber nichts gefunden. Danke für die Auflärung.

Was bedeutet a> denn? Das Symbol A "bevorzugt wird, wenn erfüllt" ? (Es gibt auch noch << )
Und wo bzw. wie geht's dann mit den LOG-Kanal weiter?

Sorry für die vielen Fragen.

Aber bisher echt top, wie einfach sich damit ein tatsächlicher Ablauf zusammen klicken lässt. Der einfache nachlauf funktioniert bei mir damit tadellos und wirklich 100 mal übersichtlicher.

Am PM nutze ich keine Hardware, sondern steuere den über die Telegramme meines Steinel TruePresence Sensors.

[coko]

B wird mit dem Taster als Umschalter belegt, der gleichzeitig auch am PM Eingang "Automatik übersteuern" hängt.

Das müsste dann Symbol C sein, B erzeugst Du abhängig vom Eingangswert zusammen mit A. Was für Auswirkungen hat das dann genau auf das Verhalten des PMs? (bzw. meinst Du damit den Steinel TP oder das OpenKNX VPM?) Das wird wahrscheinlich auch das Sendeverhalten des Präsenzsignals beeinflussen?

Klarer wird es wenn Du A (Präsenz=1) und B (Präsenz=0) schreibst, das bekommst Du auch genauso in der ETS zu sehen, wenn eine Eingangskombination A/B mit der Bezeichnung "Präsenz" versiehst.

Die habe ich gesehen, hab dazu aber nichts gefunden. Danke für die Auflärung.

Was bedeutet a> denn? Das Symbol A "bevorzugt wird, wenn erfüllt" ? (Es gibt auch noch << )
Und wo bzw. wie geht's dann mit den LOG-Kanal weiter?

Der Übergang a> ist vollkommen unabhängig vom Symbol A, und sort für eine einen "bedingten Übergang" mit Ermittlung des Folgezustands zur Ausführunsgzeit. Die definierts Du auf der Konfigurationsseite "Bedingte Übergänge". a bedeutet, dass die Ermittlung des Folgezustands in der Zeile a begonnen wird. Fehlt eine entsprechende Konfiguration (kein Logikkanel gewählt), oder kann diese nicht ausgewertet werden (Logikkanal selbst nicht aktiv, oder unsichtbar, ...), dann wird im Zustand verblieben. Ansonsten kannst Du abhängig vom Ausgangswert des gewählten Logikkanals (1, 0, undefiniert nach Neustart) einen Folgezustand angeben, auf die Angabe eines Folgezustands verzichten (= verbleib im Zustand), oder den Folgezustand durch die nachfolgene Zeile (mit anderer Bedingung) ermitteln lassen.

"<<" startet den Timeout neu, wird aber nicht als Zustandsaufruf gewertet. Das ist ein feiner Unterschied abhängig vom Sendeverhalten der Ausgänge. Btw.: Beim gewünschten Verbleib im Zustand solltest Du auch genau überlegen, ob Du wirklich einen Folgezuszand angeben solltest.

[sleepless]

Was für Auswirkungen hat das dann genau auf das Verhalten des PMs?

PM bezieht sich auf den virtuellen PM aus OpenKNX und der wird vom physikalischen Steinel TP gesteuert. Ich habe den Steinel "dumm" gelassen, da er es auch ist. Und das denken übernimmt nun der virtuelle PM.

Der Taster hängt am Virtuellen PM. Wie gesagt, der Steinel ist nur die "Hardware", da er willkürliches Verhalten in seiner Applikation aufzeigt.

Sorry für die Verwirrung, ich habe mich von der Bezeichnung in OpenKNX leiten lassen, dort wird nämlich immer vom "Präsenzsmelder" geredet, nicht vom vPM.

Der Übergang a> ist vollkommen unabhängig vom Symbol A, und sort für eine einen "bedingten Übergang" mit Ermittlung des Folgezustands zur Ausführunsgzeit.

Ich hab das jetzt 5x gelesen und verstehe nur die Hälfte und dann salat. Liegt aber an mir, nicht an der Erklärung.

a bedeutet, dass die Ermittlung des Folgezustands in der Zeile a begonnen wird.

Ich verstehe nicht, was das mit der Spalte zu tun hat, in der ich a-p auswähle. Wenn ich bei C = <a auswähle, was macht der dann?
Oder wenn ich bei D=<b auswähle?
Die Verbindung zu C= / D= erklärt sich nicht.

Wähle ich bei C= <a aus, ignoriert er dann A und Fängt bei B an und das auch nur, wenn C erfüllt ist oder was heißt das?
Wenn ja, wäre ich am Ziel 😀

[coko]

Ich verstehe nicht, was das mit der Spalte zu tun hat, in der ich a-p auswähle. Wenn ich bei C = <a auswähle, was macht der dann?
Oder wenn ich bei D=<b auswähle?
Die Verbindung zu C= / D= erklärt sich nicht.

Wähle ich bei C= <a aus, ignoriert er dann A und Fängt bei B an und das auch nur, wenn C erfüllt ist oder was heißt das?

Also Großbuchstaben bezeichnen die Eingabesymbole und Kleinbuchstaben bezeichnen bedingte Übergänge. Für die Verarbeitung eines bedingten Übergang spielt es keine Rolle über welches Symbol die Auslösung erfolgt, genauso wie bei den "normalen" Übergängen in denen Du direkt den Folgezustand angibst.

Hoffe, das hilft schon etwas weiter?

[mumpf]

sleepless: Ich versuch mal hier zu helfen, ihr redet aneinander vorbei (glaube ich).

• Normalerweise triggert ein Symbol (A-H) einen Zustandsübergang. Wenn Du also in einem Zustand bist (z.B. 5) und das Symbol C kommt und in Zeile 5, Spalte C ein Zustand 7 eingetragen ist, dann wird dieser Zustand betreten und der entsprechende Zustands-Ausgang sendet was. Das hast Du ja verstanden.
• Wenn kein Zustand eingetragen ist, dann passiert einfach gar nichts.
• Wenn aber <c eingetragen ist, dann wird in der Tabelle mit den Bedingten Zustandsübergängen geguckt. Die hat ja, wenn Du da mal geschaut hast, die Zeilen a-p. In dem Beispiel würde also in Zeile c geschaut werden.
• Bedingungen werden aber nicht direkt im Zustandsautomaten formuliert, sondern als Logikkanal (eine Logik ist ja nichts anderes als eine Bedingung).
• In der Tabelle "Bedingte Zustandsübergänge" wird also die Nummer einer Logik eingetragen (deren Ausgang wird betrachtet und muss DPT1 sein, also nur 0 oder 1 liefern). Jetzt kann man eintragen, was bei einer 1 passieren soll (Spalte 1>), bei einer 0 (Spalte 0>) und wenn der Ausgang der Logik undefiniert ist (das ist so lange der Fall, wie die Logik noch kein einziges Mal gelaufen ist).
• Für das, was passieren soll, hat man mehrere Möglichkeiten zur Auswahl:
  • Zustand: Dann wird dieser Zustand angesprungen
  • Leer: Es passiert nichts, Zustand wird beibehalten
  • ELSE: Prüfe noch den Zustand der nächsten Zeile (in unserem Beispiel Zeile d).

Auf diese Weise kannst Du Dir eben "bedingte Zustandsübergänge" bauen. Denn das Symbol C triggert jetzt nicht mehr fest den Zustand 7, sondern schaut in Zeile c nach. Ist der Ausgang der Logik EIN (egal, wie er berechnet wurde), dann springt er zu dem Zustand, der in Spalte 1> eingetragen ist. Ist die Logik AUS, dann zu dem Zustand, der in Spalte 0> steht. Du hast also für einen Trigger schon mal 2 Optionen. Wenn Du mit ELSE arbeitest, sogar eine Kaskade von Optionen.

Das ist sehr mächtig, bietet aber schnell Möglichkeiten, sich zu verzetteln.

Gruß, Waldemar

[coko]

mumpf danke für die ausführliche und treffende Beschreibung; ich war vorhin noch unterwegs und so ausführlich hätte das dann sicher nicht schreiben können.

[sleepless]

sleepless:[*]Wenn aber <c eingetragen ist, dann wird in der Tabelle mit den Bedingten Zustandsübergängen geguckt. Die hat ja, wenn Du da mal geschaut hast, die Zeilen a-p. In dem Beispiel würde also in Zeile c geschaut werden.

Danke. Das ergibt nun alles Sinn.
Also wenn C wahr ist, wird in die Tabelle zum ausgewählten Buchstaben gesprungen.
Dann muss ich eine Logik erstellen und in der Tabelle den korrekten Logikkanal wählen.
Je nach Status der Logik wird dann ein ausgewählter Zustand angesprungen.

Wenn ich das so richtig verstanden habe, begreife ich, wie genial mächtig dieser gesamte Baustein ist. Einfach genial.

Aber bei mir klappt der Sprung in die Tabelle nicht.
Und da habe ich ein verdacht, der als Ursache in Frage kommt.

Wie reagiert der DEA auf den Fall, dass sich 2 Symbole zur gleichen Zeit ändern? Welches Symbol "gewinnt" dann?

In meinem Fall Ändert sich A/B und C gleichzeitig, weil C der "Override" für den vPM darstellt und A/B die Reaktion des vPM auf den Override.

Ich glaube, das ich beim DEA schon lange im Funktionierenden Zustand bin und mir selbst ein Bein durch das zeitgleiche Ändern der Symbole stelle...

Das ganze Ding mit dem Override ist irgendwie super kompliziert, da der vPM den Grund für die Ausgangsänderung (also am A/B) mit liefern müsste.
Würde z.B. der vPM Ausgang "Status Automatik/Manuell" auch bei einem "Automatik übersteuern" verändern, wäre mein Problem sofort gelöst.

Ich muss mir also für den DEA (oder im Dea selbst) diesen Ausgang nachbauen, damit dort Differenziert werden kann, ob das "Aus" (A/B) vom vPM beachtet oder ignoriert werden soll.
Damit das ganze komplett wirr wird: der Override wird durch ein Umschalter gelöst (Taster). Das heißt, eine Änderung triggert den vPM Override, nicht ein Zustand. Der vPM entscheidet dann in Abhängigkeit vom Aktorzustand, ob die Änderung "Licht aus" oder "Licht ein" bedeutet.

Das jedoch kann ich nicht dem DEA übermitteln. Oder müsste dort "nachbauen" mit einer weiteren Logik.

Irgendwie bin ich da jetzt am klemmen.
Hat einer eine einfache Idee? Bei mir wird's gerade so kompliziert im Kopf, dass meine Umsetzung mit 50 Logiken zu explodieren droht 😮

[mumpf]

Du musst verinnerlichen: In KNX gibt es nichts gleichzeitig. Immer ein Telegramm nach dem anderen. Vielleicht schnell hintereinander, aber nicht gleichzeitig.

In meinem Fall Ändert sich A/B und C gleichzeitig, weil C der "Override" für den vPM darstellt und A/B die Reaktion des vPM auf den Override.

Eigentlich schreibst Du es bereits selber: C ist der Override, AB die Reaktion, konsequenter weise NACH dem Override. Du hast also genug Zeit, um mit C einen Zustand zu betreten, bei dem AB keine Rolle mehr spielt.

Ich habe mir Deinen Automaten nicht im Detail angesehen, aber

Ich muss mir also für den DEA (oder im Dea selbst) diesen Ausgang nachbauen, damit dort Differenziert werden kann, ob das "Aus" (A/B) vom vPM beachtet oder ignoriert werden soll.

Wieso Ausgang nachbauen? Du brauchst ja nur (wie oben beschrieben) einen weiteren Zustand, der von C getriggert wird. Falls Dir das nicht klar ist: Nicht jeder Zustand muss was auf den Bus senden. Du kannst auch einen Zustand annehmen und nichts nach außen hin machen, einfach nur um von da aus auf weitere Trigger reagieren.

Damit das ganze komplett wirr wird: der Override wird durch ein Umschalter gelöst (Taster). Das heißt, eine Änderung triggert den vPM Override, nicht ein Zustand.

Wenn Dir ein Trigger C nicht reicht, dann mach ein C/D mit 0/1-Auswertung. Wo ist das Problem? Vielleicht reichen die 16 Zustände nicht, aber für dieses Problem würde ich nicht so viele erwarten.

Gruß, Waldemar

[coko]

Also wenn C wahr ist, wird in die Tabelle zum ausgewählten Buchstaben gesprungen.

Den Eingabesymbolen A bis H (bzw. auch T) selbst ist kein Wahrheitswert zugeoednet. Bei der Erzeugung der Symbole ist der Wert allerdings wichtig, weil je nach Konfiguration nur Eigangsereignisse (Telegramme auf eigenem KO, Ändern von AusgangsKO eines angegebenen Logikkanals oder einer bestimmten KO-Nummer) mit Telegrammwert 1 oder 0, oder beiden Werten Berücksichtigung finden.

wie genial mächtig dieser gesamte Baustein ist. Einfach genial.

Das freut mich :-)

Wie reagiert der DEA auf den Fall, dass sich 2 Symbole zur gleichen Zeit ändern? Welches Symbol "gewinnt" dann?

Gleichzeitig gibt es auf d Bus nicht, wie schon von mumpf erklärt. Das Erzeugen von mehreren Symbolen durch das selbe Ereignis solltest Du dringend vermeiden. Ich verweise hier auch noch mal auf die Dokumentation OpenKNX Zustandsautomaten zu Eingabesymbolen.

Das ganze Ding mit dem Override ist irgendwie super kompliziert, da der vPM den Grund für die Ausgangsänderung (also am A/B) mit liefern müsste.
Würde z.B. der vPM Ausgang "Status Automatik/Manuell" auch bei einem "Automatik übersteuern" verändern, wäre mein Problem sofort gelöst.

Ich muss mir also für den DEA (oder im Dea selbst) diesen Ausgang nachbauen, damit dort Differenziert werden kann, ob das "Aus" (A/B) vom vPM beachtet oder ignoriert werden soll.
Damit das ganze komplett wirr wird: der Override wird durch ein Umschalter gelöst (Taster). Das heißt, eine Änderung triggert den vPM Override, nicht ein Zustand. Der vPM entscheidet dann in Abhängigkeit vom Aktorzustand, ob die Änderung "Licht aus" oder "Licht ein" bedeutet.

Ich habe wahrscheinlich noch nicht ganz durchdrungen wie Dein genauer Plan aussieht. Du hattest Dich zu den oben aufgeführten Definitionslücken auch noch nicht geäußert. Das könnte hilfreich sein bei der Definition des Verhaltens.

Was genau soll das "Override" denn machen?

Du hast folgenden Datenfluss:

1. Hardware-Sensor (Steinel TPM)
2. Erzeugtes Präsenz-Signal (Steinel TPM)
3. OpenKNX VPM ?
4. Eingang Zustandsautomaten
5. Eingabesymbol Zustandsautomaten
6. Resultierender Folgezustand
7. Ausgangswert von Zustandsautomat
8. Update/Senden von Ausgangs-KO von Zustandsautomat (abhängig von Sende-Konfiguration)

Wenn Du nun damit anfängst etwas zu bauen, bei dem zusätzlich ein Datenfluss in die entgegengesetzte Richtung stattfindet, dann wird das durch die Zyklen/Rückkopplung scher beherrschbar und könnte im ungünstigen Fall sogar dafür sorgen, dass Du keinen stabilen Zustand mehr erreichst.

Sorry, hab mir die woanders zusammen gestellt, bevor ich in den Einstellungen drauf los bin. Ich hoffe, so geht's besser zu lesen.

Bildschirmfoto 2026-05-01 um 00.19.14.png

A (Welcher nachher zu einer Kombo wird, also A/B) wird mit dem 2. Ausgang des PM's belegt.
B wird mit dem Taster als Umschalter belegt, der gleichzeitig auch am PM Eingang "Automatik übersteuern" hängt.

Was bedeute hier der Zustand Idle? Soll das das eingeschaltete Zustand sein? (Dann wäre die Bezeichnung unglücklich) Die fehlende Definition eines Ausgangswertes bei einem dauerhaft aktiven Zustand muss auch hinterfragt werden. Wenn Du dort keinen eindeutigen Wert angeben kannst, dann wären das eher merere verschiedene Zustände.
Und bei AUS wäre es ggf. sinnvoll zwischen Aus mit und ohne Override zu unterscheiden. und dann brauchst Du womöglich gar keine Bedingungsprüfung beim Übergang mehr:

Wenn Du mit Override den momentanen Beleuchtungszustand sperren willst, dann könnte das z.B. so aussehen:

	Beschreibung	A: Präsenz=1	B: Präsenz=0	C: Override=1	D: Override=0	Timeout	T		O1
1	EIN	1	2	? 5	-				100%
2	Nachlauf 1	1	-	? 6	-				30%
3	Nachlauf 2	1	-	? 6	-				10%
4	AUS	1	?	? 6	-				0%
5	EIN (Sperre)	-	7	-	1				100%
6	AUS (Sperre)	8	-	-	4				0%
7	EIN (Sperre, abweichend)	5	-	-	? 2				100%
8	AUS (Sperre, abweichend)	-	6	-	1				0%

Zusätzliche Zustände zur Abbildung der gesetzten Sperre. Wobei auch noch andere Konstruktionen möglich wären.

[sleepless]

Wo ist das Problem?

Das er nie den Symbol C (Override) beachtet. Immer wieder fällt er in den "Nachlauf" also den Zustand 2, welcher durch Symbol B kommt.

Du hast folgenden Datenfluss:

Mal ganz grob, also ohne die weiteren Beinchen am vPM für Helligkeit usw., sieht's so aus:
dea.jpg

Der Dea so:


Bildschirmfoto 2026-05-01 um 23.03.31.png
Bildschirmfoto 2026-05-01 um 23.03.48.png
Bildschirmfoto 2026-05-01 um 23.04.07.png
Bildschirmfoto 2026-05-01 um 23.04.15.png

Ich hoffe, das hilft ein bisschen mehr, meine Fall zu verstehen.

[mumpf]

Dein Bild oben macht es klarer, aber es fehlen noch die GA-Verknüpfungen und wie die Logik, die C/D beeinflusst, gesteuert wird. Dann könnte man das qualifiziert begutachten.

Das er nie den Symbol C (Override) beachtet. Immer wieder fällt er in den "Nachlauf" also den Zustand 2, welcher durch Symbol B kommt.

Nach 2 geht es ja nur von 1 aus, wenn vom PM ein AUS kommt. Wenn die GA so sind, wie Deine Grafik oben es impliziert, dann ist das auch erklärbar:
Da ist Taster mit PM-Automatik übersteuern und C/D verbunden. Der Taster sendet eine 0 für "Automatik übersteuern AUS". 0 triggert D, das ist leer, Zustand 1 bleibt erhalten. Kurz danach kommt vom PM AUS, Triggert B, er geht in den Zustand 2.
Die SM macht genau das, was Du eingestellt hast.

Noch ein paar Kommentare zur SM selbst:

• Zelle 1/A: Die 1 dort ist überflüssig (kann aber bleiben). Wenn die Zelle leer ist, bleibt er im Zustand. Du hast geschrieben, dass er in den selben Zustand gehen soll.
• Wenn der Override in der Bedingungs-Tabelle bei 1->4 und bei 0->4 geht, kannst Du ihn auch weglassen und in der SM direkt 4 statt a> eintragen. Die Logik (was auch immer sie macht) ist wirkungslos.

Zusammengefasst: Wenn Du in Zeile 1-3 die Spalte C leer machst und in Spalte D die 4 einträgst, hast Du das, was Du willst - zumindest soweit ich das beurteilen kann.

Gruß, Waldemar

[sleepless]

Dein Bild oben macht es klarer, aber es fehlen noch die GA-Verknüpfungen und wie die Logik, die C/D beeinflusst, gesteuert wird. Dann könnte man das qualifiziert begutachten.

GA's sind die Verbindungen. Alles, was zum Pfad connected ist, ist in einer GA.

So ist es nun klarer:
dea.jpg

Zusammengefasst: Wenn Du in Zeile 1-3 die Spalte C leer machst und in Spalte D die 4 einträgst, hast Du das, was Du willst - zumindest soweit ich das beurteilen kann.

So hatte ich es ja, bevor ich mit dem "Bedingten" gestartet hab.

Wie gesagt, ihn interessiert es einfach nicht die Bohne. Er fällt immer in die Nachläufe. jedenfalls ist es das, was das Teil macht, wenn ich den Taster drücke. Erwartet wird, dass in dem Fall das gute Stück "direkt" ausmacht, ohne den Nachlauf. Also dem folgt, was in C/D eingestellt wird. Der Taster triggert aber nur sofort den "Nachlauf" - ausgelöst vom vPM, da dieser korrekt reagiert.

Ich denke nicht, das der Fehler im Zustandsautomat liegt, sondern irgendwo in meiner Handhabung oder verknüpfungen etc.

Bitte beachte das, was ich zu der Reaktion des vPM auf dem Taster macht und was das für den DEA bedeutet. Ich zitiere aus der OpenKNX vPM Doku:

• Licht ist aus - Kurz drücken - Schaltet das Licht im Automatik-Modus ein (Licht geht ohne Präsenz nach der Nachlaufzeit aus)
• Licht ist an - Kurz drücken - Schaltet das Licht im Automatik-Modus aus (Licht geht so lange nicht an, wie Präsenz + Nachlaufzeit eingestellt sind)

Das heißt, der Taster kann seine Funktion auch umgekehrt erfüllen. Während Abends ein "EIN" das Licht aus macht, kann es tagsüber umgekehrt sein. Dieses muss der DEA irgendwie ebenso schnallen. Da sehe ich die nächste Herausforderung.

[mumpf]

So hatte ich es ja, bevor ich mit dem "Bedingten" gestartet hab.

Naja, bisher hast Du nur von C gesprochen, das ist definitiv falsch.

Die Logik so dazwischenzuschalten wie im Bild wird auch nicht funktionieren. Du Triggerst den Automaten, BEVOR die Logik ausgewertet sein kann. Aber ich würde die erstmal weglassen, die Logik verkompliziert das unnötigerweise.

Nochmal: Lösch die Sachen in Spalte C, schreibe die 4 in die Spalte D, schicke eine 0 mit dem Gruppenmonitor auf die GA, auf die der Taster sendet und Du wirst sehen, dass der Zustand 4 eingenommen wird.

Das heißt, der Taster kann seine Funktion auch umgekehrt erfüllen.

Ich kenne meine Doku . Ich weiß, dass das geht. Der Zustandsautomat ist aber nur für den AUS-Fall erstellt, für den EIN-Fall brauchst Du weitere Zustände.

Gruß, Waldemar

[mumpf]

Mir ist noch eine Kleinigkeit aufgefallen (nicht ursächlich für Dein Problem): Bei den Ausgängen willst Du bei "Zustands-Änderung" senden, nicht bei "Wert-Änderung".
Beispiel:

• Ein normaler EIN-AUS-Zyklus des PM wird dazu führen, dass nachgedimmt wird, Zustände 2, 3 und 4 werden betreten und die Werte 30%, 5% und 0% werden gesendet.
• Wenn Du dann EIN, gefolgt von einem Override machst, wird sofort Zustand 4 betreten, der letzte gesendete Wert war 0% und somit würde nicht erneut 0% gesendet werden (bei Wert-Änderung).

Gruß, Waldemar

[sleepless]

Edit: Ich habe es nun so gemacht und es geht nicht.
Es geht! Jup. Der Fehler war folgender:

• Die Ausgänge. Siehe deine "Kleinigkeit". Ohne dem schickt er nur einmal ein "Aus"
• Die Zuodrnung eines einzelnen Symbols, welches auf eine "0" reagieren soll.

Sobald ich die Symbolcombo so wie von dir angefordert eingerichtet hab und den Ausgang entsprechend veränderte und noch ein kleine falsche GA Zuordnung entfernte, läuft es nun 🤩