Locations, Equipment, Points, Things, Items, Pages … das ganze in einem Model – oder auch nicht. Die Fülle der Objekt-Typen die mit OH 3.x zur Verfügung stehen ist großartig, …, wenn man einen Plan hat 🙂
Die Anzahl meiner Geräte, Sensoren und Aktoren die munter an der Automatisierung meines Eigenheims beteiligt sind ist dreistellig. Mit der zweiten Version von OpenHAB fehlte mir die Möglichkeit Stuktur und Übersicht zu schaffen. Einzig die Sitemap bot ein paar Ansätze, aber nicht genug. Und genau hier kommt das Model mit Locations und Equipments ins Spiel.
Model vs. Physik
Vor OpenHAB 2.0 kümmerte man sich vor allem um eins: die Physik!
Man überlegte sich Werte bzw. Variablen (Items) und verknüpfte diese mit Dingen (Things). Dabei war der Name der Items extrem wichtig um später etwas wiederzufinden.
Diese Items waren der Speicher für physikalische Werte, als auch das Model der Automatisierung.
Das Problem dabei: Tauschte man ein Thing aus, musste man zusehen, dass man die Items wieder verwendete. Denn diese waren auch in sämtlichen Regeln untergebracht. Früher oder später hatte so vermutlich jeder den Überblick über seine Automatisierung verloren.
Vergessen wir einmal Things und Items und denken nur das zu automatisierende Objekt, z.B. ein Haus. Es hat Stockwerke und Zimmer, Terrasse, Dach und Garten. Eine PV-Anlage und eine Wärmepumpe. Eine Wetterstation und vieles mehr.
Mit Hilfe des Models lässt sich dies abbilden. Locations können in beliebiger Tiefe ineinander verschachtelt werden.
Wer also neu mit OpenHAB 3 anfängt ist gut beraten, sich zunächst einmal nur auf das zu automatisierende Objekt zu konzentrieren.
Ich habe hier im Beispiel nur zwei Ebenen verwenden, tatsächlich ist die abbildbare Tiefe in OH3 unbegrenzt.
Ich wünsche viel Spaß beim Modellieren 😉
Das Model steht – Zeit für Equipment
Rein teschnisch scheint es keinen Unterschied zwischen Equipment und Location zu geben. Und falls doch, habe ich ihn noch nicht gefunden. Ich behaupte, man könnte komplett auf Objekte vom Typ Equipment verzichten und stattdessen mit Locations arbeiten. Aber sei es drum, es gibt die Objekttypen, also nutzen wir sie auch 🙂
Equipment steht also für alles, was wir später einmal in die Automatisierung einbinden möchten. Wichtig: wir haben noch nicht ein einziges Gerät (Thing) integriert, wir sind immer noch am modellieren!
Es gibt auch die Möglichkeit aus Things direkt Equipment zu erzeugen. Aber das führt an dieser Stelle zu Verwirrung, deswegen gehe ich darauf erst mal nicht ein.
Hier noch ein wenig Inspiration:
Verbindungen zur Physik
Nun ist es an der Zeit sich konkrete Werte bzw. Variabeln zu überlegen, die später von Sensoren gefüttert werden, oder Aktoren steuern. Hierzu verwenden wir die neuen Objekte vom Typ Point. Points hängen direkt am Equiment oder an Locations und können die selben Werte wie Items einnehmen.
Ab diesem Punkt verlassen wir aber das Model ein Stück und nähern uns den Channels und Things an. Das bedeutet das Übliche, auf was in an dieser Stelle nicht näher eingehen werde: Bindings installieren, Things hinzufügen und konfigurieren.
Diese Struktur mag auf den ersten Blick umständlich aussehen. Aber stellen wir uns einmal vor, das Gerät „XYZ Luftquali Sensor“ geht kaputt und wird ersetzt. In diesem Fall verbleiben die Points an Ort und Stelle, nur das Thing wird gelöscht, die Points anschließend mit den neuen Channels verknüpft.
Alle Regeln, Scripte, Sitemaps, Pages usw bleiben intakt und bekommen von der Änderung nichts mit. Das ist der große Vorteil. Die Automatisierung bleibt übersichtlich, strukturiert und wartbar!
Hier seht ihr meinen Fibaro Bewegungsmelder im begehbaren Kleiderschrank. Ausgewählt ist der Temperatur-Wert (Point). Auf der rechten Seite seht ihr den verknüpften Channel „Temperatur“ des Z-Wave Fibaro Thing.
Noch keine Kommentare