OpenKNX StateEngine: Universelle Zustandsautomaten in KNX

[traxanos]

Also der KNX Stack erlaubt so wie wir ihn nutzen nur eine Adresse. Der HW Chip erlaubt ebenfalls nur 1 Addresse für die ACKs (was aber in Software weiter geht mit paar nachteilen). Außerdem möchte man ggf ja auch die Module intern mit einander verknüpften, da wird es dann schon schwieriger bis fast unmöglich das vernünftig zu machen.

Kurz um: Nein wird es so nicht geben.

[mumpf]

Nein, unser KNX-Stack kann nicht mehrere Applikationen, wir wissen nicht, was von der ETS aus dafür nötig wäre und müssten dafür wahrscheinlich sehr viel neu entwickeln. Wir machen das ja aus Spaß - und das macht keinen Spaß. Da sind 30 OpenKNX-Geräte ein Klacks im Vergleich zu den Kosten (Freizeitmangel), den das verursacht. Achja, und es gehen sowieso nur 2 Applikationen von der ETS aus, soviel ich weiß - was auch gegen den Aufwand einer Neuimplementierung spricht.

Wenn es nur um viele Logiken geht: Ich kann ja mal schauen, dass ich beim Logikmodul die Speicherstruktur so umbaue, dass mehr als 99 Kanäle möglich sind, wahrscheinlich käme ich schnell auf 127. Wenn ich es noch schaffe, ein Bit zu sparen, dann auch auf 255. Und alles darüber würde wieder eine Art "Neuschreiben" sein, das werde ich sicherlich nicht machen . Wenn schon neu, dann schwebt mir etwas vor, dass Logiken und Zustandsautomaten vereinigt...

Gruß, Waldemar

[traxanos]

ganz so einfach ist es nicht, weil die zähler dann 3 stellig werden müssten. zumindest nicht generisch in den verschienden gerät. höchsten im reinen oam-logik

[mumpf]

Naja, wenn Du 99 abbildest, dann musst Du min. 7 Bit für den Wert vorgesehen haben. Deswegen schrieb ich, 127 wird schnell zu erreichen sein. Alles darüber aber nicht ohne Review.

Aber ich will sowieso nicht diesbezüglich am Logikmodul was machen, lieber neue und spannendere Logik-Sachen .

Gruß, Waldemar

[willisurf]

Immer 99 Logikkanäle vorzusehen, wäre schon gut und sinnvoll.

[lopiuh]

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 [...]

z.B. um die Feuchtigkeit gegen die man vergleicht zu bilden (Tiefpassfilter), um nicht zu lüften, wenn es draußen feucht ist, oder ein schnelles Ansteigen der Feuchtigkeit zu ermitteln, oder um einen BusReset zu erkennen, um dann den Status der Logik zum Initialisieren des Aktors noch mal zu senden (ok, letzteres würde als State auch gehen).

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

Warum? Würde mich echt interessieren (wegen zu geschwollen oder vielen Worthülsen fürchte ich)? Nein, das habe ich schon selbst verbrochen, aber vielleicht eine traurige Folge davon, dasse ich in den letzten Wochen mehr (also quantitativ und Diskussionstiefe) mit LLMs "geredet" habe, als mit Menschen🤔.

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.

Ich denke da an unterschiedliche Aktionen. Geht man in den Zustand "Heizen" über und kommt von "Aus" muss man die Klimaanlage nicht ausschalten. Lief aber vorher die Klimaanlage muss sie ausgeschaltet werden. Ja ist konstruiert, aber in in die Richtung habe ich gedacht, ohne bei "meiner" Lüftersteuerung das jetzt zu haben.

Limitierender Faktor ist (im Falle der RP2040-Architektur) nicht die Hardware, sondern die Konfiguration über die ETS!

Und da wundert es mich, dass ihr so stark auf die ETS setzt. Ihr wärt doch mit einer "eigenen" Konfigurationssoftware "frei" und nicht an die ETS-Restriktionen gebunden. Und ein Konfiguarations-Datensatz/blob über die ETS dann zu übertragen, macht ihr ja mit dem Konfigbackup/-übertragen jetzt schon. ich bin da aber sehr vorbelastet, da ich nahezu alle GUIs nicht mag, vor allem wenn es nur eine GUI und keine API gibt. Dieses dumme rumgeklicke und die Arroganz der Produktentwickler zu meinen, alle Anwendungsfälle zu kennen / Vorausahnen zu können, ist imho nicht förderlich für eine Lösung.

Ich meine, Eure Produkte setzen ja eh mehr Tech-Freaks ein und wer es geflashed bekommt, der könnte auch mit einem weiteren Programm zur Konfiguration umgehen.

LG

Franky

[willisurf]

Und da wundert es mich, dass ihr so stark auf die ETS setzt. Ihr wärt doch mit einer "eigenen" Konfigurationssoftware "frei" und nicht an die ETS-Restriktionen gebunden.

Es gibt dafür gute Gründe, single point of thruth und saubere Konfiguration an einem Ort.

Zu den anderen Punkten halte ich mich mal zurück, das ist mir zu theoretisch.

[gbglace]

Lief aber vorher die Klimaanlage muss sie ausgeschaltet werden. Ja ist konstruiert, aber in in die Richtung habe ich gedacht, ohne bei "meiner" Lüftersteuerung das jetzt zu haben.

Was stört es dem KNX wenn da noch ein AUS Telegramm gesendet wird?

Nur weil ne Lampe schon AUS ist muss ich ja nicht erst kompliziert verhindern noch ein AUS zu senden.

Ich mache auch die Kleinigkeiten der KNX nativen Abhängigkeiten in den Open-KNX Geräten.

Im Server laufen nur die Externen Integrationen und die dafür notwendigen Konvertierungen.

Die ETS ist nicht das beste was man sich an Software vorstellen kann, aber es ist soweit ein Funktionsprinzip und man kann ne Menge kommentieren und Dokumentieren in dem Teil.

Und im zweifel kommt dann auch ein nicht ganz auf dem Kopf gefallener SI/Elektriker auch damit zurecht.

Dem TWS fehlt es da leider gerade noch etwas an Marktdurchdringung, um da in Seiner Logiksprache als KNX-Server-Standard zu gelten.

[coko]

[...]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.

Die 3 pro Automat hatten sich aus den vorher 32 DFA-Kanälen ergeben. Hatte diese Verhältnis bei der Größenreduktion dann erst mal beibehalten, da das bei mir im Mittel bisher auch ausgereicht hatte und auch mit Blick auf eine Update-Fähigkeit, inkl. Option auf Aufname weiterer Module die ggf. sowas wie die DPT5-Konvertierung einfacher umsetzen können. Am besten zeigst Du mir mal Deine Lösung mit den 24 Logikkanälen. Das ich bislang mit relativ wenigen Logik-Kanälen ausgekommen bin könnte natürlich auch damit zusammenhängen, dass zumindest meine Anwendungen und Anforderungen vorab besonders gut bekannt waren. Bei Funktionalität zur Eingabekonvetierung sehe ich zukünftig auch noch Potenzial zur Verbesserung, basierend auf typischen Umwandlungen die sich bei der Nutzung in der Breite zeigen.

Habe DPT5 nun auch schon mal vorgemerkt zur Prüfung.

[coko]

[Bedarf für Befehlssequenzen besteht] z.B. um die Feuchtigkeit gegen die man vergleicht zu bilden (Tiefpassfilter), um nicht zu lüften, wenn es draußen feucht ist, oder ein schnelles Ansteigen der Feuchtigkeit zu ermitteln, oder um einen BusReset zu erkennen, um dann den Status der Logik zum Initialisieren des Aktors noch mal zu senden (ok, letzteres würde als State auch gehen).

Warum sollte eine dynamische Anpassung des Feuchtungskeitsschwellwertes innerhalb eines Zustands erfolgen, vor allem wenn dieser Zustand überhaupt keinerlei Einfluss auf die Ermittlung der Schwellwerte hat? Die Betriebszustände der Lüftersteuerung werden lediglich davon beeinflusst, wann nach einer gewisse Vorverarbeitung die Ereginisse "Lüftung durch erhöhete Feuchtigkeit erforderlich" bzw. "... nicht mehr erforderlich". Ob diese Signale durch eine einfache Hysterse-Funktion ermittelt wurden, oder "irgendwie intelligenter" ist an der Stelle egal.

Warum [die Frage nach Unterstützung durch ein Sprachmodell]? Würde mich echt interessieren (wegen zu geschwollen oder vielen Worthülsen fürchte ich)? Nein, das habe ich schon selbst verbrochen, aber vielleicht eine traurige Folge davon, dasse ich in den letzten Wochen mehr (also quantitativ und Diskussionstiefe) mit LLMs "geredet" habe, als mit Menschen🤔.

Es wirkte in der Gesamtsicht auf mich eher unspezifisch. Der intensive Rückgriff auf LLMs begünstigt das...

[lopiuh]

Warum sollte eine dynamische Anpassung des Feuchtungskeitsschwellwertes innerhalb eines Zustands erfolgen, vor allem wenn dieser Zustand überhaupt keinerlei Einfluss auf die Ermittlung der Schwellwerte hat? Die Betriebszustände der Lüftersteuerung werden lediglich davon beeinflusst, wann nach einer gewisse Vorverarbeitung die Eregnisse "Lüftung durch erhöhete Feuchtigkeit erforderlich" bzw. "... nicht mehr erforderlich". Ob diese Signale durch eine einfache Hysterse-Funktion ermittelt wurden, oder "irgendwie intelligenter" ist an der Stelle egal.

hmm, das passiert doch auch außerhalb der statemachine, jedoch zusammen mit der statemachine in einem "Programm (eigentlich nur eine Sequenz von Befehlen)". Ich poste das jetzt so ausführlich, da wir vermutlich doch das gleiche Verständnis haben, was durch die Statemachine passiert und was Vorverarbeitung ist.

Beispiel: Der Zustand der statemachine ist "Lüfter AUS, keine Sperre".

Jetzt kommen Feuchtigkeitswerte über KNX rein, die das "Programm (eigentlich nur eine Sequenz von Befehlen)" triggert.

Ein Tiefpass/Mittelwert/Filter/irgendwas) wird bildet:

// Feuchtigkeitsglättung (Lowpass auf Eingangswert, Zeitkonstante aus Parameter)
"Lowpass", "$in_Feuchte", "$calc_Feuchte_geglaettet", "$in_param_Feuchte_GlaettungDauer"],

Jetzt werden die Schwellwerte berechnet:

// Schwellen berechnen (Basis: geglättete Feuchte + Offsets aus Parametern)
"Polynomial", "$ConstTrue", "$calc_EinschaltFeuchte", ["$calc_Feuchte_geglaettet", "$in_param_Feuchte_EinschaltOffset"]],
"Polynomial", "$ConstTrue", "$calc_AusschaltFeuchte", ["$calc_Feuchte_geglaettet", "$in_param_Feuchte_AusschaltOffset"]],

Jetzt werden Bedingung geprüft:

// Feuchteanforderung (Hysterese - wird gesetzt bei Überschreiten der Einschaltschwelle, rückgesetzt bei Unterschreiten der Ausschaltschwelle)
"Latch", "$ConstTrue", "$calc_isFeuchteAnforderungAktiv", "$calc_isFeuchteUeberEinschalt", 0], // Setzen bei > Einschalt
"Latch", "$ConstFalse", "$calc_isFeuchteAnforderungAktiv", "$calc_isFeuchteUnterAusschalt", 0], // Rücksetzen bei < Ausschalt

Diese Bedingungen werden in der Statemachine geprüft und beim ersten "match" ist der neue Zustand gefunden:

[
  "Statemachine",
  [
    // --- Priorität 1: SPERRE (State 4) ---
    ["$calc_isSperreAktiv",  0, 4, 0], // Von AUS nach GESPERRT
    ["$calc_isSperreAktiv",  1, 4, 0], // Von FEUCHTE nach GESPERRT
    ["$calc_isSperreAktiv",  2, 4, 0], // Von NACHLAUF nach GESPERRT
    ["$calc_isSperreAktiv",  3, 4, 0], // Von MANUELL nach GESPERRT
    ["$calc_isSperreAktiv",  5, 4, 0], // Von MAX_ZEIT nach GESPERRT (höchste Priorität in State 5)
    ["$calc_isSperreAktiv", 99, 4, 0], // Von FEHLER nach GESPERRT
    ["-$calc_isSperreAktiv", 4, 0, 0],  // Von GESPERRT nach AUS

    // --- Priorität 2: MAX_ZEIT (State 5) ---
    ["$calc_isMaxZeitTimerAbgelaufen", 1, 5, 0], // Von FEUCHTE nach MAX_ZEIT
    ["$calc_isMaxZeitTimerAbgelaufen", 2, 5, 0], // Von NACHLAUF nach MAX_ZEIT
    ["$calc_isMaxZeitTimerAbgelaufen", 3, 5, 0], // Von MANUELL nach MAX_ZEIT
    ["$calc_isTasterBetaetigt", 5, 3, 0],         // Von MAX_ZEIT nach MANUELL bei Tasterbetätigung
    ["-$calc_isFeuchteAnforderungAktiv", 5, 0, 0],   // Von MAX_ZEIT nach AUS, wenn Feuchteanforderung wegfällt

    // --- Priorität 3: MANUELLER BETRIEB (State 3) ---
    ["$calc_isTasterBetaetigt", 0, 3, 0], // Von AUS nach MANUELL
    ["$calc_isTasterBetaetigt", 1, 3, 0], // Von FEUCHTE nach MANUELL (unterbricht Feuchte)
    ["$calc_isTasterBetaetigt", 2, 3, 0], // Von NACHLAUF nach MANUELL (unterbricht Nachlauf)
    ["$calc_isManuellTimerEndeUndFeuchteHoch", 3, 1, 0], // Von MANUELL nach FEUCHTE (wenn Feuchteanforderung noch aktiv)
    ["$calc_isManuellTimerEndeUndTrocken", 3, 0, 0],     // Von MANUELL nach AUS (wenn keine Feuchteanforderung)

    // --- Priorität 4: AUTOMATIK (FEUCHTE State 1, NACHLAUF State 2) ---
    ["$calc_isFeuchteAnforderungAktiv", 0, 1, 0], // Von AUS nach FEUCHTE
    ["$calc_isStartNachlaufTrigger", 1, 2, 0],     // Von FEUCHTE nach NACHLAUF
    ["$calc_isFeuchteWiederUeberAusschalt", 2, 1, 0], // Von NACHLAUF zurück nach FEUCHTE (wenn Feuchte wieder steigt)
    ["$calc_isNachlaufTimerGeradeAbgelaufen", 2, 0, 0] // Von NACHLAUF nach AUS (wenn Nachlaufzeit abgelaufen)
  ]
]
​

(Code nicht vollständig), Ursprungsthreads sind hier und hier. Ob die statemachine überhaupt die angemessene Lösung für das Problem ist, ist nicht so relevant, da ich für diese vorliegende Aufgabe (zwecks Einarbeiten) einfach die statemachine nutzen musste/wollte.

LG

Franky

[coko]

hmm, das passiert doch auch außerhalb der statemachine, jedoch zusammen mit der statemachine in einem "Programm (eigentlich nur eine Sequenz von Befehlen)".

Diese Trennung ging aus Deinen vorherigen Beiträgen nicht so klar hervor.

Jetzt kommen Feuchtigkeitswerte über KNX rein, die das "Programm (eigentlich nur eine Sequenz von Befehlen)" triggert.

Wie wird denn dann eigentlich das zeitabhängige Verhalten ausgelöst? Auch nur bei Änderung von Feuchtigkeitswerten?

["$calc_isTasterBetaetigt", 5, 3, 0], // Von MAX_ZEIT nach MANUELL bei Tasterbetätigung ["-$calc_isFeuchteAnforderungAktiv", 5, 0, 0], // Von MAX_ZEIT nach AUS, wenn Feuchteanforderung wegfällt

Kann es sein, dass der Lüfter bei dauerhaft zu hoher Luftfeuchtigkeit nach automatischem Abschalten nie wieder automatisch eingeschaltet wird?

Mit Blick auf die Prüfung einer vollständigen Verhaltensdefinition in allen Zuständen hätte ich wohl eher eine Ordnung gewählt in der nach Ausgangszustand sortiert ist.

[lopiuh]

Diese Trennung ging aus Deinen vorherigen Beiträgen nicht so klar hervor.

👍

Wie wird denn dann eigentlich das zeitabhängige Verhalten ausgelöst? Auch nur bei Änderung von Feuchtigkeitswerten?

Es gibt z.B. Timer (Monoflop), die z.B. bei Flankenwechsel einer Variable den Timer starten. Läuft der Timer ab, wird die Logik getriggert. Es gibt zyklische Timer (ClockSignal), oder eben die Änderung einer Eingangsgröße (GA-Telegrammwert), die die Logik triggert.

Beispiel für den Max-Timer:

["Monoflop", "$calc_isLuefterAnFuerMaxZeit", "-$calc_isLuefterAnFuerMaxZeit", "$calc_isMaxZeitTimerLaeuft", "$in_param_Luefter_max_Laufzeit", 2]

Doku: link

Kann es sein, dass der Lüfter bei dauerhaft zu hoher Luftfeuchtigkeit nach automatischem Abschalten nie wieder automatisch eingeschaltet wird?

Ja genau, das ist so gewollt. Ist der Sensor bspw. kaputt und liefert nur noch hohe Werte, schaltet die MaxLaufzeitprüfung aus. Erst wenn sich zeigt, dass der Sensor doch nicht kaputt ist (und der Mensch das 2 Stunden Duschen beendet hat, das Fenster geöffnet hat und/oder den Taster zum manuellel Lüften betätigt hat und die Feuchtigkeit wieder gesunken ist), funktioniert der Feuchte-Einschalt-Automatismus zum Einschalten wieder.

Dafür sorgt die Regel:

["-$calc_isFeuchteAnforderungAktiv", 5, 0, 0], // Von MAX_ZEIT nach AUS, wenn Feuchteanforderung wegfällt

Das "-" negiert calc_isFeuchteAnforderungAktiv: -> Wechsel zu AUS, aber nur, wenn die Feuchteanforderung wegfällt (d.h., die Feuchtigkeit unter die Ausschaltschwelle sinkt).

Mit Blick auf die Prüfung einer vollständigen Verhaltensdefinition in allen Zuständen hätte ich wohl eher eine Ordnung gewählt in der nach Ausgangszustand sortiert ist.

Ok, aber man muss beachten, dass die Reihenfolge der Regeln eine Rolle spielt. Würde nicht SPERRE am Anfang abgefragt, sondern z.B. Feuchtigkeit, würde trotz Sperre der Übergang aufgrund calc_isFeuchteAnforderungAktiv erfolgen. Also ich denke, die Reihenfolge nach Priorität der Bedingungen ist hier relevant, ohne alles in den Bedingungen mit aufzunehmen (also das die Bedingung calc_isFeuchteAnforderungAktiv auch die Sperre berücksichtigt). Hier liegt es wohl daran, dass die TWS-Statemachine nicht ereignisorientiert ist. Beim OpenKNX-Modul treten die Probleme vmtl. nicht auf. Das gefällt mir eigentlich besser. Danke coko. Dieser "Designunterschied" wird mir gerade erst richtig klar.

Gemini analysiert dazu:

• Für Logiken mit klaren, hierarchischen Prioritäten (z.B. Sicherheit vor Normalbetrieb) kann der TWS Statemachine-Ansatz zu Code-Einsparungen führen. Da die Regeln sequenziell abgearbeitet werden, bestimmt ihre Reihenfolge implizit die Priorität. Alternative Methoden erfordern möglicherweise zusätzliche explizite Prüfungen dieser Prioritäten an verschiedenen Stellen in der Logik.
• Dieser potenzielle Vorteil wird jedoch relativiert, da im TWS Statemachine-Modul Regeln für globale Bedingungen (wie eine generelle Sperre) oft für jeden einzelnen Zustand, von dem aus sie greifen sollen, wiederholt definiert werden müssen.
• Bei sehr einfachen Logiken ohne Prioritätskonflikte oder komplexe Abhängigkeiten könnte ein alternativer Ansatz, der direkt auf einzelne Ereignisse reagiert, unter Umständen mit weniger Definitionsschritten realisiert werden.
• Wenn jedoch komplexere Abläufe mit Abhängigkeiten und klar definierten Prioritäten erforderlich sind, bietet die zentrale Definition aller Übergänge in der TWS Statemachine-Tabelle oft eine bessere Struktur und Übersichtlichkeit sowie potenziell eine geringere Anfälligkeit für Logikfehler. Dies kann auch dann der Fall sein, wenn die Gesamtzahl der benötigten Definitionsschritte (Regeln in der Tabelle plus vorbereitende Logik) nicht unbedingt geringer ist als bei anderen gut strukturierten Ansätzen.

Im konkreten Fall der Lüftersteuerung mit den vielen Prioritäten (Sperre > MaxZeit > Manuell > Automatik) würde ich vermuten, dass der TWS-Ansatz trotz der Regelwiederholungen wahrscheinlich nicht wesentlich mehr, eventuell sogar etwas weniger Definitions-"Zeilen" für die Kernlogik benötigt als ein vergleichbar robustes ereignisgesteuertes System, das alle Prioritäten und Zustandsprüfungen explizit in den Handlern abbilden müsste.

Gemini_ENDE

Gruß

Fanky

[coko]

Ist der Sensor bspw. kaputt und liefert nur noch hohe Werte, schaltet die MaxLaufzeitprüfung aus. Erst wenn sich zeigt, dass der Sensor doch nicht kaputt ist (und der Mensch das 2 Stunden Duschen beendet hat, das Fenster geöffnet hat und/oder den Taster zum manuellel Lüften betätigt hat und die Feuchtigkeit wieder gesunken ist), funktioniert der Feuchte-Einschalt-Automatismus zum Einschalten wieder.

Du hast einen Lüfter zur Reduktion der Feuchtigkeit und wenn das nicht ausreicht und es es dauerhaft zu feucht bleibt dann lüftest Du aus "Sicherheitsgründen" lieber gar nicht mehr. Bei Lüftern mit eingebauter Feuchtigkeitssteuerung kenne ich das so, dass nur temporär abgeschaltet wird (z.B. Ignorieren der Feuchtigkeitsüberschreitung für 6 Stunden, nach 2 Stunden Dauerbetrieb).

man muss beachten, dass die Reihenfolge der Regeln eine Rolle spielt.

Da müssten in der Tat so einige Bedingungen (u.A. Neuauswertung bei jeder Änderung und Disjunkte Einflussgrößen) gleichzeitig erfüllt sein, damit man die Reihenfolge vernachlässigen kann. Wenn der Folgezustand nicht mehr eindeutig von Bedingung und Zustand abhängig ist, dann steigt damit die Komplexität. Wird die Berechnung nun immer nur bei Änderung von Bedingungen angestoßen, oder ist das auch möglich bei jedem Eingangsereignis (z.B. für eine triggernde GA)?

[gbglace]

Je nachdem wie monolithisch man die gesamte Logik baut (Einzelne Komponenten / ein gesamthaftes Konstrukt) kann das alles frei entschieden werden. Man kann an jedem Eingangsobjekt eines Logikbausteins festlegen ob dort eingehende "Telegramme" (bezogen auf reine KNX-Werte) nur einen Wertupdate bewirken für einen nächsten Programmablauf oder nur die Berechnung triggern oder Beides zusammen, die Berechnung triggern und gleichzeitig den Wert berücksichtigen. Ebenso lässt sich das noch filtern auf Wert muss sich geändert haben, oder man negiert das.

Also da lässt sich soweit alles einbauen was man braucht.

Innerhalb eines monolithischen Logikbausteines ergibt dann aber die Anordnungsreihenfolge der verwendeten Module den "Programm"-Ablauf.