OpenKNX StateEngine: Universelle Zustandsautomaten in KNX

[lopiuh]

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.

Nein, nein, die Sicherheitsabschaltung soll ja bei "abstrus langen Lüftungszeiten" greifen, die zustande kommen, weil was "kaputt" ist. Stell Dir vor, ich bin im Winter im Urlaub und der Lüfter zieht mir die ganze warme Luft über mehrere Tage raus ... Edit: Und es geht hier ja um einen Lüfter für die Dusche, also ein Ort der sehr unter "Beobachtung" steht!

Sollte dieser Zustand im Regelbetrieb "fälschlicherweise" anschlagen, so werde ich von meiner besseren Hälfte ganz schnell unsanft darauf hingewiesen, warum denn der Lüfter denn nicht mehr läuft und das Haus doch gefälligst nicht so viel mitdenken soll, sondern nur auf Taster zu reagieren hat :-)

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

Da finde ich meine Lösung sogar besser. Ein defekter Feuchteeingangswert lässt den Lüfter gar nicht mehr (automatisiert) laufen, anstellte alle 6 Stunden für 2 Stunden Blindflug.

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

Das ist hier dasselbe. Damit die Logik die Werte einer Bedingung kennt, muss sie diese, z.B. über eine GA empfangen. Dieser Empfang kann als Trigger zum Durchlauf der Logik defniert werden. Die Logik kann aber auch einfach nur den Wert speichern, so dass er beim nächsten Logiktrigger (der die Logik zur Ausführung bringen soll) upgedated vorliegt.

Wird die Logik dann ausgeführt (trigger, z.B. irgendeine GA oder Timer), dann wird der ganze Code und auch die statemachine abgearbeitet.

Gruß

Franky

[lopiuh]

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

Es ist eigentlich nur möglich bei jedem Eingangsereignis (z.B. für eine triggernde GA)

Wenn Du mit "Berechnung" die Ausführung der statemachine meinst: Es gibt für die statemachine keine Eingangsereignisse. Jede Zeile (möglicher Zustandsübergang) hat eine individuelle Bedingung und dort können alle Eingangsgrößen (Ereignisse aus OpenKNX-Sicht) einfließen. Funktioniert schon sehr unterschiedlich im Vergleich zum OpenKNX-Zustandsautomat. Die TWS-Statemachine ist halt ein Befehl einer "custom Logik" (eine Sequenz von Befehlen: and or, monoflop, latch, statemachine, ...)". Die "custom Logik" selbst wird durch Telegramme, Timer, cron-like, ... getriggert. Diese Werte, des Triggers können, müssen aber nicht in die Bedingungen der Statemachinezeilen einfließen.

Gruß

Franky

[coko]

Wenn Du mit "Berechnung" die Ausführung der statemachine meinst:

Ja, meinte ich.

Verstehe das aus Deiner Beschreibung nun so, dass die Ausführung/Auswertung einer solchen selbst-definierten TWS "Custom-Logik" durch diverse verschiedene Ereignisse angestoßen werden kann, die in der TWS-Statemachine genutzte Bedingungen aber keine Unterstützung für eine Ereignisbehandlung mitbringen, bzw. eine solche höchstens durch eine weitere Vorverarbeitung innerhalb der Custom-Logik realisiert werden könnte.

eine individuelle Bedingung und dort können alle Eingangsgrößen (Ereignisse aus OpenKNX-Sicht) einfließen.

Die Eingangsgrößen haben nach meinem Verständnis keinen Ereignis-Charakter. Ein Ereignis wird nicht zwingend zu einer Änderung einer Eingangsgröße, oder eines abgeleiteten Wertes, führen. (Umgekehrt kann ich aber jede Änderung, oder auch jede unveränderte Wiederholung, einer Größe als Ereignis interpretieren. Wobei Die OpenKNX Zustandsautomaten bislang diese Ereignisse nicht direkt unterscheiden könnten, weil nur der neue Wert betrachtet wird. Bei Bedarf kann diese Unterscheidung jedoch einen Logik-Kanal zur Vorverarbeitung erfolgen.)

[lopiuh]

Verstehe das aus Deiner Beschreibung nun so, dass die Ausführung/Auswertung einer solchen selbst-definierten TWS "Custom-Logik" durch diverse verschiedene Ereignisse angestoßen werden kann, die in der TWS-Statemachine genutzte Bedingungen aber keine Unterstützung für eine Ereignisbehandlung mitbringen, bzw. eine solche höchstens durch eine weitere Vorverarbeitung innerhalb der Custom-Logik realisiert werden könnte.

Korrekt

Die Eingangsgrößen haben nach meinem Verständnis keinen Ereignis-Charakter.

Korrekt. Man lässt beliebige Werte (Eingangsgrößen = Ereignisse der Custom-Logik), berechnete Werte, komplexe Bedingungen, usw. in boolsche Variablen fließen. Damit ein Zustandsübergang stattfindet, muss die verwendete Variable (jede State-Zeile kann eine individuelle Variable verwenden, im Beispiel $calc_isSperreAktiv bzw. $calc_isMaxZeitTimerAbgelaufen) TRUE sein und der angegebene Zustand (im Beispiel 2) muss der aktuelle (intern) gespeicherte Zustand der Statemachine sein. Sind beide Bedingungen erfüllt, findet der Übergang zum neuen Zustand statt. Nach dem ersten Match wird das Abarbeiten der StateMachine-Zeilen abgebrochen.

Beispiel:

["$calc_isSperreAktiv", 2, 4, 0], // NACHLAUF -> GESPERRT (wenn Sperre aktiv)
["$calc_isMaxZeitTimerAbgelaufen", 2, 5, 0], // NACHLAUF -> MAX_ZEIT (bei MaxZeit Timer Ablauf - Impuls!)
​

Ein Ereignis wird nicht zwingend zu einer Änderung einer Eingangsgröße, oder eines abgeleiteten Wertes, führen. (Umgekehrt kann ich aber jede Änderung, oder auch jede unveränderte Wiederholung, einer Größe als Ereignis interpretieren.

Ich denke, ich weiß, was du meinst: Ja.

Wobei Die OpenKNX Zustandsautomaten bislang diese Ereignisse nicht direkt unterscheiden könnten, weil nur der neue Wert betrachtet wird. Bei Bedarf kann diese Unterscheidung jedoch einen Logik-Kanal zur Vorverarbeitung erfolgen.)

Ich habe mal mein (Zwischen-)Ergebnis der Custom-Logik hochgeladen und den LLM-Prompt. Es können noch Fehler enthalten sein. Ich spiele noch mit dem LLM herum. Das mit dem LLM (KI) hat nichts direkt mit dem TWS zu tun, noch ist es nötig, um mit dem TWS zu arbeiten. Das ist einfach nur Spielerei / Fortbildung von mir.

LG Frank

[coko]

Zur Info für Abonnenten dieses Threads, da nachträgliche Änderungen ansonsten unsichtbar bleiben:

Ich habe die Liste der Anwendungsbeispiele für die OpenKNX-StatEngine bzw. das Modul OpenKNX-Zustandsautomaten um weitere Einträge ergänzt, die teilweise auch in anderen Threads veröffentlicht wurden.

[coko]

Motiviert durch den Thread MDT Taster Light – Umschalten von 4 Werten mit nur einer Taste (Logik gesucht) nun mal ein weiteres kleines Beispiel, auch zur Diskussion und um zu zeigen, dass alleine durch die Modellerierung Lücken in der Verhaltensdefinition sichtbar werden:

Umschalten durch ein 1-Telegramm / Nachrüstung von Umschaltfunktion wenn nur fester Wert gesendet werden kann

Umschalten1.png

Umschalten1_Zustaende.png

Umschalten1_AusgangO1.png

Zum Umschalten habe ich jeweils einen Zwischenzustand eingeführt, der durch das Senden des passenden Schaltsignals den Zustandswechsel herbeiführen sollte. Beim nächsten (bzw. erwarteten nachfolgenden) Status-Update erfolgt ein Wechsel in den neuen Ist-Zustand.

Verhalten das noch definiert werden sollte:
* Reaktion ausbleibenden Zustandswechsel?
* Umschaltverhalten bei unbekanntem Status (z.B. nach Neustart)

[willisurf]

Schönes Video von Torben Ledermann über den OpenKNX Zustandsautomaten (inkl. Anwendungsbeispiel mit Erklärungen)
https://youtu.be/9Wlhuo1d-NI?feature=shared

[Stereofeld]

Schönes Video von Torben Ledermann

... mit einem netten Hinweis auf die "richtig coole Veranstaltung", auf der er gewesen ist.

[willisurf]

richtig coole Veranstaltung

und wie Recht er hat

[mumpf]

mit einem netten Hinweis auf die "richtig coole Veranstaltung", auf der er gewesen ist.

... was vor allem Dir zu verdanken ist, lieber Thomas.

Vielen Dank nochmal,
Waldemar

[coko]

Video von Torben Ledermann über den OpenKNX Zustandsautomaten (inkl. Anwendungsbeispiel mit Erklärungen)

Schön zu sehen, dass im Nachgang zum direkten Austausch auf dem Treffen nun ein solches Video entstanden ist, das die StateEngine-Applikation bzw. das Zustandsautomaten-Modul damit auch außerhalb des Forums noch etwas sichtbarer macht :-)

Werde das Video mit in die Link-Sammlung aufnehmen und ggf. noch einige einige Tipps und Tricks veröffentlichen, passend zum Beispiel im Video. Bin auch gespannt von welchen kreativen Anwendungen die Nutzer berichten.

[TabSel]

Ich stoße erst jetzt auf das Thema und weiß nicht ob das schon mal gefragt wurde: wird das Modul denn Teil des Fingerprint oder des VirtualPresence?

[traxanos]

technisch machbar man muss schauen ob man sowas haben möchte. das problem ist halt das sowas die ets app noch größer macht. beim FP würde ich das aber tatsächlich sehen. zumindest paar kanäle.

[Alloc]

Interessant fände ich es auch im - ähm - OAM-PresenceModule? Also REG1 mit OFM-LogicModule, OFM-"VPM" (OFM-PresenceModule glaub ich?), OFM-StateEngine. So wie ich das überblicke hat man ja aktuell da entweder das OAM-PresenceModule mit Logic+VPM aber ohne StateEngine oder die OAM-StateEngine mit Logic+StateEngine aber dafür ohne VPM. Finde das ist eigentlich eine perfekte Kombi für Logik im Verteiler

[willisurf]

Interessant fände ich es auch im - ähm - OAM-PresenceModule

Ja, so ein kleineres State-Engine Modul ist an vielen Stellen sinnvoll. Statt im Presence dann langfristig sicher noch eher im Sensormodul (beinhaltet ja das Presence Modul). Aber auch im Zusammenspiel mit VirtualButton passt das sehr gut (z.B. für Szenen/Audio Steuerung mit älteren Tastern).

Der Punkt der zu klären ist, ist Ressourcenverbrauch und wie entwickeln sich die Programmierzeiten/die ETS Performance.
Es gibt eben nichts umsonst...