OpenKNX StateEngine: Universelle Zustandsautomaten in KNX

[coko]

Nach längeren internen Tests möchte ich nun endlich das Projekt vorstellen, das mich zur Entwicklung des inzwischen vielfach integrierten OpenKNX ConfigTransfers als „Nebenprodukt“ motiviert hatte.

Die StateEngine ermöglicht, eine universelle Definition von Zustands-abhängigem Verhalten von KNX direkt in der ETS. Für derartige Funktionalität war es bislang erforderlich auf externe Lösungen zurückzugreifen und die Konfiguration außerhalb der ETS durchzuführen, sofern man sich nicht auf Standard-Anwendungsfälle wie z.B. beim VPM beschränkt. Das zunächst exklusiv in der StateEngine verfügbare neue OpenKNX-Modul Zustandsautomaten (OAM-DFA) implementiert die Möglichkeit einer entsprechenden klaren, formellen, Ereignis-orientierten Verhaltensbeschreibung auf Basis von Deterministischen Endlichen Automaten (Ein sehr bekanntes Modell aus der theoretischen Informatik). Die Zustandsautomaten können und sollten in Kombination mit dem (ebenfalls enthaltenen) OpenKNX-Logikmodul eingesetzt werden. Dadurch kann je nach Anwendungsfall in beide Richtungen die Konfiguration deutlich vereinfacht werden.

Kurzbeschreibung der 16 enthaltenen Zustandsautomaten (OAM-DFA)

• 16 Zustände zwischen denen im Betrieb gewechselt wird. Ausgabe des aktuellen Zustands über KO, optional auch direkter Aufruf des Zustands über separates oder gemeinsames KO.
• 8 Eingabesymbole (A bis H), die durch bis zu 8 unabhängige DPT1 Eingabe-KOs oder Logikausgänge erzeugt werden. Durch optionale Konfiguration als Eingabesymbolpaar kann z.B. ohne weiter Vorverarbeitung auf das Auftreten oder den Wegfall von erkannter Präsenz oder Last reagiert werden.
• Ein Timeout-Eingabesymbol T wird erzeugt, wenn innerhalb eines zustands-spezifisch konfigurierten Zeitintervalls keine Eingabe erfolgt (bzw. kein anderes Ereignis eingetreten) ist.
• Für jede Kombination aus Zustand und Eingabesymbol/-Ereignis kann ein Nachfolgezustand (oder das Ignorieren) festgelegt werden.
• 4 Ausgabekanäle (O1 bis O4) mit gängigen DPTs, darunter auch ein Kanal mit Text. Für jede Kombination aus Zustand und Ausgang kann individuell ein Wert und ein fein abgestuftes Sendeverhalten definiert werden.
• Eine Rekonstruktionsfunktion ermöglicht auf Wunsch beim Neustart eine Fortsetzung in dem letzten gespeicherten Zustand/Status
• Optionale Pause-Funktion zur Unterbrechung der Ausführung per KO.

Danke

willisurf für das unabhängige Testen im Produktiveinsatz und Feedback als Basis für Detailverbeserungen, sowie die Bereitschafft eigene innovative Anwendungsbeispiele zu präsentieren. mumpf für die Möglichkeit mit dem Producer auch OpenKNX-Module zu verwenden, die die Grenzen des internen Standard-Adressierungsschemas sprenzen. Und natürlich auch weiteren zum OpenKNX-Projekten Beitragende, für das inzwischen entstandene mächtige Ökosystem aus freier Software und freier Hardware.

Anmerkungen zum aktuellen Status als Public Beta und Bitte um Tester

Die Veröffentlichung erfolgt zunächst als Beta-Release, weil der Test bislang ausschließlich intern mit einem sehr begrenzten Nutzerkreis erfolgt ist und zuletzt noch eine größere Anpassung erfolgte (zur Verbesserung der Performance in der ETS und beim Programmieren). Bei geringerem Anspruch an Qualität und Stabilität könnte man das Beta wohl auch weglassen.

Selbst habe ich das Modul inzwischen seit über einem Jahr im Produktiveinsatz, teilweise mit über 7 Monaten ununterbrochener Laufzeit. Bei willisurf ist die die StateEngine seit etwa einem halben Jahr im Einsatz. Gravierende Fehler sind in diesem Rahmen nicht mehr aufgetreten und die Basis der Implementierung ist so weit stabil. Diese Konfigurationen decken allerdings nicht alle Funktionen vollständig ab und es ist möglich, dass neue Nutzer – ohne direkten Austausch mit mir - die Applikation in einer konzeptionell nicht erwarteten Art verwenden. Angesichts der bereits erfolgten Iterationen ist vor allem mit diversen Details zu rechnen und einer auf dieser Basis folgenden Update-fähigen Nachfolge (z.B. mit Fix zur Anzeigereihenfolge der KOs an einer Stelle in der ETS enthalten wird).

Das Testen in größerer Runde ist nun ein letzter wichtiger Schritt zum ersten offiziellen Produktiv-Release. Falls Ihr Fragen oder Vorbehalte habt, die Euch vom selbst ausprobieren abhalten, dann meldet Euch einfach.Im Rahmen des geplanten OpenKNX-Treffens wird die Möglichkeit zum direkten Austausch von Erfahrungen beim Einsatz, sowie auch gemeinsamer Erarbeitung von Zustandsbeschreibungen für individuelle Anwendungen möglich sein.

Release und weitere Links

• StateEngine DFA16 v0.1 Public Beta
  • Die Firmware unterstützt verschiedene generische OpenKNX-Geräte:
    • REG1 BASE v0
    • REG1 BASE (v1)
    • PicoBCU-Connector
    • REG2
    • OpenKNXiao
• Zustandsautomaten OpenKNX (Modul OFM-DFA)
  • Applikationsbeschreibung OFM-DFA
• OpenKNX StateEngine

Viel Spaß beim Ausprobieren. Bin gespannt welche Anwendungen Ihr damit realisieren werdet und auf Eure Erfahrungsberichte; auch zu Stellen an denen noch irgendwas unerwartet läuft.

Cornelius

[coko]

Updates

2025-05:

• Vorstellung durch Torben Ledermann auf YouTube:
  So hast du Logiken noch nie programmiert! – OpenKNX StateEngine erklärt
• Integration des DFA-Moduls mit 4 Kanälen in GardenControl-Applikation

(Platzhalter für weitere Updates)

[coko]

FAQ und Tipps zur Modellierung & Nutzung

Warum ist es problematisch wenn man Ausgabewerte für einzelne Zustände einfach weglässt?

Wird für einen Zustand kein Ausgangswert festgelegt, so bleibt der letzte Wert auf dem KO erhalten. D.h.: Bei wiederholtem Aufruf des selben Zustands habe ich nicht immer den selben Ausgangswert. Das ist ungünstig weil damit eine klare Abhängigkeit des Ausgangswertes vom Zustand fehlt. Bei Zuständen die nicht automatisch (nach kurzer Zeit) verlassen werden ist das intransparent, wenn der Ausgangswert nun davon abhängt welcher oder welche Zustände vorher aktiv waren. Bei direktem Aufruf von Zuständen ist das Verhalten auch nur noch schwer nachvollziehbar. Ein Vollmüllen des Busses mit unveränderten Werten kann durch das Sendeverhalten vermieden werden. Es schadet also in keiner Weise wenn man unveränderte Ausgangswerte mehreren Zuständen zuweist.

Ergänzende Bemerkung: Das Auslassen von Ausgangswerten kann in begründeten Fällen durchaus nützlich sein, u.A. kann dadurch die Anzahl der benötigen Zustände deutlich reduziert werden. Bei Nutzung der Rekonstruktionsfunktion steht kein vorangegangener Wert zur Verfügung, d.h. das KO bleibt bei fehlendem Ausgangswert zunächst leer.

---

Kann ich die Eingabe der vielen Parameter irgendwie beschleunigen?

• Erleichterte Eingabe von Folgezuständen: Über die Tastatur kann direkt die Zustandsnummer eingegeben werden. Mit <Tab> kann zum nächsten Eingabe gewechselt werden.
• Erleichterte Eingabe des Sendeverhaltens:
  • Über die Tasten-,k(kein Senden),w(Wert),z(Zustand),j(jedes) kann die jeweilige Sendestrategie schnell ausgewählt,bzw.zwischen den verschiedenen Ausprägungen gewechselt,werden. Mit <Tab> kann zum nächsten Zustand gewechselt werden.
  • Durch Mehrfach-Auswahl (mit Strg-Taste) kann das Sendeverhalten gleichzeitig für mehrere Ausgänge gesetzt werden, da häufig in den selben Zuständen gesendet werden soll

---

Warum ist die Auswahl und Definition des Startzustands so wichtig?

Als Startzustand es es häufig nützlich erst mal einen neutralen Zustand zu nutzen, der keine Auswirkungen hat, bzw. durch die Ausgangswerte erst einmal einen "sicheren" Zustand animmt. Zumindest sollte man dort eine bewusste Definition vornehmen, mit Berücksichtigung dass ein Neustart ggf. auch nach Stromausfall in Abwesenheit erfolgen kann.

Hinweis: Bei Nutzung der Rekonstruktionsfunktion kann auch in einem anderen Zustand neugestartet werden.

---

Was kann ich tun wenn die 4 Ausgänge nicht ausreichen?
Mit verschiedenen kleinen Tricks können mehr als 4 Ausgangswerte erzeugt werden, siehe Kurzbeschreibung verschiedener Ansätze für weitere Ausgänge eines Zustandsautomaten
Hinweis: Das Verhalten bei Einsatz dieser kann in Detail abweichen von der Nutzung der integrierten Ausgänge.

(Platzhalter für Weitere FAQ)

[coko]

Anwendungsbeispiele

• Beispiel zur Einführung: Virtueller Schaltaktor mit Sperre und Treppenhaus-Funktion
• Vorverarbeitung durch Logik-Kanäle: Umwandlung von DPT2 (Zwangsführung) in Eingabesymbole
• Mehrstufiges Schalten von gedimmten Licht oder Lüftung
• Feuchtigkeitsabhängige Lüftersteuerung
• Bewässerungssteuerung
  • Bewässerungssteuerung mit Sequenz für mehrere Ventile
  • (NEU 2025-05-18) Einfache sequenzielle Bewässerung mit Öffenen und Schließen über zentrales KO zur Ventilsteuerung
  • (NEU 2025-05-18) Nutzung von mehr als 4 Ausgängen durch Kopplung von Automaten
    • Kurze Erklärung zur Automaten-Verknüpfung durch Zustandseingang mit Screenshots
    • 4 Rasenzonen nacheinander bewässern, mit 4 Ventilen, 1 Hauptventil und Status-Text
• Steuerung Tagesfalle von Haustür-Automatikschloss
  • Funktionserweiterung und Vereinfachung durch Logikkanäle:
    • Uhrzeit/Tageszeit-abhängiges Verhalten
    • Vermeidung von Zwischenzuständen für verzögerte Reaktionen
• Grobe Skizze: Sequenzsteuerung / Verzögert / Hintereinander fahren von Rolläden
• (NEU 2025-05-23) Skizze: Warnung bei lange geöffneter Tür
• (NEU 2025-05-25) Auswahl Audio-Playlists über einzlne Taste auf MDT-GT2 mit Icons und Text
• (NEU 2025-06-11) Lichtsteuerung mit Abschaltverzögerung in verschiedenen Tagesphasen als Erweiterung von PM-Automatik

(Weitere folgen)

Update-Historie:

• 2025-04-27 Ergänzt: Grobe Skizze für Sequenzsteuerung / Verzögert / Hintereinander fahren von Rolläden
• 2025-05-18 Ergänzt: Beispiele für Bewässerungssteuerung und Verknüpfung von Automaten
• 2025-05-23+2025-05-25 Ergänzt: Skizze Türwarnung + Audio-Steuerung mit Sonos-Playlisten
• 2025-06-11 Ergänzt: Beispiel zu PM-Logik mit Abschaltverzögerung

[coko]

(Platzhalter Verhaltensbeschreibung auf Basis von Deterministischen Endlichen Automaten)

[coko]

(Platzhalter für sonstige ergänzende Informationen)

[willisurf]

Ich werde nach meinem Urlaub ab Ende März mal ein paar Anwendungsbeispiele posten.
Solch ein Zustandsautomat ermöglicht sehr übersichtliche Implementierungen von sonst nur schwer umsetzbaren Anwendungen. In meinen Beispielen Sonos oder Klimaanlagensteuerung mit einem MDT Glastaster.

Gern auch live beim OpenKNX Treffen,
da fällt mir ein neben dem Testbrett auch den GT einzupacken.

[coko]

Beispiel zur Einführung: Virtueller Schaltaktor mit Sperre und Treppenhaus-Funktion

Um die Nutzung der Zustandsautomaten etwas greifbarer zu machen, habe ich nach einem Beispiel gesucht, das für möglichst viele hier nachvollziehbar ist; insbesondere auch für die ohne theoretische Vorkenntnisse aus der Informatik. Da ich voraussetzen kann, dass alle die die StateEngine nutzen wollen auch sonst mit KNX und der ETS arbeiten, gibt es praktischerweise auch ein zustandsabhängiges Verhalten, das Ihr bereits alle kennt: Die Steuerung eines Schaltaktors mit üblichen Zusatzfunktionen. Je nach Modell und Einstellung gibt es natürlich ein unterschiedliches Verhalten, das dann ggf. durch Anpassung der Automatendefinition nachgebildet werden kann.

Eingabe

Ein Schaltaktor-Kanal mit Sperre und Treppenhausfunktion verfügt über drei typische Eingangs KOs (die bei realen Aktoren u.U. nicht immer alle gleichzeitig sichtbar sind):

• Schalten – führt bei beim Eingang von 1 zum Einschalten und 0 zum Ausschalten, solange keine Sperre gesetzt ist
• Sperren – setzt oder entfernt die Sperre
• Auslöser für Treppenhaus-Funktion – führt zum Einschalten mit Automatischer Abschaltung am Ende der Nachlaufzeit, ggf. mit Vorwarnung durch kurzes Ausschalten bei Erreichen der Vorwarnzeit

Diese können wir durch 3 Eingänge abbilden, die insgesamt 5 Eingabesymbole erzeugen:

• Kombiniertes Eingabe-KO „schalten“ zur Erzeugung der Eingabesymbole A/B (bei 1/0
• Kombiniertes Eingabe-KO „sperren“ zur Erzeugung der Eingabesymbole C/D (bei 1/0)
• Einzelnes Eingabe-KO „treppenhaus“ zur Erzeugung des Eingabesymbols E (bei 1; der Wert 0 wird hier ignoriert)

Ausgabe

Weiterhin verfügt ein entsprechender Schaltaktor-Kanel z.B. über Status-Ausgangs-KOs:

• Schalt-Status (zeigt an, ob der Kanal gerade eingeschaltet ist)
• Sperr-Status (zeigt an, ob der Kana gerade gegen Steuerung gesperrt ist)
• Treppenhaus-Vorwarn-Signal für das Ende der Nachaufzeit (zeigt an ob die ein automatisches Ausschalten bevorsteht)

Diese können wir durch die Ausgänge wie folgt abbilden, hier im Beispiel noch ergänzt um die Ausgabe eines Diagnose-Textes:

• O1 „Schalt-Status“ mit Typ DPT1
• O2 „Sperr-Status“ mit Typ DPT1
• O3 „Treppenhaus Vorwarnung“ mit Typ DPT1
• O4 „Diagnose“ mit DPT16.001

DFA_Beispiel1_VSA_basis_extended_kos.png

Zustände und Übergänge

Im Betrieb kann der Aktor-Kanal nun folgende Zustände annehmen (durch die auch die Ausgangswerte festgelegt werden):

1. aus
2. aus (gesperrt)
3. ein
4. ein (gesperrt)
5. Treppenlicht ein
6. Treppenlicht ein (gesperrt)
7. Treppenlicht Vorwarnung
8. Treppenlicht Restzeit

Beim ersten Start würde im Aus-Zustand angenommen, es kann jedoch auch ein anderer Zustand gewählt werden. Durch die aktivierte Rekonstruktion wird im selben Zustand fortgesetzt. (Anmerkung: Das ist hier im Beispiel mit der Nachlaufzeit nicht schön und wird eher vom Verhalten realer Aktoren abweichen; habe ich aber für die Zukunft auch schon eine Idee für wie man das noch besser abbilden könnte)
Bei externer Ansteuerung durch einen der Eingänge oder Zeit-Ablauf wechselt der Aktor-Kanal in einen definierten Nachfolgezustand, oder kann den Versuch der Ansteuerung auch ignorieren:

1. aus
   • A -> 3 (einschalten)
   • C -> 2 (sperren)
   • E -> 5 (Treppenhaus einschalten)
2. aus (gesperrt)
   • D -> 1 (entsperren)
3. ein
   • B -> 1 (ausschalten)
   • C -> 4 (sperren)
   • E -> 5 (Treppenhaus einschalten)
4. ein (gesperrt)
   • D -> 3 (entsperren)
5. Treppenlicht ein
   • A -> 3 (einschalten)
   • B -> 1 (ausschalten)
   • C -> 6 (sperren)
   • E -> 5 (nachtriggern mit Neustart der Nachlaufzeit)
   • T (nach 4 Minuten) -> 7 (Beginn der Vorwarnzeit)
6. Treppenlicht ein (gesperrt)
   • D -> 5 (entsperren mit Neustart der Nachlaufzeit)
7. Treppenlicht Vorwarnung
   • A -> 3 (einschalten)
   • B -> 1 (ausschalten)
   • C -> 6 (sperren)
   • E -> 5 (nachtriggern mit Neustart der Nachlaufzeit)
   • T (nach 0,3s) -> 8 (kurzes Abschalten zur Warnung)
8. Treppenlicht Restzeit
   • A -> 3 (einschalten)
   • B -> 1 (ausschalten)
   • C -> 6 (sperren)
   • E -> 5 (nachtriggern mit Neustart der Nachlaufzeit)
   • T (nach 60s) -> 1 (ausschalten)

DFA_Beispiel1_VSA_table.png

Ausgänge

Die Werte der verschiedenen Ausgänge sind direkt vom Zustand abhängig. Hier im Beispiel wird durch die Einstellung des Sendeverhaltens (Details siehe Hilfetexte) erreicht, dass EIN-Werte für Schalt- und Sperrstatus regelmäßig wiederholt werden. Der Wert des Diagnose-KOs wird nicht auf den Bus gesendet, kann aber durch das Update per Read-Request abgefragt werden.

DFA_Beispiel1_VSA_O1.png DFA_Beispiel1_VSA_O2.png DFA_Beispiel1_VSA_O3.png DFA_Beispiel1_VSA_O4.png


So viel nun als erster Überblick. Ich habe das Beispiel selbst auch noch nicht exakt in dieser Form ausprobiert.

ConfigTransfer-String:

OpenKNX,cv1,0xAC0D:0x1/DFA:0x4/1§a~Name=Virtueller%20Schaltaktor§a~Active=1§a~StateRestore=1§a~SymbolPairAB=1§a~SymbolPairCD=1§a~SymbolAName:2=schalten§a~SymbolAInput:2=1§a~SymbolCName:2=sperren§a~SymbolCInput:2=1§a~SymbolEName:1=treppenhaus§a~SymbolEInput:1=1§a~Output1Name=Schalt-Status§a~Output2Name=Sperr-Status§a~Output3Name=Treppenhaus%20Vorwarnung§a~Output4Name=Diagnose§a~Output1Dpt=10§a~Output2Dpt=10§a~Output3Dpt=10§a~Output4Dpt=161§a~z01Name=aus§a~z02Name=aus%20(gesperrt)§a~z03Name=ein§a~z04Name=ein%20(gesperrt)§a~z05Name=Treppenlicht%20ein§a~z06Name=Treppenlicht%20ein%20(gesperrt)§a~z07Name=Treppenlicht%20Vorwarnung§a~z08Name=Treppenlicht%20Restzeit§a~d01A=3§a~d01C=2§a~d01E=5§a~z01o1Send=2§a~z01o1Dpt1=0§a~z01o2Send=2§a~z01o2Dpt1=0§a~z01o3Send=2§a~z01o3Dpt1=0§a~z01o4Send=1§a~z01o4Dpt16=AUS§a~d02D=1§a~z02o1Send=2§a~z02o1Dpt1=0§a~z02o2Send=3§a~z02o3Send=2§a~z02o3Dpt1=0§a~z02o4Send=1§a~z02o4Dpt16=Sperre%20AUS§a~d03B=1§a~d03C=4§a~d03E=5§a~z03o1Send=3§a~z03o2Send=2§a~z03o2Dpt1=0§a~z03o3Send=2§a~z03o3Dpt1=0§a~z03o4Send=1§a~z03o4Dpt16=EIN§a~d04D=3§a~z04o1Send=3§a~z04o2Send=3§a~z04o3Send=2§a~z04o3Dpt1=0§a~z04o4Send=1§a~z04o4Dpt16=Sperre%20EIN§a~d05A=3§a~d05B=1§a~d05C=6§a~d05E=5§a~d05T=7§a~d05TBase=1§a~d05TTime=4§a~z05o1Send=3§a~z05o2Send=2§a~z05o2Dpt1=0§a~z05o3Send=2§a~z05o3Dpt1=0§a~z05o4Send=1§a~z05o4Dpt16=Treppe§a~d06D=5§a~z06o1Send=3§a~z06o2Send=3§a~z06o3Send=2§a~z06o3Dpt1=0§a~z06o4Send=1§a~z06o4Dpt16=Sperre%20Treppe§a~d07A=3§a~d07B=1§a~d07C=6§a~d07E=5§a~d07T=8§a~d07TBase=3§a~d07TTime=3§a~z07o1Send=3§a~z07o1Dpt1=0§a~z07o2Send=2§a~z07o2Dpt1=0§a~z07o3Send=2§a~z07o4Send=1§a~z07o4Dpt16=Treppe%20Warn§a~d08A=3§a~d08B=1§a~d08C=6§a~d08E=5§a~d08T=1§a~d08TBase=1§a~d08TTime=1§a~z08o1Send=3§a~z08o2Send=2§a~z08o2Dpt1=0§a~z08o3Send=2§a~z08o4Send=1§a~z08o4Dpt16=Treppe%20Rest§;OpenKNX

Schönen Abend noch
Cornelius

[gbglace]

Nachvollziehbares Beispiel.

Eine Anlieferung von 2 Bit Zwangsführungs Telegramme lässt sich sicher auch abbilden. Wäre ja auch nur eine abweichende Übergangsoption von z.B. 1 (aus) auf direkt 4 (ein gesperrt).

Mit sowas kann man dann schon einige Anwendungen auch ertüchtigen mit Zwangsführungstelegrammen umgehen zu können.

[mumpf]

Derzeit muss man DPT2 über das Logikmodul auf 1 Bit konvertieren.

Gruß, Waldemar

[coko]

Eine Anlieferung von 2 Bit Zwangsführungs Telegramme lässt sich sicher auch abbilden.

Bis auf weiteres sind erst mal nur DPT1-Eingänge vorgesehen. Für alles was drüber hinaus habe ich eine direkte Integration eines Logik-Ausgang als Eingabekanal (der kann direkt als Quelle gewählt werden ohne Umweg über den Bus, oder über eine KO-Nummer) vorgesehen, da ich diese Form der Vorverarbeitung von Eingangswerten als häufig notwendig (oder nützlich) sehe.

Sämtliche Funktionen des Logik-Moduls nachzubauen wäre aus verschiedenen Gründen nicht praktikabel. Wenn sich im Laufe der Zeit absolute Standardfälle herauskristallisieren dann werde ich zukünftig auch noch mal über Erweiterungen nachdenken. Die dürfen aber auch nicht zu Lasten der Performance in der ETS gehen. Habe DPT2 aber trotzdem mal vorgemerkt für eine spätere Prüfung.

Werde ggf. auch noch mal ein Beispiel für einen Automaten zum Nachrüsten von Zwangssteuerung zeigen.

[lopiuh]

Firmwareinstallation, knxprod-bau, Applikationsübertragung ohne Probleme durchgeführt. Freue mich auf die ersten Experimente.

Schon jetzt: Danke an das ganze Team!

[coko]

Schon jetzt: Danke an das ganze Team!

Gerne. Das freut uns natürlich immer, wenn es einfach so funktioniert wie erwartet :-)

Freue mich auf die ersten Experimente.

Aus reiner Neugier: Hast Du ein bestimmtes Vorhaben, dass Du mit den Automaten umsetzen willst?

[coko]

Mit sowas kann man dann schon einige Anwendungen auch ertüchtigen mit Zwangsführungstelegrammen umgehen zu können.

Ich habe nun einen ersten Entwurf (bislang ungetestet) erstellt wie sowas aussehen könnte, weil man daran auch schön die Vorverarbeitung in Logik-Kanälen erklären kann.


Beispiel zur Vorverarbeitung durch Logik-Kanäle: Umwandlung von DPT2 (Zwangsführung) in Eingabesymbole
Zwangsführungstelegramme (DPT2) können 4 Werte annehmen, die nicht direkt zur Erzeugung eines Eingabesymbols verwendet werden können. Dies lässt sich jedoch einfach durch eine Vorverarbeitung mittels Logik-Kanal lösen.
Eingabesymbole können entweder individuell oder paarweise erzeugt werden. Nachfolgend werden beide Varianten gezeigt.


Einfache Umsetzung mit 4 Logik-Kanälen:
Im einfachsten Fall nutzt man für jeden (benötigten) der 4 möglichen Werte einen eigenen Logik-Kanal, der auf seinem Ausgang die Erkennung signalisiert. Dieser kann direkt in der Symbol-Definition ausgewählt werden (ohne Umweg über eine Gruppenadresse oder die Notwendigkeit die interne KO-Nummer anzugeben):dataurl568521.png
Die Logik-Kanäle (Operation „UND“) mit einem einzelnen Eingang des Typen DPT2 und jeweils einem der 4 Werte zur Definition des Eingangs als EIN (und damit die anderen drei als AUS). Die Ausgabe kann unverändert erfolgen; die AUS-Werte können unterdrückt werden, sofern diese nicht auf eine optional zu Diagnosezwecken verbundene GA gesendet werden sollen.
Tipp: Nur im ersten Logikkanal ein Eingabe-KO bereitstellen, in allen anderen das KO wiederverwenden durch relative KO-Verknüpfung.
So sieht das Ganze aus:
dataurl568523.png

Ein „Nachteil“ dieser offensichtlichen Lösung ist die Belegung von 4 Logikkanälen, während in der StateEngine im Mittel nur 3 Logikkanäle für jeden der Automaten zur Verfügung stehen. Das gleiche Ergebnis können wir jedoch auch mit nur 2 Logik-Kanälen erreichen:


Umsetzung mit 2 Logik-Kanälen und Eingangs-Paaren:
Die Eingabesymbole können in zwei Paare unterteilt werden: Normales Schalten und Schalten mit Priorität. Diese Unterteilung ist nicht unmittelbar technisch bedingt, sorgt jedoch für eine übersichtlichere Darstellung (und lässt in diesem Anwendungsfall auch die Option offen mit geringen Anpassungen einen DPT1-Wert zusätzlich für zum Erzeugen der „normalen“ Schaltaktionen zu verwenden):
dataurl568524.png
Je ein Logik-Kanal erzeugt dann nur für den Fall „Normal“ bzw. „Priorität“ eine Ausgabe entsprechend des im DPT2 enthaltenen Schaltbefehls.
Dazu werden die Logik-Kanäle (Operation „UND“) mit zwei Eingängen konfiguriert: Eingang1 mit Typ DPT2 und den jeweils passenden zwei normalen bzw. priorisierten Werten zur Definition des Eingangs als EIN. Die anderen beiden Werte setzen den Eingang1 entsprechend auf AUS. Zur Ausgabe soll nur das Bit verwendet werden, das die Schaltaktion repräsentiert. Das kann durch eine Bit-weise-UND-Verknüpfung (Ausgangswert für EIN ermitteln als Wert einer Funktion A=E1&E2) von Eingang1 mit der Konstante 0b01 (normal schalten) definiert in Eingang2 erreicht werden, bevor eine Umwandlung in DPT1 erfolgt. Für AUS darf der Ausgang nicht senden.
Siehe dazu die Tabelle:

	*/E2	L5/E1	L5/A=E1&E2	L6/E1	L6/A=E1&E2	Symbol
normal aus (0b00)	0b01	EIN	0b00 (0b00&0b01) AUS	AUS	-	B
normal ein (0b01)	0b01	EIN	0b01 (0b01&0b01) EIN	AUS	-	A
prio aus (0b10)	0b01	AUS	-	EIN	0b00 (0b10&0b01) AUS	D
prio ein (0b11)	0b01	AUS	-	EIN	0b01 (0b11&0b01) EIN	C

dataurl568525.png dataurl568527.png dataurl568529.png


Zustände und Übergänge
Vier Zustände entsprechend der Zwangsführungswerte werden definiert. Beim Eingang eines Schaltbefehls mit Priorität erfolgt immer ein Wechsel auf den angegebenen Zustand. Beim Eingang eines normalen Schaltbefehls erfolgt ein Zustandswechsel nur dann, wenn aktuell ein normaler Zustand aktiv ist, oder aktuell derselbe Schaltzustand nur mit Priorität besteht, d.h. allein die Priorität deaktiviert wird.
dataurl568536.png
Optional kann ein automatischer Rückfall auf die Normal-Zustände definiert werden, durch Nutzung der Timeout-Funktion. In diesem Fall i.d.R. um einen erneuten Aufruf des bestehenden Zustands falls ein entsprechendes Schaltsignal eingeht


Konfigurationsexport (Variante mit 4 Logik-Kanälen):
DFA-Kanal 4 + Logik-Kanäle 7 bis 10

OpenKNX,cv1,0xAC0D:0x1/DFA:0x4/4§a~Name=Schalten%20mit%20Zwangsf%C3%BChrung%20(4%20Logiken)§a~Active=1§a~SymbolAName:1=EIN%20(std)§a~SymbolAInput:1=3§a~SymbolALogicNumber:1=7§a~SymbolBName=AUS%20(std)§a~SymbolBInput=3§a~SymbolBLogicNumber=8§a~SymbolCName:1=EIN%20prio§a~SymbolCInput:1=3§a~SymbolCLogicNumber:1=9§a~SymbolDName=AUS%20prio§a~SymbolDInput=3§a~SymbolDLogicNumber=10§a~Output1Name=schalten§a~Output2Name=sperren§a~Output4Name=Diagnose§a~Output1Dpt=10§a~Output2Dpt=10§a~Output4Dpt=161§a~z01Name=aus§a~z02Name=ein§a~z03Name=aus%20(priorisiert)§a~z04Name=ein%20(priorisiert)§a~d01A=2§a~d01C=4§a~d01D=3§a~z01o1Send=2§a~z01o1Dpt1=0§a~z01o2Send=2§a~z01o2Dpt1=0§a~z01o4Send=2§a~z01o4Dpt16=aus§a~d02B=1§a~d02C=4§a~d02D=3§a~z02o1Send=2§a~z02o2Send=2§a~z02o2Dpt1=0§a~z02o4Send=2§a~z02o4Dpt16=ein§a~d03B=1§a~d03C=4§a~z03o1Send=2§a~z03o1Dpt1=0§a~z03o2Send=2§a~z03o4Send=2§a~z03o4Dpt16=aus%20PRIO§a~d04A=2§a~d04D=3§a~z04o1Send=2§a~z04o2Send=2§a~z04o4Send=2§a~z04o4Dpt16=ein%20PRIO§;OpenKNX
OpenKNX,cv1,0xAC0D:0x1/LOG:0x35/7§f~Name=DPT2%20%3D%3D%20ein%20std%20(DFA%20Beispiel)§f~Logic=1§f~NameInput1=Zwangsf%C3%BChrung§f~E1=1§f~E1Dpt=1§f~NameOutput=DFA%20Zwang%20A%20(ein%20std)§;OpenKNX
OpenKNX,cv1,0xAC0D:0x1/LOG:0x35/8§f~Name=DPT2%20%3D%3D%20aus%20std%20(DFA%20Beispiel)§f~Logic=1§f~NameInput1=Zwangsf%C3%BChrung§f~E1=1§f~E1Dpt=1§f~E1OtherKORel=-3§f~E1UseOtherKO=2§f~E1Low0Dpt2=0§f~NameOutput=DFA%20Zwang%20B%20(aus%20std)§;OpenKNX
OpenKNX,cv1,0xAC0D:0x1/LOG:0x35/9§f~Name=DPT2%20%3D%3D%20ein%20prio%20(DFA%20Beispiel)§f~Logic=1§f~NameInput1=Zwangsf%C3%BChrung§f~E1=1§f~E1Dpt=1§f~E1OtherKORel=-6§f~E1UseOtherKO=2§f~E1Low0Dpt2=3§f~NameOutput=DFA%20Zwang%20C%20(ein%20prio)§;OpenKNX
OpenKNX,cv1,0xAC0D:0x1/LOG:0x35/10§f~Name=DPT2%20%3D%3D%20aus%20prio%20(DFA%20Beispiel)§f~Logic=1§f~NameInput1=Zwangsf%C3%BChrung§f~E1=1§f~E1Dpt=1§f~E1OtherKORel=-9§f~E1UseOtherKO=2§f~E1Low0Dpt2=2§f~NameOutput=DFA%20Zwang%20D%20(aus%20prio)§;OpenKNX

Konfigurationsexport (Variante mit 2 Logik-Kanälen):
DFA-Kanal 3 + Logik-Kanäle 5 und 6

OpenKNX,cv1,0xAC0D:0x1/DFA:0x4/3§a~Name=Schalten%20mit%20Zwangsf%C3%BChrung%20(2%20Logiken)§a~Active=1§a~SymbolPairAB=1§a~SymbolPairCD=1§a~SymbolAName:2=normal§a~SymbolAInput:2=3§a~SymbolALogicNumber:2=5§a~SymbolCName:2=prio§a~SymbolCInput:2=3§a~SymbolCLogicNumber:2=6§a~Output1Name=schalten§a~Output2Name=sperren§a~Output4Name=Diagnose§a~Output1Dpt=10§a~Output2Dpt=10§a~Output4Dpt=161§a~z01Name=aus§a~z02Name=ein§a~z03Name=aus%20(priorisiert)§a~z04Name=ein%20(priorisiert)§a~d01A=2§a~d01C=4§a~d01D=3§a~z01o1Send=2§a~z01o1Dpt1=0§a~z01o2Send=2§a~z01o2Dpt1=0§a~z01o4Send=2§a~z01o4Dpt16=aus§a~d02B=1§a~d02C=4§a~d02D=3§a~z02o1Send=2§a~z02o2Send=2§a~z02o2Dpt1=0§a~z02o4Send=2§a~z02o4Dpt16=ein§a~d03B=1§a~d03C=4§a~z03o1Send=2§a~z03o1Dpt1=0§a~z03o2Send=2§a~z03o4Send=2§a~z03o4Dpt16=aus%20PRIO§a~d04A=2§a~d04D=3§a~z04o1Send=2§a~z04o2Send=2§a~z04o4Send=2§a~z04o4Dpt16=ein%20PRIO§;OpenKNX
OpenKNX,cv1,0xAC0D:0x1/LOG:0x35/5§f~Name=DPT2%20%7C%20nur%20ohne%20prio%20§f~Logic=1§f~NameInput1=Zwangsf%C3%BChrung§f~E1=1§f~E1Dpt=1§f~E1Low0Dpt2=0§f~E1Low1Dpt2=1§f~NameInput2=Bit-Maske%20f%C3%BCr%20Schalt-Wert%20(0b01)§f~E2ConvertSpecial=5§f~E2=1§f~E2Dpt=1§f~E2LowDpt2Fix=1§f~NameOutput=DFA%20Zwang%20A%2FB%20(ohne%20prio)§f~OOn=8§f~OOnAll=8§f~OOnFunction=9§f~OOff=0§f~OOffAll=0§;OpenKNX
OpenKNX,cv1,0xAC0D:0x1/LOG:0x35/6§f~Name=DPT2%20%7C%20nur%20mit%20prio%20§f~Logic=1§f~NameInput1=Zwangsf%C3%BChrung§f~E1=1§f~E1Dpt=1§f~E1OtherKORel=-3§f~E1UseOtherKO=2§f~E1Low0Dpt2=2§f~E1Low1Dpt2=3§f~NameInput2=Bit-Maske%20f%C3%BCr%20Schalt-Wert%20(0b01)§f~E2ConvertSpecial=5§f~E2=1§f~E2Dpt=1§f~E2LowDpt2Fix=1§f~NameOutput=DFA%20Zwang%20C%2FD%20(prio)§f~OOn=8§f~OOnAll=8§f~OOnFunction=9§f~OOff=0§f~OOffAll=0§;OpenKNX

Schönen Sonntag
Cornelius

[gbglace]

Das ist dochmal eine Ausarbeitung. Sehr ordentlich.