Technische Umsetzung

Es gibt viele verschiedene Möglichkeiten, um Smart Home Anwendungen technisch umzusetzen. Bisher existiert noch keine Technologie, die sich allgemein durchgesetzt hat. Stattdessen konkurrieren verschiedene Systeme, wie Z-Wave, ZigBee, Enocean oder KNX, miteinander. Diese Systeme sind meist aber nicht zueinander kompatibel zueinander. Manche sehen dies als Problem und fordern: „Die Vernetzbarkeit von Geräten unterschiedlicher Hersteller muss weiter vereinfacht werden“ (Projektgruppe Smart Home 2015: 10). In diesem Kapitel werde ich verschiedene technische Umsetzungen vorstellen. Besonders konzentriere ich mich aber dabei auf eine mögliche technische Umsetzung, die Z-Wave Technologie. Sofern nicht anders beschrieben, folgt das Kapitel im Wesentlichen den Ausführungen von Christian Pätz (2011).

Eine Option für die technische Umsetzung in einem Smart Home ist eine Technologie, die kodierte Signale durch die Stromleitung des Hauses schickt. Sie heißt „Powerline Carrier Systems (PCS)“. Die Signale werden zu jeder Steckdose und jedem programmierbaren Schalter geschickt. Sie enthält die Adresse des Gerätes und den Befehl (z. B. „Switch off“).

Es gibt unterschiedliche Protokolle für PCS. X10 ist die erste von denen. X10 ist in 1975 bei einer schottischen Firma entwickelt. Mit X10 können die kompatiblen Geräte miteinander kommunizieren. Eine X10-Nachricht enthält folgende Informationen:

• Ein Warnsignal für das System,
• Die Nummer des Gerätes, das die Nachricht nehmen sollte
• Ein Code für die eigentliche Nachricht

X10 ist sehr schnell, aber es gibt Beschränkungen. Die Stromleitung ist nicht zuverlässig, um zu kommunizieren. Es kann Störungen durch die anderen Geräte geben. Die Geräte können die Nachrichten daher falsch oder gar nicht empfangen.

Es gibt andere Protokolle, die nicht die Stromleitung, sondern Radiosignale benutzen (für eine Übersicht siehe Lobaccaro et al. 2016: 9-12). Zwei Beispiele dafür sind ZigBee und Z-Wave. ZigBee und Z-Wave sind beide mesh-Netzwerke. Das bedeutet, dass die Nachrichten mehr als einen Weg benutzen können.

In ZigBee sucht die Nachricht den kurzen Weg, wie in Z-Wave. Allerdings ist ZigBee lediglich geeignet für die Standards vom IEEE (Institute for Electrical and Electronics Engineers) für private kabellose Netzwerke. ZigBee standardisiert nur Funkschichten. Deswegen entwickeln die unterschiedlichen Anwender ihre eigenen Funktionen. ZigBee-Geräte von unterschiedlichen Unternehmen können daher häufig nicht miteinander kompatibel sein. Z-Wave benutzt einen Algorithmus, um den kürzesten Weg zum Gerät zu berechnen. Er heißt „Source Routing Algorithm“. Die Z-Wave Geräte haben einen Embedded-Code. Wenn ein Gerät zum System angeschlossen wird, erkennt der Kontroller den Code und findet seinen Platz. Es gibt eine Hierarchie zwischen den Geräten. Manche Kontroller können die Nachrichten auslösen, manche können sie nur tragen und antworten (Rosslin und Kim 2010a: 39-40).

Man kann die Gesamtfunktionalität von Z-Wave in drei Schichten aufteilen.

1. Funkschicht: In diesem Bereich wird der Austausch von Signalen zwischen Funkknoten definiert. Das ist der Hardware-Bereich.

   • Wir müssen Abschätzungen zur Funkausbreitung machen. Dabei muss man berücksichtigen, dass Baumaterialien Funksignale unterschiedlich stark dämpfen. Mit diesen Schätzungen treffen wir Entscheidungen, wo die Funkkomponenten aufgestellt werden sollen.
   • Wir müssen dabei Störquellen berücksichtigen. Funkempfänger sollten mehr als 50 cm Abstand von den Störquellen (z. B. Computer, Mikrowellengeräte, Audio- und Videoanlagen) haben.
   • Metallische Möbel oder Gebäudeteile können die elektromagnetischen Wellen beschirmen. Dies nennt man Funkschatten. In dem Funkschatten ist kein Direktempfang möglich (Pätz 2011: 18-31).

2. Netzwerkschicht: Der Datenaustausch von zwei Kommunikationspartnern wird in diesem Bereich definiert. Die Netzwerkebene hat drei Glieder. In der Ebene „Media Access Layer“ wird die Nutzung des Funkkanals kontrolliert. In der Ebene „Transport Layer“ wird kontrolliert, ob der Austausch von einem Datenpaket zwischen zwei Funkknoten korrekt und fehlerfrei ist. In der Ebene „Routing Layer“ wird kontrolliert, ob die Kommandos zwischen den richtigen Kommunikationspartnern ausgetauscht werden. Wenn der Empfänger eine Nachricht kriegt, schickt er dem Sender eine Bestätigung (ACK). Es gibt verschiedenen Knoten, die miteinander kommunizieren. Jeder Knoten eine Home-ID (gemeinsamer Kennzeichner aller Knoten in einem Netz) und eine Node-ID. Die Knoten, die unterschiedliche Home-IDs haben, können nicht miteinander kommunizieren. Jedes Z-Wave- Gerät ist entweder „Controller“ oder „Slave“. Slaves steuern nicht die anderen Geräte. Es gibt zwei verschiedene Typen von Slaves: Slaves und Routing Slaves. Es kann einen oder mehrere Kontroller geben. Kontroller kennen alle Wege zu allen anderen Geräten im Netzwerk und können alle Nachrichten schicken. Slaves können nur einer Nachricht antworten, aber sellber keine Nachricht schicken. Routing Slaves kennen die Wege zu ihrem eigenen Kontroller und bestimmte Slaves und können nur diesen Nachrichten schicken (Pätz 2011: 32-73).

3. Anwenderebene: In diesem Bereich werden die Szenarien der Anwendungen definiert. Man kann viele verschiedene Geräte als Z-Wave-Geräte benutzen (z. B. elektrische Schalter, Motor, verschiedenen Sensoren, Fernbedienung etc.). Die Geräte müssen mit einem Z-Wave- Funkchip ausgerüstet werden. Die Kommunikation mit Geräten ist über Kommandoklassen organisiert. Für jeden Gerätetyp gibt es eine Kommandoklasse. In dieser Kommandoklasse sind die Funktionen des Gerätes enthalten. Außerdem gibt es eine Basic-Kommandoklasse, um mit den Geräten zu kommunizieren. Zusätzlich gibt es Geräteklassen: Basis, Generische und Spezielle Geräteklassen. Dies ermöglicht es, mit Geräten von unterschiedlichen Herstellern zu arbeiten. Die Basis Geräteklasse zeigt uns, ob das Gerät Controller, Slave oder Routing-Slave ist. Die Generische Geräteklasse zeigt uns die Grundfunktion des Gerätes (z. B. Allgemeiner Controller, Statischer Controller oder Eingangscontroller). Spezielle Geräteklasse kann man definieren, wenn das Gerät eine spezielle Funktion hat. Beispielsweise ist Rücksetzthermostat (SETBACK_THERMOSTAT) eine spezielle Geräteklasse der generischen Klasse „THERMOSTAT“.

Über die Geräte- und Kommandoklassen lässt sich sagen, ob ein Gerät dem Z-Wave Standard entspricht. Es muss „mindestens einer Basis- und einer generischen Geräteklasse zugeordnet werden […], diese korrekt auf Anfrage [angeben] und deren Pflichtfunktionen – sprich Pflichtkommandoklassen - korrekt [implementieren]“ (Pätz 2011: 81). Zusätzlich müssen spezielle Funktion in speziellen Kommandoklassen angegeben werden (Pätz 2011: 74-83).

Ein anderes, sehr interessantes Protokoll ist EnOcean. Die Sensoren und Aktoren in einem EnOcean- System verbrauchen sehr wenig Strom und benutzen „energy harvesting“ Methoden, so dass sie ohne Batterie funktionieren können. Allerdings sind die Kosten für ein EnOcean-System relativ hoch, deswegen ist EnOcean nicht so weit verbreitet.

MQTT (Message Queuing Telemetry Transport) ist ein anderes Beispiel. MQTT wurde im Jahre 1999 entwickelt. MQTT benutzt die Bandbreite effizient und verbraucht sehr wenig Batterie. Damit ist es gut geeignet für Geräte mit wenig Verbindungstärke, beziehungsweise schwachen Netzwerken. MQTT benutzt eine „publish/ subscribe“ Architektur statt einer „request/ response“ Architektur. In dieser Architektur gibt es „publishers“ (Sender) und „subscribers“ (Empfänger). „Publishers“ schicken die Nachrichten unter bestimmten Klassennamen. Sie wissen nicht, wer die Nachrichten annimmt. „Subscribers“ definieren welche Klassen von Nachrichten sie empfangen wollen. Sie wissen nicht, wer die Nachrichten verschickt. Die folgende Grafik von IBM zeigt eine einfache „publish/ subscribe“ Konfiguration (IBM 2017):

Eine MQTT Session hat vier Stufen: Verbindung, Authentifizierung, Kommunikation und Beendigung. Der Client verbindet sich über eine TCP/IP Verbindung mit dem „broker“. Der Client authentifiziert sich entweder mit SSL/TLS oder Klartext Benutzername und Password. Manchmal werden auch anonyme Clients ohne Benutzername- und Passwortangabe zugelassen.

Die Nachrichten sind sehr kurz. Sie enthalten einen 2-Bytes-Header, einen optionalen Header, die eigentliche Nachricht (maximal 256 MB) und eine Quality of Service (QoS) Eingabe. Der QoS Level zeigt an wie die Nachricht behandelt werden soll. Wenn ein Client (publisher oder subscriber) die Verbindung beenden möchte, schickt er eine „DISCONNECT“ Nachricht zum Broker.

Wie oben beschrieben, ist die Authentifizierung in MQTT in manchen Systemen recht einfach. MQTT ist ursprünglich nicht für unsichere Umgebungen entworfen worden. Wenn SSL/TLS nicht benutzt wird, kann dies zu Sicherheitsproblemen führen. Wenn es benutzt wird, ist die Nachricht grösser. Ein anderes Problem ist, dass man leicht schädliche Nachrichten in das Netzwerk schicken kann. Der Grund ist, dass „Subscribers“ nicht wissen, wer die Nachricht schickt (Rouse 2015).