EFH KNX Zustandsautomaten

[mumpf]

Hi Göran,

meine Bedienteile sind auch so. Und ich habe auch erst getestet, wie er sich verhält. Aber die Idee, das so zu machen, ist mir nach einem relativ kurzen Stromausfall gekommen. Da hab ich bemerkt, dass der Geschirrspüler einfach an der Stelle weiter gemacht hat, an der er vor dem Stromausfall gewesen ist.

Und meine Waschmaschine macht das auch so, deswegen geht es da jetzt weiter...

Gruß, Waldemar

[gbglace]

Jetzt muss ich nur mal probieren wie sich hier mein Spüler so in seinen Zuständen bei Strom AN/AUS an der Steckdose verhält. Meine Bedienteile sind bei dem Spüler alle quasi innen. Deckel auf dann leuchtet das Display, das sollte man wirklich am Strommessaktor feststellen, Startknopf ist auch in dem Deckel innen.

[mumpf]

Hi,

Ich erinnere mich an die Anfänge meiner Hausautomation. Wenn keiner zu Hause war, waren bestimmte Dinge einfach gesperrt bzw ausgeschaltet.

da fällt wohl jeder erstmal drauf rein, bevor man es "richtig" macht . Ich versuche Sperren zu vermeiden und mehr durch Logiken zu lösen, die wie bei Dir ein "Heartbeat" des Servers mitberücksichtigen. Oder es gibt eine manuelle Funktion, die höher priorisiert ist als die Sperre, dann wird bei manueller Bedienung die Sperre immer mit entfernt.

Bei meinem Geschirrspüler-Beispiel ist die KNX-Ebene (also was auch ohne Server funktioniert) eben darauf abgestimmt, dass es möglichst im Alltag nicht behindert. Wenn der Server läuft, ist die Bediensituation die folgende:

1. Steckdose wird durch Präsenz in der Küche eingeschaltet, das passiert ganz sicher bevor man den Geschirrspüler erreicht hat. Somit ist dieser aus User-Sicht "immer" mit Strom versorgt. Das ist nötig, da unser Geschirrspüler ein elektronisches Bedienfeld hat und somit kein Spülprogramm ohne Strom eingeschaltet werden könnte.
2. Sobald ich am Geschirrspüler das Spülprogramm auswähle (oben im Bild der Trigger "Geschirrspüler Einschalttaste"), signalisiert mir eine blinkende LED an einer Taste in der Nähe des Geschirrspülers, ob zu wenig PV-Strom da ist. Wenn ich diese Taste betätige, ist das die bei mir immer mögliche manuelle Übersteuerung, die "Trotzdem waschen"-Taste. Technisch wird die "Geschirrspüler Einschalttaste" über einen Strommessaktor erkannt.
3. Sobald ich das Waschprogramm starte (wieder durch Strommessung erkannt), wird bei zu wenig PV-Strom die Steckdose abgeschaltet und gesperrt (aus Sicht des Zustandsautomaten ist hier keine Sperre notwendig, die wird erst wichtig, wenn man sich die reine KNX-Ebene anschaut - siehe unten).
4. Sobald genügend PV-Strom da ist oder die "Trotzdem waschen"-Taste betätigt wird, geht die Steckdose an und der Geschirrspüler setzt das vorher gewählte Programm fort.
5. Nach dem spülen wird die Fertig-Meldung ausgegeben und der Automat geht in den Anfangszustand zurück.

Für den User ist das also ein "Ich wähle mein Spülprogramm, starte es", dann läuft schon alles richtig. Und falls ich es eilig habe, drücke ich die "Trotzdem waschen" Taste.

Der Server kann jetzt an jeder beliebigen Stelle dieses Zustandsautomaten ausfallen. Das muss nicht immer durch einen Systemausfall passieren, es kann ja sein, dass man selber was am Server macht (neue Funktionalität einbauen, Update der Software, Netzwerkausfall) und es deswegen zum Neustart oder ähnlichem kommt. Ohne Server sieht meine KNX-Seite beim Geschirrspüler folgendermaßen aus:

1. Steckdose wird durch den Küchen-PM ein- und ausgeschaltet, mit einer Nachlaufzeit von 30 Minuten.
2. Der Steckdosenaktor ist ein ein Strommessaktor, der seinerseits über Lastüberschreitung mit einer Nachlaufzeit von 5 Minuten ausgibt, ob der Geschirrspüler gerade wäscht.
3. PM und Lastüberschreitung gehen über ein ODER an den Aktoreingang des Geschirrspüler-Kanals.

Diese 3 Punkte sorgen dafür, dass sich für den User ohne Server-Unterstützung nichts ändert: "Ich wähle mein Spülprogramm und starte es", dann läuft alles richtig. Es findet keine Prüfung auf PV-Strom statt, aber der Geschirrspüler wäscht, das ist super. Der Punkt 1 der KNX-Ebene macht es aber notwendig, dass der Server eine Sperre bei "Warten auf genug PV-Strom" setzt (Punkt 3 der Server-Ebene). Sonst würde das Ausschalten der Steckdose beim "Warten auf PV" durch ein direktes Einschalten vom PM wieder zunichte gemacht werden.
Jetzt kann es aber noch passieren, dass der Server genau in der Situation ausfällt, dass der Geschirrspüler auf genügend PV-Strom wartet. Jetzt sitzt eine Sperre, aus der das System ohne Server nicht rauskommt. Aus User-Sicht heißt das, ich will waschen manuell einschalten können. Dafür ist die "Trotzdem waschen"-Taste da, deswegen schaltet diese Taste auch immer die Sperre an der Steckdose aus und die Steckdose ein. Für den User ist das das, was er auch macht, wenn der Server funktioniert und man trotz zu wenig PV trotzdem waschen will.

Hier sieht man ganz schön, wie die Einzelkonzepte zusammen spielen: Höhere Ebene (Serverbasiert) mit Berücksichtigung von "Smarten" Funktionen wie PV-Strom, KNX-Ebene mit Grundfunktionalität und manuelle Bedienung, die immer Vorrang hat. Die Bedienung ist immer gleich, egal ob der Server da ist oder nicht. Der Server unterstützt nur und macht den ganz normalen Bedienfall einfach "smarter". Es ist aber sehr wichtig, dass der Zustandsautomat auch die Zustände abbildet, die KNX-nativ erfolgen. Sonst kommt man ganz schnell in die Situation, dass der Zustandsautomat in einem anderen Zustand ist als die KNX-Realität, und dann ist es sehr schwer, den Fehler nachzuvollziehen und zu finden!

Das Ganze hat bei meiner Frau einen wirklich hohen WAF, obwohl sie zuerst sehr skeptisch war, ob das alles so läuft. Heute sagt sie, dass es schön ist, dass bei genügend PV-Strom immer gewaschen wird und sie sich dazu keine Gedanken machen muss.

Um obiges noch abzurunden: Der Zustandsautomat für den Geschirrspüler hat noch einige Transformationen, die nicht in dem Diagramm oben eingezeichnet sind, die hängen alle mit der Initialisierung des Automaten zusammen. Ein Zustandsautomat sollte nach einem Neustart des Servers idealerweise in einem Zustand landen, der dem Zustand des KNX-Systems entspricht und nicht unbedingt der Zustand ist, der vor dem Neustart des Servers geherrscht hat.
Beispiel hier: Zustandsautomat war beim "Warten auf PV", dann ist der Server ausgefallen. Zwischendurch wurde auf die "Trotzdem waschen"-Taste gedrückt und der Geschirrspüler wäscht gerade, wenn der Server wieder da ist. In dem Beispiel ist es offensichtlich, dass der Zustandsautomat nach dem Neustart in dem Zustand "Geschirr waschen" landen soll.

Ich habe das in Home Assistant so gelöst, dass ich auf einen "Neustart"-Trigger reagiere, so viele Bedingungen wie möglich prüfe (alles KNX-Stati), um rauszufinden, was der richtige Zustand wäre. Wenn eine der Bedingungen zutrifft, versetze ich den Automaten in den bestimmten Zustand, sonst nimmt er - je nach Automat - den Startzustand oder den letzten Zustand vor dem Neustart an. Ist nur eine Heuristik, bin aber damit bisher gut gefahren. In dem aktuellen Beispiel würde man nach dem Server-Neustart prüfen, ob die Lastüberschreitung beim Aktor TRUE ist, dann wäscht der Geschirrspüler und der Automat wird in den "Geschirrspüler wäscht"-Zustand versetzt.

So, das war es jetzt erstmal, ich muss jetzt wieder eine Runde arbeiten .

Gruß, Waldemar

P.S.: Ich arbeite gerade daran, noch eine Prognosefunktion in den Zustandsautomaten zu integrieren. Wenn die Wettervorhersage für den aktuellen Tag sowieso nur Wolken vorhersagt, dann muss man ja auch nicht auf "genug PV" warten, sondern kann gleich waschen.

P.P.S.: Bin auch dabei, den gleichen Zustandsautomat für die Waschmaschine zu realisieren...

[Beleuchtfix]

muss man meist auch nochmal die GA-Struktur etwas anpassen

Darüber würde ich jetzt gern ausführlich diskutieren gibt es da ein Best Practice für KNX? Soll ich dafür eine eigene Hauptgruppe nehmen und welchem Gewerk soll ich die benötigten Adressen zuordnen?

Gruß
Florian

[gbglace]

Und spätestens an der Stelle wo die zentrale Logik mitspielt, muss man meist auch nochmal die GA-Struktur etwas anpassen und die Telegrammwege für die "Notfallkonfiguration" implementieren. Da man ja je KO immer nur auf eine GA senden kann und bei funktionierender Logik, ein Taster meist nicht direkt mit dem Aktor spricht aber bei kaputter Logik dies tun sollte muss man sich die KNX-Telegrammwege auch noch mal genauer betrachten.

[DerStandart]

Dann kommen die Rückfallautomatiken, die die manuell erzeugten Zustände wieder zurücknehmen

Dieser Punkt ist nicht zu unterschätzen. Was passiert, wenn der Server doch einmal abraucht? Ist das Haus dann noch in einem vernünftigen Zustand?

Ich erinnere mich an die Anfänge meiner Hausautomation. Wenn keiner zu Hause war, waren bestimmte Dinge einfach gesperrt bzw ausgeschaltet. Steckdose Mikrowelle zum Beispiel. Der Server ist natürlich wieder im ungünstigsten Moment ausgefallen (Zustand nach Windows Update), ich war nicht da und zu Hause ging nicht mehr viel. Die Zeiten des Windows Servers sind zum Glück vorbei.

Ich habe eine Ausfallüberwachung über das MDT Logikmodul gelöst. Mein IP-Symcon sendet alle 60 Sekunden ein "Hallo hier bin ich". Bleibt das aus, so führt das Logikmodul einige Dinge aus, die Handlungen des Servers rückgängig machen.

Also immer auch daran denken: Was passiert, wenn die Logik ausfällt.

[martiko]

Guten Morgen zusammen,

wow, vielen Dank für den vielen Input, das muss ich alles erst mal "verarbeiten", aber ich werde mir Home Assistant auf jeden Fall mal ansehen. Auch wenn ich nicht glaube, dass ich damit alles abdecken kann, was ich bisher über die anderen Einzelkoponenten realisiert habe bzw. realisieren will, kann es vielleicht den Hauptteil ersetzen so dass ich Node Red unc co. nur noch für ganz spezielle Aufgaben brauche.

Es freut mich aber, dass ich - angeregt durch den Vorschlag von gbglace hier so ein interessantes Thema "angestossen" habe, auch wenn ich selbst noch nicht viel dazu beitragen kann. Und ich hoffe, die Diskussion geht noch weiter, davon können sicher einige profitieren!

[mumpf]

Hi Christoph,

vielen Dank für Dein konstruktives Feedback. Du scheinst da ja viel Ahnung zu haben, da kann ich vielleicht noch einiges lernen. Ich hab mir das alles nur per "lerning by doing" beigebracht.

Das sind doch zwei paar Schuhe - Objektorientierung und Zustandsautomaten.

deswegen hatte ich "Objektorientierung" in Hochkommata gesetzt. Ich wollte damit nur sagen, wovon ich mich habe inspirieren lassen bzw. was mein Leitmotiv ist. Ich wollte nicht den Eindruck erwecken, dass das irgendwas miteinander zu tun hat.

Ich selbst greife in Softwareprojekten sehr gerne auf Zustandsautomaten zurück, insb. wenn das Gesamtsystem/Verhalten noch undurchsichtig ist.

Bei den meisten Zustandsautomaten, die ich angelegt habe, war das Gesamtsystem zuerst undurchsichtig. Bei einfachen und durchsichtigen Systemen baue ich eher eine Logik und mache es direkt in KNX.

Ich empfehle bei dem Diagramm eine andere Notation der Transitionen (entlang der Pfeile) : "trigger [Bedgingung die erfüllt sein muss] / Aktion".
In deinem Diagramm sind die Aktionen in den Zuständen ausgedrückt. Das geht auch.

Danke, ich lerne gerne dazu.

Grundlegend beschreibt die Zustandsautomatentherie zwei Typen: Moore und Mealy. In letzterem sind Zustände aktionslos. D.h. alle Aktionen werden durch Transitionen aka. Zustandsübergänge ausgelöst. Ich persönlich finde das in der Umsetzung einfacher da Zustände "dumm" sind und sie nur durch externe Trigger verlassen werden. Verlassen kann auch bedeuten, dass die Transition auf den Ursprungszustand zurückführt.
Wenn die Aktionen im Zustand ausgeführt werden stellt sich auch die Frage nach dem "wann". Dazu findet man i.d.R. "on entry", "while", und "on exit" Aktionen. Das Eröffnet aber das Problem: Der Automat muss wissen "wann" es gerade ist, d.h. man hat wieder drei Unterzustände geschaffen. Sind alle Aktionen "on entry" würde ich sie den Transitionen zuordnen.

Dann mache ich wohl eher die Automaten nach Moore. Ich hab mir das mal bei Wikipedia durchgelesen. Die Überführung in einen Mealy-Automaten wäre nicht schwer, aber faktisch habe ich (bis jetzt) nur "on entry"-Aktionen (exit vermeide ich und while realisiere ich mit 2 sich gegenseitig "toggelnden" Zuständen), so dass die Automaten gleichwertig sind. Und ich würde sie nicht den Transitionen zuordnen, ganz einfach deswegen, weil es viel mehr Transitionen als Zustände gibt und ich müsste dann die gleichen Aktionen mehrfach machen (an mehrere Transitionen hängen). Hängt vielleicht auch davon ab, wie das Laufzeitsystem, dass die Automaten realisiert, gestrickt ist. Beim Home Assistant habe ich mit einzelnen Automations, die einen Zustand repräsentieren und entsprechende Aktionen ausführen, gute Erfahrungen gemacht.

Einde condition gehört nicht in einen Zustand ("Ausrechend PV").

Da hast Du recht, ist letztendlich bei diesem Automaten auch nicht so realisiert.

Eine Transition darf sich nicht verzweigen. "Steckdose an" zu "Ausreichend PV" und "Wenig PV". Daraus muss man zwei Transitionen machen, es kann auch der selbe Trigger aber mit unterschiedlichen Bedingungen sein.

Ist auch genau so realisiert. Und das Diagramm sollte keine Verzweigung darstellen, sondern nur 2 Pfeile, die sich den Text teilen. Aber wie Du schon sagtest, die Conditions hätten auch an die Pfeile gehört und dann wäre es klarer gewesen.

Du versteckst Unterzustände: Z.b. Transition Geschirr fertig -> Steckdose aus. Der Trigger ist nicht "geschirr fertig" sondern "30 sekunden abgelaufen". Der Sekunden-Timer muss aber irgendwie gestartet werden, d.h. es fehlt die Aktion "30 sekunden timer starten".

Formal hast Du natürlich recht, Aber ein gutes Laufzeitsystem für Automaten erlaubt mir Verzögerungen zusammen mit dem Trigger zu formulieren, sonst ertrinkt man in "Zwischenzuständen". Bei Home Assistant kann ich wirklich sagen:

    alias: "kueche_geschirr_fertig_strom"
    description: Nach Fertigmeldung wieder zu Steckdose an gehen
    trigger:
      - platform: state
        entity_id: variable.kueche_geschirr_state
        from: "waschen"
        to: "fertig"
        [COLOR=#16a085][B]for:
          seconds: 30[/B][/COLOR]
    action:
      - service: variable.set_variable
        data:
          variable: kueche_geschirr_state
          value: "strom"

Bei Callidomus musste ich allerdings genau den Weg gehen, den Du beschrieben hast, deswegen spreche ich von vielen "Zwischenzuständen".

Puh sorry das wurde etwas umfangreich.

Ich danke Dir, so konnte ich nochmal drüber nachdenken, hab noch was gelernt und sehe, dass es nicht kompletter Unsinn ist, was ich hier mache.

Ich habe diesen Automaten übrigens auch noch auf eine andere Weise realisiert, ich weiß keinen Fachausdruck dafür, kenne ich nur von Callidomus und SmarthomeNG.py her. Im Prinzip geht das so:

• Alle Trigger werden dem Laufzeitsystem bekannt gegeben und jeder Trigger löst eine Evaluation des Zustandsautomaten aus
• Die Evaluation durchläuft eine Liste von Conditions, jede Condition kann aus komplexen UND/ODER-Ausdrücken bestehen
• Mit jeder Condition ist ein Zustand verbunden. Die erste Condition in der Liste, die erfüllt wird, führt zu dem ihr zugeordnetem Zustand.
• Der Zustand wird angenommen und er führt die ihm zugeordneten "on entry"-Aktionen durch
• Es gibt auch while- und on exit-Behandlung, aber die hab ich bisher nicht gebraucht.

Im Prinzip ist das mit einer großen If-elseif-elseif-...-endif Kaskade vergleichbar, die von den Triggern immer angestoßen wird. Damit kann man das gleiche lösen, ist aber schwer zu überblicken und vor allem schwer anzupassen, wenn einige Zeit verstrichen ist und man nicht mehr weiß, warum man bestimmte Sachen gemacht hat.

Haben solche Automaten auch einen Namen? Sind es überhaupt Zustandsautomaten?

So, das reicht für heute,
Gruß, Waldemar

[mumpf]

Hi Martin,

Wie hast Du denn die Zustandsautomaten implementiert?

die meisten bei mir laufenden Zustandsautomaten habe ich mit callidomus implementiert, das ist eine Logikengine und Visu für KNX, das wird aber nicht mehr weiterentwickelt. Deswegen experimentiere ich gerade mit Home Assistant. Da gibt es zwar keine Zustandsmaschinen "out of the box", aber die da verfügbaren automations unterstützen alle notwendigen Aspekte.

Für gewisse Komfort-Funktionen, kann es dann auch etwas "Bastelei" sein, z.B. über Node-Red auf meinem raspberry pi (da habe ich die Anwesenheitsprüfung über die Fritz!Box laufen oder auch ansteuerung von Hue-Lampen und später mal Historische Daten mit Anzeige über Grafana).

Wenn ich hier raspberry, Node-Red, Hue, Fritz!Box und Grafana lese, wäre vielleicht Home Assistant auch was für Dich? Läuft auf dem raspberry und integriert all die anderen Dinge... Und Zustandsautomaten bekommt man damit auch hin

Gruß, Waldemar

[TheOlli]

Bei mir sieht es ähnlich aus. Grundfunktionen und Alarme müssen nativ über KNX laufen.

Komfort (der zur Not auch mal ausfallen darf) läuft über Node Red.

Die Steckdosen von Spülmaschine, Waschmaschine und Trockner werden nach Erkennung „Fertig“ von Node Red abgeschaltet.
Allerdings schalten wir die Steckdosen über Taster manuell wieder ein.

Historische Daten zeige ich auch über Grafana an.

[Chr1stoph]

P.S.: Bei mir wird die "Objektorientierung" übrigens über Zustandsautomaten realisiert.

Das sind doch zwei paar Schuhe - Objektorientierung und Zustandsautomaten. Der Zustandsautomat ist zuletzt eine abstrakte und übergeordnete Systembeschreibung die das Verhalten abbildet. Ob man dies nun strukturiert oder in spaghettiartigen Systemen implementiert ist ein anderes Thema.

Ich selbst greife in Softwareprojekten sehr gerne auf Zustandsautomaten zurück, insb. wenn das Gesamtsystem/Verhalten noch undurchsichtig ist. Viele Zustände sind eher unerwünscht aber kein Problem - wenn man strukturiert arbeitet.

Das Wichtigste (meiner Meinung nach) dabei ist die Struktur vollständig zu Papier zu bringen - wie in deinem Diagramm. Anschließend wird jeder Zustandsübergang implementiert und zeitnah getestet.

Ich empfehle bei dem Diagramm eine andere Notation der Transitionen (entlang der Pfeile) : "trigger [Bedgingung die erfüllt sein muss] / Aktion".
In deinem Diagramm sind die Aktionen in den Zuständen ausgedrückt. Das geht auch.
Grundlegend beschreibt die Zustandsautomatentherie zwei Typen: Moore und Mealy. In letzterem sind Zustände aktionslos. D.h. alle Aktionen werden durch Transitionen aka. Zustandsübergänge ausgelöst. Ich persönlich finde das in der Umsetzung einfacher da Zustände "dumm" sind und sie nur durch externe Trigger verlassen werden. Verlassen kann auch bedeuten, dass die Transition auf den Ursprungszustand zurückführt.
Wenn die Aktionen im Zustand ausgeführt werden stellt sich auch die Frage nach dem "wann". Dazu findet man i.d.R. "on entry", "while", und "on exit" Aktionen. Das Eröffnet aber das Problem: Der Automat muss wissen "wann" es gerade ist, d.h. man hat wieder drei Unterzustände geschaffen. Sind alle Aktionen "on entry" würde ich sie den Transitionen zuordnen.

Einde condition gehört nicht in einen Zustand ("Ausrechend PV").
Eine Transition darf sich nicht verzweigen. "Steckdose an" zu "Ausreichend PV" und "Wenig PV". Daraus muss man zwei Transitionen machen, es kann auch der selbe Trigger aber mit unterschiedlichen Bedingungen sein.

Du versteckst Unterzustände: Z.b. Transition Geschirr fertig -> Steckdose aus. Der Trigger ist nicht "geschirr fertig" sondern "30 sekunden abgelaufen". Der Sekunden-Timer muss aber irgendwie gestartet werden, d.h. es fehlt die Aktion "30 sekunden timer starten".
Von "Geschirr waschen" zu "Geschirr fertig" könnte es so aussehen:
"Geschirrspüler fertig" [ - ] / "Fertigmeldung (piep) ausgeben; 30 sekunden timer starten"
Von "Geschirr fertig" zu "Steckdose ein":
"30 sekunden timer abgelaufen" [ - ] / "..."


Puh sorry das wurde etwas umfangreich.

[martiko]

Moin Waldemar,

also erstmal vielen Dank für Deine Mühe, das so ausführlich zu beschreiben. Ich gebe zu, in das Detaillevel habe ich die meisten Dinge noch nicht bedacht, ich bin ja noch ganz am Anfang. Da ich aber nur eine Wohnung und z.B. auch keine PV-Anlage habe, wäre die Anzahl Zuständen und die Komplexität sicher deutlich gerinter.

Was ich aber - ohne es so konkrekt beschrieben zu haben wie Du - genauso machen möchte ist, dass so viel wie möglich mit KNX gehen sollte. Hintergrund ist, dass man ja nie weiß, ob und wie lange man sich um gewisse "Spielereien" kümmern kann. Und da ist es mir wichtig, dass mindestens alle Grundfunktionen mit normalen KNX-Mitteln funktionieren, so dass diese (falls ich mal nicht Verfügbar bin) im Notfall auch von einem SI oder guten Elektriker mit KNX-Erfahrung gepflegt werden könnten. Für gewisse Komfort-Funktionen, kann es dann auch etwas "Bastelei" sein, z.B. über Node-Red auf meinem raspberry pi (da habe ich die Anwesenheitsprüfung über die Fritz!Box laufen oder auch ansteuerung von Hue-Lampen und später mal Historische Daten mit Anzeige über Grafana).

Wie hast Du denn die Zustandsautomaten implementiert? Gibt es für sowas "Standard-Software", die man "nur" konfigurieren muss, oder hast Du das selbst programmiert?

Gruß
Martin

[mumpf]

Hi Martin,

das ist natürlich ein großes Thema. Mal schauen wie sich die Diskussion entwickelt. Die Zustandsautomaten selbst laufen alle auf einem zentralen Server, da es in KNX nativ keine Zustandsautomaten gibt. Und ein KNX-Server (so was wie der X1, EIBPC, Timberwolf, Domovea etc.) ist immer noch ein zentraler Server, die das Problem mitbringen, dass nichts funktioniert, wenn sie ausfallen. Deswegen verfolge ich ein Schichtenmodell:

1. So viel wie möglich in KNX nativ lösen
2. Wenn Logiken notwendig werden, möglichst KNX native Logiken und möglichst lokal (auf dem gleichen Gerät oder im gleichen Raum verwenden)
3. Wenn die ersten beiden Punkte nicht reichen, dann versuche ich es mit dem MDT Logikmodul nativ in KNX zu lösen
4. Erst wenn die obigen Punkte nicht gehen, springt der zentrale Server ein

Zusätzlich kommen noch 2 Konzepte hinzu:

1. Eine minimale Grundfunktion muss immer nativ in KNX funktionieren, ganz ohne Server, notfalls mit reiner manueller Bedienung
2. Der Zustandsautomat sitzt dann "oben drauf" und sorgt für zusätzlichen Komfort

Und dann kommt noch mein Bedienkonzept mit einer Prioritätenliste, das die Zustandsautomaten nicht einfacher macht:

1. Alarme (Windalarm, Regenalarm, Rauchalarm) haben immer Vorrang (sind ja auch Automatiken)
2. Dann kommt die manuelle Bedienung (die ist immer möglich, bei seltenen Ereignissen nur über die Visu, sonst durch Taster)
3. Dann kommen die Rückfallautomatiken, die die manuell erzeugten Zustände wieder zurücknehmen
4. Niedrigste Priorität haben dann "normale" Automatiken

Das alles macht meine Zustandsautomaten recht kompliziert, der für die Beschattung hat 31 Zustände .

Ich kann gerne ins Detail gehen, die Frage ist, auf welcher Ebene. Ich bin auch noch lange nicht so weit, wie ich eigentlich sein möchte. Die Konzepte sind nicht so einfach zu realisieren und ich bin immer wieder am optimieren.

Statemachine-Geschirrspueler.PNG
Ich hab als erstes mal den Zustandsautomat für meinen Geschirrspüler angehängt. Das ist der, an dem ich gerade arbeite und der gerade im Haus getestet wird. Ansonsten würde ich vorschlagen, dass Du einfach fragst/sagst, welcher Bereich Dich interessieren würde.

Gruß, Waldemar

[martiko]

Hi, in einem anderen Thread hat mumpf das Thema Zustandsautomaten hochgebracht, damit die Diskussion dazu nicht im anderen Thread untergeht, habe ich das Thema auf Vorschlag von @gbglance in ein eigenes Thema ausgegliedert.

Als Referenz hier die entscheidenden Aussagen von Waldemar:

Hi Martin,

....

Ich habe mich relativ früh für "Objektorientierung" entschieden (also das, was man vom Programmieren her kennt und was sehr gut funktioniert): Jedes Objekt weiß am besten, wie es sich verhalten soll, indem es selbst externe Einflussfaktoren auswertet.

Bei Licht heißt das: Der PM schaltet ein Hauptlicht ein, über Taster/Szenen/Logiken können andere Lichtkonfigurationen eingestellt werden, der PM schaltet bei Abwesenheit aber immer alle Lichter im Raum aus. Somit brauche ich kein "Alles aus" für Licht, der PM im Raum sorgt dafür, dass kein Licht an bleibt.

Bei der Waschmaschine/Kochfeld/Geschirrspüler sorgen auch die jeweiligen Geräte dafür, sich selbst zu verwalten: Steckdose (und damit das Gerät) geht an, wenn genügend PV-Energie zum Waschen da ist, Steckdose geht aus, wenn das Gerät fertig ist. Somit ist auch hier kein "Alles aus" nötig.

Beim Haus heißt das: Wenn ich in den Urlaubsmodus schalte (manuell, per Handy, per Google-Kalender oder per Abwesenheit > 48 Stunden) bekomme ich Informationen aufs Handy, wenn noch etwas an ist, was nicht sein sollte -> dann kann ich entscheiden, ob ich es noch remote ausschalten will oder mich auf die automatische Abschaltung verlassen.

Was ich eigentlich sagen will: Dem unbedarften Kunden wird häufig "Alles aus" als eine tolle Funktion verkauft, weil sie in KNX fast gar nichts kostet, in konventioneller Technik aber mit erheblichen Mehrkosten verbunden ist. Macht man sich aber mal Gedanken darüber, merkt man, dass man gar kein "Alles aus" haben will. Man will eine sinnvolle Reaktion aller Geräte (wohlgemerkt, jedes für sich) auf die aktuelle Situation.

Ich würde immer wieder so vorgehen, ist aber natürlich viel komplizierter zu realisieren als eine "Alles aus"-GA.

Gruß, Waldemar

P.S.: Bei mir wird die "Objektorientierung" übrigens über Zustandsautomaten realisiert.

Vielleicht hat berichtet Waldemar ja noch ein bisschen, wie er das umgesetzt hat und was er da zum Beispiel für "Zustände" umgesetzt hat...

Interessant wären auch Trigger, die einzelne Zustandswechsel auslösen. das würde ich für den Moment aber auch hier im Thema diskutieren wollen und dazu nicht gleich noch ein separates Thema aufmachen.