Suche
Ein Feuermeldesystem mit Eclipse SmartHome aufsetzen

SmartHome in Action mit openHAB und MQTT

Christian Götz, Markus Mann
SmartHome in Action mit openHAB und MQTT

© Shutterstock / Bloomua

Wie kann ein Smart Home in Zukunft zur Sicherheit in den eigenen vier Wänden beitragen? Anhand eines Beispiels gehen wir dieser Frage auf den Grund und zeigen, wie mit frei verfügbarer Hard- und Software ein Smart-Home-System mit Sicherheitsfunktionen aufgebaut werden kann. Dabei geben wir einen Einblick in die Konfigurationsmöglichkeiten von openHAB und in das Protokoll MQTT.

In den eigenen vier Wänden einen Schaden zu erleiden, stellt für viele ein Horrorszenario dar. Dies gilt vor allem, wenn neben reinen Sachwerten auch ideelle Werte verlorengehen oder gar Menschenleben gefährdet sind. Bei Bränden ist gerade das zu oft der Fall: Trotz sehr guten Brandschutzmaßnahmen kosten Feuer in Deutschland jährlich immer noch 400 Menschen das Leben, 4 000 Menschen werden schwer verletzt.

Der in Haushaltsbränden auftretende Brandrauch ist dabei die eigentliche Gefahr. Die verschiedenen Materialen im Haushalt lassen häufig giftige Rauchgase entstehen. Drei Atemzüge eines solchen Giftcocktails können für eine Rauchgasvergiftung mit unvermeidlich tödlichem Ausgang ausreichen. Es werden auch Fälle beschrieben, in denen ein einziger Atemzug für eine schwere Vergiftung ausreichend war – mit langfristigen Konsequenzen für die Gesundheit.

Die Ansicht, dass man Brandgeruch rechtzeitig wahrnimmt, trifft im Ernstfall leider nicht zu. 70 Prozent aller Brände entstehen nachts, und im Schlaf ist der menschliche Geruchssinn nicht aktiv. Auch Haustiere erweisen sich nur in den seltensten Fällen als zuverlässige Brandwächter. Die einzige Abhilfe stellt momentan die Installation eines zertifizierten Brandmelders dar. Auf diese Tatsache hat der Gesetzgeber in Deutschland bereits reagiert, deshalb ist ab 2018 in ganz Deutschland die Installation solcher Brandmelder auch für Bestandsgebäude Pflicht.

Mit Blick auf die rasante Entwicklung des Smart-Home-Markts stellt sich nun die Frage, inwiefern heimtaugliche intelligente Gebäudetechnik in einem Smart Home mit Brandmeldern zusammenwirken kann, um den Komfort und die Sicherheit zu erhöhen. Durch Vernetzung mit anderen Geräten können sinnvolle Zusatzfunktionen vergleichsweise einfach implementiert werden. Wir wollen in diesem Artikel untersuchen, wie integrierte Lösungen bereits heute mit der Integrationsplattform openHAB bzw. Eclipse SmartHome realisiert werden können.

Funktionalität des Systems und Basisarchitektur

Neben den Standardfunktionen eines Rauchmelders sollen in unserem Smart Home folgende Funktionen geboten werden:

  • Mobiler Alarm: Insbesondere, wenn Kinder oder ältere bzw. pflegebedürftige Menschen im Haushalt wohnen, verspricht ein verlässlicher mobiler Alarm zusätzliche Sicherheit und ein besseres Gefühl bei Abwesenheit.
  • Eskalationsmechanismen: Wenn die Angehörigen nicht erreichbar sind oder eine Klärung der Alarmursache für die Angehörigen bzw. registrierten Helfer nicht möglich ist, kann die automatische Weiterleitung eines Alarms an professionelle Leitstellen Leben retten beziehungsweise das Ausmaß des Brandschadens reduzieren. Die Zeit bis zur Alarmierung der Feuerwehr besonders in Gebäuden mit isolierter Lage kann somit signifikant reduziert werden.
  • Vereinfachte Wartung: Ein Mehrwert wäre beispielsweise die Anzeige der Batteriewarnung unter Angabe des Raums am Mobiltelefon.

Unser Smart Home bauen wir aus Geräten von HomeMatic und einem Raspberry Pi als Hauszentrale mit openHAB auf. Außerhalb des Hauses vermittelt ein MQTT-Broker zwischen Haus und anderen Geräten oder Diensten, im Beispiel einem Android-Mobiltelefon. Der MQTT-Broker bietet außerdem einen Anknüpfungspunkt für professionelle Leitstellen, die Notfälle effizient managen können (Abb. 1).

Abb. 1: Architektur

Abb. 1: Architektur

Die Rauchmelder

Bei den Rauchmeldern unseres Smart Home legen wir uns für diesen Artikel auf den Hersteller e-Q3 mit seinem Produkt HomeMatic fest. Es gibt am Markt eine Vielzahl von Komponenten mit anderen Funkstandards wie EnOcean oder ZigBee. Die Integration mit openHAB funktioniert mit anderer Hardware über verschiedene Plug-ins, prinzipiell werden die populärsten Funkstandards durch openHAB unterstützt. Es können auch in einem System mehrere Technologien gleichzeitig verwendet werden.

HomeMatic arbeitet mit dem proprietären Funkprotokoll BidCoS. Die Kommunikation erfolgt bidirektional über das 868-MHz-Band. Das Signieren von Steuerbefehlen mittels AES ist möglich, birgt aber momentan eine kleine Unannehmlichkeit: Geht ein einmal gesetzter AES-Schlüssel verloren, kann das Gerät nur mehr vom Hersteller zurückgesetzt werden.

Als Schnittstelle zwischen den Geräten und openHAB bietet eQ-3 ein eigenes Gerät namens CCU2 an. Dieses Gerät arbeitet als Gateway zwischen BidCoS und Ethernet. Über Ethernet hat openHAB Zugriff auf einen XMLRPC-Server am Gerät, der Methoden zum Aufruf anbietet.

Eine Alternative zum CCU2 bietet das Projekt Homegear, das die gleiche Serverschnittstelle anbietet, aber direkt auf dem Raspberry Pi läuft. Dazu ist nur ein Aufsatz für den Pi zur 868-MHz-Kommunikation notwendig. Das „SCC“ ist ein Beispiel für ein solches Modul und ist über busware.de erhältlich. Damit läuft unsere Hauszentrale auf einem einzelnen Gerät.

Die Hauszentrale

Als Hauszentrale setzen wir einen Raspberry Pi mit Raspbian und openHAB neu auf. Ein .deb-Paket für die komfortable Installation auf dem Pi kann man erstellen, indem man den Quellcode von openHAB selbst mit Maven baut. Zu finden ist das Paket nach dem Build im Ordner distribution/target. Die Erweiterung der Plattform um Technologiespezifika erfolgt in openHAB über so genannte Bindings. Das sind OSGi-Plug-ins, die im openHAB-Verzeichnis unter addons abgelegt werden. Wir verwenden für unser Smart Home die Bindings HomeMatic und MQTT.

Für die Bearbeitung der openHAB-Konfiguration eignet sich der openHAB-Designer. Dabei handelt es sich um eine IDE mit Features wie Codevervollständigung oder Templates. Die grundsätzliche Konfiguration von openHAB und aller Bindings erfolgt über die Datei openhab.cfg. Für unsere Bindings sind die in Listing 1 gezeigten zusätzlichen Konfigurationen notwendig.

Listing 1: configurations/openhab.cfg

# URL to the MQTT broker, e.g. tcp://localhost:1883 or ssl://localhost:8883
mqtt:hivemq.url=tcp://[MQTT-BROKER-URL]:1883
# Unique client id used by the broker to identify the client
mqtt:hivemq.clientId=HomeMatic
# Send all messages as „retained“ so subscribers will get the last message
# that was published when they subscribe to the topic
mqtt:hivemq.retain=true
mqtt:hivemq.qos=1
# Set last will and testament. This is a message the broker will publish,
# when this client disconnects to notify other clients
mqtt:hivemq.lwt=haus1/master/technical/status:0:1:true
# Hostname / IP address of the HomeMatic CCU
HomeMatic:host=raspberrypi

Kommunikation mit der Außenwelt über MQTT

Damit die Hauszentrale mit anderen Diensten außerhalb des Hauses kommunizieren kann, haben wir uns für die Verwendung von MQTT als Protokoll entschieden. MQTT wurde 1999 von Andy Stanford-Clark (IBM) und Arlen Nipper (Cirrus Link) als ein M2M-Kommunikationsprotokoll mit minimalem Protokolloverhead entwickelt, um vernetzten Geräten eine Möglichkeit zu bieten, möglichst bandbreiten- und batterieschonend zu kommunizieren.

Das Protokoll schlägt mit seinem ereignisgesteuerten Ansatz einen anderen Weg ein als beispielsweise HTTP, welches auf Request/Response basiert. MQTT benutzt das Publish-Subscribe-Pattern. Das bedeutet, dass die Clients sich untereinander nicht kennen und einen zentralen Verteiler, einen sog. Broker, zur Kommunikation nutzen. Der Broker ist dafür zuständig, dass eine gesendete Nachricht alle interessierten Clients erreicht. Wenn ein Client sich zu einem Broker verbindet, teilt dieser dem Broker mit, für welche so genannten Topics er benachrichtigt werden möchte, also welche Topics er abonnieren möchte. Diesen Vorgang nennt man Subscribe. Wenn ein Client eine Nachricht sendet, muss dieser die Information mitsenden, an welches Topic diese Nachricht gesendet werden soll. Diesen Vorgang nennt man Publish. Durch diese Architektur ist es möglich, hochskalierbare Lösungen mit tausenden von Clients zu entwickeln, ohne dass Abhängigkeiten zwischen den teilnehmenden Clients entstehen. Abbildung 2 zeigt dies am Beispiel eines Temperatursensors, welcher Nachrichten versendet, und zwei Clients (Laptop und einem Mobilgeräte), welche diese Nachrichten abonnieren.

Der Unterschied zu HTTP ist, dass ein Client nicht erst durch einen Request anfragen muss, ob neue Informationen vorhanden sind, sondern dieser automatisch vom Broker benachrichtigt wird. Sollte ein Client nicht verbunden oder der Broker nicht erreichbar sein, implementiert das Protokoll selbst Mechanismen zum Persistieren der Nachrichten und automatischem Senden, sobald Broker oder Client wieder erreichbar sind.

Abb. 2: Publish Subscribe mit MQTT

Abb. 2: Publish Subscribe mit MQTT

Topics

Jeder Client kann frei wählen, zu welchem Topic er publishen oder subscriben möchte. Topics sind frei wählbare Strings und können mittels „/“ hierarchisch aufgebaut werden. Beispiele wären „home/temperature“ und „home/brightness“. Das Root-Topic wäre hier „home“, die untergeordneten Topics wären „temperature“ und „brightness“. Ein Client könnte entweder ein konkretes Kind-Topic abonnieren oder mittels einer Wildcard („#“) alle Kind-Topics eines Eltern-Topics abonnieren. Beispielsweise könnte er „home/#“ abonnieren, was zur Folge hätte, dass er alle Nachrichten für „home/temperature“ und „home/brightness“ zugestellt bekommen würde. Bei den Topic-Namen wird zwischen Groß- und Kleinschreibung unterschieden.

Warum MQTT?

Wir haben uns für MQTT aus mehreren Gründen entschieden. Einer davon ist, dass das Protokoll sehr leichtgewichtig ist und es ermöglicht, bandbreitenschonend Daten an mobile Geräte zu übertragen. Durch das Publish-Subscribe-Pattern von MQTT ist es ein Leichtes, diese Informationen an mehrere Datenkonsumenten zu verteilen, welche sich alle zu einem HiveMQ MQTT Broker verbinden. Außerdem werden die Nachrichten durch die offene TCP-Verbindung, die jeder MQTT-Client zum Broker hält, direkt per Push an alle abonnierenden Clients versendet. Da die Verbindung eines MQTT-Clients zum Broker vom Client ausgeht, gibt es auch keinerlei Probleme, wenn sich ein MQTT-Client hinter eine Firewall oder einem NAT befindet, wie es in den meisten Privathaushalten der Fall ist. Alles läuft reibungslos sowohl auf Seiten der Hauszentrale, wie auch bei den mobilen Anwendungen.

Ein anderer interessanter Aspekt sind die verschiedenen Servicequalitäten (QoS) von MQTT. Obwohl MQTT auf TCP basiert, kann es bei Mobilfunknetzen zu Übertragungsproblemen kommen, welche durch Protokollmechanismen ausgeglichen werden. Die Zusicherung der Übertragung kann für jede Nachricht individuell angegeben werden. Level 0 bietet keinerlei Garantie, dass die Nachricht ankommt, bei Verwendung von Level 1 wird sichergestellt, dass diese mindestens einmal ankommt und bei Level 2, dass die Nachricht genau einmal ankommt. Durch die Verwendung von Level 2 bei der Übertragung zwischen Hauszentrale und dem Broker in der Cloud, sowie zwischen dem Broker und der Android-App, ist sichergestellt, dass alle Nachrichten auch wirklich ankommen.

Abb. 3: Kommunikation zwischen Hauszentrale und mobiler Anwendung über MQTT

Abb. 3: Kommunikation zwischen Hauszentrale und mobiler Anwendung über MQTT

Die konkrete Kommunikation in unserem Anwendungsfall ist in Abbildung 3 dargestellt. Man sieht darin, wie Hauszentrale und App über das Versenden und Abonnieren von MQTT-Nachrichten miteinander kommunizieren. Dabei ist es ganz einfach möglich, andere Geräte oder Abnehmer für die bereits vorhandenen Topics hinzuzufügen oder neue Daten mit neuen Topics über den Broker zu versenden, um auch andere Systeme, wie beispielsweise eine Notrufzentrale anzubinden.

Konfiguration von openHAB

Nachdem wir die verschiedenen Komponenten und die Kommunikation zwischen dem Smart Home und seinen Bewohnern aufgezeigt haben, beschäftigen wir uns nun mit der Konfiguration der Hauszentrale.

Um die verschiedenen Technologien in einem Smart Home zusammenzubringen, bietet openHAB die Möglichkeit, Geräte im Haus mit so genannten Items zu abstrahieren. Items sind typisiert und repräsentieren einzelne Attribute oder Schalter von Geräten bzw. Objekten. Der Alarm und die Batteriewarnung unseres Rauchmelders können beispielsweise als Items vom Typ „Switch“ konfiguriert werden (Listing 2).

Listing 2: configurations/items/rauchmelder.items

#Type      Name                   "Label"           (Group)
Switch     SmokeDetector1_Alert   "Alarm"           (Schlafzimmer)
Switch     SmokeDetector1_LB      "Batterie"              (Schlafzimmer)

Unsere Items werden laut Konfiguration der Gruppe Schlafzimmer zugewiesen. Auch solche Gruppen werden als Item konfiguriert, allerdings vom Typ Group:

Group      Schlafzimmer      "Schlafzimmer"      <bedroom>

Das Binding der Items an unsere HomeMatic-Geräte wird ebenfalls in der Item-Konfigurationsdatei vorgenommen. Hier kommt zu jedem Item in geschweiften Klammern eine Binding-Konfiguration hinzu (Listing 3).

Listing 3: configurations/items/rauchmelder.items

#Type      Name                    "Label"   <Icon>      (Group)
Switch     SmokeDetector1_Alert    "Alarm"   <fire>      (Schlafzimmer)
  {HomeMatic="id=XXX012345, channel=1, parameter=STATE"}
Switch     SmokeDetector1_LB       "Batterie"            (Schlafzimmer)
  {HomeMatic="id=XXX012345, channel=0, parameter=LOWBAT"}

Die Kanäle und Parameternamen der Geräte sind in der HomeMatic-Script-Dokumentation beschrieben, die frei über den Hersteller im Internet verfügbar ist. Auch MQTT-Topics werden in openHAB als Item dargestellt. In der Binding-Konfiguration wird der Broker angegeben, dazu die MQTT-Parameter wie QoS-Level. Außerdem wird die Richtung der Kommunikation mittels „<“ oder „>“ angegeben, in diesem Fall „Subscribe“ also „<“ (Listing 4).

Listing 4

Switch      MQTT_Master_Test
    {mqtt="<[hivemq:haus1/master/technical/test:command:MAP(mqttToOnOf.map)]", autoupdate="false" }

Die Definition von autoupdate=“false“ sorgt hier dafür, dass das Item nicht wie ein Schalter, sondern wie ein Taster funktioniert. Nach Empfang des Kommandos wird das Item also nicht dauerhaft gesetzt, sondern „springt zurück“. Für die Transformation von openHAB-spezifischem Item-Status (ON/OFF) und dem tatsächlichen MQTT-Payload (1/0) sorgt hier außerdem eine Transformationsdefinition (Listing 5).

Listing 5: configurations/transform/mqttToOnOf.map

0=OFF
OFF=0
1=ON
ON=1

Durch die symmetrische Definition kann dieselbe Datei für beide Kommunikations-Richtungen verwendet werden. An diesem Punkt haben wir nun bereits drei Items fertig konfiguriert. Diese könnten nun bereits über die openHAB-Konsole angesteuert werden. Mit einer kleinen zusätzlichen Konfiguration kann dies aber auch komfortabler gestaltet werden: In openHAB können so genannte sitemaps festgelegt werden. Mithilfe dieser Konfiguration lassen sich Items in einer einfachen Weboberfläche direkt anzeigen und ansteuern (Listing 6).

Listing 6

sitemap rauchmelder label="Main Menu"
{
  Frame label="Sicherheitsstatus" {
    Switch item=SmokeDetector1_Alert
  }
}

Diese einfache Konfiguration ermöglicht das Anzeigen und sogar aktive Schalten des gebundenen Items. All denjenigen, die sich das Erfolgserlebnis gönnen möchten, diesen Schalter nun zu drücken, sei gesagt, dass Rauchmelder einen Schalldruckpegel von etwa 85 dB erreichen und das Ausschalten des Alarms auf den Geräten meist einige Sekunden dauert.

Abb. 4: openHAB Web UI

Abb. 4: openHAB Web UI

Mit so genannten rules können nun Ausführungsregeln definiert und das System somit in ein echtes Smart Home verwandelt werden. Die Regeln folgen einem einfachen „Wenn/Dann“-Schema. In unserem System können wir mit so einer Regel z. B. einen Testalarm implementieren, der über MQTT ausgelöst werden kann. Hierzu bietet sich der Channel „INSTALL_TEST“ unserer Rauchmelder an, der einen ohrenfreundlicheren Signalton erzeugt (Listing 7 und 8).

Listing 7: configurations/items/rauchmelder.items

#Type      Name                  "Label"      <Icon>    (Group)
Switch     SmokeDetector1_Test   "Test_Alarm"           (Schlafzimmer)
  {HomeMatic="id=XXX012345, channel=1, parameter=INSTALL_TEST"}

Listing 8: configurations/rules/rauchmelder.rules

rule "Initiate test of all smoke detectors"
  when
    Item MQTT_Master_Test received command
  then
    SmokeDetector1_Test.sendCommand(ON)
end

Der then-Teil kann auch mehrere Anweisungen enthalten und erlaubt komplexeren Skriptcode. Hierzu wird von openHAB eine eigene Skriptsprache zur Verfügung gestellt, die über das Framework Xtext eingebunden ist. Die Regelsprache von openHAB ist sehr mächtig und kann über Plug-ins erweitert werden.

Was ist openHAB und was ist der Unterschied zu Eclipse SmartHome?

Die Plattform openHAB wurde 2010 von Kai Kreuzer ins Leben gerufen und ist eine Integrationsplattform für Smart-Home-Systeme. Die Plattform bietet einen Systemkern und darauf aufbauend eine Vielzahl von Plug-ins für verschiedene Technologien und Protokolle im Smart-Home-Umfeld. Dadurch lassen sich herstellerübergreifende Lösungen bauen und Automatisierung im Haus umsetzen. Um die Verwendung in Projekten weiter zu vereinfachen, wurde der Systemkern von openHAB 2013 als Eclipse SmartHome an die Eclipse Foundation gespendet. Dieser Teil kann somit unter der EPL frei lizensiert und weiterentwickelt werden und wird in Zukunft beispielsweise von der Telekom in ihrem Produkt QIVICON eingesetzt. openHAB existiert als Projekt weiter und setzt ab der Version 2.0 auf Eclipse SmartHome auf.

 

Der openHAB EventBus

Abb. 5: Architektur von openHAB

Abb. 5: Architektur von openHAB

Technologiespezifische Bindings kommunizieren mit dem openHAB-Core über den Event-Bus (Abb. 5). Die Item Registry reagiert auf die Events und macht die aktualisierten Informationen an den gebundenen Items verfügbar. Dadurch können Automationslogik und User Interface auf den abstrakten Items aufsetzen, ohne die technischen Details der Hardware zu kennen.

Der Vollständigkeit halber möchten wir noch ein weiteres Konzept in openHAB erwähnen: Es ist möglich, den zeitlichen Verlauf von Item-Werten einfach mit verschiedensten Technologien, z. B. MySQL abzuspeichern. Für die Erweiterung der Plattform um verschiedene Persistence-Dienste wird, ähnlich wie bei Bindings, der OSGi-Plug-in-Mechanismus genutzt. Die Konfiguration erfolgt wieder in text-Dateien.

Die Android-App

Wie wir gesehen haben, bringt openHAB zur Steuerung und Anzeige von Werten bereits eine einfache Standardoberfläche mit. Über diese ist aber keine aktive Benachrichtigung im Alarmfall möglich. Für die Anzeige eines Alarms binden wir deshalb über den MQTT-Broker eine Android-App an (Abb. 6). Diese abonniert die Topics des Hauses und meldet Steuerbefehle, wie z. B. das Startsignal für einen Funktionstest. Für die Benachrichtigung des Benutzers verwenden wir die Notification-Funktionalitäten des Android-SDK. Weil unser Fokus nicht auf der Entwicklung einer Android-App liegt, belassen wir es bei einer Auflistung von Punkten, die aus unserer Sicht bei der Entwicklung Beachtung finden sollen:

  • Der Alarm im Notfall darf nicht von der Lautstärkeeinstellung des Systems abhängen. Dies kann erreicht werden, indem der Ton über den Alarmstream des SDK ausgegeben wird.
  • Die App muss im Hintergrund MQTT-Nachrichten verarbeiten können. Üblicherweise sparen moderne Mobiltelefone aber häufig Strom, indem sie die CPU abschalten. Dadurch erfordern Hintergrundtasks auf Android immer ein Abwägen zwischen Reaktionszeit und Stromverbrauch. Durch Kombination von regelmäßigem Aufwecken des Device und Wake-Locks kann hier eine gute Balance gefunden werden. Dies ist jedoch eine Herausforderung für sich.
  • Bedienbarkeit und Design werden bei professionellen Lösungen ausschlaggebend für den Erfolg einer App sein. Auch eine Statusanzeige für das Gesamtsystem kann sich auf das Vertrauen des Kunden in die Lösung sehr positiv auswirken.
Abb. 6: Oberfläche der Android-App

Abb. 6: Oberfläche der Android-App

Die Integration von weiteren Geräten

Baut ein Smart Home auf einer offenen Integrationsplattform auf, wird durch die einfache Kombination mit anderen Geräten plötzlich eine Fülle von Anwendungsfällen möglich, die für sich gesehen viel aufwändiger zu implementieren wären. Im Bedürfnisbereich Sicherheit können beispielsweise recht einfach durch die Integration mit vorhandenen, typischen Smart-Home-Geräten weitere Funktionen implementiert werden.

Die häufigsten Anwendungsfälle für ein Smart Home sind die Steuerung von Licht und die effiziente Regelung der Heizung. Für diese Anwendungsfälle sind beispielsweise häufig bereits Schaltaktoren für Lichter im Haus und Fenstergriffsensoren für die Heizungsabschaltung verbaut. Nutzt man diese Geräte gemeinsam mit den Rauchmeldern in einer Integrationsplattform wie openHAB, wird nur durch die Definition zusätzlicher Regeln ein neuer Sicherheitsanwendungsfall möglich:

  • Der Benutzer kann das Smart Home in den Modus „Einbruchsschutz“ schalten.
  • Öffnet sich in diesem Modus ein Fenster, dann wird der Eigentümer sofort benachrichtigt.
  • Danach werden die Rauchmeldersirenen aktiviert, und alle Lichter im Haus beginnen zu blinken. Ein Einbrecher wird dadurch abgeschreckt.
  • Bei Fehlalarm kann der Alarm sehr einfach z. B. über die App deaktiviert werden.

Fazit und Ausblick

Mit openHAB können alleine durch Konfiguration komplexe Integrationsszenarien unter Verwendung vieler verschiedener Technologien realisiert werden. Dadurch ist die Plattform als Basis für Smart-Home-Produkte ein ernstzunehmender Kandidat. In unserem konkreten Beispiel stößt der Raspberry Pi allerdings aufgrund seiner limitierten Ressourcen mit Homegear und openHAB an seine Leistungsgrenze. Dies wirkt sich negativ auf das Laufzeitverhalten und auch die Stabilität des Systems aus: Es kann dadurch zum Verlust von Nachrichten kommen, weil die CPU des Raspberry Pi überlastet ist – für sicherheitskritische Anwendungen ein „No-Go“.

Bei der Erstellung von Sicherheitslösungen kann zudem die Flexibilität und Offenheit einer Plattform den notwendigen Stabilitätsanforderungen entgegenstehen. Es ist beispielsweise aus momentaner Sicht undenkbar, für eine flexibel erweiterbare, in ein Smart-Home-System integrierte Brandschutzlösung auf Basis von openHAB eine VdS-Zertifizierung zu erhalten. Diese ist jedoch für heutige Rauchwarnsysteme Standard. Sehr wohl können Smart-Home-Lösungen aber über den Basisfunktionsumfang von marktüblichen Sicherheitslösungen hinaus nützliche Zusatzfunktionen bieten. Die Sicherheit von Leib und Leben muss dabei aber über zertifizierte Einzelkomponenten gewährleistet werden, die auch autark funktionieren und dadurch die nötige Robustheit mitbringen. Bei unserem Beispiel ist beispielsweise die Basisfunktion der Rauchmelder nicht von anderen Komponenten abhängig.

Der Smart-Home-Markt und auch die Open-Source-Communitys sind aktuell einem rasanten Wandel unterworfen. Auch bei openHAB steht mit dem Release von Version 2.0 ein weiterer großer Schritt nach vorne an: Unter anderem wird die Basis – Eclipse SmartHome – aktuell für Embedded-Systeme optimiert, und die Möglichkeiten der Konfiguration werden weiter verbessert. Beides sind wichtige Schritte hin zu einem selbst für die harten Anforderungen in Sicherheitsszenarien empfehlenswerten Produkt, und die ersten professionellen Lösungen werden sicher nicht lange auf sich warten lassen.

Aufmacherbild: illustration concept of smart house via Shutterstock / Urheberrecht: Bloomua

Geschrieben von
Christian Götz
Christian Götz
Christian Götz entwickelt bei der dc-square GmbH hoch skalierbare Lösungen für das Internet der Dinge, basierend auf MQTT und dem MQTT Broker HiveMQ.
Markus Mann
Markus Mann
Markus Mann ist Senior Consultant bei iic solutions GmbH. Gemeinsam mit Kunden aus der Versicherungswirtschaft arbeitet er an neuartigen Produkt- und Dienstleistungsangeboten auf Basis digitaler Technologien.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: