Haus Modus und Zustandswechsel

[gama]

Hallo Zusammen,

ich wollte mal in die Runde fragen, ob es schon einmal Überlegungen zu einem allgemeinen "Haus Zustandsmodell" gegeben hat?
Im Forum sowie über google bin ich nicht so richtig weiter gekommen.

Die Idee ist folgende:
Es gibt (viel zu) viele Zustände und Szenen die ein EFH annehmen kann. Die Frage ist, ob man mehr oder minder unabhängig von jeweiligen Anforderungen ein allgemeines Skelett entwerfen kann, welches eine Grundlogik darstellt. Also Zustände beschreiben einen aktuellen Modus in dem Bestimmte Ereignisse individuell ausgewertet werden. Zum Beispiel sind im Zustand "home" offene Fenster kein Problem. Das Signal blockiert ggf. den jeweiligen Rollo oder Heiz-/Kühlventil. Im Modus "away" oder "sleeping" dient das Signal hingegen der Außenhüllen Überwachung. Der Unterschied zwischen diesen beiden Modi liegt darin, dass im "away" Modus alle Fenster in der Meldekette sind, im "sleep" Modus die Schlafzimmerfenster ausgenommen sind... usw. usw. usw.

Ereignisse / Signale erlauben einen Zustandswechsel, so kann ein Abschließen der Haustür von "home" in "leaving" wechseln (in diesem Modus ist die Alarmanlage noch nicht scharf und die Wegbeleuchtung noch aktiv) und nach einem Timeout wechselt "leaving" in "away" und es wird ggf. die Anwesenheitssimulation aktiviert. Wie letztendlich die Ereignisse lauten, die einen Zustandswechsel herbeiführen sollte zunächst mal frei bleiben.

Erste Gedanken habe ich in eine Liste aufgenommen und hoffe auf Euer Feedback.

Grüße
Markus

[callidomus]

Hallo Markus,

ja, ich habe mir schon mal Gedanke dazu gemacht. Allerdings hatte ich noch nicht ausreichend Zeit/Muße das umzusetzen. Mich juckt es aber einen Zustandsautomaten zu bauen, den man einfach konfigurieren kann.
Es gibt das Autoblind-Plugin, das wesentlich mehr kann als nur Beschattung. Vlld. siehts Du Dir das mal an.

P.S. schöner Plan

Bis bald

Marcus

[bmx]

Hallo Markus,

eine gute Idee. Ich habe sowas schon mal angefangen, allerdings nicht mit Smarthome.py. Derzeit habe ich keine weitere Zeit dafür. Mir ist aufgefallen, das es noch interessant sein könnte zu berücksichten, ob es familienfreme Personen innerhalb des Hauses gibt (z.B. Party, Reinigungskraft, Babysitter, etc.) die eine Anpassung bedingen sowie die Berücksichtigung eines Gaslecks (Funkenbildung vermeiden -> Aktoren UP sperren bzw. in der Verteilung, sämtliche Außenbeleuchtung an wg. Hilfkräften etc.)
und auch den Alarmfall eines Hilferufes Krankenwagen o.ä.

Viel Erfolg bei der Umsetzung, ich werde Deinen Posts gespannt folgen...

Gruß,
Bernd

[offline]

Hallo Markus,

ich nutze das AutoBlind-Plugin um unser Haus in verschiedene "Zustände" zu versetzen. Allerdings weniger für Alarme etc, wie in deinem Beispiel. Eigentlich habe ich auch keinen Status für das gesamte Haus, sondern jeweils einen Status für jedes Stockwerk. Somit können die Status für die Stockwerke auch mal unterschiedlich sein.
Ich habe das so gemacht, dass ich die Grundzustände "Tag", "Nacht" und "Abwesend" habe. "Abwesend" wir über den "Zentral-Aus"-Taster getriggert, Tag und Nacht werden Tages- und Uhrzeitabhängig festgelegt. Zusätzlich gibt es verschiedene Sonderzustände, die mit diesen Grundzuständen kombiniert werden können (z. B. "Party im Haus", "Im Garten", ...). In Abhängigkeit vom Stockwerks-Zustand werden dann ggf. weitere Zustände einzelner Objekte gesteuert. Bei "Im Garten" beispielsweise sind Bewegungsmelder im Garten deaktiviert, die Lampen werden Helligkeitsgesteuert eingeschaltet. "Party im Haus" hingegen bringt das EG uhrzeitunabhängig in den Tag-Modus, das OG aber nicht, ...
Abhängig vom Stockwerkszustand habe ich

Das AutoBlind-Plugin ist mittlerweile ein vollwertiger Zustandsautomat, nur der Name des Plugins stammt noch aus den Anfängen. (Vielleicht sollte man das mal umbenennen.) Ich denke, dass sich deine Zustände und Trigger komplett mit dem Plugin abbilden lassen.

Grüße
offline

[gama]

Hallo,

das sind schon mal super Anregungen. Autoblind kannte ich bislang nicht, aber ein erster Blick in den Code sieht schon sehr nach dem aus, was meine Intension war. Der Grundgedanke war jedoch, erst einmal in eine Art Software Modellbildung / Architektur zu gehen - also die Logik auf den Anwendungsfall Haus / Stockwerk / etc. möglichst Allgemein zu beschreiben. Denn das Problem welches man oft liest geht ja dahin, dass man bestimmte Szenarien nicht vollständig durchdacht hat und es somit zu Fehlern kommt.

Die Frage ist auch in wie weit sich Vererben einsetzen lässt, also z.B. "party", "guest" sind von "home" vererbt und es werden nur die relevanten Funktionen überschrieben.

In diese logische Struktur möchte ich zunächst kommen, hänge aber immer wieder an bestimmten Designfragen fest wo ich auf das Feedback der Community hoffe...

AutoBlind als Basis der Implementierung zu nehmen ist sicherlich ein guter Ansatz - dann warum sollte man das Rad neu erfinden. Die Frage ist nur, ob man evtl. die Architektur hinsichtlich "vererben" überdenken muss...

Vielleicht sollten man versuchen bestimmte Use-Cases aus der Praxis(!) zusammenzutragen, also was macht Ihr im "Gästemodus" oder wenn der "Saugroboter" läuft, etc. Ich habe auch noch keine finale Darstellungsmöglichkeit gefunden. Gerne hätte ich ein "Big Picture", vielleicht als finite state machine, kann aber auch eine andere Darstellungslogik sein, die sich A0 ausdrucken lässt

Danke und Grüße
Markus

[mumpf]

Hi Markus,

ich habe mit offline in den Anfangstagen vom Autoblind auch häufig diskutiert und mich sehr gefreut, dass es zu einem generischen Zustandsautomaten ausgebaut wurde (danke nochmal offline). Im prinzip verfolge ich auch die Idee, verschiedene Hauszustände zu haben, allerdings glaube ich nicht, dass man alles über "den einen universellen Zustandsautomaten" abbilden kann. Ich verwende viele einzelne Automaten (Rolläden, Heizung, Lüftung, Licht), dann habe ich Automaten für Raumgruppen (Schlafräume, Wohnräume, Kinderzimmer, Bäder, Flure und Keller) und letztendlich auch einen Haus-Zustandsautomaten. Teilweise haben jetzt Hauszustände Auswirkungen auf die Zustände, die die Einzel-Automaten annehmen können (bei Haus-Anwesend nie die Lüftung auf Stufe 3), aber auch umgekehrt (wenn irgendwo "Schlafmodus" dann auf jeden Fall "Anwesend").

Ist aber alles noch nicht ausgegoren, ich spiele immer wieder dran rum, geht aber sehr langsam voran, da ich derzeit als Hauptaufgabe meinen Dachboden ausbaue und somit kauf Freizeit übrig ist.

Perspektivisch möchte ich mal da hin kommen, dass man bestimmten Räumen bestimmte Rollen zuweisen kann (Wohnraum ist ab jetzt Schlafraum, weil Besuch da übernachtet oder Schlafraum Kind ist jetzt Schlafraum Schwiegermutter, weil die zu Besuch ist) und dann sowohl die Räume eine personalisiertes Verhalten zeigen (Schwiegermutter kommt mit automatisierten Licht nicht klar, sie will immer explizit ein- und ausschalten - das darf sie dann zumindest in ihrem Schlafraum) wie auch die Gruppen- und Hausautomaten dann auf das geänderte Rollenverhalten reagieren. Das dauert dann aber noch ein paar "Jährchen".

Gruß, Waldemar

[gama]

Hallo Waldemar,

vielen Dank für Deinen Beitrag. Ich sehe es in der Umsetzung wie Du, dass die Zustände pro Einheit herunter gebrochen werden müssen, aber um mal anzufangen habe ich das EFH gewählt um eher den Weitwinkel anzusetzen. Ich habe die Liste (siehe Anhang) noch einmal um "Unterzustände" erweitert, einfach um die Ideen mal aufs Papier zu bringen.
Wahrscheinlich geht die erste Frage noch einmal in die Richtung ob ein Modus exklusiv ist oder ob er überlagert werden kann, also z.B. Party im Haus und zeitgleich Gast (Schwiegermutter über Nacht). Eine Konstellation die sich schon in der Realität kaum abbilden lässt und für eine Automatisierung sicherlich zur Herausforderung wird...
Die Idee Rollen mit Zustände auf Räume zu legen ist wahrscheinlich ein sehr guter Lösungsweg um die Aufgabe "Modi EFH" insgesamt zu meistern und möchte ich gerne mit aufnehmen, aber in erster Linie sollten wir mal alle möglichen (praxisnahen) Zustände durchdenken, geeignet gliedern und dann die Lösung einer nahe einer Implementierung suchen.

Also her mit den Ideen

Grüße
Markus

PS: ist vielleicht auch ein Thema welches außerhalb von smarthome.py diskutiert werden könnte... aber smarthome.py ist wahrscheinlich am besten für eine elegante Implementierung geeignet

[Onkelandy]

Die Zustandsliste ist schon mal sehr spannend, Danke gama. Ich bin auch gerade dabei, im ganzen Haus auf Autoblind umzustellen. Ist alles recht aufwändig, aber solch ein Konzeptvorschlag wie von dir erscheint mir hier sehr sinnvoll. Damit man auch wirklich von Beginn an alles denken kann.

Generelle Frage: kannst du wirklich auf all die gelisteten Dinge zugreifen? Wie hast du denn die Verbindung zu Klingel, Staubsauger und Rasenmäher?

Was die Zustände und so anlangt, schätze ich, dass einige Dinge recht individuell sind. Fraglich ist, wie weit wir hier ins Detail gehen bei der Diskussion. Interessant wäre auf jeden Fall mal zu erörtern, was alles über Zustände abgefangen werden soll und wo eine normale Logik/Szene mehr Sinn macht.
Sollen wir hier einfach mal alle Ansätze sammeln?

Hab bei mir zB noch einen Fernseh/Kino-Modus. Zum einen gibt es da ein paar Aktionen durch eine Logik, zum anderen schließen sich aber auch die Jalousien und die Präsenz/BW Melder werden umkonfiguriert: kurze Nachlaufzeit, geringe Sensibilität, niedriger Sollwert für die Lichter.

Außerdem gibt es auch einen Abend-Modus, der sich insbesondere auf die Lichtfarbe auswirkt.

Als Trigger für "abwesend" spiele ich derzeit noch mit den Location Services vom iphone in Verbindung mit dem Mail-Plugin. Funktioniert seit Wochen sehr zuverlässig. Und wenn mal nicht, ist es auch nicht so tragisch. Taster gehen aus meiner Sicht gar nicht für sowas, auch nicht für Schlafen

Hab auch noch diverse Zustände für Steckdosen, Lichter und Jalousien wie: Advent (Weihnachtsbeleuchtung), Halloween (alle LEDs orange ), etc. Für diverse Sachen natürlich auch Wetter bedingte Zustände, usw. Kann also schon recht kleinkörnig werden, wenn man wirklich Gewerke-mäßig aufdröselt.

Weiters überlege ich mir, meinen Sleeping-Trigger auch über Zustände abzufragen anstatt mit der Logik, die bei mir recht kompliziert geworden ist. Ich habe 2 Bettmatten. Sind beide für eine bestimmte Zeit belegt und ist seit x Minuten keine Bewegung im Geschoß, wechselt alles in den Sleeping Mode (paar Steckdosen abschalten, alle Lichter aus, Sollwerte für BWM/Lichter sehr niedrig, etc.). Steht man in der Zwischenzeit aber wieder auf, wird der Schlafmodus nicht aktiviert. Ähnliches Spiel beim Deaktivieren. Wobei es auch zeiten geben soll, in denen keinesfalls der Schlafmodus (de)aktiviert werden kann bzw. nur unter härteren Bedingungen.

[kex]

Hört sich alles ziemlich klasse an.
Ich sehe aber das Problem, dass man aufpassen muss Sicherheitsrelevante Funktionen über so einen Zustandsautomat abzubilden.
Solche Sachen sollte man am besten direkt mit den Sperr- bzw. Alarmobjekten der Busteilnehmer verbinden.

Wie geht ihr mit diesem Thema um?

[Onkelandy]

Sicherheitsrelevant habe ich eigtl. nur ein den Windsensor mit den Raffstores gekoppelt. Und das ist über KNX Wetterstation und Aktor definiert. Nichts desto trotz bilde ich das auch über den Zustandsautomaten ab, einfach nur, um das entsprechende Feedback in der Visu zu haben.

[mumpf]

Hi,

habe mir jetzt auch mal genauer den Plan angeschaut - sind schon gute Ideen dabei. Allerdings zeigt er auch recht deutlich ein Problem, das man bei einer (großen) State-Engine bekommt: Eine dünn besetzte Matrix. Ein weitere Frage, die ich mir sofort stelle ist, inwiefern sich ein solches Konzept so verallgemeinern lässt, dass es wirklich für mehrere Leute sinnvoll ist. Bekommt man wirklich ein Konzept hin, bei dem sich einfach Zustände streichen lassen (wir haben z.B. keine Alarmanlage) und das Ganze macht dann trotzdem noch Sinn? Ansonsten diskutieren wir hier über den individuellen Zustandsautomaten des TE, was durchaus ok ist, nur habe ich den Thread anders verstanden.

Außerdem fehlen mir in der Matrix noch manuelle Eingriffe, die zumindest bei uns die Sache endlos kompliziert machen. Ich bin der gleichen Meinung wie Onkelandy, dass man Sicherheitsfunktionen auch in States abbilden sollte, ganz unabhängig davon, ob zusätzlich noch direkt per KNX implementiert sind: Der Zustandsautomat sollte immer die Realität repräsentieren.

Ich glaube fest daran, dass man eine Art "Layering" verschiedener Zustandsautomaten braucht, deren Zustände auf den Haus-Automaten wirken, aber die ihrerseits auch vom Haus-Automaten beeinflusst werden. Meiner Meinung nach werden viele der Trigger für den Haus-Automaten ihrerseits von Zustands-Automaten bestimmt. Das Beispiel mit Schlafmodus von Onkelandy passt sehr gut und ich würde das gerne aufgreifen:

Auch ich hatte mal gedacht, dass der Schlafmodus automatisch ermittelt werden soll. Also habe ich mit einem Zustandsautomaten pro Schlafzimmer begonnen, der den Schlafmodus ermittelt. Wir haben 5 Schlafzimmer (4 normale und ein Gästezimmer). Belegungsmatte ins Bett - prima. Ich (und auch die anderen Familienmitglieder) würden gerne auch mal im Bett lesen, also muss man das mit einer Zeit kombinieren. Das ist aber zu starr - ab wann ist lesen zu Ende und schlafen angesagt? Was ist mit Krankheit? Nachmittagsschläfchen? Ein Bett ist ein Wasserbett, da braucht man auch für die Belegung einen anderen Indikator. Bei viel Besuch kann das Wohnzimmer auch noch als Schlafmöglichkeit dienen, das muss dann auch die Rolle eines Schlafzimmers bekommen. Wenn irgendeiner den anderen Indikatoren (Lesen, Krank, Belegung) über eine Taste oder über die Visu vergeben werden muss, dann ist eine einfache "Schlafen"-Taste am Bett besser. Da mir für Lesen und Krank nichts gutes eingefallen ist, ermittle ich den Schlaf-Modus pro Zimmer bei uns über eine Taste. Wann allerdings der Schlafmodus ausgeht, ist komplizierter: Wochentags gibt es einen Wecker (Licht geht gedimmt an, Musik auch - ist noch auf Aufbau), 5 Minuten später geht der Schlafmodus aus. Die Weckzeit ist natürlich pro Schlafzimmer individuell. Am Wochenende/Feiertags/Ferien geht der Schlafmodus automatisch um 12:00 Uhr Mittags aus, sofern er nicht vorher manuell aufgehoben und dann wieder eingeschaltet worden ist (z.B. wegen Mittagsschlaf, Krankheit).

Prima, jetzt will ich den Schlafmodus auch pro Stockwerk haben (z.B. für Pipi-Licht). Hier war es recht einfach: Das Stockwerk geht in den Schlafmodus, wenn eines der Zimmer auf diesem Stockwerk in den Schlafmodus geht und es Abends ist. Komplizierter wurde es wieder beim Aufheben des Schlafmodus: Sobald der erste Schlafmodus aufgehoben wird, soll das Stockwerk den Schlafmodus verlassen - somit ist der Stockwerk-Schlafmodus ein (kleiner) Zustandsautomat. Der Schlafmodus im Erdgeschoss ist ein Zustandsautomat, der eine Heuristik implementert, die Licht, Präsenz, Geräte (TV, Stereoanlage, Kaffeemaschine), Terrassentür und natürlich den Schlafmodus im Wohnzimmer berücksichtigt; torpediert wird das durch unsere Katzen, deswegen ist "Präsenz" alleine schon ein Unter-Zustandsautomat...

Was ist jetzt mit dem Haus-Schlafmodus? Die Aussage "Wenn alle schlafen, ist das Haus auch im Schlaf-Modus" ist nicht einfach zu realisieren. Dazu muss man nämlich wissen, wie viele Leute im Haus sind und in welchen Zimmern sie schlafen. Dass nur ein Stockwerk im Schlafmodus ist, reich für das Haus nicht. Letztendlich ist es bei uns eine Heuristik, die sowohl den Trivialfall berücksichtigt (alle Schlafräume sind im Schlafmodus) wie auch Ausgaben verschiedener Unter-Automaten (Person ist wahrscheinlich abwesend, da deren Handy zur üblichen Schlafenszeit nicht im Haus ist; EG ist im Schlafmodus, keiner ist im Keller etc.)

Warum schreibe ich das Ganze? Man kann sich durchaus Gedanken zu einer Haus-Zustandsmatrix machen, aber schon ein einfacher Eintrag wie "TRIGGER: Sleep" enthält für ein ganzes Haus eine Reihe von individuellen Einflüssen, die diesen Trigger bestimmen und wiederum eine Reihe von individuellen Aktionen, die davon ausgelöst werden können. Über den Trigger "Abwesend" könnte man eine ähnliche Abhandlung schreiben. Und je mehr Personen (und vielleicht Haustiere) im Haus leben, desto schwieriger wird es, solche Trigger zu ermitteln. Ferner hängt das Ganze auch noch von der verfügbaren Sensorik ab, die wiederum sehr individuell ist.

Ich stelle mir die Frage, ob der "Outcome" der hier vorgeschlagenen Matrix genug Substanz haben kann, um den Status der Trivialität zu verlassen.

Das soll jetzt genug für heute sein,
Gruß, Waldemar

[Onkelandy]

Waldemar gibt wieder Gummi Die Frage ist halt auch, was bewirken die Zustände tatsächlich? Bei uns sind im Schlafmodus eben einfach einige Geräte aus und das Licht dezent. Meiner Meinung nach macht es gerade bei den Geräten Sinn, wenn der Schlafmodus wirklich nur an geht, sobald alle Betten belegt sind, also alle schlafen. Sobald eine Person aufsteht, ist vorbei mit Sleepmode, da ja zum einen WLAN gewünscht ist, zum anderen das Morgenlicht.

Und bezüglich Pipi-Licht muss man halt abwägen.. will derjenige, der als Letztes in Bett geht unbedingt Vollbeleuchtung? Dann muss das Licht wohl erst dann in Schlafmodus schalten, sobald alle im Bett sind (also gleich wie bei Geräten). Ist es den meisten eh egal, dann kann das Licht schon dimmen, wenn nur 1 Person pennen geht. Oder wenn man's übertreiben will, gibt es dann verschiedene Dimm-Modi je nach Anzahl Leute im Bett - so hätte man auch immer einen dezenten Hinweis darauf, wie viele Leute schon gemütlich im Land der Träume sind, hehe

Also gerade bei Komfortlösungen wäre ich da einfach ne Spur flexibel... aber letztlich ist klar - für viele Trigger kann man lange Abhandlungen schreiben. Eventuell kann man sich hier im Thread aber tatsächlich auf die Haupt-Dinge in punkto "Haus" konzentrieren. Mindestens so spannend wie die Zustände sind ja auch die Aktionen. Hier denke ich, wäre schon Potenzial, alles mal in eine große Matrix zu werfen, um Ideen zu teilen. Und bezüglich Trigger könnte man sich ja auch auf eine kurze Beschreibung limitieren wie z.B. Trigger Schlafmodus: a) Bettmatte, b) BWM-Analyse, c) Taster am Bett, d)blabla.. einfach, um die Vielfalt ein wenig abzubilden, ohne ins Detail zu gehen.

PDFs sind dazu aber natürlich ungünstig.. vielleicht ein Google Spreadsheet, o.ä., an dem man wirklich gemeinsam arbeiten kann?

[gama]

Hallo Zusammen,

zunächst herzlichen Dank für den Input. Mir geht es im Wesentlichen darum zunächst eine geeignete Darstellungsform zu finden, die auch (nach individuellen Bedürfnissen) angepasst und detailliert werden kann. Bin mir nicht sicher ob hier eine einfache Matrix ausreicht. In Summe gibt es sicher (zu) viele Zustände und mögliche Trigger, aber die Frage ist ob man ein Logisches Korsett schaffen kann.
Ich finde mittlerweile die Idee, dass ein Raum einen Zustand annehmen kann sehr geschmeidig, so kann man im Kinderzimmer 1 "Kino" aktivieren während Kinderzimmer 2 "Schlafen" hat. Ich denke die Trigger welche einen Zustand erkennen oder wechseln werden meist individuell sein und an die vorhandene Sensorik angepasst werden.
Mit dem Zustand pro Raum lassen sich auch Raum-Gruppen definieren (=Stockwerk) die in Abhängigkeit der Unterzustände den Gruppenzustand ableiten können. Zusammengefasst ein Modell, welches sich flexibler anhört als mein erster Entwurf der Matrix.

Mir ist noch nicht ganz klar, was in die Layer soll. Sollte hier der Funktionsumfang (z.B. Alarmfunktion ja/nein) je Raum und Zustand eingebaut werden können. Wäre Reizvoll... mir fehlt jedoch die Idee wie man so etwas vernünftig in code abbilden könnte...

Es ist und bleibt ein sehr komplexes Thema, aber ich denke mit fortschreitender HomeAutomation wird man sich diesen Dingen stellen müssen...

[Onkelandy]

Sollte da ein Anhang ran?

[hyman]

Ich finde den Gedanken, zunächst mal die möglichen Zustände zu modellieren, sehr sinnvoll. Da die Implementierung auf unterschiedliche Weise erfolgen kann, würde ich das zunächst ohne Berücksichtigung schon bestehender Implementierungen machen.

Klar ist, dass es um mehr geht, als eine lineare Abfolge von Zuständen. Mir scheint eine Architektur aus mehreren, hierachrchisch angeordneten Zustandsautomaten, die nur begrenzt miteinander wechselwirken, am einfachsten. Grundgerüst (für ein Mehrfamilien-Wohnhaus) etwa so:

Haus
Zustandsautomat Heizung; Zustände: Nachtabsenkung, Morgenaufheizung, Normalbetrieb
Zustandsautomat Beleuchtung; ...
...

pro Wohnung
pro Stockwerk
sind ja in den obigen Posts schon eine Reihe guter Ideen, die müsste man jetzt halt noch etwas formalisieren.
Ideen, wann eine untergeordnete Hierarchiestufe in eine übergeordnete eingreifen soll, wurden ja auch schon genannt.

pro Raum
kommt man in 99% aller Fälle mit Szenen gut hin, das oben genannte Beispiel "Fernsehen" eingeschlossen.
Auch Szenen können ja bei Bedarf in übergeordnete Hierarchiestufen eingreifen oder von ihnen modifiziert werden.

Grüße von Horst