OpenKNX StateEngine: Universelle Zustandsautomaten in KNX

[skywalker007]

Ich habe nun gerade ein neues Release der State-Engine bereitgestellt.

Ich hab gerade (bevor ich neue Logiken und Automaten konfiguriere) das Update von 0.4 auf 0.6 durchgeführt und es lief extrem smooth. Selbst meine bestehenden Logiken und Automaten wurden übernommen. Dickes Lob!

[coko]

0.4 auf 0.6 durchgeführt und es lief extrem smooth. Selbst meine bestehenden Logiken und Automaten wurden übernommen. Dickes Lob!

Danke! Wir sind immer bestrebt, dass Updates ohne Konfigurationsverlust oder kompatiblitätsbrechende Änderungen möglich sind. Und meistens gelingt uns das sogar. Im Fall vom Update auf v0.6 waren sogar relativ große Änderungen mit drin, die nach mehreren Jahren Historie nötig geworden waren. Eigentlich ist der saubere Update-Pfad also eher eine "langweilige" Selbstverständlichkeit, bei der es aber um so mehr freut wenn das als positiv wahrgenommen wird. Für wesentlich spektakulärer halte ich die Möglichkeite Automaten mit aktiver Rekonstruktion sogar über (die meisten) Updates mehr oder weniger nahtlos weiterlaufen zu lassen.

Ansonsten kann ich schon mal versprechen "nach dem Update ist vor dem Update": Die 0.7-Version läuft bereits im internen Produktiv-Test und wird "bedingte Zustandsübergänge" als eine größere Funktionserweiterung einführen...

neue [...] Automaten

Darf ich neugierig sein, welche Anwendungsfälle Du damit abbildest?

[skywalker007]

Darf ich neugierig sein, welche Anwendungsfälle Du damit abbildest?

Dafür ist es noch etwas früh weil ich gerade erst angefangen habe Dinge umzusetzen, Generell habe ich damals beim Hausbau auf ein Misch-Masch von KNX und Loxone gesetzt und ich versuche step by step Loxone raus zu kriegen. Wegen Zeitmangel geht das aber eher langsam. Viele meiner simpleren automationen lassen sich durch eine Kombination von Logik und DFA abbilden und ich werd das Schritt für Schritt umsetzen. Wenn es etwas in den nächsten Monaten gibt das sich universell replizieren lässt dann werd ich es hier dokumentieren. Gestern Abend hab ich eine simple Zeitschaltuhr gebraucht die mir für Nachts eine 0 und für Tags eine 1 auf den Bus legt. Dafür reichte die Logikengine. Ich hatte nur Angst meine Config beim update zu verlieren und hab daher erstmal auf die letzte version upgedated.
Backups gehen ja nur durch kanalweisen export / import oder? Da war ich froh das es erst ein DFA und zwei Logiken waren.
Wär ja cool man könnte mit einem ps script vor dem update die ganze config runter und bei bedarf wieder hoch laden.
VG!

[mumpf]

Nicht nötig. Unser Applikationen sind und bleiben aktualisierbar. Wenn überhaupt, gibt es nur geringe manuelle nacharbeiten.

Gruß, Waldemar

[coko]

ich hatte nur Angst meine Config beim update zu verlieren und hab daher erstmal auf die letzte version upgedated.
Backups gehen ja nur durch kanalweisen export / import oder?

Backup vor einem Applikationsupdate in der ETS solltest Du (zusätzlich zum regelmäßigen Projekt-Export) anders machen: Gerät kopieren und über Inhalte Einfügen mit GA-Verknüpfung duplizieren. Dann am besten noch entsprechend Beschriften und parken. Damit hast Du auch die KO-Konfiguration erhalten. Später solltest Du die Kopie dann aus dem Projekt entfernen und das Projekt komprimieren. Die StateEngine und auch andere OpenKNX-Applikationen wie der Raumcontroller sind sehr groß, weil mehrfachen Updates wächst das Projekt sonst langfrisig stark an.

Die ETS legt intern beim Update auch eine Kopie an; die bekommt man allerdings nur zu Gesicht, wenn wirklich was schief geht. Hatte ich bewusst bislang nur im Entwicklungsprozess bei eigenen Fehlern. Ist dann Anlass dafür die Applikation und den Migrationspfad noch mal kritisch zu prüfen, noch bevor interne Tests beginnen. Wenn man bewusst drauf achtet, dann funktioniert das mit der Aktualiserbarkeit sehr gut, bzw. kann man manuellen Anpassungsbedarf zumindest dokumentieren. Resultat unseres Anspruchs siehe Waldemar.

Wär ja cool man könnte mit einem ps script vor dem update die ganze config runter und bei bedarf wieder hoch laden.

Meinst Du vom Gerät? Das wird erst mit Firmwareupdate und ggf. erforderlichem neuem Programmieren aus der ETS verändert. Die Rolle eines PS-Scripts kann ich ansonaten nicht so richtig einordnen. Der Konfigurationstransfer funktioniert anders und reizt die beschränkten Scripting-Fähigkeiten der ETS auf einer Technologiebasis aus dem letzten Jahrtausend schon recht weit aus. Für KO-Support fehlt es an einer internen API. Was ich aber schon versprechen kann: Es wird in Zukunft (irgendwann) auch noch einen Multi-Kanal-Transfer geben...

[coko]

Neues Release mit größerer Funktionserweiterung: Bedingte Zustandsübergänge

Für Nutzer die noch eine ältere Version als v0.6 nutzen: Update-Hinweise unten beachten!

Anders als beim letzten Release gibt es, neben den üblichen kleinen Detailverbesserungen, ein komplett neues größeres Feature:

(1) Mit den "Bedingten Zustandsübergängen" sind nun deutlich flexiblere Automatendefinitionen möglich, die über die Möglichkeiten des Basismodells hinausgehen und eine dynamischen Ermittlung von Folgezuständen erlauben. Alternativ zu einem festen Folgezustand (1 bis 16) kann dazu nun ein bedingter Übergang (a> bis p>) angegeben werden, der bei Aufruf in Abhängigkeit von (mindestens) einem Logik-Kanal den Folgezustand ermittelt, oder entscheidet im aktuellen Zustand zu verbleiben. Damit sind nun Verhaltensbeschreibungen möglich, die vorher viel komplizerter gewesen wären, bzw. angesichts einer deutlich höheren erofrderlichen Zustandsanzahl nicht mehr praktikabel gewesen wären. Für einen ersten Eindruck siehe die nachfolgenden Bilder; eine genauere Erklärung wird noch mal separat folgen um den Rahmen der Release-Vorstellung nicht zu sprengen.

Anwendungsbeispiele: Zustandswechsel in Abhängigkeitvon von Uhrzeit, Sonnenstand,Temperaturgrenzen, oder beliebige andere Bedingungen die direkt oder indirekt durch das Logikmodul abgebildet werden können.

Anmerkung: Dieser Ansatz ähnelt den Entscheidungs-Pseudozuständen und Bedingungen (Guards) die in UML-Zustandsdiagrammen verwendet werden, erlaubt darüber hinaus allerdings auch den Verbleib im Ausgangszustand ohne explizite Angabe; was wichtig ist für eine mehrfache Nutzung.
DFA_v0.7.1_Bedingte_Uebergaenge.png DFA_Conditional_Transitions_Example.png


(2) Detailverbesserung: Über einen zusätzlichen Eingang kann nun auch der für Timeouts ("Symbol T") definierte Folgezustand direkt aufgerufen werden. Dieser kann analog zu den Eingängen für regulären Symbole A bis H konfiguriert werden. DFA_v0.7.1_Input_T.png

(3) Vorschau auf eine erweiterte Diagnosefunktion (aktuell noch unvollständig umgesetzt!): Die Historien-Funktion liefert eine Information über die letzten verarbeiteten Symbole und kann damit unterstützen das Erreichen des aktuellen Zustands nachzuvollziehen.



Die v0.7.0/v0.7.1 läuft bei mir seit Anfang November produktiv, u.A. auch willisurf hat wieder kräftig mitgetestet und wird in Kürze interessante Anwendungsbeispiele vorstellen. Ich werde zunächst noch einige Tage den Status "Pre-Release" hinterlegt lassen (weil größerer Umbauten an zentraler Stelle erforderlich waren) und entfernen, wenn keine kritischen Fehlerberichte mehr auflaufen. Wäre daher auch dankbar für Rückmeldungen, wenn es einfach unspektakulär läuft.



Cornelius

---

Release: v0.7.1 Bedingte Zustandsübergänge


Änderungen:

• OFM-DFA auf v0.7.1:
  • Feature: Bedingte Zustandsübergänge (Verwandt, aber nicht identisch, mit UML "Choice" Pseudo-Zuständen)
    • Neuer Parameter-Block "Bedingte Übergänge"
    • Diagnose-Kommando dfaNN choice=x zum direkten Aufruf von bedingten Übergängen (unabhängig vom aktuellen Zustand)
  • Feature: Eingabe-Symbol/Eingang T zum direkten Auslösen von Timeout
  • Feature-Vorschau (Unvollständige Umsetzung!): Historien-Funktion zur Diagnose (Kommando dfaNN history)
  • Refactor: Umfangreicherer Umbau der Zustandsübergänge (Voraussetzung für bedingte Zustandsübergänge)
  • Fix/Verbesserung ETS-Applikation:
    • Fix #57: Überlappende Parameter für sich sichtbare Kanäle und Diagnose mit Schriftzugriff (ohne bekannte Auswirkungen bei der Ausführung)
    • Applikationsbeschreibung und Kontexthilfen: "Kanal verwenden?", "Ausgabe", "Ausgang n", "Pausieren erlauben?"
    • Tabelle zur Definition der Ausgänge auf 100% Breite
    • Info-Text für Text-Ausgänge
    • Info-Text für Rekonstruktion
  • Doc: Hinweise zur Integration in OpenKNX OAMs
  • Bereinigung ETS-Applikation/XML
• Update anderer OpenKNX-Module:
  • knx auf 2.2.2
  • OGM-Common auf 1.5.1
    • Hinweis: Synchronisation von Modul-Support wurde deaktiviert, da keine hardwareabhängigkeit vorhanden
  • OFM-LogicModule auf 3.7.3
  • OFM-FileTransferModule auf 0.1.4
  • OGM-HardwareConfig auf Stand 2025-10-24

Update-Hinweise für Nutzer von älterer Versionen (vor v0.6)

1. Die Geräteadresse (PA) muss erneut zugewiesen werden, da sich das interne Speicherformat im Stack verändert hat.
   • Bemerkung: Es kann sein, dass die Option zur Automaten-Rekonstruktion in diesem Szenario nicht funktioniert. Falls diese genutzt wird, so sollten nach Abschluss des Updates (Firmware und ETS-Programmierung) die Betriebszustände der Automaten überprüft werden. (... grundsätzlich ist eine Rekonstruktion auf über Upgrades hinweg möglich, den Pfad von v0.1 auf v0.7.1 habe ich jedoch nicht explizit getestet)
2. KO-Nummern im Bereich 2 bis 19 haben sich verändert.
   Ggf. vorhandene interne Referenzen müssen manuell angepasst werde.
   Zur Übersicht siehe Tabelle Änderung von zentralen Kommunikationsobjekten unten.

[coko]

.

[coko]

Wie funktionieren die bedingten Übergänge?

Bei Nutzung eines bedingten Übergangs, wird der Folgezustand abhängig vom Ausgangswert eines gewählten Logikkanals ermittelt. Wie bereits bei der Erzeugung der Eingangsymbole profitiert man damit von der großen Flexibilität des OpenKNX Logikmoduls.

Für jeden verwendeten Übergang muss man einen Logikkanal über die Kanal-Nummer auswählen, der als aktiv und mit Ausgangstyp DPT1 (Standard) konfiguriert sein muss. Anschließend kann für jeden der 3 möglichen Ausgangswerte* die Auswahl eines Folgezustand festgelegt werden:

• "" (leerer Wert / Standardauswahl)
  • Sorgt für einen Verbleib im aktuellen Zustand. D.h.: Es erfolgt kein Zustandswechsel.
  • Diese Option ist u.A. nützlich für eine mehrfache Verwendung des selben Übergangs für verschiedne Zustände
• 1 bis 16 (Zustandsnummer)
  • Wechselt in den angegebenen Zustand
• ELSE
  • Übergibt die Entscheidung an den bedingten Übergang in der nächsten (diekt folgenden) Zeile.
  • Mit dieser Option können verkettete Auswertungen von mehreren unabhängigen Bedingungen realisiert werden

Im einfachsten Fall nutzt man nur eine Zeile und reagiert nur auf den Logik-Ausgangswert "1 >": Das reicht aus um einen Zustandsübergang von einer Nebenbedingung abhängig zu machen. (Vergleichbar mit Guard-Expressions aus verschiedenen formalen Modellen).

Es ist allerdings auch möglich komplexere Auswertungen zu definieren, die dann eine Form "Wenn LOG1 ist undefiniert, dann wechsle in Zustand 10, sonst Wenn LOG2 ist 1, dann wechsle in Zustand 11, sonst Wenn LOG3 ist 0 oder undefiniert, dann wechsle in Zustand 12, sonst verbleibe im Zustand. (Für Entwickler IF-ELSE-IF-...-ELSE). Das ist etwas was ich bislang in (Open)KNX über die ETS nicht so bequem abbilden ließ.

So würde das aussehen:

	Bezeichnung	Logikkanal	1 >	0 >	undefiniert >
a	Erste Auswertung: Wenn	1	ELSE	ELSE	10
b	Zweite Auswertung: Sonst Wenn	2	11	ELSE	ELSE
c	Dritte Auswertung: Sonst Wenn + Sonst	3	-	12	12

Bei einer Verkettung von mehreren bedingten Übergängen kann die Auswertung auch irgendwo in der Mitte begonnen werden. Das konnte man bei genauem Hinsehen auch in der ersten Ankündigung schon sehen. (Für Entwickler ist es vielleicht hilfreich, dass sich mit dem Einsatz von ELSE eine gewisse Analogie zu einem Fall-Through in Switch-Case verschiedener Programmiersprachen ergibt. Der Einstieg in kann Abhängig vom Vergeleichswert an einem beliebigen Punkt erfolgen, die Ausführung läuft dann auch mit nachfolgenden Fallbehandlungen weiter bis explizit eine Rückggabe oder Abbruch erfolgt.).

Anmerkung: Eine Fortsetzung mit beliebigen bedingten Übergängen habe ich bewusst augeschlossen, weil dadurch leicht endlose Schleifen in der Auswertung entstehen können. Mit einer Fortsetzung ausschließlich in der nächsten Zeile ist die Auswertung nach spätestens 16 Durchläufen abgeschlossen. Praktische Einschränkungen habe sich daraus noch keine bekannten ergeben.

* Hintergrund: Die Logikkanäle stellen, wie bei KNX üblich, eine 3-wertige Logik bereit; so lange noch kein definierter Ausgangswert vorliegt ist das Ausgangs-KO undefiniert. Für ein definiertes Startverhalten kann und sollte daher auch ein Folgezustand für "undefiniert" festgelegt werden und nicht nur für 1 und 0.