Haus Modus und Zustandswechsel

[Onkelandy]

Machen wir da noch weiter oder geben wir auf ?

[gama]

Hi,

mir fehlt aktuell die zündende Idee, wie man so etwas (am besten graphisch) darstellt... vermutlich reicht die Matrix nicht mehr aus, um diese Automaten zu beschreiben und auch die Abhängigkeiten zu modellieren. Ideas welcome...

Markus

[hyman]

So vielleicht: https://de.wikipedia.org/wiki/Zustan...ramm_%28UML%29

Vermutlich braucht man nicht die gesamte Mächtigkeit der Notation. Man könnte ja mal anfangen mit einfachen Zuständen (abgerundete Rechtecke) und Übergängen (Pfeile mit auslösenden Aktionen/Bedingungen dran). Zeichnen kann man solche Diagramme z. B. mit Dia <http://dia-installer.de/index.html.de>.

[Onkelandy]

Gute Idee, Hyman.. Die Programmierer sollten den UML Kram ja kennen Ich werde auch mal in den nächsten Wochen versuchen, beispielhaft was entsprechendes aufzubauen... Mal sehen, obs was wird.

[gama]

Gibts da freie Software dazu, sodass jeder seine Ideen selbst pflegen kann (sonst bleibt alles an Einem hängen...)
In den letzten Tagen ist mir aufgefallen, dass die Heizungssteuerung hier ein guter Startpunkt wäre, denn die Temperaturregelung ist pro Zimmer/Einheit (Komforttemperatur) und je Gebäude / Etagen Zustand (Anwesend, Abwesend, Urlaub) und zentraler Zeitsteuerung (Tag/Nacht/Wochenende) überlagert... außerdem gibt es nicht zig Sonderfunktionen sondern meist 4 Betriebsmodi und Soll-Temperaturen welche in einer Logik verwaltet werden müssen.

[Onkelandy]

Tools gibt's wohl zuhauf.. https://en.wikipedia.org/wiki/List_o...Language_tools

Wichtig wäre eine Online Integration zum gemeinsamen Basteln. Mit draw.io und einem Google Account scheint das wunderbar zu funktionieren:
https://www.draw.io/

Man kann dann einfach den Link zum Dokument "freigeben" und sharen. Die anderen rufen die URL dann auf. Nach dm Login auf Google Drive über draw.io lässt sich di Datei dann direkt öffnen und bearbeiten. Alles in Echtzeit und mit Version History.

[LukasW]

Servus zusammen,

sehr spannendes Thema (Obwohl ich einen EibPort habe). Ich stoße auch dauernd an die Grenze, dass mir die Ordung in der Programmierung fehlt...

Um was beizutragen: Für Diagramme aller Art (auch state maschines) nutze ich gerne yEd, das gibt's für privat kostenlos.

[gama]

Hallo Zusammen,

ich wollte mich kurz zurückmelden (war in der Zwischenzeit damit beschäftig WAF-Grundfunktionen zu implementieren) um im Thema weiter zu kommen.

Vielleicht noch einmal die Zusammenfassung der wesentlichen Punkte aus dem Thread:
- Überlegung mit "Rollen" auf "Objekte" zu abstrahieren (z.B. Rolle Schlafen auf Objekt "Gästezimmer")
- Implementierung von einfachen Szenen ("Stimmungen" wie Weihnachtsbeleuchtung oder Fernsehen die meist auf ein Objekt bezogen sind
- Problem der XXXL State Machine (die am Ende keiner mehr blickt bzw. die Fehlersuche extrem schwierig gestaltet)
- Beibehaltung manueller Eingriffe

Zwischenzeitlich habe ich auch mal Google angeworfen und in verwandten Themen (z.B. "Internet of Things") oder in Dissertationen gesucht.
Ergebnis: eher ernüchternd bzgl. eines Architektur-Ansatzes. Auf der anderen Seite super, weil wir weitestgehend Neuland betreten dürfen...
ABER: es gab ein interessanten Gedanken: Die Grundfunktionen nicht über klassische Regler laufen zu lassen, sondern mit "Observer" und "Controller" zu arbeiten.

Mit dieser gedanklichen Stütze können wir die diskutieren Themen auch besser zuordnen, z.B:
- Der Observer "beobachtet" und hat als zentrale Aufgabe Zustände zu erkennen oder auch vorherzusagen (Interessant für Energiemanagement!)
- Der Controller Implementiert dann die Aktionen / Logiken / Regler / etc.

Weiterhin bin ich mir nicht wirklich sicher, ob eine Finite State Machine alle Anforderungen pauschal und elegant lösen kann.

Um weiter zu kommen, stellt sich nach wie vor die Frage, was ein Framework als Design-Standard leisten kann, ohne die Freiheitsgrande einer individuellen Implementierung noch des Manuellen Eingriffs einzuschränken.

Mein aktueller Ansatz basiert zunächst auf dem Objekt "Einfamilienhaus" (um es in der Startphase möglichst einfach zu halten) und umfasst mehrere Module die untereinander kommunizieren. Die Module sind generell als Observer / Controller gedacht.

MODE Management
- Eingang: diverse Signale
- Ausgang: Hauptzustände (ATHOME, LEAVING, AWAY, COMINGHOME) die sich gegenseitig ausschließen, und Unterzustände die aufgeschaltet werden können und zeitgleich aktiv sein können z.B. (ATHOME.PARTY, ATHOME.HANGOVER, ATHOME.GUESTS, etc.)
- Observer: Ermittlung des Zustands
- Controller: deaktiviert alle Unterzustände wenn der Hauptzustand wechselt.

BLIND Management
- Eingang: Uhrzeit, Helligkeit, Signale aus dem MODE Management, etc.
- Ausgang: Rolladen, Jalousie Signale
- Observer: Ermittlung des Zustands (evtl. mit Wettervorhersage Daten)
- Controller: Steuerung von Höhe und Lamellen (teilweise in Abhängigkeit vom Sonnenstand)

MONITOR Management
- Eingang: ...
- Ausgang: Warn-/Alarmmeldungen
- Observer: Erkennung Feuer, Einbruch, Wasserbruch, etc.
- Controller: Alarmstrategie und Nachrichten-Dispatcher (z.B. es wird extern alarmiert, wenn AWAY)

ENERGY Management
tbd.

SIMU Management
tbd.

evtl. SCENE Management
tbd.


Mit der Umsetzung habe ich beim MODE Management angefangen und es läuft bereit auf Basis von autoblind, parametrierbaren Verzögerungen der Übergangsmodi LEAVING und COMINGHOME. Die Submodi sind noch in Arbeit. Zudem gibt etwas .html code um den Automaten auf SmartVisu zu visualisieren... btw: wer ist bei blocky tiefer drin? Wäre es denkbar gleich erste Schritte in die BackendVisu zu machen? Gibt es schon Ansätze für autoblind?

Als nächsten Schritt werde ich BLIND Management (logischerweise auch auf autoblind) und MONITOR Management (mit Message Broadcast über Telegram Plugin, siehe https://knx-user-forum.de/forum/supp...08#post1022108) implementieren wollen.

Das der Winter etwas mehr Zeit für Programmierung erhoffen lässt, komme ich wahrscheinlich auch weiter

Generell würde mich Eure Meinung zur angepassten Architektur interessieren. Bitte visionäre Ansätze, Kritik, mögliche Limits nach wie vor posten!

[Onkelandy]

Schön, dass sich hier wieder mal was tut.. Mit Blockly habe ich noch nichts ausprobiert.
Die Ansätze find ich soweit spannend.. Wie bildest du aktuell denn die Unterzustände mit autoblind ab? Wäre generell cool, wenn du ein, zwei Beispiele mit konkreten Items listen könntest. Danke!

[gama]

Das mit den Unterzuständen ist so eine Sache, da z.B. ATHOME.PARTY und ATHOME.GUEST keine echten Zustände sind da diese zeitgleich aktiv sein können. Es sind vielmehr "Optionen" die den Zustand ATHOME genauer definieren. Wird jedoch der Zustand gewechselt sollen die "Optionen" auch deaktiv werden. Ebenso soll eine "Option" nur aktiv werden können, wenn der zugehörige Zustand aktiv ist.

HOLIDAY (als Unterzustand von AWAY) wird aktuell über Delay Timer aktiv (=wenn AWAY > 24h dann wechsel zu HOLIDAY). Der Zustand HOLIDAY schaltet dann zwei Signale (away, holiday) auf 1 - also eine Art Vererbung, sodass nur die Langzeit Routinen aktiv werden (z.B. Energiemanagement, Heizung, Warmwasser, etc.).

Es zeigt sich jedoch eine Abhängigkeit von Zuständen, Unterzuständen und Optionen welche das Framework handhaben muss. Bei den Optionen bin ich gerade am Überlagen, ob es nicht ausserhalb von autoblind mit evals besser zu lösen wäre... ideas welcome

Code folgt...