Hochschule für Technik und Wirtschaft Dresden

Fakultät Informatik/Mathematik

Studiengang Angewandte Informationstechnologien

Projektdokumentation

Forschungseminar Sensornetze– Gruppe HomeMatic –

Autoren: Marcus Kupke, Markus Fischereingereicht am: 1. März 2013Projektleiter: Prof. Dr.-Ing. Jörg Vogt

Inhaltsverzeichnis

1 Einleitung 1

2 Problematik 1

3 Praktisches Vorgehen 23.1 Recherchearbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.2 Erstes Mitschneiden von BidCoS-Nachrichten . . . . . . . . . . . . . . . . . 33.3 Aufbau auf bestehender Wissensbasis - Das Projekt FHEM . . . . . . . . . 43.4 Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.5 Vom Prototyp zum HM-Modul . . . . . . . . . . . . . . . . . . . . . . . . . 63.6 Das Gateway als Verbindungsstück von COAP und HomeMatic/FS20 . . . 73.7 Anbindung des FS20-Funkschaltsystems an das Gateway . . . . . . . . . . 73.8 Erweiterung des HM-Moduls für Kommunikation mit dem Gateway . . . . 83.9 Refactoring und Optimierung des HM-Moduls . . . . . . . . . . . . . . . . . 8

4 Zusammenfassung 94.1 Erkenntnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

i

Abkürzungsverzeichnis

AES . . . . . . . Advanced Encryption Standard

BidCoS . . . Bidirectional Communication Standard

CUL . . . . . . . CC1101 USB Lite

FHEM . . . . Freundliche Hausautomation und Energie Messung

RTT . . . . . . . Round Trip Time

TPDM . . . . Third-Party Device Management

XML-RPC Extensible Markup Language Remote ProcedureCall

ii

Abbildungsverzeichnis1 Schematischer Pairingvorgang . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Tabellenverzeichnis2 Aufstellung der für dieses Projekt relevanten FHEM-Skripte . . . . . . . . . 5

iii

1 Einleitung

1 Einleitung

Innerhalb des Forschungsseminars Sensornetze soll die Möglichkeit geschaffen werden,andere Hausautomatisierungs-Systeme zu integrieren. Insbesondere die sehr populärenSysteme FS20 und HomeMatic vom Hersteller eQ-3. Dadurch kann schnell das eigeneSystem mit vielen Komponenten erweitert werden und der langwierige Entwicklungsprozesseingespart werden. Außerdem können ggf. die Vorteile der anderen Systeme verwendetwerden.

Die Steuerung der Komponenten und damit speziell die Logik, wird vom Heimautomatisie-rungsserver übernommen. Dieser sowie das restliche Sensornetz sollen ausschließlich mitOpen Source-Standards realisiert werden. Um die Verbindung der Fremdkomponenten mitunserem Sensornetz zu gewährleisten, kommt ein Gateway zum Einsatz. Dieses ist in derLage, die COAP-Befehle in entsprechende für FS20/HomeMatic umzusetzen.

Die meisten Probleme bei einer Integration treten durch die Geschlossenheit der anderenSysteme auf. Das betrifft neben dem verwendeten Kommunikations-Protokoll auch dieForm der Datenübertragung. Es wird daher nötig, verschiedene Untersuchungen durch-zuführen sowie sich nach ähnlichen Projekten umzusehen, welche sich u.U. als wichtigeInformationsquellen herausstellen können.

Aus diesem Grund kann ein entsprechendes System immer nur schrittweise erweitert werdenund wahrscheinlich nie die vollständige Funktionalität des nativen Systems replizieren.

2 Problematik

Ausgehend von der zu Anfang erläuterten Aufgabenstellung lassen sich Fragen ableiten,die im Rahmen des Forschungsseminars untersucht wurden. Von besonderem Interesse sinddabei die nachfolgenden Fragestellungen:

1. Lässt sich das proprietäre HomeMatic-Hausautomationssystem in eine auf freienStandards basierende Softwarelösung integrieren?

2. Wie hoch ist der Aufwand einer Integration einzuschätzen?

3. Welche Vorgehensweise bezüglich der Aufgabenstellung ist sinnvoll?

4. Was zeichnet HomeMatic oder auch FS20 aus und warum ist deren Einsatz imRahmen des Forschungsseminars „Sensornetze“ interessant?

5. Welche Schwachstellen offenbaren sich bei Arbeit mit HomeMatic? / Was sprichtgegen den Einsatz von HomeMatic?

Integration in eine freie Software

Es muss geklärt werden, welche Bestandteile von HomeMatic nicht öffentlich sind. Auchist von Interesse, über welche Schnittstellen das System zugänglich ist. Gibt es eventuelloffengelegte Kommunikationsmöglichkeiten?

1

3 Praktisches Vorgehen

Aufwand einer Integration

Abhängig von der vorhergehenden Fragestellung ist der Arbeitsaufwand von Interesse.Wenn das HomeMatic-System mit einer Blackbox gleichgesetzt werden kann, resultiert diesbeispielsweise in großen analytischen Aufwand. Kann in diesem Fall auf eine existierendeWissensbasis zurückgegriffen werden?

sinnvolle Vorgehensweise

Unter Berücksichtigung der Aufgabenstellung wurde die Vorgehensweise nach folgendemSchema festgelegt:

1. Recherche zum Thema HomeMatic2. Analyse des HomeMatic-Protokolls, insofern dies möglich ist → Gegebenenfalls Suche

nach alternativen Informationsquellen3. Implementation eines Programms (Python-Skript) zur Ansteuerung der verfügbaren

IHM-Hardware4. Tests und Optimierungsarbeiten an der Python-Implementation

Die Python-Implementation wird im Weiteren als HomeMatic-Modul (kurz: HM-Modul)bezeichnet.

Argumente für den Einsatz im Forschungsseminar

Es existieren unzählige Hausautomationssysteme. Welche Aspekte sprechen für die Verwen-dung von HomeMatic/FS20 in diesem Projekt? Gibt es eventuell Alleinstellungsmerkmale?

Schwachstellen

Kein Hausautomationssystem genügt allen gestellten Anforderungen. Worin bestehen dieNachteile von HomeMatic?

3 Praktisches Vorgehen

3.1 Recherchearbeiten

Wenn man sich zum Thema Hausautomatisierung belesen möchte, kommt an HomeMaticund FS20 nicht vorbei. Beiden Systemen ist gemein, dass sie in der privaten Hausauto-matisierung weit verbreitet sind und eine Vielzahl an Komponenten anbieten. Außerdemüberzeugt die Langlebigkeit der Systeme (FS20 seit 2002), die großen Fangemeinden unddie Online-Portale, welche Anleitungen und Hilfestellung bieten. In puncto Sicherheit undZuverlässigkeit gibt es jedoch größere Differenzen. HomeMatic zeichnet sich dabei vorallem durch die Quittierung von Nachrichten und die bei einigen Komponenten vorhandeneAES-Authentifizierung aus. FS20 bietet dahingehend keine Optionen und ist folglich we-sentlich anfälliger gegenüber angriffen. Die im Zusammenhang mit HomeMatic beworbene

2

3 Praktisches Vorgehen

Verschlüsselung stellt sich bei genauerer Betrachtung als wenig sicher heraus. Trotzdem istdie AES-Authentifizierung ein Schritt in die richtige Richtung und ein Alleinstellungsmerk-mal von HomeMatic. Ein weiterer Nachteil der beiden System ist die Beschränktheit aufherstellereigene Produkte. Nur mit zusätzlicher Fremdhard- und Software können solcheMischbetriebe verwaltet werden.

Möchte man nun genauere Information über spezielle Systeme in Erfahrung bringen, siehtes sehr düster aus.Viele Hersteller sind sehr darauf bedacht, ihre Systeme und derentechnischen Aufbau sowie die Implementationsumsetzungen geheim zu halten. Zum Teilwird dieser Umstand mit Fragen der Sicherheit begründet.

Um dennoch an geeignete Daten zu gelangen, wurden innerhalb dieses Projektes verschiede-ne Informationsquellen genutzt. Darunter befanden sich u.a. die Dokumentationen ähnlicherProjekte sowie die gesammelten Erkenntnisse einiger Enthusiasten in verschiedenen Forenund HM-Portalen.

Nach einiger Recherchearbeit stößt man schließlich auf den Aufbau des HomeMatic-Paket-Headers. Der wichtige Payload der Pakete bleibt aber weitestgehend unbekannt undmuss nach und nach durch die Untersuchung der von den Komponenten übertragenenNachrichten analysiert werden. Hierbei erwies sich die FHEM-Software als guter Einstieg,um ein grundlegendes Verständnis des typischen Nachrichtenaufbaus zu erlangen.

Weitere Nachforschungen ergaben, dass es momentan keine Möglichkeit gibt, die von Ho-meMatic verwendete AES-Authentifizierung nachzubilden. Lediglich durch die Verwendungeines HM-Adapters können einige Funktionen der Authentifizierung unterstützt werden.Da aber die meisten Komponenten die Möglichkeit der Authentifizierung gar nicht anbietenund diese optional ist, wurde in dieser Arbeit der Funktion eine niedrigere Priorität zugewiesen.

3.2 Erstes Mitschneiden von BidCoS-Nachrichten

Das HM-Protokoll stellt sich als Blackbox dar, dessen Aufbau unbekannt ist und eineAnalyse des Protokolls im Speziellen des Payloads erforderlich macht. Eine Variantewäre recht rudimentär mit einem RF-Transceiver gegeben. Mit dem Transceiver könnenFunksignale erfasst und die daraus resultierenden Signal-Dumps auswertet werden. Einhoher analytischer Aufwand spricht gegen diese Methode. Wesentlich leichter geht dasMitschneiden mithilfe des CUL-Dongles und der Firmware culfw vonstatten.

Als Hardware standen ein Aktor (HM-), ein Sensor (HM-) und der CUL selbst zur Verfügung.Der CUL wird dabei mit der Open Source Firmware culfw betrieben. Die nachfolgendenSchritte zeigen dabei exemplarisch das Aufspielen der Firmware auf den CUL:

• Herunterladen und Entpacken der Firmware culfw

• Anstecken des CULs an den PC

• unter Linux: Installation des Paketes dfu-programmer

• im Terminal: in das Verzeichnis culfw/Devices/CUL wechseln und den Befehl makeusbprogram ausführen

• ggf. testen des CUL

3

3 Praktisches Vorgehen

Wurde die Firmware erfolgreich auf den CUL geladen, so kann dieser meist unter derGerätedatei /dev/ttyACM0 angesprochen werden. Im nächsten Schritt muss der CUL inden HomeMatic-Modus versetzt werden. Dafür schreibt man einfach die Zeichenkette „Ar“nach /dev/ttyACM0. Für das Schreiben der Zeichenkette kann z.B. GNU Screen verwen-det werden. Möchte man statt HomeMatic-Pakete mitzulesen lieber BidCoS-Nachrichtenversenden, schreibt man analog die Zeichenkette „As“ in die Gerätedatei, gefolgt vomeigentlichen HM-Paket als Folge von Hexwerten.

Das Ver- und Entschlüsseln der BidCoS-Nachrichten übernimmt die Firmware, sodass hierkein weiterer Aufwand entsteht. Empfangene Nachrichten liegen dem folgend als Klartext,genauer gesagt einem Hex-String vor.

Für das kontinuierliche Mitlesen von BidCoS-Nachrichten können verschiedene Tools ver-wenden werden. Diese unterscheiden sich im Großteil nur in der unterschiedlich formatiertenAusgabe des Protokolls. Einer der bekanntesten Sniffer ist mit Wireshark gegeben. NachInstallation des Paketes „usbmon“ kann das USB-Interface /dev/ttyACM0 ausgewähltund mitgeschnitten werden. Leider gibt Wireshark das komplette USB-Protokoll mit aus.Ein besseres Werkzeug ist mit dem asksin-dumper verfügbar. Als Bestandteil der culfw-Firmware sei zu diesem Perl-Skript geraten. Neben der sinnvollen Ausgabe können imGegensatz zu Wireshark Befehle direkt in den CUL geschrieben werden. Gleiches ist mitGNU Screen ebenfalls möglich, jedoch ist die Ausgabe eines Paketes unformatiert.

Die Firmware culfw unterstützt mehrere RF-Protokolle. Zur Unterscheidung der Protokolleist jedem ein unterschiedliches Präfix zugeordnet. Für BidCoS beispielsweise lautet dies„A“. Dem Präfix folgt eine Funktion (lesen, senden, . . .) oder eine Folge von Hexwerten(eigentliches Paket).

3.3 Aufbau auf bestehender Wissensbasis - Das Projekt FHEM

Der Hersteller eQ-3 möchte bewusst eine Offenlegung des BidCoS-Protokolls vermeiden. EinRecht, das klar dem Hersteller obliegt, aber die Untersuchung des Protokolls erschwert. DieAnalyse der Nachrichten ist dem folgend sehr aufwendig. Dies gilt vor allem in Bezug aufden Payload. Da der dafür notwendige Zeitrahmen nicht gegeben war und die Integrationvon HomeMatic innerhalb des Projektes sekundär ist, wurde entschieden an dieser Stelleauf einer existierenden Wissensbasis anzuknüpfen - dem Open Source Projekt FHEM.

Die “Freundliche Hausautomation und Energie-Messung” (FHEM) ist ein Perl-basiertesServerprogramm für die Hausautomation. Wie der Name andeutet, dient die Software zurautomatisierten Bedienung von Aktoren sowie der Aufzeichnung von Sensorinformationen(z.B. Raumtemperatur). Der Umfang an Forumeinträgen der erst kürzlich geschlossenenFHEM Google Gruppe macht den Aufwand deutlich, der zur Untersuchung des proprietärenBidCoS betrieben wird.

Nach dem Herunterladen des FHEM-Quellcodes erfolgte eine kurze Einarbeitungszeit, umdie für uns relevanten Quelldateien zu finden. Eine Auflistung der obligatorischen Dateienkann Tabelle 2 entnommen werden. Bei der Analyse des Quellcodes wird schnell klar, dassnoch längst nicht alle Protokollspezifikationen ermittelt wurden.

4

3 Praktisches Vorgehen

Tabelle 2: Aufstellung der für dieses Projekt relevanten FHEM-Skripte

Dateiname Dateipfad Beschreibung10_CUL_HM.pm /fhem-5.X/FHEM/ Wichtigste Informationsquelle. Enthält alle

Routinen für HomeMatic sowieGeräteklassen, -attribute und Informationzum Paketaufbau.

00_CUL.pm /fhem-5.X/FHEM/ Das CUL-Modul stellt Funktionen (z. B.Senden/Empfangen) für den Zugriff aufden CUL bereit.

DevIo.pm /fhem-5.X/FHEM/ Wird u.a. vom CUL-Modul (Wrapper)verwendet und enthält die eigentlichenRoutinen (open,close,read, write) für denGerätezugriff.

fhem.pl /fhem-5.X/ Hauptskript der FHEM-Software. Ladenaller benötigten Module und Initialisierung.

Wie in Abschnitt 3.1 Abs. 3 erwähnt, wurde FHEM verwendet, um ein besseres Verständnisder HM-Nachrichtenabläufe zu erlangen. Die Software wurde mit der zur Verfügunggestellten HM-Hardware getestet und die Logdateien konsultiert. Die insgesamt darausresultierenden Erkenntnisse flossen anschließend bei der Implementierung eines Prototypenmit ein.

3.4 Prototyp

Der Prototyp ist eine rudimentäre Implementation des HM-Moduls, bei dem die folgendenFunktionalitäten umgesetzt worden:

• Senden und Empfangen von Nachrichten• Pairing mit einem HM-Device• eine einfache Geräteverwaltung

Der CUL kann als serielles Gerät angesprochen werden. Python stellt hierfür die Bibliothekserial zur Verfügung. Die darin bereitgestellten Methoden und auch die Anwendung dieser,sind der Dateiarbeit ähnlich. Unter Angabe der Gerätedatei /dev/ttyACM0, der Baudrate(9600) oder auch weiteren Parametern (z.B. Timeout) kann mit der Methode open() eineserielle Verbindung zum CUL eröffnet werden. Analog der Datenarbeit existieren dieFunktionen read(), readline(), write() und close() für die Zugriffe auf den CUL. Wennanfangs ein Timeout für Leseoperationen gesetzt wurde, kann zwischen blockierendenund nicht-blockierenden Lesen unterschieden werden. Bei dem blockierenden Modus kehrtdie Methode read() erst zurück, wenn Daten gelesen worden. Dieses Verhalten ist nichterwünscht, weil zum Beispiel ausstehende Sendevorgänge nicht ausgeführt werden können.Die Möglichkeit die (blockierende) Leseoperation in einen Thread auszulagern ist dabeizwar denkbar, aber das grundsätzliche Problem des „Verhungerns“ von Schreiboperationoder auch des „Vergessens“ von eingehenden Nachrichten bleibt bestehen. Es wurde einTimeout von 100 ms gesetzt.

5

3 Praktisches Vorgehen

Das Pairing (Abbildung 1) zweier HM-Endgeräte erfordert das Senden und Empfangen vonBidCoS-Nachrichten als auch dem Auswerten von Paketen. Die Methoden read(), write()und parse() stellen diese Funktionalitäten zur Verfügung. Nach Aufruf der Funktion read()steht die empfangene Nachricht bereit und wird der parse-Funktion übergeben. Handelt essich um eine Pairing-Anfrage, so wird die Methode pair() gerufen und die dafür notwendigenBefehle generiert. Da eine bestimmte Sequenz von Befehlen erforderlich ist, werden dieseeiner Warteschlange für Sendeoperationen hinzugefügt und nach Erhalt der entsprechendenACKs kontinuierlich versandt. Eine solche Queue gibt es für jedes anzulernende HM-Device. Die Queue und weitere Informationen (z.B. individueller Nachrichtenzähler) sindBestandteile der Geräteverwaltung.

Device A Device B

Config Start

Ack

Config Write

Ack

Pairing-Mode

Device Info

.

.

.Config End

Ack

Abbildung 1: Schematischer Pairingvorgang

3.5 Vom Prototyp zum HM-Modul

Nachdem die ersten Tests mit dem Prototyp positiv verliefen, war der nächste Schritt dieEntwicklung eines eigenständigen HomeMatic-Moduls. Auf Basis der bisher gesammeltenErkenntnisse konnte das Modul entworfen und implementiert werden. Dabei wurden dieprimitiven Funktionen zum Senden und Empfangen von Nachrichten in das sogenannteCUL-Modul ausgelagert. In einer Hauptschleife wird zunächst das CUL-Modul aufgerufenund nach neuen Nachrichten gefragt. Wurde eine Nachricht empfangen, so wird diese imAnschluss von der Parse-Funktion untersucht. Die Nachricht wird dabei in ihre wesentli-chen Bestandteile zerlegt und je nach Typ weiterverarbeitet. Im Falle einer Device InfoMessage werden beispielsweise verschiedene Nachrichten generiert und in einen Nachrichten-Ausgabezwischenspeicher abgelegt. Wenn der Lesevorgang abgeschlossen ist, wird in derHauptschleife die Funktion Process aufgerufen. Dort werden alle zwischengespeichertenNachrichten für die Ausgabe an das CUL-Modul weitergeleitet und versendet. Die Kompo-nentenverwaltung erfolgt momentan über ein Dictionary, in dem alle Komponenten sowie

6

3 Praktisches Vorgehen

deren Parameter abgelegt wurden. Beim Starten des Programmes werden alle bekanntenKomponenten aus einer Datei geladen.

3.6 Das Gateway als Verbindungsstück von COAP und HomeMatic/FS20

Das Gateway übersetzt die von einer externen Instanz kommenden COAP-Nachrichten,so dass HomeMatic- oder FS20-Geräte angesprochen/gesteuert werden können. Sendetein HM/FS20 Gerät (z.B. ein Raumthermostat) eine Nachricht (mit Temperaturwert) ausund ist diese von Relevanz, so muss das Gateway darauf reagieren und die entsprechendeCOAP-Nachricht generieren und verschicken.

Das Grundgerüst des Gateways wurde von der Gruppe “Heimautomatisierungsserver”bereitgestellt und ist in der Lage auf die COAP-Methoden GET, POST und DISCOVER zureagieren. Jeder Sensor und Aktor wird als eine Ressource angesehen und muss entsprechendausprogrammiert werden. Das Grundgerüst stellt hierfür stellvertretend eine PUT- und eineGET-Ressource bereit, wobei eine PUT-Ressource auch auf GET-Anfragen reagieren kann.Ein Beispiel für Letzteres ist ein HM-Funk-Zwischenstecker. Dieser kann geschalten (PUT)werden und seinen Zustand (GET) mitteilen. Einen Sonderfall stellt der FS20-Schaltaktordar, da dieser nur empfangen kann, d.h. es muss nur auf die PUT-Methode reagiertwerden und ggf. bei einer GET-Anfrage ein Fehler ausgegeben werden. Der verfügbareHM-Funksender stellt sich als GET-Ressource dar.

Für das Versenden der COAP-Nachrichten ist das Firefox-Plugin Cooper verwendet worden.Über den Button Discover werden die Ressourcen der angegeben URL abgefragt. Innerhalbdes Gateways werden diese Anfragen von der Klasse DiscoverRessource behandelt.

3.7 Anbindung des FS20-Funkschaltsystems an das Gateway

Das Ziel des Forschungsseminars “Sensornetze” im Wintersemester 2012/13 ist es, einenersten funktionstüchtigen Prototypen im Rahmen der Aufgabenstellung (“freie” Haus-automatisierung) zu schaffen. Dies bedingt ebenfalls die Integration der zur Verfügunggestellten FS20-Komponenten, d. h. die Anbindung von FS20 an das Gateway. Von Relevanzhierbei soll vorerst nur die FS20-Funksteckdose sein, da diese geschaltet werden kann. DerFS20-Handsender und der Schließkontakt können nur senden, sodass es eine Instanz gebenmüsste, die den letzten Status eines FS20-Senders zwischenspeichert.

In Analogie zur HomeMatic-Funksteckdose wird innerhalb des Gateways für die FS20-Funksteckdose eine PUT-Ressource implementiert. Diese Ressource ist als FS20ActorRessourcebenannt. Die FS20ActorRessource nimmt im Falle einer PUT-Anfrage die Parameter “on”,“off” und “toggle” entgegen und löst die entsprechende Aktion aus. Ein unbekannter Pa-rameter wird mit der Meldung “wrong parameter” zurückgewiesen. Da ein FS20-Aktornur empfangen kann, ist sein Zustand unbekannt1. Folglich muss eine GET-Anfrage fürdie FS20-Funksteckdose nicht in einem extra Zweig behandelt werden, sondern kann wieweitere nicht von der Ressource unterstützte COAP-Methoden mit der Meldung “Methodnot allowed” verworfen werden.

1Ein FS20-Aktor kann nicht senden. Dementsprechend kann kein Status abgefragt werden oder Nachrichtenvom Aktor kommend mitgelesen werden.

7

3 Praktisches Vorgehen

Ein Problem, das mit der Anbindung von FS20 auftritt, ist die Zuordnung des CUL. Bisherwar nur HomeMatic an das Gateway angebunden und diesem der CUL unter /dev/ttyACM0zugeordnet. Da aufgrund unterschiedlicher Modulation und Datenraten ein dualer Betriebmit nur einem CUL nicht möglich ist, muss man mindestens 2 CULs verwenden sowie einestatische oder dynamische Zuordnung (“Hausautomatiesierungssystem X nutzt den CULunter /dev/ttyACMx”) treffen. Die statische Zuordnung wurde wie folgt vorgenommen:

• /dev/ttyACM0 : FS20

• /dev/ttyACM1 : HomeMatic.

Eine dynamische Zuordnung des CUL muss noch implementiert werden. Wenn nur einCUL mit dem Server verbunden ist, kann folglich momentan nur FS20 verwendet werden.

3.8 Erweiterung des HM-Moduls für Kommunikation mit dem Gateway

Da das HM-Modul eine Vielzahl von Aufgaben übernehmen muss, um die Kommunikationund die Verwaltung der Komponenten zu gewährleisten, ist eine Integration in das Gatewaynicht möglich. Aus diesem Grund besitzt das HM-Modul einen separaten Thread, über denes Nachrichten mit dem Gateway austauschen kann. Stellt das Gateway eine Anfrage, sowird diese vom Socket im Thread entgegen genommen und auf Korrektheit geprüft. Fürden Fall, dass die Anfrage ein unbekanntes Gerät adressiert oder einen unbekannten Befehlenthält, antwortet das HM-Modul mit einer Fehlermeldung. Ist die Anfrage jedoch valide,wird sie in die Abarbeitungswarteschlange des HM-Moduls gesteckt. Sollte innerhalb einerdefinierten Zeit keine Antwort von der angesprochenen Komponente ankommen, so wirddem Gateway ein „timeout“ mitgeteilt. Im Normalfall bekommt das HM-Modul jedoch vonder Komponente die benötigte Rückmeldung. Diese wird vor dem Senden an das Gatewayggf. noch in eine sinnvolle Nachricht übersetzt.

Das Austauschformat zwischen Gateway und HM-Modul sieht wie folgt aus:

<Systempraefix><Adresse>/<Befehl> z. B.: hm1A5D14/on

3.9 Refactoring und Optimierung des HM-Moduls

Das Gateway und das HM-Modul haben einen Zustand erreicht, in dem beide gemeinsamim Betrieb getestet werden können. Das Gateway wird auf einem Rechner A auf Port5683 betrieben. Das HomeMatic-Modul separat auf einem Rechner B an Port 50010. DasFirefox-Plugin Copper dient zur Erzeugung von COAP-Nachrichten und zur Interaktionmit dem Gateway.

Nach den ersten Testversuchen wurden Fehler behoben und für ein stabileres Verhalten derImplementationen gesorgt. In den Testdurchläufen fiel immer wieder die hohe Round TripTime (RTT) auf, welche zwischen 400 ms und 700 ms schwankte. Diese Werte entsprachennicht den Erwartungen, sodass das Problem untersucht wurde. In der Folge hat man einTestprogramm geschrieben, um die RTT einer BidCoS-Übertragung bestimmen zu können.Im Mittel wurde eine RTT von 149 ms gemessen. Eine Variation des Lese-Timeout imBereich von 10 ms bis 100 ms ergab die Summe aus der BidCoS-Übertragungszeit und demangegeben Timeout. Bei einem Timeout von 10 ms wurde eine mittlere RTT von 160 msgemessen. Dieses Verhalten konnte trotz sehr ähnlicher Implementierungen nicht bei dem

8

4 Zusammenfassung

HM-Modul beobachtet werden. Das HM-Modul lieferte den besten RTT-Wert von 393 msmit eingestellten Timout von 80 ms. Eine weitere Verringerung des Lese-Timeout brachtekeine Besserung.Mit der Eingrenzung der Fehler kam man zu dem Ergebnis, dass sich das Testprogrammund das HM-Modul nur in einem Punkt unterschieden. Mit jedem Schreib- oder Lesezugriffauf die Gerätedatei /dev/ttyACM0 wurde bei dem HM-Modul die serielle Verbindungstets geöffnet und geschlossen. Diese Vorgänge wurden innerhalb kürzester Zeit ständigwiederholt und führten zur Verzögerung des Ablaufes sowie dem verpassen von vielen schnelleingehenden Nachrichten. Nach der Anpassung des HM-Moduls wird im Durchschnitt eineRTT von 250 - 300 ms erreicht.

4 Zusammenfassung

4.1 Erkenntnisse

Prinzipiell ist es möglich, proprietäre Hausautomationssysteme und insbesondere HomeMa-tic in einen offenen Standard zu integrieren. Es existieren jedoch einige Hürden auf demWeg dahin.Der Aufwand ist dabei stark von der Offen- oder Geschlossenheit des gegebenen Systemsabhängig. Bei proprietären Systemen liegt die Anstrengung vor allem in der Analyse desverwendeten Protokolls sowie den technischen Übertragungsspezifika.HomeMatic zählt zwar zu den proprietären Hausautomationslösungen, bietet aber dennocheinige Schnittstellen an. Diese sind hinsichtlich des Funktionsumfanges beschränkt undbenötigen spezielle Komponenten. Exemplarisch sei die von eQ-3 offengelegte XML-RPC-Schnittstelle genannt, über die Sensorwerte abgefragt und Schaltaktionen durchgeführtwerden können. Alternativ können auch andere Softwarelösungen, die das HomeMatic-Protokoll unterstützen, eingesetzt werden, z. B. FHEM.In dieser Arbeit wurde keine der angebotenen Schnittstellen verwendet, sondern versuchtmittels anderer Methoden, wie in Abschnitt 3 beschrieben, die Einbindung von HomeMaticin das Forschungsseminar und damit ein freies System zu gewährleisten.Ein wesentlicher Nachteil von HomeMatic ist die Sicherheit. Zwar wird mit der AES-Authentifizierung ein Verfahren verwendet, das Aktionen in sicherheitskritischen Bereichenermöglicht, aber eben nicht in allen Komponenten integriert ist. Zwangsläufig sollte man beiEinsatz von AES den Standardsystemschlüssel durch einen individuellen Schlüssel ersetztenund nicht den erhöhten Konfigurationsaufwand scheuen. Die ungeschützten Komponentenbleiben dennoch angreifbar und mit etwas Aufwand und Zeit können Informationen überein bestehendes Hausnetz gesammelt werden. Dabei sind besonders die Adressen derKomponenten und die gegenseitig angelernten Komponenten von Interesse. Mittels dergewonnenen Erkenntnisse und dem Wissen über dem Aufbau von HomeMatic-Paketenkönnen dann beispielsweise gefälschte Nachrichten versendet werden. Im harmlosesten Fallerlaubt sich ein Angreifer ein Spaß mit der Lichtsteuerung. Er kann aber beispielsweiseebenso prüfen, ob ein Fenster geöffnet ist.Um die Kommunikation mit dem Heimautomatisierungsserver zu ermöglichen, wurde einProgramm geschrieben, welches die Nachrichten vom Server nebenläufig empfängt und zu

9

4 Zusammenfassung

einer Abarbeitungswarteschlange hinzufügt. Ebenso werden die vom HM-Modul generiertenAntworten von dem Programm zurück an den Heimautomatisierungsserver geschickt.

Durch die Implementierung eines Testprogrammes konnte annähernd die minimale RTTvom Absenden der Nachricht bis zum Erhalt der Quittierung ermittelt werden. Dies wurdeerforderlich, um die Performance des HM-Moduls abzuschätzen. Im Mittel ergab sich eineRTT von 150 ms. Durch Optimierungen gelang es, das HM-Modul von anfänglich 400 –700 ms auf eine RTT von durchschnittlich 250 ms zu trimmen. Im Abschnitt 3.9 wurde dieUrsache und die Lösung für die zu hohe RTT beschrieben.

4.2 Ausblick

Ein erster Punkt hinsichtlich der Erweiterung des Gateways und des HM-Moduls umfasstdie Implementierung weiterer Ressourcen bzw. Gerätetypen. An dieser Stelle sollte abervorerst die Beschränkung auf die verfügbare Hardware genügen.

Mehr von Relevanz in Bezug auf das HM-Modul ist die Entwicklung einer neuen HomeMatic-Geräteverwaltung zur besseren Handhabung der komponentenspezifischen Eigenschaften.Momentan ist diese statisch und speichert nur allgemeine Eigenschaften sowie einenZustandswert. Denkbar wäre eine Gruppierung der Komponenten mit ähnlichen Attributenin Geräteklassen z. B. Zusammenfassen und Schaltern und Fernbedienungen. Dabei wärenFunktionen für die Validierung eigehender Nachrichten des Heimautomatisierungsserverssowie der Erzeugung von Ausgaben sinnvoll.

Verallgemeinern wir den Gedanken, so wird ersichtlich, dass eine solche Umsetzung auchfür FS20-Komponenten (und ggf. noch für hinzukommende Hausautomatisierungssysteme)relevant ist. Dieses “Third-Party Device Management” (TPDM) ist größtenteils schoninnerhalb des HM-Moduls umgesetzt und muss in ein extra Modul ausgelagert werdendamit für das FS20-Modul die Funktionalitäten des TPDM zur Verfügung stehen. DasFS20-Modul ist ein weiterer Punkt, der erarbeitet werden muss. Aus organisatorischenGründen erfolgte die Entwicklung für HomeMatic und FS20 getrennt, sodass die FS20Implementierung einer Überarbeitung bedingt. Insbesondere die beiden CUL-Klassenmüssen zusammengeführt werden.

In Abschnitt 3.7 wurde die Limitierung des CULs auf ein einstellbares System angedeutetund eine vorerst statische Zuordnung der 2 verfügbaren CULs festgelegt. Dies ist nachteilig,wenn man HomeMatic einsetzen möchte und nur ein CUL vorhanden ist. Dieser CUL istdann zwar unter der Gerätedatei /dev/ttyACM0 ansprechbar, aber HomeMatic ist auf/dev/ttyACM0 definiert. Die Lösung dieses Problems besteht in der Implementierung einerautomatischen Zuordnung des CULs.

Ein weiterer Punkt ist die Integration von Komponenten mit AES-Verschlüsselung. Hierzugibt es bereits einige Diskussionen innerhalb der HomeMatic-Gemeinde mit dem Konsens,dass eine Umsetzung nur sehr schwer realisierbar sie. Eine Anlaufstelle für die Problematikist z. B. das FHEM-Forum http://forum.fhem.de.

Interessant wäre sicherlich auch die Frage, ob es möglich ist, die Firmware der HomeMatic-Komponenten durch eine eigene zu ersetzen und damit die Vorteile fertiger Hardware zunutzen (Schaltung, Aufbau, geeichte Sensoren etc.) Auch hier sei wieder auf das FHEM-Forum verwiesen.

10