OpenKNX StateEngine: Universelle Zustandsautomaten in KNX

[lopiuh]

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

Eigentlich will ich nahezu jedes Logikproblem als Zustandsautomat umsetzen, da ich so sicher bin, alle Zustände zu durchdenken, bzw. im else eine Debugausgabe zu bekommen, dass ein unbedachter Fall vorliegt.

Ich setze gerade eine Lüftersteuerung im Timberwolfserver mit klassischer Logik um (in den TWS arbeite ich mich gerade ein) und werde danach das ganze mal mit dem KNX-Modul machen. Ich habe einfach noch nicht die richtige Lösung, in der ich routiniert und schnell bin, um Logiken für die Hausautomatisierung (primär KNX) umzusetzen. Was noch aussteht ist, ist der Test von SmarthomeNG/Homeassistant/OpenHAB/...

Gruß

lopiuh

[gbglace]

HA und Logiken muss man auch irgendwie richtig wollen min. das was Du da vorhast sind dann entweder von anderen fertig gebaute Komponenten oder wildes Geklicke in Automationen Helfern usw. Oder eine Auslagerung in NR wo Du dann auch schneller bist mit JS Dir alles in einem functionNode in klassischer Hochsprache zu programmieren.

Und all das ist dann doch anders als der Aufbau der nativen KNX Logik. Und da sind der TWS und das Logikmodul hier gar nicht soweit auseinander, das UI ist halt verschieden.

[lopiuh]

Ja, mich spricht eher reiner Code oder eine übersichtliche Tabelle an. Die Customlogiken vom TWS sind da nochmal ein weiterer Weg. Da darin aber so viel umgesetzt wurde/werden kann, will ich das mal intensiver im Haus einsetzen. Die Lernkurve ist auf jeden Fall steil ;-)

[coko]

Eigentlich will ich nahezu jedes Logikproblem als Zustandsautomat umsetzen

Es freut mich natürlich erst einmal, dass Du einen intensiven Einsatz des DFA-Moduls in der StateEngine planst; ich befürchte jedoch, ich muss Deinen Enthusiasmus hier zunächst wieder etwas bremsen und davor warnen die Automatendefinitionen pauschal als Lösung für alle „Logikprobleme“ zu sehen!

Die Zustandsautomaten sind nicht geeignet, und auch nicht vorgesehen, als Ersatz für (die ebenfalls aus StateEngine enthaltenen) Logikkanäle. Es gibt zwar Problemstellungen die Du sowohl über die Logikkanäle oder (Teile von) Zustandsautomaten lösen kannst, Fälle in denen beides gleich gut passt dürften allerdings eher selten sein. Die Nutzung des unpassenden Ansatzes wird die Komplexität nur unnötig erhöhen.

Vor der Implementierung des DFA-Moduls hatte ich damit experimentiert Deterministischen Endlichen Automaten durch das Logikmodul abzubilden. Grundsätzlich wäre das sogar möglich, aber es braucht für einen Automaten sehr viele Logikkanäle (und durch die verteilte Verarbeitung könnten ein undefiniertes Verhalten auftreten bei zeitnah auftretenden Eingangsereignissen). Umgekehrt kann man auch einfache Logik-Funktionen durch einen Zustandsautomaten abbilden, dieser wird allerdings sehr komplex und das Risiko ist hoch dort einen falschen Zustandsübergang zu definieren (Ggf. werde ich das auch noch mal als abschreckendes Beispiel präsentieren). Von beiden Varianten ist entsprechend also abzuraten und es ist wichtig das zum Problem passende Modul zu nutzen.

Beispiel:

• Willst Du ermitteln ob zwei Türen A und B beide geschlossen sind dann machst Du das besser mit einem Logikkanal. Auch wenn Du das Ergebnis als die beiden Zustände „beide geschlossen“ und „mindestens eine Tür ist geöffnet“ interpretieren kannst. Die Reihenfolge der Status-Wechsel der Türen ist hier egal.
• Willst Du allerdings ermitteln, ob Tür A nach Tür B verschlossen wurde, dann solltest Du einen Zustandsautomaten verwenden.

… alle Zustände zu durchdenken, bzw. im else eine Debugausgabe zu bekommen, dass ein unbedachter Fall vorliegt.

Da kann ich Deiner Vorstellung noch nicht so ganz folgen: Wo siehst Du denn die Debug-Ausgabe im „else“? Was auf jeden Fall sehr gut möglich ist mit dem formalen Modell ist das Erkennen nicht bedachter Zustandswechsel; insbesondere in der Tabellarischen Darstellung fallen die sehr schnell auf.

[lopiuh]

Hallo coko,

danke für Deine ausführliche Antwort und sorry, dass ich so spät antworte. Ich bin grade in der Einarbeitung ins Logikmodul vom TWS und dem Versuch mit LLMs komplexere Logiken (link) und die Dokumentation (link) erstellen zu lassen, was hier: (Vorstellung: ETS-Gruppenadressen Generator (Blocksystem)) schon prächtig funktioniert hat.

Eigentlich will ich nahezu jedes Logikproblem als Zustandsautomat umsetzen, da ich so sicher bin, alle Zustände zu durchdenken, bzw. im else eine Debugausgabe zu bekommen, dass ein unbedachter Fall vorliegt.

Da kann ich Deiner Vorstellung noch nicht so ganz folgen: Wo siehst Du denn die Debug-Ausgabe im „else“? Was auf jeden Fall sehr gut möglich ist mit dem formalen Modell ist das Erkennen nicht bedachter Zustandswechsel; insbesondere in der Tabellarischen Darstellung fallen die sehr schnell auf.

Ich glaube, ich meine genau das, was Du gerade beschrieben hast:
Die Idee war, dass die Tabelle mit den Zustandsübergängen jede "valide" (durchdachte) Kombination von

• Ereignis
• Variablenwerte (wenn das System das zulässt)
• dem Zustand_alt (als Literal / Enumeration / integer / Bitmaske)
• dem Zustand_neu

abbildet. Wenn dann in der Welt eine Situation eintritt, und keine Zeile matched, greift eine "CatchAll" Zeile (das meinte ich mit else) und macht was sinnvolles oder/und eine Debugausgabe. Das Gefühl, wann Zustandstabellen/statemachine nicht zielführend ist, habe ich noch nicht.

Bislang habe ich für komplexe Probleme in der Regel Wahreitstabellen erstellt, durch "Irrelevanzanzeiger" verdichtet und dadurch eine umfassende Darstellung aller (theoretisch) möglichen Kombinationen bekommen.

Gruß

Franky

[coko]

Ich glaube, ich meine genau das, was Du gerade beschrieben hast:
Die Idee war, dass die Tabelle mit den Zustandsübergängen jede "valide" (durchdachte) Kombination von

• Ereignis
• Variablenwerte (wenn das System das zulässt)
• dem Zustand_alt (als Literal / Enumeration / integer / Bitmaske)
• dem Zustand_neu

abbildet. Wenn dann in der Welt eine Situation eintritt, und keine Zeile matched, greift eine "CatchAll" Zeile (das meinte ich mit else) und macht was sinnvolles oder/und eine Debugausgabe.

Ich bin mir da noch nicht so sicher, ob wir wirklich die selbe Vorstellung haben.

• Ereignisse werden durch die Spalten mit den Eingabesymbolen (A-H sowie T) der Tabelle abgebildet
• "Zustand_alt", bzw. der Zustand in dem das Eintreten der Eingabesymbole ausgewertet wird, hast Du in den Zeilen der Tabelle - als Integer bzw. Szenennummer. Du kannst hier natürlich eine Codierung wählen, in denen die 4 Bits eine bestimmte Bedeutung erhalten. Vorteile abgesehen von einer möglichen externen Auswertung hast Du damit aber erst mal nicht. Und in den meisten Fällen sollte das durch die 4 individuellen Ausgangswerte einfacher sein.
• Zustand_neu legst Du im Schnittpunkt zwischen "Zustand_alt" und "Ereignis" fest.

Beim "Variablenwerte" ist unklar was Du damit meinst:

• Momenttanwerte von GAs auf dem Bus, bzw. Eingangs-KOs/-Kanäle? - die finden keine direkte Berücksichtigung, bzw. können sich je nach Zustandsautomat jedoch direkt aus dem Zustand ergeben: Falls Zustände ausschließlich dann aufgerufen werden ein bestimmter Wert eingeht und (und die beim Eingang aller anderen Werte verlassen werden). Das wäre auch nicht hilfreich, wenn Du die zusätzlich zum Zustand noch betrachten wolltest, weil Du dann (mit d:Z×V×X→Z∪{undef} statt d:Z×X→Z∪{undef}) eine deutlich größere Definitionsmenge betrachten müsstest. Aktuell hast Du |Z×X|=16*9=144, nimmst Du nur 4 Binär-Eingänge dazu (bei denen jeweils auch der mögliche Initial-Zustand undefiniert mit betrachtet werden muss!) dazu, so ergeben sich bereits |Z×V×X|=16*(3^4)*9=11664 (die trivialen Fälle für direkten Zustandsaufwurf habe ich hier ausgeblendet). Bei Verwendung der selben Variablen die auch die Ereignisse auslösen, würde sich daraus auch eine Redundanz ergeben. I.d.R. brauchst Du das aber auch nicht, da der erreichte Zustand auch schon eine anwendungsfallspezifische Interpretation des relevanten Umgebungsbildes enthält. Theoretisch besteht durch den Direktaufruf von Zuständen auch die Möglichkeit etwas ähnlich zu realisieren. Das würde die Komplexität aber deutlich steuern. Was ich an dieser Stelle ausdrücklich empfehlen möchte ist das Starten in einem Zustand "undefiniert" in bewusst keine Annahmen über die Umgebung getroffen werden.
• Zustands-Spezifische Ausgangswerte? Die kannst Du natürlich sehr leicht als weitere Spalten in einer erweiterten Tabelle aufnehmen:

z	A	B	C	D	E	F	G	H		O1	O2	O3	O4
1	2		3							0%			"aus"
2	3	1	3	1						10%			"orientierung"
3	4	2		1						50%			"normal"
4		3	3	1						100%			"maximum"

Das Gefühl, wann Zustandstabellen/statemachine nicht zielführend ist, habe ich noch nicht.

Bislang habe ich für komplexe Probleme in der Regel Wahreitstabellen erstellt, durch "Irrelevanzanzeiger" verdichtet und dadurch eine umfassende Darstellung aller (theoretisch) möglichen Kombinationen bekommen.

Dann hast Du bisher wahrscheinlich eher zustands-/gedächtnislose Definitionen vorgenommen?

In einer Wahrheitstabelle definiert sich der Ausgangswert durch die Kombination aller Eingangswerte. Bei Vorliegenden der selben Eingangswerte erhälst Du, auch bei wiederholtem Setzen von unveränderten Werten, immer den selben Ausgangswert. Es erfolgt auch keine Auswertung von Ereignissen wie eingehenden Befehlen, sondern höchstens eine Reaktion auf Änderung von Werten.

Mit den Zustandsautomaten kannst Du auf wiederholte Ereignisse in Abhängigkeit vom aktuellen Zustand jedes mal anders reagieren. Habe in der Tabelle oben mal dargestellt wie ein mehrstufiges Schalten einer gedimmten Beleuchtung (auch analog auch eine Lüftungssteuerung) aussehen könnte: mit A würde immer zu nächsthöheren Stufe weitergeschaltet, mit B die Stufe reduziert (bietet sich hier als Eingabepaar an), mit C würde direkt auf die Stufe normal geschaltet und mit D direkt aus. Anmerkung: Vereinfachtes Modell, ohne Berücksichtigung externer Steuerung.

Ich bin grade in der Einarbeitung ins Logikmodul vom TWS und dem Versuch mit LLMs komplexere Logiken (link) und die Dokumentation (link) erstellen zu lassen, was hier: (Vorstellung: ETS-Gruppenadressen Generator (Blocksystem)) schon prächtig funktioniert hat.

Gerade bei komplexeren Logiken wäre ich da vorsichtig. Dafür habe ich schon zu oft erlebt, dass die LLMs bei überschreiten von Komplexitätsgrenzen z.B. Teile von Anforderungen unterschlagen und sogar noch auf Nachfrage zwischen verschiedenen unvollständigen Lösungen hin und herspringen. Das Skizzieren eines Zustandsautomaten auf einem Blatt Papier mit graphischer Notation (möglich, dass ich da schon erwähnt hatte) wird Dir ggf. deutlich schneller ein Ergebnis liefern und Du hast auch direkt eine erste Dokumentation...

[lopiuh]

Ich bin mir da noch nicht so sicher, ob wir wirklich die selbe Vorstellung haben.

Ja, ist ja auch komplex das Thema und du bist um mehrere Größenordnungen tiefer drin als ich ;-)

• Ereignisse werden durch die Spalten mit den Eingabesymbolen (A-H sowie T) der Tabelle abgebildet

OK, meine "Variablen" waren (gedanklich) die Spalten. Habe jetzt aber verstanden, wie es hier funktioniert.

• "Zustand_alt", [...]
• Zustand_neu. [...].

ja, verstanden

Beim "Variablenwerte" ist unklar was Du damit meinst:

• Momenttanwerte von GAs auf dem Bus, bzw. Eingangs-KOs/-Kanäle? - [ ... Berechnungen ... ]

Das muss ich erstmal verdauen ;-) Vielen Dank dafür, das muss ich verstehen.

Ja, ich meinte damit irgendwelche Daten, die (zustandsabhängig) eine Rolle spielen, also vermutlich, wie Du schreibst, "Zustands-Spezifische Ausgangswerte?"

Du bisher wahrscheinlich eher zustands-/gedächtnislose Definitionen vorgenommen?

Ja! und ich habe das alles in einen Topf geworfen bzw. erweitere diese "Zustands-/gedächtnislose Definition" nun mit einem "Zustands-enum"

Mit den Zustandsautomaten kannst Du auf wiederholte Ereignisse in Abhängigkeit vom aktuellen Zustand jedes mal anders reagieren. Habe in der Tabelle oben mal dargestellt wie ein mehrstufiges Schalten einer gedimmten Beleuchtung (auch analog auch eine Lüftungssteuerung) aussehen könnte: mit A würde immer zu nächsthöheren Stufe weitergeschaltet, mit B die Stufe reduziert (bietet sich hier als Eingabepaar an), mit C würde direkt auf die Stufe normal geschaltet und mit D direkt aus. Anmerkung: Vereinfachtes Modell, ohne Berücksichtigung externer Steuerung.

Das werde ich mir alles noch mal genau durchdenken müssen, insbesondere wann welche Lösung optimalerweise zu verwenden ist.
Ich setze die Lüftersteuerung aus o.g. Thread jetzt erstmal mit dem "StateMachine-Modul" vom TWS um und dann reflektiere ich, ob es einfacher geht 😀

Gerade bei komplexeren Logiken wäre ich da vorsichtig. [...]

Ja, ich nehme gerade 2.5 gemini Exp 03-25 und das hat einen riesen Schritt mit dem großen Tokenspeicher nach vorne gemacht. Aber ich weiß was Du meinst. Neben dem Halluzinieren ist das geringe Gedächnis ein Problem.

Das Skizzieren eines Zustandsautomaten auf einem Blatt Papier mit graphischer Notation (möglich, dass ich da schon erwähnt hatte) wird Dir ggf. deutlich schneller ein Ergebnis liefern und Du hast auch direkt eine erste Dokumentation...

ok, das müsste ich üben. Bin da noch sehr tabellenbezogen.

Liebe Grüße

Frank

[coko]

Ja, ich meinte damit irgendwelche Daten, die (zustandsabhängig) eine Rolle spielen, also vermutlich, wie Du schreibst, "Zustands-Spezifische Ausgangswerte?"

Die Ausgangswerte sollten keinen Einfluss haben auf die Zustandsverarbeitung selbst. Inbesondere sollten diese (normalerweise) nicht zur Erzeugung von Eingangsymbolen führen, weil das dazu führen kann, dass der Automat keinen stabilen Zustand annimmt.

Ja! und ich habe das alles in einen Topf geworfen bzw. erweitere diese "Zustands-/gedächtnislose Definition" nun mit einem "Zustands-enum"
[...]
Das werde ich mir alles noch mal genau durchdenken müssen, insbesondere wann welche Lösung optimalerweise zu verwenden ist.
Ich setze die Lüftersteuerung aus o.g. Thread jetzt erstmal mit dem "StateMachine-Modul" vom TWS um und dann reflektiere ich, ob es einfacher geht 😀
[...]
ok, das müsste ich üben. Bin da noch sehr tabellenbezogen.

Damit machst Du Dir das Leben wahrscheinlich eher schwer. Überlege lieber zunächst welche Betriebszustände Du überhaupt Du überhaupt von außen unterscheiden musst, und bei welchem Ereignis ein Wechsel stattfindet.

Im Fall von Deiner Lüftersteuerung (habe ich nur kurz überflogen) gibt es mindestens folgende Zustände:

• aus
• ein (manuell)
• ein (automatisch)
• ein (nachlaufzeit)

und folgende Ereignisse:

• manuell einschalten
• manuell ausschalten
• feuchtigkeitsschwelle überschritten
• trocken-schwelle unterschritten

Damit erhälst Du dann einen Automaten der in in einer graphischen Darstellung (hier UML-StateChart-Notation, für DEAs verwendet man sonst Kreise für die Zustände) etwa so aussieht: (ersten einfachen Entwurf, in wenigen Minuten entstanden. Da fehlen sicher noch Details und Übergänge):
grafik.png

Das TWS-StateMachine-Modul unterscheidet sich konzeptionell in einigen Punkten, soweit ich das nach kurzem Blick sehe. U.A. bin ich mir nicht sicher ob das Ereignis-Basiert verarbeitet wird und die Timeouts hängen nicht vom Zustand sondern vom vorangegangenen Zustandsübergang ab.

[lopiuh]

Die Ausgangswerte sollten keinen Einfluss haben auf die Zustandsverarbeitung selbst. Inbesondere sollten diese (normalerweise) nicht zur Erzeugung von Eingangsymbolen führen, weil das dazu führen kann, dass der Automat keinen stabilen Zustand annimmt.

ok, ich meinte Eingangsdaten, die die Zustandsermittlung beeinflussen. Das wäre für das OpenKNX-Modul dann wohl ein weiteres Ereignis (wenn es in irgendeinem Zustand Relevanz hat).

Damit erhälst Du dann einen Automaten der in einer graphischen Darstellung (hier UML-StateChart-Notation, für DEAs verwendet man sonst Kreise für die Zustände) etwa so aussieht: (ersten einfachen Entwurf, in wenigen Minuten entstanden. Da fehlen sicher noch Details und Übergänge):

Danke!

Das TWS-StateMachine-Modul unterscheidet sich konzeptionell in einigen Punkten, soweit ich das nach kurzem Blick sehe. U.A. bin ich mir nicht sicher ob das Ereignis-Basiert verarbeitet wird und die Timeouts hängen nicht vom Zustand sondern vom vorangegangenen Zustandsübergang ab.

Ereignisbasiert schon. Jedoch nicht auf Ebene der statemachine, da diese ja nur eine Funktion ist, die man in einer "Logikeinheit) nutzen kann. Diese "Logikeinheit" wirfd über Trigger, also Wertänderungen, Timerabläufe aufgerufen. Nutzt man den statemachine-Baustein, kann man individuell für jeden Zustand(_alt) eine Bedingung auswerten lassen. Ist das Ergebnis der Bedingung TRUE, ist es ein Match für die Zeile, weitere Verlgeiche werden abgebrochen und der "Übergang" findet statt.

Danach macht man ein Case auf den Zustand(_neu), um Dinge zu tun.

Wobei ich mich grad frage, ob der Übergang, also ob man von "a" nach "x" oder von "b" nach "x" übergeht unterschieden wird in einer Standard statemachine. Beim Timberwolf wohl nicht, wenn ich das richtig verstehe.

Ich denke schon, dass es wichtig ist, da man ja Zustand_alt abhängig ggf. unterschiedliche Aufräumaktionen ausführen will. Oder ist das dann ein individueller Folgezustand? Also wenn von "a" nach "x" was anderes gemacht werden muss als von "b" nach "x", dann sind es zwei unterschiedliche Folgezuständem also "x_Variante_kommt_von_a" und "x_Variante_kommt_von_b"? Ist das so? Kann man das pauschal beantworten? Ich muss doch mal tiefer in die formale Definition und die Varianten von Zustandsmaschinen eintauchen.

Das mit dem timeout beim Timberwolf ist richtig. Der ist relativ zum konkreten Übergang. Den statemachine-Timer kann ich in meinem Fall nicht nutzen, da ich bei dem Feature "Sicherheitsabschaltung max Laufzeit" einen Timer benötige, der über mehrere Zustände / Übergänge aktiv ist (Feuchtelüften -> Nachlauf summiert die Laufzeit). Dafür gibts einen Monoflop Baustein, den man dann in bestimmten Zuständen startet / stoppt. Läuft er ab, ist es ein event für die Logik und eine mögliche Eingangsgröße, um die Bedingung zu beeinflussen, die die statemachine für den Zustand_alt dann prüft.

Gruß

Franky

[coko]

Ereignisbasiert schon. Jedoch nicht auf Ebene der statemachine, da diese ja nur eine Funktion ist, die man in einer "Logikeinheit) nutzen kann. Diese "Logikeinheit" wirfd über Trigger, also Wertänderungen, Timerabläufe aufgerufen. Nutzt man den statemachine-Baustein, kann man individuell für jeden Zustand(_alt) eine Bedingung auswerten lassen. Ist das Ergebnis der Bedingung TRUE, ist es ein Match für die Zeile, ewitere Verlgeiche werden abgebroichen und der "Übergang" findet statt.

Wenn ich das richtig verstehe, dann erfolgt die Auswertung der Bedingungen im TWS-StateMachine-Module also nicht zwingend zusammen mit Änderung der Bedingungs-Ergebnisse, sondern muss gesondert angestoßen werden?

Wobei ich mich grad frage, ob der Übergang, also ob man von "a" nach "x" oder von "b" nach "x" übergeht unterschieden wird in einer Standard statemachine. Beim Timberwolf wohl nicht, wenn ich das richtig verstehe.

Es gibt unterschiedliche Arten von Automaten: Bei Mealy-Automat hast Du eine Ausgabe in Abhängigkeit vom Zustandsübergang (Ausgangszustand und Eingabeysmbol - also sogar noch mehr als das was Du beschreibst), bei Moore-Automaten ist die Ausgabe nur vom aufgerufenen Zustand abhängigkeit. Beim Timeout hat das TWS-Modul wohl die Charakteristik eines Mealy-Automaten, bei den möglichen Ausgaben gibt es aber wohl keine Unterscheidung (also wie bei Moore). Das ist aber keine zwingende Einschränkung, da Du zwischen den Typen umwandeln kannst (das ist der Vorteil einer solchen theoretischen Basis), was Du selbst angedacht hast:

Ich denke schon, dass es wichtig ist, da man ja Zustand_alt abhängig ggf. unterschiedliche Aufräumaktionen ausführen will. Oder ist das dann ein individueller Folgezustand? Also wenn von "a" nach "x" was anderes gemacht werden muss als von "b" nach "x", dann sind es zwei unterschiedliche Folgezuständem also "x_Variante_kommt_von_a" und "x_Variante_kommt_von_b"? Ist das so? Kann man das pauschal beantworten? Ich muss doch mal tiefer in die formale Definition und die Varianten von Zustandsmaschinen eintauchen.

Dein Beispiel zeigt schon ganz schön, dass die Umwandlung in diese Richtung zu einer Erhöhung der Zustandsanzahl führt und dabei gleichzeitig auch noch Redundanz schafft durch Vervielfachung von fachlich identischen Zuständen. Du denkst da bei den "Aufräumaktionen" in Richtung einer Ausgangsaktion die Du bei universelleren Modellen zur Modellierung von zustandsbehaftetem Verhalten finden kannst. Durch Nutzung solcher Aktionen erhöhst Du aber die Komplexität und reduzierst die Nachvollziehbarkeit des Systems. Das steht also eher im Widerspruch zu Deiner Zielsetzung einer beherrschbaren Umsetzung. Ich empfehle den gefühlten Bedarf von Aufräumaktionen mal kritisch zu hinterfragen: Wozu ist das nötig? Was muss denn mehr passieren als Zustands-abhängige Ausgangswerte zu definieren?

Zumindest in meinem DFAModul habe ich mich bewusst an besonder einfachen und gängigen formalen Definitionen orientiert: Grundidee in Anlehnung an gängige formale Definitionen
Die Zustände werden nach außen als als KNX-Szenen dargestellt, wodurch Du direkt der Zustands-Szene zugeordnete Aktionen auslösen kannst. Die vier Ausgänge könnte man auch als Abkürzung sehen für Fälle Du nicht den "Umweg" von Szenen gehen, oder noch eine deutlich differenzierte Ausgabesteuerung nutzen willst. Bei undefinierten Ausgangswerten bleibt hier der vorangegangene Wert erhalten (also genau wie bei einer KNX-Szene auf die nicht reagiert wird)

[lopiuh]

Hi coko,

Wenn ich das richtig verstehe, dann erfolgt die Auswertung der Bedingungen im TWS-StateMachine-Module also nicht zwingend zusammen mit Änderung der Bedingungs-Ergebnisse, sondern muss gesondert angestoßen werden?

Genau, eine "Logik" wie die Lüftersteuerung kann als ein "Programm" (eigentlich nur eine Sequenz von Befehlen) gesehen werden. Über boolsche Eingabeparameter entscheidet die aufgerufene Funktion, ob sie überhaupt etwas macht oder sofort returned. Somit sparen sie sich sämtliche Programmflussstrukturen (insb. Blöcke). Der Hersteller sieht darin einen Vorteil für die Stabilität (man kann bspw. schwerer loops bauen). Die Logiken werden zusätzlich auf zu viel CPU Verbrauch überwacht. Die Hardware soll eine Appliance sein, die man nicht so einfach kaputt konfigurieren kann, schaun wir mal, werd ich schon hinbekommen :->>

Es gibt unterschiedliche Arten von Automaten: [...]

Danke, werde ich mir angucken...

Durch Nutzung solcher Aktionen erhöhst Du aber die Komplexität und reduzierst die Nachvollziehbarkeit des Systems.

Ja, sehe ich genau so. Vielleicht kann man es auch dadurch vereinfachen, dass man so viel wie möglich gleich hält. Wenn, am Beispiel der Aufräumaktionen, diese nicht so teuer sind, führt man halt "immer" "alle" aus, auch wenn sie nicht aus jedem Zustand benötigt werden.

Eine Frage zum Logikmodul / zur StateEngine: Wenn man mehrer Logiken abbilden wollte, müsste man ja mehrere (Hardware)-Module einsetzen. Auch das MDT-Logikmodul, mit dem ich gestartet bin, war relativ schnell "voll". Ist das nicht mehr ein Problem des Speichers als der Rechenleistung? War das schon mal ein Thema, mehr Speicher anbinden zu können?

LG

Frank

[gbglace]

Die Hardware soll eine Appiance sein, die man nicht so einfach kaputt konfigurieren kann, schaun wir mal, werd ich schon hinbekommen :->>

Solche Phänomene gab es mal in den ersten Versionen der Logik. Aber das haben auch die Extremuser mittlerweile schon lange nicht mehr hinbekommen, den TWs via solcher Logiken in die Knie zu zwingen. Und dann war es auch nur auf das Logik-Subsystem begrenzt alles andere an Schnittstellen lief unbeeindruckt weiter im Server. Und zum Glück braucht man in dem Teil ja nicht immer Logiken um Werte von System A nach System B zu bringen.

[coko]

Genau, eine "Logik" wie die Lüftersteuerung kann als ein "Programm" (eigentlich nur eine Sequenz von Befehlen) gesehen werden. Über boolsche Eingabeparameter entscheidet die aufgerufene Funktion, ob sie überhaupt etwas macht oder sofort returned. Somit sparen sie sich sämtliche Programmflussstrukturen (insb. Blöcke). Der Hersteller sieht darin einen Vorteil für die Stabilität (man kann bspw. schwerer loops bauen). Die Logiken werden zusätzlich auf zu viel CPU Verbrauch überwacht.

Ich verstehe nicht so recht, wo Du hier den Bedarf für irgendwelche Befehlssequenzen siehst. Das System der Lüftersteuerung kann verschiedene Zustände annehmen und (bei Eintritt verschiedener Ereignisse) zwischen diesen wechseln. Das reicht aus, um zu entscheiden, ob der Lüfter laufen soll (oder im erweiterten Fall ggf. auch noch wie stark), oder nicht. D.h.: jedem Zustand ist ein fester (Soll-) Schaltzustand des Lüfters zugeordnet.

Btw.: Ist die obige Aussage unterstützt durch ein Sprachmodell entstanden?

Vielleicht kann man es auch dadurch vereinfachen, dass man so viel wie möglich gleich hält. Wenn, am Beispiel der Aufräumaktionen, diese nicht so teuer sind, führt man halt "immer" "alle" aus, auch wenn sie nicht aus jedem Zustand benötigt werden.

Für mich ist immer noch nicht klar, wozu Du überhaupt irgendwelche Aufräumaktionen benötigst. Ich sehe darin ein Indiz für ein konzeptionelles Problem. Vielleicht kannst Du mal beschreiben, warum und was Du aufräumen musst.

Eine Frage zum Logikmodul / zur StateEngine: Wenn man mehrer Logiken abbilden wollte, müsste man ja mehrere (Hardware)-Module einsetzen. Auch das MDT-Logikmodul, mit dem ich gestartet bin, war relativ schnell "voll". Ist das nicht mehr ein Problem des Speichers als der Rechenleistung? War das schon mal ein Thema, mehr Speicher anbinden zu können?

Das OpenKNX-Logikmodul ist in fast allen OpenKNX-Applikationen mit drin und i.d.R. auch mit einer höheren Anzahl von Logikkanälen. Die aktuelle StateEngine-Release mit „nur“ 48 Logikkanälen ist da im Vergleich sehr sparsam ausgestattet. Das ist auch darin begründet, dass eine Update-Fähigkeit der in ETS gewährleistet werden soll. Eine spätere Erhöhung ist relativ einfach möglich, eine Reduzierung würde für Probleme sorgen. Andere Applikationen haben inzwischen oft das Maximum von 99 Kanälen.

Das DFA-Modul ist aktuell exklusiv in der StateEngine-Applikation integriert und bietet 16 Automaten mit je 16 Zuständen. Diese Dimensionierung ist das Ergebnis der letzten rein internen Test-Runde: Die lief noch mit einer Zusammenstellung 32xDFA32+96xLOG (32 größere Zustandsautomaten mit jeweils 32 Zuständen und 96 Logikkanäle, also 3 je Automat). Rein technisch ist auch mit dieser Größenordnung das Machbare auf der OpenKNX-Plattform noch nicht ausgereizt, allerdings ist in dieser Dimensionierung der Bedarf an Konfigurationsspeicher und ETS-Parameteranzahl deutlich größer als bei allen anderen OpenKNX-Applikationen und ich habe auch außerhalb des Projekts noch keine größeren Applikationen gesehen.

Limitierender Faktor ist (im Falle der RP2040-Architektur) nicht die Hardware, sondern die Konfiguration über die ETS! Die ETS programmiert mehr oder weniger regelmäßig nicht partiell und bei etwa jeder zehnten Änderung 6 Minuten warten zu müssen steht spürbar im Konflikt mit einer zufriedenstellen Nutzererfahrung. Auch die Reaktions-Geschwindigkeit der ETS-Bedienung sinkt mit den Dimensionen der ETS-Applikation. Ich hatte am Anfang sogar mal mit Automaten mit vollen 64 Zuständen experimentiert, was beim Aufruf der
Zustandsübergangstabelle (mit dann allein schon 768 Parametern!) zu Verzögerungen in der Größenordnung von 30s innerhalb der ETS führte. Ich bin da bei der Evaluation der Möglichkeiten also schon sehr deutlich an, oder eher über, die Grenzen der ETS gegangen.

Ohne da nun schon etwas Konkretes zu versprechen: In Zukunft könnte es durchaus noch mehr Möglichkeiten geben für Nutzer die das DFA-Modul gerne umfangreicher einsetzen wollen…

[mumpf]

aktuelle StateEngine-Release mit „nur“ 48 Logikkanälen

Wie nur 48 Logik-Kanäle? Also ich brauchte letztens für einen Automaten 24 Logikkanäle. Wie kommst Du auf eine Annahme von 3 pro Automat? Alleine wenn ich die Eingangssymbole aus Werten (DPT5) statt bool bilden möchte oder aus Zeiten, brauche ich doch pro Eingang eine Logik. Beim Zustandsautomaten sind die 99 Kanäle knapp (schon immer gewesen). Hier verstehe ich ehrlich gesagt Deine künstliche Beschränkung nicht.

Wenn man mehrer Logiken abbilden wollte, müsste man ja mehrere (Hardware)-Module einsetzen.

Hier frage ich mich, was Du mit "mehrere Logiken" meinst? Die meisten Logiken, die man so braucht, sind zum Schließen von Lücken in den Applikationen. Es sind solche Dinger wie:

• Du hast eine Szene (z.B. Kinoabend), über die Du Licht und Rollladen steuern kannst aber der PM kann über Szene nicht gesperrt werden
• Heizmodus "Komfort" soll als LED-Anzeige auf dem Taster dargestellt werden, dazu muss von DPT20.102 (HVAC-Modus) nach DPT1 umgewandelt werden
• Du willst ein Signal beeinflussen über Ein-/Ausschaltverzögerung, Wiederholung, Treppenlicht
• Du willst Signale sperren, weil die Applikation nativ keine Sperre unterstützt
• Du willst von/nach verschiedenen DPT konvertieren
• etc...

Solche Sachen sind recht einfach zu erreichen, normalerweise mit einem Logikkanal. Dann hast Du beim OpenKNX-Logikmodul gleich 99 davon (wenn das nicht künstlich beschnitten wurde). Und komplexere Logiken baust Du eben aus mehreren Kanälen zusammen...

Auch das MDT-Logikmodul, mit dem ich gestartet bin, war relativ schnell "voll".

Beim MDT-Logikmodul hat man den Ansatz gewählt, eher wenige Logikkanäle mit vielen KOs anzubieten. Eine UND-Logik mit 2 Eingängen "kostet" dort genauso viele Kanäle wie eine mit 8 Eingängen, Du hast dann aber auch eine Sperre gleich dabei. Dafür braucht man für ein Treppenlicht oder eine Ein-/Ausschaltverzögerung wieder weitere Kanäle. Hier bin ich auch sehr schnell an die Grenzen der 24 Kanäle gestoßen.
Bei mir bekommst du die Signalbeeinflussung mit jedem Kanal, für Sperren oder für mehr Logikeingänge brauchst Du bei mir zusätzliche Kanäle. Ist alles Geschmackssache. Da wir aber Logiken in jedem Gerät haben, leidet man nicht an Kanalmangel bei OpenKNX-Logiken . Ich nutze derzeit nicht alle 2970 Logikkanäle (30 Geräte x 99 Logikkanäle) aus...

Gruß, Waldemar

[henfri]

Limitierender Faktor ist (im Falle der RP2040-Architektur) nicht die Hardware, sondern die Konfiguration über die ETS! Die ETS programmiert mehr oder weniger regelmäßig nicht partiell und bei etwa jeder zehnten Änderung 6 Minuten

Wäre es eigentlich denkbar, dass eine Hardware mehrere physikalische Adressen und somit mehrere Applikationen in der ETS hat?

So könnte man das Problem umgehen, wenn man keine 30 openKNX geräte hat.