JAXenter.de

Das Portal für Java, Architektur, Cloud & Agile
X

Schon abgestimmt im Quickvote? Docker versus Rocket - wer hat Recht?

Home, Smart Home

Home, Smart Home: Heimautomatisierung mit OSGi

Kai Kreuzer

Die IT hat fast alle Lebensbereiche erobert, nur in der Hauselektrik fristet sie noch ein Schattendasein. Mit zunehmender Anzahl elektronischer Geräte wird aber auch hier die Vernetzung immer interessanter und eröffnet zahlreiche neue Möglichkeiten. Der Open Home Automation Bus (openHAB [1]) nutzt OSGi, um verschiedene Systeme miteinander zu verbinden und unter einer einheitlichen Oberfläche bedienen zu lassen.

Das Smart Home ist schon seit mehr als einem Jahrzehnt ein viel diskutiertes Thema, verspricht es doch neben Komfortgewinn auch eine höhere Sicherheit sowie Energieeinsparungsmöglichkeiten. Dennoch konnte es sich bisher in Privathaushalten noch nicht durchsetzen. Das liegt einerseits sicher an den recht hohen Einstiegskosten und dem notwendigen Installationsaufwand, andererseits aber auch an der starken Marktfragmentierung. So steht der willige Käufer vor einer unübersichtlichen Zahl von Optionen: Soll er ein System mit Bus-Kabel (z. B. KNX [2]) verwenden oder zwecks einfacherer Nachrüstung doch lieber auf Funk (z. B. EnOcean [3]) oder gar Powerline (z. B. DigitalSTROM [4]) setzen? Welche Taster und Aktoren bekommt er von welchem Hersteller für welches System? Welche Geräte gibt es für die Steuerung und Programmierung? Wie greift man übers Internet darauf zu? Und kann er auch seine Waschmaschine daran anschließen? Oder reicht nach dem Blick in die Preislisten doch eine einfache Steckdosenleiste mit Ethernetanschluss?

Was ist ein Smart Home?
Der Begriff "Smart Home" bezeichnet die Automatisierung und Vernetzung von Hauselektrik (Licht, Rollläden etc.), Elektrogeräten (Waschmaschine, Kühlschrank etc.) und Unterhaltungselektronik (TV, Hifi etc.). Im deutschsprachigen Raum wird allgemein auch der Begriff "Intelligentes Wohnen" [8] verwendet. Dabei werden je nach Einsatzart verschiedene Ziele verfolgt:

  • Komfort: das offensichtlichste Merkmal – das Haus denkt mit, man selbst wird entlastet. Eine besondere Form hiervon ist der Bereich Ambient Assisted Living [9], bei dem ältere Menschen von intelligenter Technik unterstützt werden, wobei sich diese fast unsichtbar im Hintergrund hält.
  • Sicherheit: Eine professionelle Alarmtechnik wird man nur in den wenigsten Smart Homes finden, aber bereits zeitgesteuerte Rollläden, ein Hinweis auf offene Fenster beim Verlassen des Hauses oder die automatische Abschaltung des Bügeleisens können die Sicherheit deutlich erhöhen. Auch SMS-Benachrichtigungen sind eine sinnvolle Ergänzung.
  • Energieeinsparung: Im Rahmen der Realisierung von Smart Grids versuchen die Energieversorgungsunternehmen im Bereich Smart Home Fuß zu fassen. Für den Verbraucher lässt sich mit einer intelligenten Heizungssteuerung oft eine deutliche Einsparung realisieren, z. B. durch Nachtabsenkung, Präsenzerkennung oder Fernsteuerung (aus dem Urlaub). Für die Energieversorger wird es erst richtig interessant, sobald der Strompreis flexibel gestaltet werden kann, d. h. zu Spitzenzeiten der Strom teuerer ist als beispielsweise in der Nacht. Auch wenn mittlerweile intelligente Stromzähler installiert werden, wird es noch einige Jahre dauern, bis die Netzinfrastruktur sowie die Abrechnungsverfahren dafür bereitstehen.

Im Allgemeinen wird man in Smart Homes eine Kombination von allen drei Bereichen vorfinden, da sie oft sinnvoll ineinander greifen. Welche Ausprägung man wählt, hängt vom persönlichen Geschmack und auch vom Budget ab.

Integrationsplattform

Egal welche Entscheidung man trifft, die Wahrscheinlichkeit, ein System zu wählen, das in ein paar Jahrzehnten kaum noch einer kennt und für das es keine erschwinglichen Ersatzteile mehr gibt, ist äußerst hoch. Auch wird man kein Angebot finden, das in allen Bereichen überzeugt und sämtliche Wünsche zu einem akzeptablen Preis erfüllen kann. Man wird aber kaum mit mehreren Insellösungen leben wollen, die jeweils ihre eigene iPhone-App brauchen und nicht interagieren können. Es gilt also, eine offene Integrationsplattform zu finden, die es zum einen erlaubt, flexibel neue Systeme anzuschließen (bzw. bestehende durch eine andere Technologie zu ersetzen) und zum anderen ein über alle Systeme einheitliches User Interface sowie systemübergreifende Automatisierungsregeln bietet. Genau hier setzt der Open Home Automation Bus an.

Die Idee einer solchen Plattform ist natürlich nicht neu, sondern schon so alt wie die Idee des Smart Homes selbst. Doch fast alles, was sich im Open-Source-Umfeld finden lässt, kommt aus der Linux/Skripting-Community – als prominentes Beispiel für ein sehr umfangreiches Projekt sei hier Misterhouse [5] erwähnt. Doch was macht der verwöhnte Java-Entwickler, der den Komfort einer IDE wie Eclipse gewohnt ist – von Syntax Checks über Content Assist und einem leistungsfähigen Debugger? Genau an diesen wendet sich openHAB – mit Equinox als serverseitige OSGi-Runtime, Jetty als HTTP-Server, Xtext für Konfigurationen und JBoss Drools für die Automatisierungsregeln. Doch eins nach dem anderen.

openHAB-Architektur

openHAB besteht aus zwei Teilen: der Runtime und dem Designer. Die Runtime läuft serverseitig in einer JVM und nutzt Equinox als OSGi-Umgebung. Sie ist plattformunabhängig und läuft auf Windows, Mac und Linux gleichermaßen. Der Designer dient der Konfiguration – anstelle eines einfachen Texteditors können hier die Konfigurationsdaten und Regeln mit komfortablen Editoren erstellt und bearbeitet werden. Das reduziert das sonst oft nötige Trial-and-Error-Verfahren und reduziert die Gefahr, dass sich Bugs einschleichen – und diese sind in Heimautomatisierungsregeln oft nicht lustig, zumindest nicht für den Rest der Familie.

Die Grundidee der openHAB Runtime basiert auf einem Event Bus nach dem Publish Subscribe Pattern, der technisch durch den OSGi Event Admin Service realisiert ist. Jedes anzusteuernde Gerät bzw. jeder Sensor wird als abstraktes "Item" definiert, wobei ein "Item" beispielsweise einen Schalter, einen Temperaturmesswert oder auch den aktuellen Radiosender repräsentieren kann. Erst so genannte Bindings koppeln Items an konkrete Hardware, Schnittstellen oder Protokolle, wie in Abbildung 1 zu sehen ist. Diese Trennung sorgt dafür, dass auf Basis der Items Benutzerschnittstellen gestaltet sowie Automatisierungsregeln formuliert werden können, ohne dass auf konkrete Hardware Bezug genommen werden muss. So kann sich das System jederzeit um neue Komponenten erweitern, darüber hinaus können bestehende Items durch Änderung der Bindings an neue Hardware gekoppelt werden.

Abb. 1: Die Architektur der openHAB Runtime

Was verbirgt sich nun technisch hinter einem Item? Es hat im Wesentlichen einen eindeutigen Namen und einen Typ (z. B. Switch, Dimmer, Number etc.). Ein Typ definiert mögliche Zustands- bzw. Kommandotypen eines Items. So kann ein Dimmer z. B. Boolean-Werte (ON/OFF) und Prozentwerte als Status haben und zusätzlich Kommandos wie increase oder decrease akzeptieren. Weiterhin kann zu einem Item ein Default-Labeltext, sowie ein Default-Item definiert werden. Eine besondere Stellung haben Items des Typs Group. Sie gruppieren, wie der Name schon sagt, mehrere Items entweder logisch (z. B. alle Items eines bestimmten Raums) oder nach Typ (alle Lichter). Über solche Gruppen kann dann sehr leicht der Status von mehreren Items gleichzeitig überwacht ("irgendwo ein Fenster offen?") bzw. ein Kommando an viele Geräte geschickt werden ("alle Lichter aus!").

Items werden der Runtime durch ItemProvider als OSGi-Service bereitgestellt. So können dynamisch zur Laufzeit Änderungen vorgenommen und Items hinzugefügt oder entfernt werden. Dennoch ist es in den meisten Fällen sinnvoll, Items statisch zu definieren, denn verbaute Schalter oder Sensoren ändern sich nicht so oft. Hierzu bietet openHAB einen ItemProvider, der Dateien mit einer einfachen Syntax einliest. Diese Syntax ist als Xtext-Grammatik definiert, wodurch komfortable Editoren im openHAB-Designer zur Verfügung stehen. Ein einfaches Beispiel für eine solche Datei zeigt Listing 1.

/* Gruppen */
Group Licht
Group Bad "Bad"

/* Badezimmer */
Switch Licht_Bad_Decke "Deckenlicht" (Bad, Licht)
Switch Licht_Bad_Spiegel "Spiegellicht" (Bad, Licht)
Number Temperatur_Bad "Temperatur [%.1f °C]" <temp> (Bad)
Switch Heizung_Bad "Heizung" <heating> (Bad)
Rollershutter Rollladen_Bad "Rollladen" (Bad)
Contact Fenster_Bad "Fenster [%s]" (Bad)

/* Wetter */
Number Aussentemperatur "Außentemperatur [%.1f °C]" <temp>
Number Wind "Windgeschwindigkeit [%.1f m/s]" <wind>
Number Helligkeit "Helligkeit [%.0f Lux]" <sun>

/* Status */
Switch Anwesend <present>
 

Kommentare

Ihr Kommentar zum Thema

Als Gast kommentieren:

Gastkommentare werden nach redaktioneller Prüfung freigegeben (bitte Policy beachten).

Übersicht zu diesem Beitrag
  1. Home, Smart Home: Heimautomatisierung mit OSGi
  2. Seite 2: User Interface
  3. Seite 3: Konnektivität