Diplomarbeit KNXApp

Transcrição

Diplomarbeit KNXApp

IT-HTL Ybbs/Donau
Höhere Technische Lehranstalt für Informationstechnologie
Ausbildungsschwerpunkt Netzwerktechnik
DIPLOMARBEIT
Entwicklung einer Tablet-Applikation zur Gebäudesteuerung
(KNXApp)
Ausgeführt im Schuljahr 2011/12 von:
Betreuer:
Michael Eder
5AHITN-05
DI Christian Hammer
Markus Hinterleitner
5AHITN-07
DI Rudolf Kashofer
Ybbs an der Donau, am 10. Mai 2012
I
Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die vorliegende Diplomarbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und die den benutzten
Quellen wörtlich und inhaltlich entnommenen Stellen als solche erkenntlich gemacht habe.
Ybbs an der Donau, am 10. Mai 2012
Michael Eder
Markus Hinterleitner
II
Danksagung
Wir bedanken uns herzlichst bei unseren Projektbetreuern DI Christian Hammer und DI Rudolf Kashofer, die uns immer mit Rat und Hilfe unterstützt haben. Zusätzlicher Dank gilt unserem Projektbetreuer DI Christian Hammer, welcher das Testboard zur Verfügung gestellt hat, sowie dem SZ-YBBS
für die Bereitstellung des Android Tablets.
Weiters wollen wir uns noch bei der Firma Jägerbau Pöggstall bedanken, die uns die Grundrisse für
die Applikation zur Verfügung stellten.
III
Kurzbeschreibung
Ziel dieser Diplomarbeit war es, eine mobile Applikation zu entwickeln, welche die Steuerung von Ge-
1
räten über ein Bussystem ermöglicht. Dies funktioniert mit Hilfe einer Busschnittstelle , welche über
Ethernet mit einem Server verbunden ist. Dieser Server ermöglicht die Kommunikation mit dem Bus
und vereinfacht zusätzlich den Zugri auf diesen. Weiters ist der Server mit einem WLAN-Router
verbunden, welcher die Kommunikation mit dem mobilen Gerät über eine Netzwerkverbindung ermöglicht. Dies funktioniert sowohl durch eine direkte Verbindung mit dem WLAN-Router als auch über
2
das Internet .
Besonderer Wert wurde auf eine hohe Flexiblität des Systems gelegt, um die Steuerung beliebiger
Systeme so einfach wie möglich zu machen. Die Applikation wurde für Tablets mit dem mobilen Betriebssystem Android (Version 3 - Honeycomb) entwickelt. Als Bussystem wurde KNX gewählt, da
dieses System eine Menge Vorteile
3 bietet und eine enstprechende Testumgebung zur Verfügung stand.
Beim erstmaligen Start der Applikation sollten die Einstellungen entsprechend konguriert werden,
sodass eine Verbindung zu den Servern hergestellt werden kann. Weiters können in einer separaten
Ansicht alle Stockwerke und Räume angelegt werden. Diese, sowie alle zugewiesenen Geräte werden
in einer Datenbank abgelegt. Auÿerdem gibt es die Möglichkeit, eigene Grundrisse der verschiedenen
Stockwerke in die Applikation zu laden, wo es möglich ist, die zuvor denierten Räume zuzuweisen.
Danach kann durch Berühren eines bereits zugewiesenen Raums in eine weitere Ansicht gewechselt
werden. In dieser können dem jeweiligen Raum Geräte via Drag and Drop zugewiesen werden. Nun
ist es möglich, Lampen und Dimmer zu steuern, sowie Sensorwerte (z.B. von Temperatursensoren,
Feuchtigkeitssensoren, . . . ) und Webcam-Bilder anzeigen zu lassen.
1
KNX/IP-Router
Um dies zu ermöglichen, muss der WLAN-Router entsprechend konguriert werden
3
Diese Vorteile werden im Abschnitt Grundlagen von Bussystemen genauer erläutert.
2
IV
Abstract
The primary goal of this diploma thesis was to develop a mobile application which enables the control
4 that is connected to an intermediate
of devices via a bus system. This is achieved with a bus interface
server via Ethernet which in turn is connected to a Wireless LAN router that allows the mobile device
to communicate with the bus system.
Great emphasis was put on the exibility of the application to make the control of arbitrary systems as easy as possible. The application was developed for tablets running on the mobile operating
system Android.
At rst, the user has to congure the settings appropriately so that the connection to the servers
can be established. Next, all the oors and the related rooms have to be dened manually by the user.
All these oors, rooms as well as the assigned devices are stored in a database. Furthermore, all the
bus devices have to be added in a separate view so that they can be assigned later. It is possible to
load custom ground plans of the dierent oors into the application where the user can assign the
previously dened rooms.
Afterwards the user can switch to any assigned room by touching the related position on the groundplan. Now the dierent devices can be assigned to this room via drag and drop.
Finally the user is able to control common lamps and dimmers, show sensor values (e.g.: temperature sensors, humidity sensors, ...) as well as webcam pictures.
4
KNX/IP-Router
V
Inhaltsverzeichnis
1. Einleitung
1
1.1.
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2.
Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3.
Persönlicher Nutzen / Wertschöpfung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4.
Gliederung der Arbeit
4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Grundlagen von Bussystemen
5
2.1.
Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.
Unterschied zur bisherigen Schalttechnik . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.
Technik des KNX-Netzes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4.
2.5.
2.6.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1.
Vorteile und Nachteile
2.3.2.
Adressierung der Buskomponenten
2.3.3.
Physikalische Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3.4.
Logische Adressen (Gruppenadressen)
. . . . . . . . . . . . . . . . . . . . . . .
13
Buskommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . . . . . .
3.2.
3.3.
10
11
2.4.1.
Telegrammstruktur und Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.4.2.
KNX-Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4.3.
KNX/IP Router
18
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Programmierung der Busgeräte (ETS)
. . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.5.1.
Grasche Oberäche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.5.2.
Geräte kongurieren
21
2.5.3.
Gruppenadressen kongurieren
2.5.4.
Busverbindung herstellen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.5.5.
Programmierung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.5.6.
Busmonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
3. Analyse
3.1.
5
22
27
Beschreibung des Testaufbaues
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.1.1.
Aktoren und Sensoren
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.1.2.
Mobile Geräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
Direkte Kommunikation
3.2.1.
Vorteile
3.2.2.
Nachteile
3.2.3.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Mögliche Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Kommunikation mittels Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.3.1.
Vorteile
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.3.2.
Nachteile
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.3.3.
Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.3.4.
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
VI
3.4.
Auswahl der Datenbank
3.4.1.
3.5.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
Auswahl des mobilen Betriebssystems
3.5.1.
. . . . . . . . . . . . . . . . . . . . . . . . . . .
38
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4. Realisierung Server
39
4.1.
Server Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.
Installation Server
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.3.
Konguration Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.4.
Startskripts
47
4.5.
Sensordatenverläufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.6.
Webcam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.7.
Datenbanksystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.8.
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5. Realisierung mobile Applikation
5.1.
5.2.
5.3.
5.4.
Android
40
56
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.1.1.
Grundlegendes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.1.2.
Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
5.1.3.
Grundlegendes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.2.1.
Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.2.2.
Networking
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
5.2.3.
Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.2.4.
Entities
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
5.2.5.
Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.2.6.
Activities
71
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beschreibung der Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.3.1.
Menüführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.3.2.
Verbindung zum Server herstellen . . . . . . . . . . . . . . . . . . . . . . . . . .
79
5.3.3.
Hauptmenü . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.3.4.
Konguration verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.3.5.
Geräte steuern
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
6. Zusammenfassung
91
A. Struktur der Tabellen
I
A.1. Tabelle oors
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I
A.2. Tabelle rooms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I
A.3. Tabelle devices
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4. Tabelle room_expand
II
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
II
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III
A.6. Tabelle log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III
A.7. Tabelle persist
IV
A.5. Tabelle webcams
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B. Management
V
B.1. Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VII
V
B.2. Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VI
B.3. Aufgabenverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VII
C. Dokumentation
VIII
Literaturverzeichnis
XIII
Abbildungsverzeichnis
XV
Tabellenverzeichnis
XVI
VIII
Diplomarbeit KNXApp
1. Einleitung
Einleitend soll die Motivation, die Aufgabenstellung sowie der persönliche Nutzen und die Wertschöpfung erklärt werden. Die Gliederung der Arbeit wird ebenfalls in diesem Kapitel erläutert.
1.1. Motivation
Im modernen Wohn- und Zweckbau werden Elektroinstallationen immer häuger mit Bussystemen
realisiert. Diese Bussysteme bieten eine enorme Flexibilität und nahezu unbegrenzte Möglichkeiten,
da alle Geräte über das Bussystem gesteuert werden können und die Programmierung der Geräte so
vorgenommen werden kann, dass diese genau den Bedürfnissen und Anforderungen des Benutzers entspricht. Einen zusätzlichen Vorteil bieten Bus-Schnittstellen, welche die Verbindung des Bussystems
mit einem IP-basierten Netz ermöglichen. Dadurch bietet es sich an, die Steuerung des Gebäudes nicht
nur mit herkömmlichen Methoden, sondern auch mit Hilfe mobiler Geräte zu ermöglichen. Speziell
Tablets eignen sich besonders gut zur Steuerung eines Gebäudes, da die einzelnen Geräte durch TouchGesten intuitiv gesteuert werden können. Im Hinblick auf die Mobilität kann die Steuerung der Geräte
im Haus auch über ein entferntes Netz, zum Beispiel dem Internet erfolgen. Hierbei muss jedoch besonders auf die Sicherheit geachtet werden, da ein unbefugter Zugri auf das Bussystem weitreichende
Folgen haben kann.
Eine zusätzliche Herausforderung dieser Arbeit ist die Analyse verschiedener Lösungen sowie danach
eine auszuwählen, welche den Anforderungen entspricht. Es gibt eine Fülle an Möglichkeiten zur Steuerung eines Bussystems mittels eines computergesteuerten Systems. Die möglichen Systeme reichen von
Homeservern
1 bis hin zu freien Lösungen von Bildungseinrichtungen oder Open-Source Organisatio-
nen.
1
vollständige Lösungen zur Gebäudesteuerung, bekanntester Hersteller: Gira
Michael Eder, Markus Hinterleitner
Seite 1 von 91
Diplomarbeit KNXApp
1.2. Aufgabenstellung
Ziel der Arbeit ist es, eine mobile Applikation zu entwickeln, die eine einfache Steuerung und Verwaltung
2
von Geräten eines Bussystems ermöglicht. Das Projektteam und die Betreuer entschieden, das KNX Bussystem zu verwenden, da die Verbreitung dieser Systeme im Vergleich zu anderen Systemen sehr
hoch ist und es der einzige einheitliche Standard in der Gebäudeautomation ist. Die Software soll für
das mobile Betriebssystem Android, sowie für Apple's iOS entwickelt werden. Die mobile Applikation
soll mit einem WLAN-Router kommunizieren, der die nötigen Befehle zum Bussystem weiterleitet und
somit die Steuerung und Verwaltung ermöglicht. Weiters sollen auch bereits existierende Lösungen
analysiert und eventuell für die Umsetzung verwendet werden. Besonderer Wert soll auf die Flexibilität
gelegt werden, sodass die Steuerung beliebiger Systeme ermöglicht werden kann.
Abbildung 1.1.: Grundsätzlicher Aufbau des Systems
Wie aus der Abbildung 1.1 zu erkennen ist, können mobile Endgeräte über das intern verfügbare WLAN
oder über das öentlich zugängliche Internet auf das Bussystem zugreifen.
2
KNX steht für Konnex
Seite 2 von 91
Diplomarbeit KNXApp
1.3. Persönlicher Nutzen / Wertschöpfung
Durch die Arbeit werden viele neue Techniken erlernt. Eine besondere Herausforderung ist die eigenständige Analyse der Möglichkeiten, die Auswahl einer treenden Variante bis hin zur Planung und
Umsetzung des Systems. Es werden eine Menge selbständiger Entscheidungen getroen, besonders in
Bezug auf die verwendeten Techniken und Varianten. Die Kommunikation zwischen den Diplomanden ist ebenfalls sehr wichtig, da dies gerade bei einem Softwareprojekt ein nicht zu unterschätzender
Aspekt ist. Durch Instant-Messaging und E-Mail wird sichergestellt, dass die Diplomanden immer den
gleichen Wissenstand über die Applikation und das System haben.
Das selbständige Arbeiten, das Erlernen neuer Fähigkeiten, das Treen von Entscheidungen, sowie
die Kommunikation im Team sind als positive Aspekte zu nennen und konnten durch diese Arbeit
verbessert und ausgebaut werden.
Seite 3 von 91
Diplomarbeit KNXApp
1.4. Gliederung der Arbeit
Die Diplomarbeit gliedert sich in fünf Kapitel:
Einleitung
Das Kapitel Einleitung beschreibt die Aufgabenstellung, die Motivation sowie den persönlichen
Nutzen.
Grundlagen von Bussystemen
Das Kapitel Grundlagen von Bussystemen beschreibt den Aufbau und die Techniken eines Bussystems. Zusätzlich wird die Programmiersoftware erklärt, die es ermöglicht, das Bussystem zu
programmieren.
Analyse
Das Kapitel Analyse beschäftigt sich mit den verschiedenen Lösungen, die getestet wurden. Neben den Vor- und Nachteilen werden auch die Entscheidungen, die in der Analysephase getroen
wurden, erklärt und begründet.
Realisierung Server
Das Kapitel Realisierung Server beschäftigt sich mit der Installation und Konguration des
Servers.
Realisierung mobile Applikation
Das Kapitel Realisierung mobile Applikation durchleuchtet den Source-Code sowie die Architektur der Applikation. Weiters wird die Bedienung der Applikation beschrieben und erklärt.
Seite 4 von 91
Diplomarbeit KNXApp
2. Grundlagen von Bussystemen
In diesem Kapitel werden die Grundlagen von Bussystemen erklärt. Im Fokus steht das Bussystem
KNX, das einen gemeinsamen Standard von 3 verschiedenen Vorgängersystemen darstellt. Die Vorgängersysteme von KNX sind:
EIB (European Installation Bus)
Installationsbus zur Gebäudeautomation in Wohn- und Zweckbauten.
EHS (European Home System)
Dieses System wurde speziell für den Bereich der Haushaltsgeräte entwickelt.
BatiBUS
Der BatiBUS wurde speziell für den Bereich der Haushaltsgeräte entwickelt.
KNX basiert auf dem EIB-Protokoll, wurde aber erweitert um die Bitübertragungs- und Buszugrisverfahren, die Kongurationsmodi sowie die Anwendungserfahrungen von BatiBUS und EHS.
KNX ist somit völlig abwärtskompatibel mit EIB und wird von der KNX Association weiterentwickelt
und verbessert. KNX ist der einzige weltweite Standard im Bereich der Haus- und Gebäudetechnik.[1]
2.1. Geschichte
Die Entwicklung von KNX startete im Jahre 1996. Die oben genannten Organisationen BatiBus Club
International (BCI), European Installation Bus Association (EIBA) und European Home System Assocation (EHSA) schlossen sich zusammen und begannen einen gemeinsamen Standard in der Gebäudeautomation im kommerziellen und im Wohn- und Zweckbau-Markt zu entwickeln.
Ein weiterer wichtiger Schritt in der Geschichte von KNX wurde im Jahr 1999 getätigt. In diesem
Jahr unterzeichneten nämlich 11 führende Unternehmen aus der Elektrotechnik- und Gebäudemanagementindustrie die Statuten der neuen Organisation. Die Gründungsmitglieder der KNX-Associaton
sind:

Albrecht JUNG GmbH & Co.KG

Bosch Telecom GmbH

Delta Dore S.A

Électricité de France

Electrolux AB
Seite 5 von 91
Diplomarbeit KNXApp

Hager Holding GmbH

Merten GmbH & Co. KG

Siemens AG

Division A & D ET

Siemens Building Technologies Ltd.

Landis & Staefa Divison
Bereits im Jahr 2002 wurde die vollständige Spezikation von KNX veröentlicht und 2003 in die
europäische Norm EN 50090 übernommen.
2006 wurde KNX als internationaler Standard akzeptiert. (ISO/IEC 14543-3 )
Heute ist der KNX-Standard der de facto Standard in der Gebäudeautomation und mittlerweile haben
sich schon mehr als 100 Unternehmen weltweit diesem Standard angeschlossen.[2]
2.2. Unterschied zur bisherigen Schalttechnik
Der gröÿte Unterschied zur bisherigen Schalttechnik ist die Trennung von Stromversorgung und Gerätesteuerung. In der bisherigen Schalttechnik wurden alle Geräte elektrisch an- oder ausgeschaltet.
Dies wurde mit Parallel- oder Reihenschaltungen verwirklicht und die Steuerung der Geräte erfolgt
ausschlieÿlich über das Stromkabel. Die Stromversorgung war mit einer Netzspannung von 230 Volt
Wechselspannung gegeben. Dieser Standard war seit Beginn der Elektrizierung vor circa 100 Jahren
die einzige Möglichkeit zur Gebäudesteuerung.
Durch die Einführung von Bussystemen wurden erstmals die Stromversorgung der Geräte und die
Steuerung eben dieser getrennt. Das heiÿt, dass nun 2 Netze benötigt werden, einerseits das Stromversorgungsnetz mit 230 Volt Wechselspannung und andererseits das Steuerungsnetz
1 mit maximal
30 Volt Gleichspannung. Die beiden Netze werden unabhängig voneinander im Gebäude verlegt. Der
oensichtliche Nachteil, dass die Verlegung der beiden Netze aufwendiger ist, kann durch die vielen
Vorteile von KNX, wie etwa höherer Komfort und mehr Flexibilität wettgemacht werden.
1
oftmals auch KNX-Netz genannt
Seite 6 von 91
Diplomarbeit KNXApp
Abbildung 2.1.: KNX-Bussystem mit Steuerungsnetz und Stromversorgungsnetz[3]
Die Abbildung 2.1 zeigt ein KNX-Bussystem mit den zwei verschiedenen Netzen.
KNX bietet zusätzlich auch eine sogenannte Powernet-Variante an, hierbei werden die Steuersignale über das normale Stromnetz gesendet. Diese Variante wird vor allem bei bestehenden Bauten zur
nachträglichen Implementierung von KNX verwendet.[4]
2.3. Technik des KNX-Netzes
Grundsätzlich wird zwischen den Verbrauchern (z.B. Elektrogerät, Lampe, Fensteröner, ...) ein Steuerungsgerät eingebaut. Dieses Steuerungsgerät wird Aktor genannt. Der Aktor ist nicht nur ans Stromnetz, sondern auch ans KNX-Netz, also dem Steuerungsnetz angeschlossen.
Es gibt je nach Anforderungsprol verschiedene Aktoren.[5]
Schaltaktor
Ein Schaltaktor ist ein Gerät, das dazu dient verschiedene Verbraucher ein bzw. auszuschalten.
Heizungsaktor
Ein Heizungsaktor kann zur Steuerung eines Heizungssystems eingesetzt werden. Durch den
Einsatz von speziellen Ausgängen ist es möglich, eine erhöhte Anzahl von Schaltspielen durchzuführen. Die Belastbarkeit eines solchen Aktors ist gegenüber eines Schaltaktors geringer.
Seite 7 von 91
Diplomarbeit KNXApp
Dimmaktor
Dimmaktoren sind spezielle Aktoren, die durch variable Spannungsausgänge das Dimmen von
Verbrauchern ermöglichen.
Jalousieaktor bzw. Rollladenaktor
Jalousieaktoren dienen zur Steuerung von Jaulosien und Rollläden. Diese Aktoren besitzen Parameter zur Positionierung und Laufzeit. Eine besondere Eigenschaft ist, dass die Ausgänge gegenseitig verriegelt sind. Das bedeutet, dass ein Auf- und Zu-Befehl nicht gleichzeitig stattnden
kann.
Diese Aktoren sind an das KNX-Netz angeschlossen und erhalten von diesem Daten. Diese Daten
können entweder von einem Sensor, beispielsweise einem Temperatursensor, oder einem Computer
stammen.
Wenn ein Aktor nun einen Befehl erhält, einem bestimmten Verbraucher Spannung zuzuführen, dann
schaltet er die Netzspannung an das Gerät durch. Je nach Programmierung können die Befehle von
unterschiedlichen Sensoren stammen.
Die KNX-Leitung, die beim Steuerungsnetz zum Einsatz kommt, besteht grundsätzlich aus zwei Adernpaaren (rot-schwarz und weiÿ-gelb), wobei nur das Adernpaar rot-schwarz verwendet wird. Solche Leitungen werden als Twisted-Pair-Kabel bezeichnet, denn die einzelnen Adern sind paarweise miteinander
verdrillt. Der Vorteil beim Einsatz solcher Kabel besteht darin, dass diese gegen äuÿere magnetische
Wechselfelder und elektrostatischen Beeinussungen geschützt sind.
In Abbildung 2.2 ist eine solche KNX-Leitung zu sehen:
Abbildung 2.2.: KNX-Leitung[6]
Neben den oziellen KNX-Leitungen, die beispielsweise auf www.eibmarkt.com vertrieben werden,
können auch herkömmliche Twisted-Pair Kabel eingesetzt werden. Wichtig beim Einsatz von anderen
Twisted-Pair Kabeln ist, dass der Leitungsdurchmesser von 1mm nicht überschritten wird.
Seite 8 von 91
Diplomarbeit KNXApp
Bei der Verlegung muss darauf geachtet werden, dass nur sogenannte zertizierte KNX-Leitungen
direkt neben den Starkstromleitungen verlegt werden dürfen.
Der KNX-Bus wird von einem Netzteil mit 30 Volt Gleichspannung versorgt. Diese Spannung versorgt die Busankoppler. Der Busankoppler stellt eine Verbindung zwischen dem Anwendungsmodul
(z.B. Taster, Bewegungsmelder,...) und der KNX-Leitung her. Die Busankoppler verfügen auch über
2
eine BCU . Jedes KNX-Gerät verfügt über einen Busankoppler, auch wenn dieser nicht sofort erkennbar ist. Grundsätzlich kann man davon ausgehen, wenn das KNX-Gerät eine Busklemme besitzt, dann
bendet sich auch ein Busankoppler in diesem Gerät.
Abbildung 2.3.: Busklemme mit darunterliegendem Busankoppler am Beispiel eines Innentemperatursensors
Wie aus der Abbildung 2.3 erkennbar ist, wird über die Busklemme die Verbindung mit dem KNX-Bus
hergestellt. Der Datenaustausch erfolgt über sogenannte Telegramme, die etwas später beschrieben
werden.
KNX setzt das Zugrisverfahren CSMA/CA ein, um Telegrammverluste im Falle von Kollisionen auszuschlieÿen. CSMA/CA steht für Carrier Sense Multiple Access/Collision Avoidance und bezeichnet
das Prinzip für die Kollisionsvermeidung bei Zugri mehrerer Teilnehmer auf denselben Übertragungskanal. Der KNX-Bus verfügt über eine Datenrate von 9,6 kBit/s. Diese Übertragungsgeschwindigkeit
reicht bei korrekter Programmierung aus, um mehrere 10.000 Geräte an den Bus anzuschlieÿen.[7]
2
Bus Coupling Unit: dient der Kommunikation mit dem KNX-System
Seite 9 von 91
Diplomarbeit KNXApp
2.3.1. Vorteile und Nachteile
Bussysteme und speziell der KNX-Bus bieten eine Vielzahl an Vorteilen, aber auch Nachteile ergeben
sich bei der Implementierung dieses Bussystems.
Vorteile
Das Bussystem KNX bietet eine schnelle und unkomplizierte Bedienung. Da die Sensoren und
Aktoren frei programmiert werden können, bietet der KNX-Bus eine enorme Flexibilität. Diese
soll nun durch ein kleines Beispiel verdeutlicht werden.
Beispiel:
Ein Schalter, der eine Lampe im Wohnzimmer steuert, könnte durch einen
minimalen Programmieraufwand die Jalousien im Schlafzimmer steuern.
Der KNX-Bus bietet auch die Möglichkeit verschiedene Aktoren und Sensoren miteinander zu
verbinden. Heizung, Belüftung und Wetterstation können somit über ein einheitliches Netz miteinander kommunizieren und auf verändernde Umweltbedingungen reagieren. Ein einfaches Beispiel soll auch diesen Vorteil erklären.
Beispiel:
Sinkt die Auÿentemperatur oder auch die Innentemperatur, dann können diese
Sensordaten verwendet werden, um die Heizung automatisch zu starten.
Der KNX-Bus hilft Energie zu sparen, und steigert die Ezienz erheblich. Synergien durch die
Kombination von Heizung, Sensoren oder Beleuchtung sind ebenfalls als Vorteil anzuführen.
Im Vergleich zu anderen Bussystemen ist KNX ein genormter Standard. Dies bietet den Vorteil, dass auch Geräte verschiedener Hersteller miteinander kombiniert werden können.
Durch den Einsatz von KNX/IP-Routern kann der KNX-Bus auch über das IP-Netzwerk gesteuert und überwacht werden. Hierbei ergeben sich unzählige Möglichkeiten, wie Fernwartung,
Steuerung mittels Computer, Smartphone oder Tablet. Auch die Steuerung über eine serielle
3 ist möglich.
Schnittstelle oder über USB
Nachteile
Als gröÿter Nachteil von KNX können die hohen Anschaungs- und Implementierungskosten
genannt werden. Im direkten Vergleich mit einer herkömmlichen Installation sind die Kosten wesentlich höher. Auch der Aufwand bei der Installation ist höher. Da es zwei Netze gibt, einerseits
das Stromnetz, andererseits das KNX-Netz, ist der Aufwand zum Verlegen der Kabel höher.
Der Stromverbrauch der KNX-Anlage ist ebenfalls ein Nachteil. Die Aktoren und Sensoren benötigen nämlich mehr Energie, als die Geräte bei einer herkömmlichen Installation.[4]
Die Inbetriebnahme und der Betrieb einer solchen Anlage erfordert spezisches Know-How, sodass
qualiziertes Personal nötig ist. Dies erhöht ebenfalls die Gesamtkosten. Der Dokumentationsaufwand ist ebenfalls höher einzuschätzen, als bei einer herkömmlichen Installation.
3
Universal Serial Bus
Seite 10 von 91
Diplomarbeit KNXApp
2.3.2. Adressierung der Buskomponenten
Beim KNX-Bussystem unterscheidet man zwischen zwei Adressarten:

physikalische Adressen

logische Adressen
Grundsätzlich sind diese Adressen sehr ähnlich, da beide Adressen eine Länge von 16 Bit aufweisen.
Im folgenden Abschnitt werden Einsatzzwecke und die Unterschiede der beiden Adressarten erklärt.
Seite 11 von 91
Diplomarbeit KNXApp
2.3.3. Physikalische Adressen
Physikalische Adressen kennzeichnen ein Busgerät eindeutig. Das heiÿt, eine physikalische Adresse
kommt im gesamten KNX-Netz nur einmal vor. Die physikalischen Adressen müssen während der Programmierung in das KNX-Gerät eingespielt werden.
Abbildung 2.4.: Adressfeld der physikalischen Adresse [7, Seite 49]
Die Abbildung 2.4 zeigt den Aufbau einer physikalischen Adresse und die Bedeutung von den einzelnen Bits. Eine physikalische Adresse wird in drei Bereiche aufgeteilt, die jeweils mit einem Punkt
getrennt werden (Bereichsadresse.Linienadresse.Teilnehmeradresse ). Eine physikalische Adresse kann
folgendermaÿen aussehen: 1.2.3 .Die physikalische Adresse ist nach einer Hierarchie aufgebaut, die
über die Programmiersoftware ETS festgelegt werden kann. Die Software, sowie der Aufbau dieser
Hierarchie wird im Abschnitt Programmiersoftware ETS näher erklärt.
Bereichsadresse
Die Bereichsadresse gibt Auskunft, in welchem Bereich sich der Teilnehmer bendet.
Linienadresse
Die Linienadresse gibt an, in welcher Linie sich der Teilnehmer bendet.
Teilnehmeradresse
Die Teilnehmeradresse kennzeichnet den Teilnehmer innerhalb einer Linie.
Seite 12 von 91
Diplomarbeit KNXApp
2.3.4. Logische Adressen (Gruppenadressen)
Im Gegensatz zu den physikalischen Adressen können die logischen Adressen, im folgenden Gruppenadressen genannt, frei gewählt werden. Es müssen die Hierarchiebestimmungen von Linien
und Bereichen nicht eingehalten werden. Gruppenadressen sind also frei wählbare Adressen, die
in einer bestimmten Form angegeben werden, um eine bessere Übersicht zu gewährleisten. Eine
Gruppenadresse besteht aus 16 Bit. Das letzte Bit (Bit 15 (siehe Abbildung 2.4)) ist bei dieser
Adresse jeweils eine binäre 0.
Gruppenadressen können als zwei oder dreistuge Adressen dargestellt werden. Das Trennzeichen zwischen den Stufen ist jeweils ein Slash(/), dadurch können die Gruppenadressen besser
von den physikalischen Adressen unterschieden werden.
Gruppenadressen mit 3 Stufen haben folgenden Aufbau:
Hauptgruppe/Mittelgruppe/Untergruppe
Die Hauptgruppe besteht aus 4 Bit, die Mittelgruppe aus 3 Bit und die Untergruppe aus 8
Bit.
Gruppenadressen mit 2 Stufen haben folgenden Aufbau:
Hauptgruppe/Untergruppe
Für die Hauptgruppe sind bei dieser Adressart 4 Bit reserviert und die Untergruppe besteht
aus 11 Bit.
Zwischen den beiden Darstellungsformen kann beliebig gewechselt werden, die Umrechnung erfolgt folgendermaÿen:
Umrechnung von 3-stuger Darstellung (HG/MG/UG) zu 2-stuger (HG/UG):
HG = HG
U G = M G ∗ 256 + U G
Umrechnung von 2-stuger Darstellung (HG/UG) zu 3-stuger (HG/MG/UG):
HG = HG
M G = ganzer Wert
G
U G = Rest von U
256
von
UG
256
Mit Hilfe eines Beispiels soll die Umrechnung erklärt werden.
Beispiel:
Die Gruppenadresse 1/1/5 soll in eine 2-stuge Darstellung umgerechnet werden.
HG = 1
U G = 1 ∗ 256 + 5 = 261
Die 2-stuge Gruppenadresse ist also 1/261. Diese Gruppenadresse soll nun
wieder in die 3-stuge Darstellung umgerechnet werden.
HG = 1
M G = ganzer Wert von
U G = Rest von 261
256 = 5
261
256
=1
Die 3-stuge Gruppenadresse lautet nun wieder 1/1/5.
Seite 13 von 91
Diplomarbeit KNXApp
2.4. Buskommunikation
Unter Buskommunikation versteht man die Kommunikation der einzelnen KNX-Geräte untereinander.
Wie schon erwähnt, erfolgt die Kommunikation über Telegramme. Der Bus verwendet ein ereignisorientiertes Übertragungsverfahren, das heiÿt, wenn nichts passiert, ist der Bus frei. Ein Ereignis wird
ausgelöst, wenn beispielsweise ein Schalter betätigt wird.
Abbildung 2.5.: Ereignis löst die Datenübertragung aus [7, Seite 50]
Die Abbildung 2.5 kann folgendermaÿen interpretiert werden: Wenn ein Teilnehmer ein Ereignis E
registriert, wartet er solange, bis dass er eine Pause von 5,2 ms im Datenstrom erkennt. Erkennt er
eine solche Pause, schickt er ein Datentelegramm auf den Bus. Nach Abschluss der Übertragung hat
der Empfänger 1,35 ms Zeit, die empfangenen Daten zu prüfen. Danach erfolgt die Quittierung des
Telegramms durch den Empfänger. Werden mehrere Empfänger angesprochen, dann quittieren alle
Empfänger das Telegramm.
2.4.1. Telegrammstruktur und Aufbau
Ein Telegramm ist ein kompletter Datenblock, der zur Übertragung einer Information dient. Jedes Telegramm enthält neben den eigentlichen Nutzdaten noch zusätzliche Informationen. Zu diesen zusätzlichen Informationen (auch Header oder Trailer genannt) gehören zum Beispiel Priorität, Quelladresse,
Zieladresse, Routing-Zähler und Datensicherung.
Abbildung 2.6.: Aufbau eines Telegramms [7, Seite 50]
Die Abbildung 2.6 zeigt ein KNX-Telegramm. Die einzelnen Bits werden für die Übertragung zu Blöcken
Seite 14 von 91
Diplomarbeit KNXApp
von 8 Bit Länge (entspricht 1 Byte) zusammengefasst.
Steuerfeld (8 Bit)
Das Steuerfeld legt die Priorität einer Nachricht fest. Wie in Tabelle 2.1 zu erkennen ist, gibt es
4 verschiedene Prioritätsstufen, die die Priorität der Nachricht festlegen.
Prioritätsstufe Bedeutung/Anwendung
1
Systemfunktionen
2
Alarmfunktionen
3
hohe Betriebspriorität
4
niedrige Betriebspriorität
Tabelle 2.1.: Prioritätscodierung[7, Seite 47]
Mit diesen Prioritäten soll sichergestellt werden, dass wichtige Telegramme auch nach einer Kollision weitergeleitet werden.
Quelladresse (16 Bit)
Die Quelladresse deniert den Sender der Nachricht. Die Quelladresse ist immer die physikalische
Adresse des Senders, sodass jede Nachricht auf dem Bus eindeutig zugeordnet werden kann. Aus
der Quelladresse kann der Sender eindeutig abgeleitet werden.
Zieladresse (17 Bit)
Die Zieladresse deniert den/die Empfänger der Nachricht. Die Zieladresse kann eine physikalische Adresse sein, dann wird nur dieser eine Teilnehmer mit der angegebenen physikalischen
Adresse angesprochen. Wird eine Gruppenadresse in diesem Feld angefügt, dann reagieren alle
Teilnehmer, die dieser Gruppe zugeordnet wurden.
4
Für die Kennzeichnung des Adresstyps wird ein 17. Bit der Zieladresse hinzugefügt. (DAF )
17. Bit = 0
Die Zieladresse ist eine physikalische Adresse, es wird somit nur ein Teilnehmer angesprochen.
17. Bit = 1
Die Zieladresse ist eine Gruppenadresse, das heiÿt alle Teilnehmer mit dieser Gruppenadresse
werden angesprochen.
4
Destination Address Flag
Seite 15 von 91
Diplomarbeit KNXApp
Routing-Zähler (3 Bit)
Der Routing-Zähler ist ein Mechanismus zur Weitervermittlung von Telegrammen in einem KNXNetz. Der Routing-Zähler gibt an, wie oft ein Telegramm über Linien- oder Bereichskoppler
weitervermittelt werden darf. Wichtig hierbei ist, dass nur Telegramme mit einem Zählerstand
gröÿer Null weitergeleitet werden. Durch die Länge von 3 Bit ergeben sich Werte von 0 bis 7.
Zählerstand 0
Besitzt ein Telegramm diesen Zählerstand, wird es nicht weitervermittelt.
Zählerstand 1...6
Diese Telegramme werden weitervermittelt, jedoch wird der Routing-Zähler beim Durchlaufen eines KNX-Gerätes um den Wert 1 verringert.
Zählerstand 7
Telegramme mit diesem Zähler werden unverändert und beliebig oft über alle Busgeräte
weitergeleitet.
Der Routing-Zähler verhindert durch seinen Einsatz ein unnötiges Weiterleiten von Telegrammen
innerhalb des Bussystems.
Länge (4 Bit)
Die Länge gibt an, wie groÿ das folgende Nutzdatenfeld ist. Mit den eingesetzten 4 Bit lassen
sich Zahlen von 0 bis 15 darstellen, daraus ergibt sich die Anzahl der Nutzdatenbyte. Dadurch
sind Nutzdaten von 1 bis 16 Byte (8 bis 128 Bit) möglich.
Nutzdaten (8 bis 128 Bit)
Dieses Feld enthält die Nutzdaten des Telegramms. Hier werden die Informationen übertragen,
die der Empfänger einleiten muss (z.B. Schalten einer Lampe)
Datensicherung (8 Bit)
Die Datensicherung soll sicherstellen, dass die übertragenen Daten vor Verfälschungen gesichert
werden. Verfälschungen können durch Störsignale oder durch defekte Leitungen entstehen.
Der Sender generiert aus seiner Nachricht, nach einer bestimmten Vorschrift, sogenannte Prüfzeichen. Diese werden dann im Datensicherungsfeld übertragen. Der Empfänger bildet diese Prüfzeichen aus der empfangenen Nachricht ein zweites Mal und stellt mittels eines Vergleiches fest
ob eine Veränderung aufgetreten ist. Wenn die Prüfzeichen nicht übereinstimmen, sendet der
Empfänger eine negative Quittung an den Sender. Eine Nachricht gilt erst dann als korrekt
übertragen, wenn alle Empfänger eine positive Quittung an den Sender übertragen.
2.4.2. KNX-Datentypen
In KNX-Netzen werden Datentypen dafür eingesetzt, um zu denieren, welche Bedeutung die Nachricht hat. Die KNX-Datentypinformation wird in den Nutzdaten übertragen. Die KNX-Datentypen
wurden eingeführt, um sicherzustellen, dass auch Geräte von verschiedenen Herstellern miteinander
kommunizieren können. Die Codierung wird Datenpunkttyp (datapoint type oder DPT) genannt.
5
Bevor die DPT eingesetzt wurden, waren die gebräuchlichen Datentypen die sogenannten EIS -Typen.
Diese Datentypen wurden durch den Einsatz der DPTs abgelöst.
5
EIB Interworking Standard
Seite 16 von 91
Diplomarbeit KNXApp
Ein DPT wird deniert durch:

einen Haupttyp

einen optionalen Untertyp.
Der Haupttyp enthält Informationen über Länge, Format und Codierung. Der Untertyp gibt Auskunft
um welchen speziellen Datentyp es sich handelt (z.B. Einheit).
Die Schreibweise eines DPTs sieht folgendermaÿen aus: Haupttyp.Untertyp.
Beispiel:
Der Haupttyp 1 bedeutet '1 Bit' , der Untertyp 1.001 kann die Werte 0 und 1
annehmen (0=Aus, 1=Ein).
Wird ein anderer Untertyp verwendet, z.B. 1.008,
dann haben die Werte 0 und 1 eine andere Bedeutung. (0=Auf, 1=Ab)
Wie aus dem Beispiel ersichtlich, bedeutet die Zahl des Haupttyps die Gröÿe des DPTs in Bit. In der
Tabelle 2.2 werden die vorhandenen DPTs überblicksmäÿig aufgelistet.
DPT-Haupttyp DPT-Untertyp DPT Name (Einsatz)
1
2
3
4
5
1.001
DPT_SWITCH
1.008
DPT_UPDOWN
1.100
DPT_HEAT/COOL
2.001
DPT_BOOL_CONTROL
2.004
DPT_RAMP_CONTROL
2.005
DPT_ALARM_CONTROL
3.007
DPT_CONTROL_DIMMING
3.008
DPT_CONTROL_BLINDS
4.001
DPT_CHAR_ASCII
4.002
DPT_CHAR_8859_1
5.003
DPT_Angle
Tabelle 2.2.: Auszug aus den KNX-Datentypen [7, vgl. Seite 158]
6 von KNX zu nden.
Die vollständige Liste aller verfügbaren DPTs ist in der Dokumentation
6
http://www.knx.org/at/knx-standard/how-to-order/
Seite 17 von 91
Diplomarbeit KNXApp
2.4.3. KNX/IP Router
Der KNX/IP Router, in Abbildung 2.7 zu sehen, ist eine Schnittstelle vom KNX-Bus zum IP-Netz.
7
Grundsätzlich wandelt der KNX/IP Router UDP -Pakete in für den KNX-Bus verständliche Telegramme um. Das eingesetzte Protokoll heiÿt KNXnet/IP und wurde in einer Erweiterung des KNX
Standards deniert. KNXnet/IP kennt zwei verschiedene Arten zur Datenübertragung.[8]
KNXnet/IP Tunneling
Diese Art nutzt eine Punkt-zu-Punkt Verbindung (Singlecast). Beim KNXnet/IP Tunneling wird
eine gesicherte Verbindung aufgebaut, das heiÿt, dass diese Verbindungsart zuverlässig arbeitet.
Der Zugri aus anderen Netzen (z.B. das Internet) ist möglich. Der Tunneling-Modus lässt nur
eine Verbindung gleichzeitig zum KNX-Bus zu.
KNXnet/IP Routing
Beim KNXnet/IP Routing wird eine Punkt-zu-Mehrpunkt Verbindung verwendet (Multicast).
Es ndet hierbei keine gesicherte Übertragung statt und der Zugri aus anderen Netzen ist nicht
möglich. Bendet sich der KNX/IP Router im Routing-Modus, so können mehrere Verbindungen
gleichzeitig erfolgen.
Wenn der KNX/IP Router als Schnittstelle zwischen dem KNX-Bus und dem IP-Netzwerk arbeitet,
wird er als KNX/IP Gateway bezeichnet.
Der in der Umsetzung eingesetzte eibd arbeitet im Tunneling-Modus. Dieser Modus wurde gewählt, da
nur im Tunneling-Modus ein Remote-Zugri auf den KNX-Bus möglich ist. Der eibd kann aber auch
im Routing-Modus gestartet werden. Der KNX/IP-Router kann auch als Linien- oder Bereichskoppler
fungieren.
Abbildung 2.7.: KNX-IP Gateway
7
User Datagram Protocol
Seite 18 von 91
Diplomarbeit KNXApp
2.5. Programmierung der Busgeräte (ETS)
ETS steht für
EIB Tool Software.
Die ETS3 ist eine Software, die es ermöglicht ein KNX/EIB-System zu kongurieren. Es bietet Tools
zur Inbetriebnahme, Projektierung und Diagnose von KNX/EIB-Systemen. Die Software wird im Auftrag der KNX Association entwickelt.[9]
Die KNX Association ist das einzige Unternehmen, das die Software vertreibt.
ETS bietet 2 Versionen für ihre Kunden an:
Starter
Diese Version kann für kleine Projekte mit max. 50-70 Geräten eingesetzt werden. Die ETS3
Starter kommt besonders Einsteigern sehr entgegen.
Professional
Diese Version kann für gröÿere Projekte eingesetzt werden und unterscheidet sich sowohl von der
Oberäche, als auch vom Funktionsumfang von der ETS3 Starter Version.
Während der Arbeit wurde die ETS3 Professional verwendet, um alle Funktionen nutzen zu können.
Seite 19 von 91
Diplomarbeit KNXApp
2.5.1. Grasche Oberäche
Abbildung 2.8.: ETS3-Hauptansicht
Wie in der Abbildung 2.8 zu sehen ist, besteht die Software aus einem Hauptfenster welches wiederum
3 weitere Fenster beinhaltet.
Topologie
In diesem Fenster werden die physikalischen Geräte angezeigt. Die Topologie kann aufgeteilt
werden in mehrere Bereiche, die wiederum Linien enthalten. In jeder Linie können danach die
Geräte hinzugefügt werden.
Gebäude
In diesem Fenster, das sich auf der rechten Seite bendet, können die verschiedenen Gebäude
verwaltet und eingesehen werden. Hier kann eine logische Anordnung der physikalischen Geräte
stattnden.
Gruppenadressen
Hier können die Gruppenadressen angelegt und verwaltet werden. Zu jeder Gruppenadresse können die Geräte aus der Topologie hinzugefügt werden und somit zum Beispiel ein Dimmer mit
einem Taster verbunden werden, sodass der Taster nun einen Dimmer steuern kann.
Seite 20 von 91
Diplomarbeit KNXApp
2.5.2. Geräte kongurieren
Im Topologie-Fenster können über ein Kontextmenü die Eigenschaften der einzelnen Geräte geändert
werden. Hierzu muss der Punkt Parameter bearbeiten im Kontextmenü ausgewählt werden.
Grundsätzlich bietet jedes Gerät verschiedene Parameter an, die in diesem Dialog konguriert und
eingestellt werden können. Im folgenden Beispiel werden die Parameter eines KNX-Sensors erklärt.
Dieser Sensor besitzt die Möglichkeit, Temperaturmesswerte zu senden.
Abbildung 2.9.: Temperatur Parameter bearbeiten
Wie in der Abbildung 2.9 zu sehen ist, können beim Temperaturmesswert verschiedene Parameter bearbeitet werden.
Aus diesem Dialog sind besonders die Punkte Temperaturmesswert und Zyklisch senden alle von Bedeutung. Hier kann beispielsweise der Temperaturmesswert nur bei einer Änderung oder eben zyklisch
gesendet werden. Letzteres bietet dann zusätzlich die Möglichkeit ein Intervall festzulegen, in welchen
Abständen die Temperaturmesswerte gesendet werden sollen.
Seite 21 von 91
Diplomarbeit KNXApp
2.5.3. Gruppenadressen kongurieren
Um die Geräte nun logisch miteinander zu verknüpfen, müssen Gruppenadressen deniert werden.
Hierbei können in dem dafür vorgesehenem Fenster die nötigen Gruppenadressen angelegt und konguriert werden.
Abbildung 2.10.: Gruppenadresse Temperatur
Die Abbildung 2.10 zeigt eine Gruppenadresse, die den Temperaturmesswert beinhaltet.
Die Gruppenadresse ist hierarchisch geordnet und besitzt somit den Wert 1/0/1.
Seite 22 von 91
Diplomarbeit KNXApp
2.5.4. Busverbindung herstellen
Die ETS bietet verschiedene Möglichkeiten eine Verbindung zum Bus herzustellen. Getestet wird die
Verbindung per USB sowie über den KNX/IP Router.
Die Konguration der Busverbindung erfolgt im Menü Extras/Optionen in der Registerkarte Kom-
munikation und kann danach auch direkt getestet werden. In der Abbildung 2.11 ist eine erfolgreiche
Busverbindung zu sehen.
Abbildung 2.11.: erfolgreiche Busverbindung
2.5.5. Programmierung
Bei einer hergestellten Busverbindung können die einzelnen Geräte programmiert werden. Der Dialog
zum Programmieren kann über das Kontextmenü im Topologie-Fenster oder im GruppenadressenFenster aufgerufen werden. In Abbildung 2.12 ist ein solcher Dialog zu sehen.
Abbildung 2.12.: Programmierung der Busgeräte
Seite 23 von 91
Diplomarbeit KNXApp
Je nachdem, welche Komponenten programmiert werden sollen, können die entsprechenden Programmiervorgänge eingeleitet werden.
Phys. Adr. programmieren
Wenn die physikalische Adresse programmiert werden soll, muss nach Starten der Programmierung ein Programmierknopf am entsprechenden Gerät gedrückt werden, sodass die physikalische
Adresse programmiert wird.
Abbildung 2.13.: Programmierknopf am Beispiel eines Auÿentemperatursensors
Die Abbildung 2.13 zeigt den Programmierknopf, der im blauen Kreis zu sehen ist. Sobald der
Knopf gedrückt wurde, leuchtet die LED, das sich direkt neben dem Programmierknopf bendet.
Wenn die Programmierung erfolgreich beendet wurde, erlischt die LED.
Applikations-Programm
Das Applikations-Programm ist eine Software und wird vom Hersteller eines KNX-Gerätes zur
Verfügung gestellt. Diese Software ist gerätespezisch und kann mittels Produktdatenbank in
ETS importiert werden (Datei/Import ). Programmiert man das Applikations-Programm, wird
die neue Software in das KNX-Gerät eingespielt.
Partiell programmieren
Diese Form der Programmierung kann angewendet werden, wenn sich schon ein ApplikationsProgramm am KNX-Gerät bendet. Partiell programmieren bedeutet, dass nur Änderungen
in das Gerät eingespielt werden. Hierbei kann beispielsweise nur die Gruppenadresse oder die
Parameter programmiert werden.
Seite 24 von 91
Diplomarbeit KNXApp
2.5.6. Busmonitor
Die ETS hat einen Busmonitor implementiert. Der Busmonitor zeichnet alle Aktivitäten am Bus auf
wodurch die Funktionalität der einzelnen Geräte überprüft werden kann. Der Busmonitor bietet zusätzlich die Möglichkeit, Werte zu senden bzw. zu lesen. In der Abbildung 2.14 können die Werte von
Temperatur und Feuchtigkeit, die zyklisch auf den Bus gesendet werden, verfolgt werden.
Abbildung 2.14.: Busmonitor
Seite 25 von 91
Diplomarbeit KNXApp
2.6. Fazit
Im Umgang mit ETS sind einige Herausforderungen aufgetreten. Beispielsweise lässt das KNX/IPGateway nur eine aktive Verbindung zum Bussystem zu. Dies hat zur Folge, dass während einer aktiven
Busverbindung von ETS keine weiteren Verbindungen über das KNX/IP-Gateway zugelassen werden.
Eine aktive Busverbindung ist beispielsweise ein gestarteter Busmonitor oder auch der eibd, der auf
Port 6720 arbeitet. Es besteht aber die Möglichkeit, auch während eines aktiven eibds, mit ETS zu
arbeiten. Hierbei ist es möglich die IP-Adresse des eibd anstatt der Adresse des KNX/IP-Gateways
anzugeben und somit über diesen die Programmiervorgänge durchzuführen.
8 mittels ETS programmiert. Der Upload des
Während der Arbeit wurde auch ein KNX-Touchpanel
Applikationsprogrammes stoppte während des Programmiervorganges und danach reagierte das Touchpanel nicht mehr. Eine Internetrecherche ergab, dass das Touchpanel nur mittels ETS4
9 vollständig
programmiert werden kann. Nachdem der Upload des Applikationsprogrammes in ETS4 erfolgt war,
konnte das Touchpanel wieder herkömmlich in ETS3 partiell programmiert werden. Ein vollständiger
Upload des Applikationsprogrammes war in ETS3 nicht mehr möglich, darum mussten alle folgenden
Programmiervorgänge an diesem Gerät partiell erfolgen. In Abbildung 2.15 ist ein solches Touchpanel
zu sehen.
Abbildung 2.15.: Zennio ZAS Touchpanel [10]
8
9
Zennio ZAS Touchpanel
Nachfolgeversion von ETS3
Seite 26 von 91
Diplomarbeit KNXApp
3. Analyse
In der Analyse wird sowohl die zur Verfügung stehende Busumgebung, als auch die eingesetzten mobilen Geräte analysiert und dokumentiert.
Ein weiteres Ziel der Analyse ist es, eine geeignete Kommunikationsmöglichkeit zwischen der mobilen
1 und dem KNX-Bus zu nden. Dabei wird besondere Rücksicht auf spezielle Anforderun-
Applikation
gen sowie eventuelle Vor/Nachteile der jeweiligen Varianten gelegt. Grundsätzlich kann zwischen zwei
verschiedenen Varianten der Kommunikation unterschieden werden:

Direkte Kommunikaton zwischen App und Bus

Kommunikation über einen dazwischenliegenden Server
3.1. Beschreibung des Testaufbaues
Im Zuge der Arbeit wurde ein Testboard zur Verfügung gestellt, das mit KNX-Komponenten ausgestattet ist. Auf diesem Board sind sowohl Aktoren, Sensoren als auch ein Systemgerät angebracht. Das
Testboard wurde sowohl zum Testen der Programmierung der einzelnen KNX-Geräte verwendet, als
auch zum Testen der Applikation unter realen Bedingungen. Der Einsatz einer realen Testumgebung
ist wichtig, da manche Herausforderungen nur unter realen Bedingungen auftreten.
Das Testboard besteht aus 5 Aktoren und aus 2 Sensoren. Diese Geräte haben unterschiedliche Funk-
2
tionen und wurden genauer analysiert. Das Testboard verfügt auÿerdem über 6 Verbraucher . Der auf
dem Testboard bendliche KNX/IP-Router wird als Systemgerät bzw. auch als Schnittstelle bezeichnet. Diese Komponente ist im Kapitel 2 Grundlagen von Bussystemen beschrieben.
1
2
Nachfolgend auch immer wieder als App bezeichnet
Die Verbraucher sind Glühbirnen in verschiedenen Farben
Seite 27 von 91
Diplomarbeit KNXApp
Abbildung 3.1.: Testboard
Die KNX-Geräte in Abbildung 3.1 sind mittels eines Busnetzwerkes miteinander verbunden und können somit miteinander kommunizieren. Die Abbildung zeigt nicht alle getesteten Geräte, da ein Einsatz
aller Geräte zur gleichen Zeit aus Platzgründen nicht möglich war. Der Testaufbau besteht aus einem
Bereich und einer Linie.
Zum Testen der Applikation wurde ein Samsung Tablet und ein Emulator eingesetzt.
3.1.1. Aktoren und Sensoren
Das Testboard besteht aus einem Dimmaktor, einem Netzteil mit Schaltaktor, zwei Tastaktoren und einem Schaltaktor mit Stromerkennung. Zusätzlich wurden noch zwei Sensoren getestet, die Temperatur
und andere Messwerte liefern.
Aktoren
Wie im Kapitel 2 Grundlagen von Bussystemen beschrieben, sind Aktoren grundsätzlich Steuerungsgeräte, die zwischen Verbraucher geschaltet werden. Die Eigenschaften der eingesetzten Aktoren sollen
im folgenden Abschnitt beschrieben werden.
Dimmaktor
ABB UD/S.4.210.1
Der Dimmaktor vom Hersteller ABB verfügt über 4 Ausgänge. Es besteht die Möglichkeit, Verbraucher sowohl zu dimmen, als auch diese ein- bzw. auszuschalten.[11] In Abbildung 3.2 ist ein
ABB Dimmaktor zu sehen.
Seite 28 von 91
Diplomarbeit KNXApp
Abbildung 3.2.: ABB Dimmaktor[11]
Schaltaktor
ABB SA/S 8.16.6.1
Der Schaltaktor der Firma ABB verfügt über 8 Ausgänge. Dieser Typ eignet sich besonders
zum Schalten von hohen Eingangsstromspitzen. Eine weitere Besonderheit ist die Laststromerkennung, die für jeden Ausgang verfügbar ist. Der Schaltaktor hat einen maximalen Laststrom
von 20 A pro Ausgang.[12]
In Abbildung 3.3 ist ein ABB Schaltaktor zu sehen.
Abbildung 3.3.: ABB Schaltaktor [12]
Seite 29 von 91
Diplomarbeit KNXApp
Netzteil-Schaltaktor mit USB
Lingg&Janke NTA6F16H+USB
Der Netzteil-Schaltaktor wird von der Firma Lingg&Janke hergestellt. Neben den 6 Aktoren
ist zusätzlich eine Spannungsversorgung von 640 mA integriert. Das Netzteil versorgt den Bus
mit der nötigen Spannung.[13]
Abbildung 3.4 zeigt einen Lingg&Janke Netzteil-Schaltaktor.
Abbildung 3.4.: Lingg&Janke Netzteil-Schaltaktor
Tastaktor 4-fach
Siemens 5WG1 245-2AB11
Der Tastaktor der Firma Siemens ist mit 4 Aktoren ausgestattet, die es ermöglichen, Verbraucher zu steuern. Der Tastaktor bietet auch die Möglichkeit, durch langes Drücken eines Schalters,
verschiedene Verbraucher zu dimmen.[14]
Abbildung 3.6 zeigt einen 4-fach Taster von Siemens.
Abbildung 3.5.: Siemens 4-fach Taster[15]
Taster-Schnittstelle
Siemens 5WG1 220-2AB03
Die Siemens Taster-Schnittstelle verfügt über 4 Binäreingänge, an denen potentialfreie Schalter-
Seite 30 von 91
Diplomarbeit KNXApp
bzw. Tasterkontakte angeschlossen werden können. Die Leitung von der Taster-Schnittstelle bis
zu den potenzialfreien Kontakten sollte eine Leitungslänge von 10 Meter nicht überschreiten.
Zusätzlich müssen die Leitungspaare gedrillt geführt werden.[16]
Abbildung 3.6 zeigt eine Taster-Schnittstelle der Firma Siemens.
Abbildung 3.6.: Siemens Taster-Schnittstelle
Sensoren
Sensoren sind Geräte, die verschiedene Messwerte aufzeichnen, welche bei korrekter Programmierung
die Steuerung von Aktoren beeinussen oder die Messdaten werden von anderen Systemen weiterverarbeitet.
Innenraumsensor
Elsner-Elektronik KNX TH-UP
Der Innenraumsensor vom deutschen Unternehmen Elsner-Elektronik besitzt eine Vielzahl an
Funktionen. Neben der Lieferung von Temperatur- und Feuchtigkeitsmesswerten kann der KNX
TH-UP basic auch den Taupunkt berechnen. Der Innenraumsensor bietet die Möglichkeit externe
Messwerte zu empfangen, aus denen er danach Mischwerte berechnet. Der Sensor hat ebenfalls
einen PI-Regler für Heizung, Kühlung und Lüftung integriert, zusätzlich sendet er, bei entspre-
3 verlassen wird.
chender Konguration, eine Warnung an den Bus, sobald das Behaglichkeitsfeld
Ein weiteres Feature des Sensors ist die Bereitstellung von sieben Schaltausgängen sowie UNDund ODER-Logik-Verknüpfungen[17].
3
nach DIN 1946
Seite 31 von 91
Diplomarbeit KNXApp
Abbildung 3.7 zeigt einen Innenraumsensor von Elsner-Elektronik.
Abbildung 3.7.: Innenraumsensor KNX TH-UP basic weiÿ[17]
Temperatursensor
Elsner-Elektronik KNX T-AP
Dieser Sensor von der Firma Elsner Elektronik misst die Temperatur im Innen- und im Auÿenbereich. Der Temperatursensor kann externe Messwerte empfangen und stellt UND- und
ODER-Logik-Verknüpfungen zur Verfügung. Neben den vier Schaltausgängen des Sensors ist
auch ein PI-Regler für Heizung und Kühlung integriert.
Der Temperatursensor kann bei einer Umgebungstemperatur von -30 bis +85 Grad Celsius betrieben werden.[18]
Abbildung 3.8 zeigt einen Temperatursensor von Elsner-Elektronik.
Abbildung 3.8.: Temperatursensor KNX T-AP[18]
Seite 32 von 91
Diplomarbeit KNXApp
3.1.2. Mobile Geräte
Während der Arbeit wurde den Diplomanden ein Tablet (Samsung Galaxy Tab 10.1 ) zur Verfügung
gestellt. Zusätzlich zum physikalischen Gerät wurde auch ein Emulator verwendet.
Samsung Galaxy Tab 10.1
Das Samsung Galaxy Tab 10.1 wurde im August 2011 auf den Markt gebracht und ist der nächste und
schärfste Konkurrent zu Apples iPad.
In Tabelle 3.1 sind die technische Spezikationen zu sehen:
Komponente
Hersteller und Modell
Prozessor
Tegra 1 Ghz (Dual Core)
Arbeitsspeicher(RAM)
1024 MB
Bildschirm
25,6 cm (10,1 Zoll)
Auösung
1280x800 Pixel
Betriebssystem
Android 3.2
Tabelle 3.1.: Technische Spezikationen
Das installierte Betriebssystem ist Android 3.2. Jedoch wurde das Betriebssystem von Samsung modi-
4
ziert .
In Abbildung 3.9 ist die Vorderseite des Samsung Galaxy Tab 10.1 zu sehen.
Abbildung 3.9.: Samsung Galaxy Tab 10.1[19]
4
TouchWiz-Bedienoberäche
Seite 33 von 91
Diplomarbeit KNXApp
Emulator
Die Applikation wurde ebenfalls in einem Emulator getestet. Dieser wird im Abschnitt 5.1.2 näher
beschrieben.
Beim Einsatz des Emluators el auf, dass dieser eine schlechte Performance hat. Das Wechseln zwischen
den Screens ist nur mit langen Verzögerungen möglich. Durch die schlechte Performance wurde die
Entwicklung auf einem physikalischen Gerät (Samsung Tablet) bevorzugt, jedoch wurde die Applikation
auch auf dem Emulator getestet und gedebuggt.
Seite 34 von 91
Diplomarbeit KNXApp
3.2. Direkte Kommunikation
Bei dieser Variante erfolgt die Kommunikation zwischen Applikation und Bus ohne dazwischenliegende
Komponenten. Daraus ergibt sich, dass die komplette Steuerung vollständig über die mobile Applikation erfolgen muss.
Abbildung 3.10 soll diese Variante der Kommunikation veranschaulichen.
Abbildung 3.10.: Aufbau bei der direkten Kommunikation
3.2.1. Vorteile

Ein oensichtlicher Vorteil ist, dass kein zusätzlicher Server benötigt wird, damit die Applikation
mit dem Bus kommunizieren kann. Somit erspart man sich eine zusätzliche Komponente im
Gegensatz zur zweiten Variante.
3.2.2. Nachteile

Ein wesentlicher Nachteil dieser Variante besteht darin, dass keine zeitlichen Verläufe von Werten an den Sensoren oder anderen Geräten am Bus (z.B. Temperatur, Feuchtigkeit, . . . ) erstellt
werden können, da nicht davon ausgegangen werden kann, dass die mobile Applikation permanent läuft. Es gibt also keine Komponente, die empfangene Werte vom Bus über einen längeren
Zeitraum hinweg aufzeichnen und speichern könnte.

Weiters ergibt sich dadurch der Nachteil, dass der Benutzer nicht darüber informiert werden
kann, dass sich ein bestimmter Messwert in einem kritischen Bereich bendet (z.B. zu niedrige
Temperatur), falls die mobile Applikation zu diesem Zeitpunkt nicht läuft.

Ein weiterer Nachteil ergibt sich durch die Limitierung der Anzahl der gleichzeitigen Verbindungen mit dem KNX/IP-Router, welche von der verwendeten Variante abhängt (Routing oder
Tunnelling). Da die Variante des Tunnelling verwendet wurde, kann gleichzeitig nur ein Benutzer
eine Verbindung mit dem KNX/IP-Router herstellen.
3.2.3. Mögliche Lösungen
Grundsätzlich wurden zwei verschiedene Varianten der direkten Kommunikation analysiert. Bei beiden handelt es sich um APIs, die die Kommunikation mit dem Bus über das KNXnet/IP-Protokoll
ermöglichen.
Seite 35 von 91
Diplomarbeit KNXApp
1 heruntergeladen, welche diese
Auÿerdem wurde zu Testzwecken eine App aus dem Google-Play-Store
Variante der Kommunikation nutzt. Ob überhaupt eine bzw. welche Bibliothek bei dieser App für den
Zugri auf den Bus verwendet wurde, konnte leider nicht herausgefunden werden.
Calimero
Calimero wurde erstmals auf der KNX Scientic Conference 2005 vorgestellt und wird von der Fakultät
für Automatisierungssysteme der Technischen Universität Wien entwickelt. Dabei handelt es sich um
eine Open Source Java-Bibliothek, die den Zugri auf den KNX-Bus über das KNXnet/IP-Protokoll
auf einer höheren Abstraktionsebene ermöglicht und somit Protokolldetails vor dem Programmierer
'versteckt'. Die aktuelle Version ist die Version 2, welche auch als Calimero-Next-Generation bezeichnet
wird.
Für die Vorführung beim Tag der oenen Tür des Schulzentrums Ybbs wurde mit Hilfe der CalimeroBibilothek eine kleine Android-App zur Demonstration der Steuerung von KNX-Geräten mittels Tablet
entwickelt. Die App ermöglichte das Schalten sowie das Dimmen von Lampen der Testumgebung.
Falcon
Bei Falcon SDK handelt es sich um ein SDK, das einen vereinfachten Zugri auf den KNX-Bus ermöglicht. Falcon wird von der oziellen KNX-Organisation entwickelt.
Da zum Testzeitpunkt bereits die Entscheidung getroen wurde, dass die Kommunikation über einen
Server erfolgt, wurde das Falcon SDK nicht näher analysiert.
3.3. Kommunikation mittels Server
Bei dieser Variante erfolgt die Kommunikation zwischen App und Bus nicht direkt, sondern über einen
dazwischenliegenden Server. Abbildung 3.11 veranschaulicht diese Variante der Kommunikation.
Abbildung 3.11.: Aufbau bei der Kommunikation mittels Server
1
Früher Android-Market - https://play.google.com/store?hl=de
Seite 36 von 91
Diplomarbeit KNXApp
3.3.1. Vorteile

Durch einen dazwischenliegenden Server wird eine zusätzliche Abstraktionsschicht hinzugefügt,
welche die Transparenz für den Programmierer deutlich erhöhen und somit die Kommunikation
mit dem Bus erheblich vereinfachen kann.

Da der Server permanent läuft, ist es auch möglich, den Bus ständig zu überwachen, um mögliche
Ereignisse zu protokollieren sowie zeitliche Verläufe von beliebigen Daten (z.B. Temperaturverlauf, Feuchtigkeitsverlauf, . . . ) erstellen zu können.

Weiters gibt es dadurch (theoretisch) keine begrenzte Anzahl an gleichzeitigen Verbindungen, da
sich beliebig viele Benutzer mit dem Server verbinden können, während zwischen Server und Bus
jedoch weiterhin nur eine einzige Verbindung besteht.
3.3.2. Nachteile

Durch den Umstand, dass der Server immer aktiv sein muss, ergibt sich der Nachteil einer zusätzlichen Kompontente gegenüber ersterer Variante.

Ein weiterer Nachteil ergibt sich durch die Abhängigkeit vom Server, da ein Ausfall bzw. sonstige
technische Probleme eine Nicht-Verfügbarkeit des Busses für den Benutzer zur Folge haben. Es
besteht also ein Single-Point-of-Failure bei dieser Variante.
3.3.3. Lösung
Bei dieser Variante wurde nur eine mögliche Lösung analysiert.
European Installation Bus Daemon (EIBD)
Der EIBD ist ein Server, der eine Schnittstelle zum KNX-Bus darstellt. Er ermöglicht die Kommunikation mit dem Bus über verschiedene physikalische Schnittstellen, darunter USB sowie KNXnet/IP (sowohl Tunneling als auch Routing) und andere. Die Kommunikation mit dem Bus erfolgt über TCP/IP
und/oder UNIX-Domain-Sockets. Auÿerdem ermöglicht der EIBD mehrere gleichzeitige Benutzer und
beinhaltet einen eigenen Busmonitor, welcher mit dem Namen vBusmonitor bezeichnet wird. Dieser
ermöglicht das protokollieren von sämtlichem Trac, der vom EIBD weitergeleitet wird.
3.3.4. Fazit
Die Vor-und Nachteile der beiden Varianten wurden miteinander verglichen und basierend auf den
Anforderungen wurde eine entsprechende Auswahl getroen. Zu Beginn wurde zwar auch die direkte
Kommunikation mittels Calimero in Erwägung gezogen, jedoch el die schlussendliche Entscheidung
auf die Variante mit einem dazwischenliegenden Server. Der ausschlaggebene Grund dafür war die Möglichkeit, sämtlichen Bus-Trac aufzeichen zu können, wodurch die Erstellung von beliebigen Verläufen
sowie das Protokollieren von (mitunter kritischen) Ereignissen ermöglicht wird.
Seite 37 von 91
Diplomarbeit KNXApp
3.4. Auswahl der Datenbank
Zum Speichern der Applikationsdaten ist es erforderlich eine Datenbank einzusetzen. Hierbei musste
eine entsprechende Datenbank gefunden werden, die die Anforderungen erfüllt. Die Datenbank soll die
Applikationsdaten speichern und ein einfacher Zugri auf die Datenbank soll ebenfalls möglich sein.
Eine weitere Anforderung ist es, dass auf die Datenbank auch mittels Android zugegrien werden kann.
5
Zu Beginn wurde in Erwägung gezogen, eine sogenannte SQLite -Datenbank zu verwenden. SQLite
ist eine File-basierte Open-Source Datenbank und grundsätzlich bietet jedes Android-Gerät Unterstützung für SQLite. Ein Vorteil dieser Datenbank ist der nur sehr geringe Speicherbedarf (einige 100 KB).
Der groÿe Nachteil bei der Verwendung dieser Datebank wäre jedoch die Tatsache, dass jedes Gerät seinen eigenen Datenstand haben würde. Das bedeutet, dass z.B. alle Stockwerke, Räume, Geräte,. . . auf
jedem weiteren Gerät erneut hinzugefügt werden müssten. Auf Grund dieses enormen Nachteils wurde
entschieden, eine serverbasierende Datenbank zu verwenden.
3.4.1. Fazit
6
Die eingesetzte serverbasierte Datenbank war MySQL . Diese Datenbank wurde verwendet, da bereits
gute Kenntnisse im Umgang mit diesem Datenbanksystem vorhanden waren. Zusätzlich ergab sich
durch den Einsatz der Distribution OpenSuse der Vorteil einer einfachen Installation und Konguration
eines MySQL-Servers.
7 wichtigen Daten der Applikation in der Datenbank abgelegt.
Grundsätzlich werden fast alle
3.5. Auswahl des mobilen Betriebssystems
Zu Beginn sollte die Applikation sowohl für Apple's mobiles Betriebssystem iOS als auch für Android
entwickelt werden. Da eine parallele Entwicklung für zwei verschiedene Systeme jedoch einen zu hohen
Aufwand mit sich gebracht hätte, wurde in Absprache mit den Betreuern entschieden, sich auf ein
System zu beschränken.
3.5.1. Fazit
Auf Grund guter Vorkenntnisse sowie eines von der Schule zur Verfügung gestellten Android-Testsystems
wurde gemeinsam mit den Betreuern entschieden, die mobile Applikation für das mobile Betriebssystem
Android zu entwickeln.
5
6
7
http://www.sqlite.org/
http://www.mysql.de/
ausgenommen: Einstellungen und Linknx-Geräte
Seite 38 von 91
Diplomarbeit KNXApp
4. Realisierung Server
In diesem Kapitel wird die Installation sowie die Konguration des Servers beschrieben.
Anhand der Netzwerkskizze in Abbildung 4.1 soll der Aufbau des Systems visualisiert und erklärt
werden.
Abbildung 4.1.: Netzplan des Systems
Im Netzplan können alle relevanten Serverdienste eingesehen werden. Zusätzlich kennzeichnen Pfeile
die Kommunikation zwischen den einzelnen Komponenten. Aus der Abbildung 4.1 kann abgelesen
werden, wie die Kommunikation zwischen den einzelnen Komponenten abläuft. Nachfolgend werden
die einzelnen Komponenten des Servers beschrieben sowie Startskripts, Sensordatenverläufe und der
Einsatz einer Webcam erklärt. Das Datenbankschema wird ebenfalls in diesem Abschnitt erklärt.
Seite 39 von 91
Diplomarbeit KNXApp
4.1. Server Komponenten
Aufgrund der Wahl einer Serverlösung musste im ersten Schritt ein Server konguriert werden. Zu
beachten ist, dass die Firewallregeln angepasst werden müssen, da ansonsten Kommunikationsprobleme
auftreten. Die Testumgebung bietet folgende Hard- bzw. Softwarekomponenten:
Hardware
In Tabelle 4.1 sind die Komponenten der verwendeten Hardware aufgelistet:
Komponente
Hersteller und Modell
Rechner
Lenovo T60
Prozessor
Intel(R) Core(TM)2 CPU 2 x 1.66 GHz
Arbeitsspeicher
2 GB
Grakkarte
ATI Mobility Radeon X1300
Festplattenspeicher
80 GB
Webcam
Microsoft LifeCam VX-1000
Tabelle 4.1.: Hardwarekomponenten
Software
In Tabelle 4.2 sind alle Softwarekomponenten aufgelistet:
Komponente
Produkt
Version
Betriebssystem
OpenSuSE
Webserver
Apache
2.2.12
Datenbankserver
MySQL
5.0.8
Schnittstelle zu KNX-Bus
eibd
0.0.5
XML-Server zur Busvisualisierung
linknx
12.1
0.0.1.28
Tabelle 4.2.: Softwarekomponenten
4.2. Installation Server
In diesem Abschnitt wird erläutert, wie die Installation des Servers funktioniert bzw. was zu beachten
ist, um eine Busverbindung herzustellen.
Betriebssystem
Als Betriebssystem wurde die Linux-Distribution OpenSuSE 12.1 verwendet.
Bei der Installation wurden 2 Partitionen angelegt:
ext4 : 70.00 GB
SWAP : 3.00 GB
Seite 40 von 91
Diplomarbeit KNXApp
Die weitere Installation des Betriebssystems wurde standardmäÿig durchgeführt.
Webserver Apache
Als Webserver wurde Apache verwendet. Der Webserver wird benötigt, um in der App die Sensordatenverläufe anzuzeigen. Zusätzlich wird er auch dazu verwendet, um mittels eines php-Skripts
die Datenbankanbindung herzustellen und das Datenbankschema zu verwalten.
Das verwendete Softwarepaket heiÿt apache2.
Datenbankserver MySQL
Um die Konguration von den Stockwerken und den Räumen bzw. die aktuellen Sensordaten
zu speichern, ist eine Datenbank nötig. Hierbei ist es erforderlich, eine MySQL-Serverdatenbank
zu installieren und kongurieren.
Um MySQL nutzen zu können, muss das Paket mysql installiert werden. Nach erfolgreicher Installation muss der Dienst über den Befehl
mysql_secure_installation eingerichtet werden.
Da die Konguration des MySQL-Servers über die Konsole aufwändig und kompliziert ist, kann
das Paket phpMyAdmin installiert werden. Dieses Service kann nach erfolgreicher Installation
über den Browser aufgerufen werden und bietet danach eine Oberäche zur Konguration des
Datenbankservers.
Abbildung 4.2 zeigt die Oberäche von phpMyAdmin:
Abbildung 4.2.: Oberäche von phpMyAdmin
Seite 41 von 91
Diplomarbeit KNXApp
eibd
Die Verbindung zum Bus wird über den eibd hergestellt. Um die Software installieren zu können,
sind einige Pakete im Voraus zu installieren:
pthsem
m68hc05
bcusdk
Diese Pakete werden von der Technischen Universität auf der Homepage www.auto.tuwien.at/ mkoeg-
ler/index.php/bcusdk zur Verfügung gestellt.
Da diese Pakete kompiliert werden müssen, ist das Paket gcc zusätzlich zu installieren. Die Pakete
müssen genau in der Reihenfolge, wie sie gelistet sind, installiert werden, da manche Abhängigkeiten von den vorigen Paketen installiert werden.
Das Paket m68hc05 benötigt zusätzlich die Pakete patch, bison und ex.
Alternativ kann auch in einer OpenSuSE-Distribution im Software-Manager das BCU SDK Repositories hinzugefügt werden. Die Repositories lauten:
http://www.auto.tuwien.ac.at/∼mkoegler/rpm/opensuse
http://www.auto.tuwien.ac.at/∼mkoegler/rpm/opensuse10.3
Danach ist eine einfache Installation über den Paket-Manager Yast möglich.
Linknx
Linknx ist ein XML-Server, der die Kommunikation mit dem Bus vereinfacht und überwacht.
Um linknx installieren zu können, müssen einige Pakete vorinstalliert werden:
libmysql-client und libmysql-client-devel
Durch diese Pakete hat linknx die Möglichkeit auf die MySQL-Datenbank zu schreiben bzw.
zu lesen.
gcc-c++
Dieses Paket wird benötigt, um die C++-Files zu kompilieren.
libesmtp und libesmtp-devel
Wenn linknx mit E-Mail support installiert werden soll, werden diese Pakete benötigt.
lua und lua-devel
Die lua-Pakete werden benötigt, um lua-scripting für linknx zu aktivieren. Lua-Scripting
wird benötigt, um Kommandozeilenbefehle mittels linknx auszuführen.
Wenn diese Pakete installiert wurden, kann linknx kompiliert werden.
1
2
3
4
5
./ configure -- enable - smtp -- with - libcurl
-- with - mysql =/ usr / bin / mysql_config
make
make install
make check
Die Installation von linknx, und vor allem die Installation der optionalen Features kann durch den
Befehl linknx -V überprüft werden. Bei folgendem Output ist die Installation mit allen optionalen
Features erfolgreich gewesen:
Seite 42 von 91
Diplomarbeit KNXApp
1
2
3
4
linknx 0.0.1.30
- E - Mail gateway enabled
- MySQL support enabled
- LUA scripting support enabled
RRDtool
RRDTool wurde ursprünglich von Tobias Oetiker entwickelt, und ist unter der GNU General
Public License (GPL) lizenziert. Heute sind viele weitere Personen an der Entwicklung/Fehlerbehebung beteiligt. RRDTool ist für viele verschiedene Betriebssysteme verfügbar. Die Abkürzung
RRD steht für Round-Robin-Database, das heiÿt das die Daten in periodischen Abständen abgefragt werden und danach in eine Datenbank gespeichert werden.
Folgende Komponenten werden für RRDTool benötigt
eibd
linknx
perl
webserver (apache)
Das RRDTool selbst kann mit Hilfe eines Paketmanagers oder auf der oziellen Homepage
(http://oss.oetiker.ch/rrdtool/ ) heruntergeladen werden.
Zusätzlich zum RRDTool wurde ein Perl Modul dazu installiert. Hierbei wurde der Perl Package
1 benutzt. Um auch einen Datenbankzugri mittels Perl-Skripts herstellen zu
Manager CPAN
können, muss das Modul DBI installiert werden.
1
2
3
4
5
6
perl - MCPAN -e shell
install Bundle :: CPAN
reload cpan
install Error :: RRDs
install DBI
install DBD :: mysql
Nachdem die Pakete und Module installiert wurden, können die perl-Skripts zur Sensordatenauswertung richtig ausgeführt werden.
4.3. Konguration Server
Apache und MySQL-Server
Der Apache und der MySQL-Server sind standardmäÿig zu kongurieren und zu starten.
Wichtig hierbei ist es, dass das php-Skript zum Anlegen der Tabellenschemata im Webroot
Verzeichnis des Apache liegt, sodass das App darauf zugreifen kann.
1
Comprehensive Perl Archive Network (CPAN) ist ein Online-Repository für Perl-Module und Anwendungen
Seite 43 von 91
Diplomarbeit KNXApp
eibd
Die Busverbindung wird über das KNX/IP-Gateway hergestellt. Dieses Gateway kann mit Hilfe
der Programmiersoftware ETS eine IP-Adresse erhalten.
Der eibd ist auch in der Lage, eine Verbindung über USB oder serielle Verbindung aufzubauen.
Tabelle 4.3 zeigt die von EIBD verwendeten Ports und wozu diese verwendet werden:
Protokoll
Kongurationsport
Lese Port
Schreib Port
TCP oder UDP
6720
3671
3672
Tabelle 4.3.: Ports des eibd
Beim Starten des eibd sind die Portangaben aus der Tabelle standardmäÿig voreingestellt. Diese
sind jedoch veränderbar und können mit den entsprechenden Optionen beim Starten des eibd
angepasst werden. Mit folgendem Befehl kann der eibd gestartet werden:
1
eibd -d -i ipt : < IP - Adresse vom KNX /IP - Gateway >:3671 &
Optionen:
-d, daemon[=FILE]
eibd wird als Daemon gestartet und läuft als Prozess im Hintergrund
-i, listen-tcp[=PORT]
eibd hört auf gewissen TCP port (standardmäÿig 6720, wenn kein spezischer Port angegeben wird)
ipt:router-ip[:dest-port[:src-port[:nat-ip[:data-port]]]]
eibd verbindet sich mit dem KNX/IP-Router unter der Verwendung des KNX/IP Tunneling
Protokolls
Sobald der eibd erfolgreich gestartet wurde, können mittels groupswrite bzw. groupsread Busgeräte gesteuert oder deren Werte ausgelesen werden.
1
groupswrite ip : localhost 1/2/3 1
Dieser Befehl sendet den Wert 1 an die Gruppenadresse 1/2/3, was zum Beispiel das Anschalten
einer Lampe veranlässt.
Der eibd liefert auch einen Busmonitor mit, der alle Aktivitäten am Bus aufzeichnet. Mit dem
Befehl busmonitor1 ip:localhost kann dieser in einer Shell gestartet werden.
Seite 44 von 91
Diplomarbeit KNXApp
linknx
Die Konguration von linknx ist in einer XML-Datei gespeichert.
Die allgemeinen Informationen, sowie der Aufbau der Software, basiert auf der Dokumentation
von linknx.[20] Diese XML-Datei gliedert sich grundsätzlich in drei Teile:
services
objects
rules
Im Folgenden werden die einzelnen Abschnitte erklärt. Alle Teile werden von einem cong-Tag
umschlossen.
service
In diesem Abschnitt werden alle Dienste deniert. Beispielsweise auf welchem Port der
linknx-Server läuft, oder wie das E-mail-Gateway konguriert wird. Hier wird auch die Verbindung mit dem eibd hergestellt (knxconnection). Zusätzlich wird in diesem Abschnitt
deniert, wo linknx die log-Daten und die persist-Daten speichert. Hierbei gibt es die Möglichkeit dies in ein File zu schreiben oder in eine Datenbank zu speichern.
1
2
3
4
< xmlserver type =" inet " port ="1028" / >
< knxconnection url =" ip :127.0.0.1" / >
< persistence type =" mysql " host ="127.0.0.1" user =" root "
pass =" passwd " db =" knx " table =" persist " logtable =" log " / >
Das Beispiel zeigt die Denition vom XML-Server und das dieser auf Port 1028 gestartet
wird. Die knxconnection deniert, wo der eibd läuft, in diesem Fall läuft er am selben System,
also localhost. Das persistence-Tag deniert wo linknx die anfallenden Daten loggen soll, in
diesem Fall werden die Daten in einer MySQL-Datenbank abgelegt und danach werden die
Verbindungsdaten zum MySQL-Server angegeben.
objects
Die Objekte, die in diesem Abschnitt angelegt werden, können alle KNX-fähigen Geräte
sein. Mit dem type-Tag wird der KNX-Datentyp deniert. Die verfügbaren KNX Daten-
2 von KNX nachgelesen werden. Zusätzlich wird auch
typen können in der Dokumentation
noch für jedes Objekt eine Id festgelegt, die in der linknx Konguration eindeutig ist. Jedes
Objekt muss zusätzlich noch eine Gruppenadresse besitzen.
1
< object type ="1.001" id =" blau_on_off " gad ="1/1/0" > blaue lampe </ object >
Das Beispiel zeigt die Denition von einem Objekt. Es werden KNX-Datentyp, Id und
Gruppenadresse sowie Name des KNX-Gerätes deniert.
rules
In diesem Abschnitt können verschiedene Regeln deniert werden. Jede Regel besteht grundsätzlich aus
2
http://www.knx.org/at/knx-standard/how-to-order/
Seite 45 von 91
Diplomarbeit KNXApp
*
einem Zustand
*
einer Aktion, die ausgeführt wird, wenn ein bestimmter Zustand eintrit. (optional)
*
einer Aktion, die ausgeführt wird, wenn ein bestimmter Zustand nicht eintrit. (optional)
Anhand eines Beispiels wird nun erklärt, wie eine Regel aussehen kann.
1
2
3
4
5
6
7
8
9
< rule id =" alarm - detect " >
< condition type =" and " >
< condition type =" object " id =" blau_on_off " value =" on " trigger =" true "/ >
</ condition >
< actionlist >
< action type =" cycle -on - off " id =" red_on_off " on ="1" off ="1" count ="10" / >
</ actionlist >
< rule >
</ rules >
Die Regel wird ausgeführt, wenn die Lampe mit der Id blau_on_o eingeschaltet wird.
Die Aktion, die dann ausgeführt wird, schaltet die Lampe mit der Id red_on_o 10 mal
zyklisch ein und aus. Dies soll einen Alarm simulieren.
Um die Features zum Loggen und zum Speichern der aktuellen Sensorwerte in die Datenbank zu
aktivieren, werden 2 Tabellen benötigt. Die Tabelle log speichert alle Änderungen von Objekten,
für die in der XML-Datei log=true angegeben wurde. Die Tabelle persist speichert den aktuellen
Wert eines Objektes, für das in der XML-Datei init=persist angegeben wurde. Beide Tabellen
werden beim Start der Applikation automatisch angelegt.
Wurden nun alle Kongurationsschritte durchgeführt, kann linknx gestartet werden:
1
linknx -- config = < PATH - TO - CONFIG > -w -d
Die Optionen beim Starten werden nachfolgend etwas detaillierter beschrieben:
-c, -cong[=FILE]
Gibt den Pfad zum linknx Kongurationsle(XML-Datei) an. Wird diese Option nicht angegeben, so wird im Standardverzeichnis nach der linknx.xml gesucht (/var/lib/linknx/).
-w, write[=FILE]
Hier wird die Konguration bei einer Änderung durch linknx auch in der Kongurationsdatei selbst verändert. Wird bei dieser Option kein Filename angegeben, so wird die vorher
angegebene Kongurationsdatei überschrieben.
-d, daemon[=FILE]
Diese Option startet linknx als Daemon und loggt die Ausgabe in einer Datei mit, wenn
diese angegeben wird.
RRDtool
Für die Sensoren werden mittels des RRDtools Verläufe erstellt. Für diese Verläufe müssen folgende Verzeichnisse am Server erzeugt werden:
Seite 46 von 91
Diplomarbeit KNXApp
mkdir ∼/knxapp
In diesem Unterordner des Home-Verzeichnisses werden später die Perl-Skripts und die
RRDtool-Datenbanken abgelegt.
mkdir ∼/knxapp/rrd
Dieses Verzeichnis wird benötigt, um die Perl-Skripts abzulegen.
mkdir ∼/knxapp/rrdDB
In diesem Verzeichnis ist die RRDtool-Datenbank gespeichert.
4.4. Startskripts
Für die Programme eibd und linknx wurden Startskripts erstellt. Startskripts ermöglichen ein einfaches
Starten und Stoppen der Programme. Für die Erstellung von Startskripts bietet es sich an, eine Vorlage zu verwenden, die skeleton genannt wird. In dieser Datei können alle Abschnitte eines Startskripts
beispielhaft eingesehen werden.
In einer OpenSuSE Distribution bendet sich die skeleton Datei in /etc/init.d/.
Im Folgenden wird das Startskript des eibd erklärt. Das Startskript für linknx ist analog zu dem
vom eibd.
Das Startskript beginnt mit einem Kommentarblock. Dieser Kommentarblock wird vom Paketmanager
YAST gelesen. Der Kommentarblock beginnt mit BEGIN INIT INFO und endet mit END INIT INFO.
In diesem Kommentarblock wird deniert, wie das Service heiÿt, was das Service vor dem Starten benötigt usw. Weiters werden die Runlevel deniert, in welchem das Skript gestartet wird. Die Runlevels
können je nach Distribution unterschiedlich sein. Nähere Informationen zu den Runlevels in OpenSuSE
3 nachgelesen werden.
können in einer Dokumentation
1
2
3
4
5
6
7
8
9
#! / bin / sh
### BEGIN INIT INFO
# Provides : eibd_knxapp
# Required - Start : $network
# Required - Stop :
# Default - Start :3
# Default - Stop :0 6
# Description : starts the eibd
### END INIT INFO
In den nächsten Zeilen werden globale Variablen deniert, die je nach System und Konguration
abgeändert werden müssen. Die IPADDRESS Variable gibt die IP-Adresse des KNX/IP-Routers an.
1
2
3
# SET GLOBAL VARIABLES
EIBD =/ usr / bin / eibd
IPADDRESS =10.0.0.10
Das Skript testet zusätzlich, ob der eibd installiert ist. Ist der Test negativ, so wird das Skript beendet.
Durch die Implementierung des Status-Skripts sind die Ausgaben des Skripts farbig, und entsprechen
den Ausgaben von anderen Skripten (z.B. Startskript des Apache).
1
3
# TEST INSTALLATION OF EIBD
http://www.linuxtopia.org/online_books/opensuse_guides/opensuse11.1_reference_guide/sec_boot_init.
html
Seite 47 von 91
Diplomarbeit KNXApp
2
3
4
5
6
7
test -f / usr / bin / eibd || exit 0
# Include the status script and
# clear its status
. / etc / rc . status
rc_reset
Der folgende Code ist nun das eigentliche Skript. Es wird der erste Parameter gelesen und je nachdem
welche Optionen angegeben wurden, darauf reagiert. Die verfügbaren Optionen sind start, stop, restart
und status. Wird dem Skript kein Parameter übergeben, so wird eine Fehlermeldung ausgegeben.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
case " $1 " in
start )
echo " start eibd "
eibd -d -i ipt : $IPADDRESS
# find PID of eibd and store it
pidof eibd > / var / run / eibd . pid
rc_status -v
;;
stop )
echo " stop eibd "
/ bin / kill -9 $ ( cat / var / run / eibd . pid )
# delete pid file
rm / var / run / eibd . pid
rc_status -v
;;
restart )
echo " restart eibd "
$0 stop
$0 start
rc_status
;;
status )
echo -n " checking for eibd "
checkproc $EIBD
rc_status -v
;;
*)
echo " Usage : $0 { start | stop | restart | status }"
exit 1
;;
Bei der Erstellung von Shell-Skripts muss besonders darauf geachtet werden, welche Rechte diese Datei besitzt. Das Ausführungsrecht(x ) ist hierbei essentiell, da ansonsten kein User das Shell-Skript
ausführen kann.
Wurden die Rechte richtig vergeben, und das Skript ist ausführbar, so kann das Skript über die Kommandozeile aufgerufen werden.
1
/ etc / init . d / eibd_knxapp start | stop | restart | status
Wenn das Skript nun beim Hochfahren des Server gestartet werden soll, sind noch weitere Schritte
einzuleiten. Hierbei sind zwei Varianten möglich. Entweder man aktiviert das Skript mittels Yast
(System -> System Services(Runlevel)), oder man aktiviert das Skript mittels folgendem Befehl:
1
chkconfig -a eibd_knxapp
Seite 48 von 91
Diplomarbeit KNXApp
Nun sollte das Skript beim Start des Systems automatisch ausgeführt werden.
Für die Implementierung einer Webcam wurde ebenfalls ein Startskript erstellt, das dazu dient, regelmäÿig Aufnahmen von der Webcam zu machen und diese danach in ein angegebenes Verzeichnis zu
kopieren.
4.5. Sensordatenverläufe
Wie schon erwähnt werden mit Hilfe von Perl-Skripts und dem RRDtool Sensordatenverläufe erstellt.
Diese werden danach mit Hilfe eines cronjobs periodisch ausgeführt.
Perlskript zum Erstellen der Sensordatenverläufe
Es werden drei verschiedene Perl-Skripts angeboten, die jeweils Diagramme von
Temperatur,
Feuchtigkeit oder
Stromwert
erstellen.
Die Perlskripts müssen in den vordenierten Ordner (∼/knxapp/rrd) kopiert werden. Zusätzlich müssen die Perlskripts so abgeändert werden, sodass ein richtiges Ausführen des Skripts
möglich ist.
Anhand des Temperatur-Perl-Skripts (rrdtemp.pl ) werden nun die Variablen erklärt, die geändert
werden müssen.
1
2
3
4
5
6
7
my
my
my
my
my
my
my
$user = " root ";
$password = ' Abcd1234 ';
$db = 'knx ';
$host = '127.0.0.1 ';
$deviceID = ' temp_val ';
$DB = "/ home / knxapp / knxapp / rrdDB /". $deviceID .". rrd ";
$PIC = "/ srv / www / htdocs / sensoren /". $deviceID .". jpg ";
Bedeutung der Variablen:
user: Datenbankuser
password: Passwort des Datenbankusers
db: Datenbank, wo die Tabellen log und persistent erstellt wurden
host: IP-Adresse bzw. Hostname des Datenbankservers
deviceID: die ID, die in linknx für den Temperatursensor verwendet wird
DB: Pfad zur RRDtool-Datenbank (wird beim erstmaligen Starten automatisch angelegt)
PIC: Pfad zum Webroot des Webserver (Ordner muss dort existieren)
Dieses Perlskript kann nach der Änderung der Variablen erfolgreich ausgeführt werden.
Seite 49 von 91
Diplomarbeit KNXApp
Periodisches Ausführen der Skripts mittels cronjob
Um die aktuellen Daten der Sensoren ständig verarbeiten zu können, ist es sinnvoll, dies automatisch mittels eines cronjobs durchzuführen. Der cronjob kann mit crontab -e bearbeitet werden.
Dort kann auch eingestellt werden, wie oft das Skript ausgeführt werden soll. Zu beachten ist,
dass der Dienst cron korrekt am System läuft.
1
*/1
*
*
*
*
perl / home / knxapp / knxapp / rrd / rrdtemp . pl - ug
In diesem Beispiel wird das Skript jede Minute ausgeführt. Die Option u wird dazu verwendet
um die RRDtool-Datenbank zu aktualisieren, die Option g zeichnet den Temperaturverlauf neu
und speichert ihn.
aufgezeichnete Sensordatenverläufe
Die abgebildeten Sensordatenverläufe wurden während der Arbeit dokumentiert und aufgezeichnet. Die Abbildungen 4.3, 4.4 und 4.5 zeigen die Verläufe der verschiedenen Sensoren.
Abbildung 4.3.: Temperaturverlauf
Seite 50 von 91
Diplomarbeit KNXApp
Abbildung 4.4.: Feuchtigkeitsverlauf
Abbildung 4.5.: Stromverlauf
Seite 51 von 91
Diplomarbeit KNXApp
4.6. Webcam
Bei der Realisierung des Projektes wurde auch eine Webcam eingesetzt. Eine Webcam kann beispielsweise im Eingangsbereich eines Hauses eingesetzt werden, und dient als Überwachungskamera. Für die
Implementierung der Webcam ist es nötig, dass die Webcam ein Bild speichert. Die getesteten Bild-
4 und PNG5 . Die Bilder müssen über einen Webserver zugänglich gemacht werden,
formate sind JPEG
sodass die mobile Applikation darauf zugreifen kann.
In der Testumgebung wurde eine Microsoft LifeCam VX-1000 eingesetzt und installiert. Diese Webcam kann Bilder in einer Auösung von 640x480 Pixel aufnehmen. Schlieÿt man die USB-Webcam an
den Server an, so kann mittels lsusb überprüft werden, ob die Webcam richtig erkannt wurde.
1
Bus 002 Device 002: ID 045 e :00 f7 Microsoft Corp . LifeCam VX -1000
Liefert die Ausgabe des Befehls die angeschlossene Webcam, so kann davon ausgegangen werden, dass
die Webcam richtig erkannt wurde. Hierbei kann noch überprüft werden, ob das Gerät /dev/video0
verfügbar ist.
Die Bilder werden von der Webcam mit dem Programm streamer aufgenommen. Dieses Tool kann
mittels Yast installiert werden, oder frei heruntergeladen werden.
Um ein einfaches JPEG-Bild aufzunehmen, kann folgendes Kommando verwendet werden:
1
streamer -c / dev / video0 -o / srv / www / htdocs / webcam . jpeg -q
Dieser Befehl speichert ein JPEG-Bild in das Webroot-Verzeichnis des Servers. Die einzelnen Optionen
des Programmes, die eingesetzt wurden, werden nun erläutert.
-c device
Deniert das v4l
6 Gerät. Standardmäÿig wird hier das Gerät /dev/video0 verwendet.
-o lename
Diese Option wird benötigt, um die Ausgabe, also das JPEG-Bild im entsprechenden Ordner zu
speichern.
-q
Wird diese Optionen eingesetzt, so liefert das Programm keinen Output (quiet ).
4
Joint Photographic Experts Group
Portable Network Graphics
6
video for linux
5
Seite 52 von 91
Diplomarbeit KNXApp
Um das Bild ständig zu aktualisieren, wurde ein Skript entwickelt, welches jede Sekunde ein neues
Bild aufnimmt. Dieses Skript besteht aus einer Endlosschleife, die bei jedem Durchlauf ein Bild mittels streamer aufnimmt und danach wird das Skript eine Sekunde pausiert, bevor es wieder ein Bild
aufnimmt.
1
2
3
4
5
6
#!/ bin / bash
while true
do
streamer -c / dev / video0 -b 16 -o / srv / www / htdocs / webcam . jpeg -q
sleep 1
done
Das Programm streamer bietet die Möglichkeit Videos oder Filme in verschiedenen Formaten aufzunehmen. Weiters kann das Programm auch Audiodateien aufnehmen.
Während der Entwicklungsphase wurde die Webcam dazu eingesetzt, um das Testboard zu überwachen. Die Position der Webcam wurde so gewählt, dass die Lampen des Testaufbaues sichtbar waren.
Somit konnte jederzeit überprüft werden, ob ein Schaltvorgang erfolgreich war. Dies brachte einen
erheblichen Vorteil, da somit das Testboard x installiert werden konnte und die Entwicklung unabhängig vom Standort des Testboards möglich war.
In Abbildung A.5 ist eine Bildaufnahme der Webcam zu sehen:
Abbildung 4.6.: Aufnahme der Webcam
Seite 53 von 91
Diplomarbeit KNXApp
4.7. Datenbanksystem
Die Datenbank enthält sieben Tabellen. Das Erstellen des Datenbankschemas erfolgt, bei Bedarf, automatisch beim Start der Applikation, da die nötigen Tabellen über das php-Skript angelegt werden.
Folgende Tabellen werden vom php-Skript angelegt:

devices

oors

rooms

room_expand

webcams

log

persist
Die Struktur sowie der Aufbau der Tabellen werden im Anhang erklärt.
In Abbildung 4.7 ist das gesamte Datenbankmodell mit allen Tabellen und deren Attributen sowie
Beziehungen zu sehen:
Abbildung 4.7.: Datenbankmodell
Seite 54 von 91
Diplomarbeit KNXApp
4.8. Fazit
Die eingesetzte Hardware hat, bei richtiger Programmierung, während der Testphase einwandfrei funktioniert. Der Server mit der installierten Linux-Distribution wurde ebenso über einen längeren Zeitraum
getestet. Bei den installierten Programmen für die Buskommunikation (eibd und linknx ) konnten keine
Fehler festgestellt werden. Hierbei ist anzumerken, dass die Dokumentation speziell von linknx nicht
ausführlich ist. Mit Hilfe des KNX-User-Forums
7 konnten aber alle Fragen zur Software beantwortet
werden.
8
Bei der Implementierung der Webcam wurden zuerst einige Programme getestet (ZoneMinder , moti-
9
10
on , webcam_server ). Diese erwiesen sich aber als aufwendig zu kongurieren und wurden deshalb
bei der Realisierung nicht verwendet. Die Entscheidung auf das Kommandozeilentool streamer el
deshalb, weil die Bedienung und Konguration einfach ist.
7
http://http://knx-user-forum.de/
http://www.zoneminder.com/
9
http://www.lavrsen.dk/foswiki/bin/view/Motion/WebHome
10
http://webcamserver.sourceforge.net/
8
Seite 55 von 91
Diplomarbeit KNXApp
5. Realisierung mobile Applikation
In diesem Kapitel wird auf alle wichtigen Aspekte sowie grundlegende Dinge der mobilen Applikation
und des verwendeten Systems eingegangen. Zusätzlich soll der Source Code etwas durchleuchtet und
zuletzt die Bedienung der Applikation erklärt werden.
5.1. Android
Einleitend werden allgemeine Dinge über Android geklärt, danach wird speziell auf notwendigen Komponenten sowie die Grundlagen der Entwicklung eingegangen.
5.1.1. Grundlegendes
Android ist ein auf Linux basierendes Betriebssystem für mobile Geräte wie z.B. Smartphones, Tablets,
aber auch Netbooks. Es wird von der Open Handset Alliance unter der Führung von Google entwickelt.
Weiters ist der Source-Code des Android-Systems als Open-Source unter der Apache Lizenz verfügbar.
Im Februar 2012 lag die Anzahl der Aktivierungen pro Tag bereits bei 850.000 Geräten und die Gesamtanzahl der Android-Geräte lag bei 300 Millionen.
Einige der wichtigsten Versionen von Android werden an dieser Stelle aufgelistet. Diese besitzen jeweils
1
eine Versionsnummer sowie einen zugehörigen Codenamen .
2.3 - Gingerbread
Derzeit (April 2012) die meist verbreitetste Android-Version (63.7%)[22]. Einige Funktionen, die
mit dieser Version eingeführt wurden: Copy/Paste-Funktion, verbessertes Software-Keyboard,
2
Unterstützung für NFC , . . . .
3.x - Honeycomb
Speziell für Tablets entwickelt, bietet Unterstützung für Geräte mit gröÿeren Screens. Zusätzlich
wurden mehrere neue User-Interface Features eingeführt sowie Multi-Prozessor Support .
4.x Ice Cream Sandwich
In dieser Version wurden die Versionen für Smartphones (2.x) und für Tablets (3.x) wieder zusammengeführt. Auÿerdem wurden einige Features von Honeycomb übernommen. Neue Features
3
dieser Version sind unter anderen Face-Unlock , Kontrolle des Datenverbrauchs, Datenaustausch
mittels NFC, . . . Die aktuelle für Geräte verfügbare Android-Version ist die Version 4.0.4.
[23]
1
Jeweils benannt nach einem Dessert, in alphabetischer Reihenfolge.
Near Field Communication
3
Entsperren des Geräts mittels Gesichtserkennung
2
Seite 56 von 91
Diplomarbeit KNXApp
Abbildung 5.1 zeigt die Oberäche von Ice Cream Sandwich.
Abbildung 5.1.: Oberäche von Android Ice Cream Sandwich
Einige wichtige Features von Android:
Application framework
Dalvik VM
integrierter Browser
Optimierte Grak-Unterstützung
Medienunterstützung
GSM-Telefonie
Bluetooth, EDGE, 3G und WiFi
Kamera, GPS, Kompass und Beschleunigungssensor
Umfangreiche Entwicklungsumgebung
[24]
Seite 57 von 91
Diplomarbeit KNXApp
Abbildung 5.2 beschreibt die Systemarchitektur von Android.
Abbildung 5.2.: Architektur von Android [24]
Die einzelnen Komponenten dieser Abbildung werden nun aufsteigend etwas detaillierter beschrieben.
Linux Kernel
Android basiert auf dem Linux-Kernel 2.6. Dieser stellt die Kernfunktionen für das System zur
Verfügung. Dazu gehören:
Speicherverwaltung
Prozessverwaltung
Netzwerkkommunikation
Hardware-Treiber
[24]
Libraries
Android inkludiert mehrere in C/C++ geschriebene Bibliotheken, welche vom System verwendet werden. Diese stellen eine Menge von Funktionen bereit, welche den Entwicklern über das
Application Framework zur Verfügung gestellt werden. [24]
Android-Runtime
Die Android-Runtime besteht aus den Kern-Bibliotheken sowie der Dalvik-Virtual-Machine. [24]
Diese wurde speziell für mobile Geräte entwickelt und ist daher besonders ressourcenschonend
und ezient. In Android läuft jede Applikation in einem eigenen Prozess in einer eigenen Instanz
der DVM. Folgende Schritte werden bei der Installation einer Applikation durchgeführt:
Seite 58 von 91
Diplomarbeit KNXApp
Kompilieren von Java-Source-Code in Bytecode
4
Die daraus entstehenden .class -Files werden mit dem sogenannten dx -Tool in sogenannte
5
.dex -Files kompiliert.
[25]
Application Framework
Das Application Framework ermöglicht Entwicklern den vollen Zugri auf APIs, welche von den
Kern-Applikationen genutzt werden. Dabei wurde dieses so entworfen, dass das Austauschen
sowie das Wiederverwenden von bestehenden Komponenten ohne Probleme möglich ist. [24]
Applications
In der obersten Schicht benden sich die Android-Applikationen (Apps), welche in der Programmiersprache Java geschrieben werden. Android wird mit einigen bereits vorinstallierten Applikationen ausgeliefert. (z.B. SMS-App, Kontakte, Kalender, E-Mail-Client, Browser, Google Maps,
. . . ) [24]
5.1.2. Entwicklung
6
Für die Programmierung des KNXApp wurde ausschlieÿlich die Eclipse -Entwicklungsumgebung verwendet, da diese eine komfortable Entwicklung von Android-Applikationen ermöglicht.
Notwendige Komponenten
Folgende Komponenten sind notwendig, um die Android-Entwicklung mit Eclipse zu ermöglichen:
Android SDK7 Starter Package
Dieses beinhaltet nur die sogenannten Android-SDK-Tools, alle weiteren Komponenten müssen
über den Android SDK Manager hinzugefügt werden.
ADT8 -Plugin für Eclipse9
Ein spezielles Android-Plugin für Eclipse. Es ermöglicht eine komfortable Entwicklung von AndroidApplikationen mit Eclipse.
[26]
4
5
6
7
Im Normalfall werden diese von der Java-Virtual-Machine in .java-Files kompiliert
Dalvik Exectucable
http://www.eclipse.org/
Software Development Kit
Android Development Tools
9
Wird nur benötigt, wenn mit Eclipse entwickelt wird
8
Seite 59 von 91
Diplomarbeit KNXApp
Tools
Diese Tools werden mit dem Starter-Package installiert, und beinhalten folgende Komponenten:
Android SDK Manager
Dieser ermöglicht das Herunterladen von (weiteren) Android-Plattform-Versionen, den zugehörigen Tools sowie Add-Ons, Code-Samples, Dokumentationen, . . . . Um entwickeln zu können,
muss zumindest eine Android-Plattform sowie die zugehörigen Tools installiert sein.
Abbildung 5.3 zeigt einen Screenshot des Android SDK-Manager.
Abbildung 5.3.: Android SDK-Manager
Seite 60 von 91
Diplomarbeit KNXApp
Android Virtual Device Manager
Dieses Tool ermöglicht das Verwalten der sogenannten Android Virtual Devices (AVDs), welche
als Kongurationen für den Emulator angesehen werden können. Im AVD-Manager können AVDs
hinzugefügt/gelöscht/editiert und auch gestartet werden. Beim Hinzufügen muss zumindest ein
Name für das Gerät sowie die Android-Version ausgewählt werden (natürlich stehen nur installierte Android-Versionen zur Auswahl). Zusätzlich können noch Parameter wie Auösung, Gröÿe
der SD-Karte und unterstützte Hardware-Komponenten (z.B. GPS) hinzugefügt werden.
In Abbildung 5.4 ist ein Screenshot des Android Virtual Device Manager zu sehen.
Abbildung 5.4.: AVD-Manager
Wurde ein AVD erstellt, kann dieses im Emulator gestartet werden.
Seite 61 von 91
Diplomarbeit KNXApp
Emulator
Der Android Emulator ermöglicht das Ausführen und Testen von Applikationen in einer virtuellen
Umbegung ohne Verwendung eines echten Geräts. Der Emulator hat eine Menge von Funktionen,
dazu gehören unter anderem: das Aufbauen von Netzwerkverbindungen, eine virtuelle Tastatur,
Audio-Unterstützung, Unterstützung von Sensoren wie z.B. Beschleunigungssenoren, GPS, . . . .
[27]
Abbildung 5.5 zeigt die Oberäche des Android-Emulators mit der Version 4.0 .
Abbildung 5.5.: Android Emulator
[27]
5.1.3. Grundlegendes
Nachfolgend werden einige grundlegende Aspekte der Android-Programmierung beschrieben. Dabei wird nur auf selektive Aspekte eingegangen, sowie jene, die bei der Programmierung des
KNXApp von Bedeutung waren.
Activities
Grundsätzlich kann man sagen, dass in Android jede Activity ein eigenes User Interface darstellt.
Weiters existiert für jede Activity eine eigene Android-XML-Datei, in welcher die graschen Elemente einer Activity sowie deren Eigenschaften (z.B. Höhe, Breite, . . . ) deniert werden (können).
Will man auf in XML-Code denierte GUI-Elemente im Java-Code zugreifen, müssen diese zur
Laufzeit instanziiert werden. Natürlich ist es dennoch wie gewohnt möglich, mittels Java-Code die
komplette GUI zu programmieren, es wird jedoch ausdrücklich empfohlen, dies soweit möglich,
mittels XML umzusetzen.
Alle Activities sind unabhängig voneinander und können (falls die Applikation es erlaubt) auch
von anderen Applikationen aufgerufen werden. [28]
Seite 62 von 91
Diplomarbeit KNXApp
Intents
Intents können als Nachrichten angesehen werden und ermöglichen die Kommunikation zwischen
Komponenten in Android. Beispielsweise beim Aufruf einer anderen Activity werden Intents
verwendet. Natürlich ist es auch möglich, zusätzliche Daten (sogenannte Extras ) mit einem Intent
zu übergeben. Weiters ist es zum Beispiel möglich, andere Komponenten des Systems aufzurufen,
zum Beispiel das Senden einer E-Mail aus der eigenen Applikation oder das Aufrufen einer URL
im Browser. [29]
AndroidManifest.xml
Im AndroidManifest.xml werden grundlegende Informationen über die App festgelegt. Diese werden benötigt, sodass die Applikation überhaupt kompiliert werden kann.
Zu den wichtigsten Dingen, die im AndroidManifest.xml angegeben werden müssen, gehören:
Permissions
Alle Berechtigungen, welche die Applikation benötigt müssen hier angegeben werden. Falls
eine App im Play-Store veröentlicht wird, können alle Berechtigungen, die eine App benötigt, vom Benutzer vor der Installation eingesehen werden. Zum Beispiel ist folgende
Berechtigung notwendig, um der Applikation das Aufbauen von Netzwerkverbindungen zu
android.permission.INTERNET
Min. SDK Version
erlauben:
Angabe des minimal erforderlichen API-Levels für die Installation der Applikation, basierend
auf den verwendeten APIs. Für Geräte mit einem niedrigeren API-Level ist die Installation
nicht möglich.
Angabe von Bibliotheken, welche nicht Teil des Android-Frameworks sind. (z.B. Google
Maps Library)
Deklaration aller vorhandenen Activities
Java-Package-Name
Dieser muss bei einem eventuellen Upload in den Play-Store eindeutig sein. Es dürfen also
im gesamten Play-Store nicht mehrere Applikationen mit dem gleichen Java-Package-Name
existieren. Dieser Name muss folgendes Format haben:
com.example.project
Angabe des Icons für die Applikation
u.v.m.
[30]
Seite 63 von 91
Diplomarbeit KNXApp
5.2. Source Code
In diesem Abschnitt wird der Source Code etwas näher beschrieben, wobei besonders auf die wichtigsten Klassen/Methoden genauer eingegangen wird. Ziel ist es, den Source Code etwas zu durchleuchten,
um eine mögliche Erweiterung durch weitere (derzeit nicht am Projekt beteiligte) Entwickler zu vereinfachen. Weiters soll es dadurch auch nicht in die Entwicklung involvierten Personen, die am Source
Code interessiert sind, ermöglicht werden, diesen leichter zu verstehen.
5.2.1. Allgemeines
Als Projektname wurde KNXApp gewählt und als Java Package Name at.knx.htl.
Auÿerdem besitzt das App folgende Permissions:

android.permission.INTERNET
Erlaubt der Applikation, Netzwerkverbindungen aufzubauen.

android.permission.WRITE_EXTERNAL_STORAGE
Erlaubt der Applikation, auf einen externen Speicher (z.B.:SD-Karte) zu schreiben.
Der Source-Code wurde in sechs verschiedene Java Packages aufgeteilt:

activities

dialogs

facade

entities

networking

source
Nachfolgend werden diese Packages mit den zugehörigen Klassen und eventuell wichtigen Methoden/Attributen sowie Schlüsselstellen im Source-Code etwas detailierter beschrieben. Die Reihenfolge,
in der die Packages beschrieben werden, wurde so gewählt, dass die Klassen, welche häug in anderen
Klassen aufgerufen werden, zuerst beschrieben werden.
Seite 64 von 91
Diplomarbeit KNXApp
5.2.2. Networking
In diesem Package benden sich alle Klassen, in denen die eigentliche Kommunikation mit dem LinknxServer stattndet.
Folgende Klassen sind in diesem Package enthalten:

ConnectionToServer

Request

ReadData
Nun folgt eine nähere Beschreibung dieser Klassen:
ConnectionToServer
Diese Klasse dient zum Herstellen der Verbindung mit dem Linknx-Server.
Im Konstruktor können IP-Adresse und Port des Servers übergeben werden. Wichtig ist, dass diese
Klasse von der Klasse Thread erbt, da sämtliche Netzwerkoperationen in Android nicht im sogenannten
UI-Thread ausgeführt werden dürfen, also in einem separaten Thread ausgeführt werden müssen.
Weiters besitzt die Klasse eine Methode connect, welche dann die Verbindung mit dem Server herstellt. Hier ist noch zu erwähnen, dass ein Connection-Timeout von 5000 ms gesetzt wurde. Zum Senden/Empfangen von Daten wurden die Java Klassen PrintWriter
10 und BueredReader 11 verwendet.
Auÿerdem gibt es eine Methode close, welche dazu dient, die Verbindung zu schlieÿen. Diese Methode
wird beim Beenden der App aufgerufen. Zuletzt gibt es noch einige Getter-Methoden
12 , welche den
Reader/Writer sowie den derzeitigen Verbindungsstatus für andere Klassen zur Verfügung stellen.
ReadData
Grundsätzlich ist es die Aufgabe dieser Klasse, Daten vom Linknx-Server zu empfangen. Natürlich
wird auch diese in einem separaten Thread ausgeführt, wobei dieser erst mit der App beendet wird,
da jederzeit Daten vom Linknx-Server empfangen werden können. Im Konstruktor wird der
BueredReader sowie ein eigens denierter Datentyp namens CommandType übergeben. Werden neue
Daten empfangen, so wird zuerst überprüft, um welche Art von Linknx-XML-Message es sich handelt.
Danach wird die Klasse ParseXML zum Parsen der empfangenen Daten aufgerufen.
Request
Diese Klasse dient dazu, mit Hilfe der bereits erwähnten Klasse PrintWriter, einen String an den
Linknx-Server zu senden. Sowohl der zu sendende String als auch der PrintWriter werden im Konstruktor übergeben.
Folgende Code-Zeile soll die Verwendung dieser Klasse verdeutlichen.
1
Request . send ( xmlString , ConnectionToServer . getWriter () ) ;
Als Parameter müssen wie bereits erwähnt der zu sendende String sowie der zu verwendende Print-
Writer übergeben werden.
10
11
12
http://docs.oracle.com/javase/1.4.2/docs/api/java/io/PrintWriter.html
http://docs.oracle.com/javase/1.5.0/docs/api/java/io/BufferedReader.html
Methoden, welche dazu dienen, den Wert eines Attributes zurückzugeben.
Seite 65 von 91
Diplomarbeit KNXApp
5.2.3. Source
Dieses Package beinhaltet alle Klassen, für die es nicht als notwendig empfunden wurde, ein eigenes
Package zu erstellen.

GetData

MyCustomDrawableView

ParseXML

PhpRequest
Nachfolgend wieder eine detailierte Beschreibung der Klassen:
GetData
Diese Klasse stellt einen sehr wichtigen Bestandteil der App dar. Sie wird ebenfalls in einem separaten Thread ausgeführt und besitzt Methoden zum Erstellen der Linknx-XML-Strings, welche an
den Linknx-Server gesendet werden sollen. Dazu wurde ein eigener Datentyp RequestType erstellt, anhand welchem der jeweilige String zusammengesetzt wird. Weiters werden in dieser Klasse die bereits
beschriebenen Klassen Request und ReadData aufgerufen. Diese Klasse sorgt also dafür, dass eine bestimmte Nachricht an den Linknx-Server gesendet wird und dass auch die zugehörige Antwort gelesen
wird. Weiters wird in dieser Klasse beim Start der App die Linknx-Cong gelesen, sowie sogenannte
Linknx-Notications
13 für jedes Gerät hinzugefügt.
Folgender Code-Ausschnit soll den Einsatz dieser Klasse etwas genauer erläutern:
1
2
3
GetData . createChangeValueCommand ( device . Id , ObjectValue . on ) ;
GetData getData = new GetData ( RequestType . UPDATE_OBJECT_VALUE ) ;
getData . start () ;
In Zeile 1 wird mit Hilfe einer statischen Methode der Linknx-String zusammengestellt, wobei die ID
des Objekts sowie der Wert (in diesem Fall on) übergeben werden. Danach wird eine Instanz der Klasse
erstellt mit dem RequestType, der in diesem Fall angibt, dass der Wert eines Objekts geändert werden
soll. Zuletzt wird der Thread gestartet und bei Erfolg sollte die Lampe mit der jeweiligen ID (falls
vorhanden) nun leuchten.
MyCustomDrawableView
Diese Klasse wird benötigt, um das Zeichnen von Rechtecken (Zuweisen von Räumen) zu ermöglichen.
Weiters sorgt sie dafür, dass alle bereits hinzugefügten Räume gezeichnet werden.
ParseXML
Diese Klasse dient zum Parsen von XML-Daten. Zum Parsen wurde der DOM
14 -Parser verwendet.
Weiters wurde wieder ein eigenes Enum deniert, welches die Art des zu parsenden Linknx-XMLStrings festlegt. Also ob z.B.: eine ganze Cong oder nur der Wert eines Objekts geparsed werden soll.
13
14
Ermöglichen es, dass die App über Zustandsänderungen am jeweiligen Busgerät informiert wird.
Document Object Model - http://de.wikipedia.org/wiki/Document_Object_Model
Seite 66 von 91
Diplomarbeit KNXApp
Folgende Codezeile zeigt ein Anwendungsbeispiel für diese Klasse:
1
ParseXML . parse ( xmlString , XMLParseType . parseConfig ) ;
Da die Klasse statisch ist, muss keine Instanz erstellt werden. Als erster Parameter wird der zu parsende
XML-String übergeben und der zweite Parameter bedeutet in diesem Fall, dass eine gesamte LinknxCong geparsed werden soll.
PhpRequest
Diese Klasse dient zum Senden eines HTTP-POST-Requests an ein PHP-Skript. Dazu wurde die Klasse
HttpPost
15 verwendet. Anhand des eigens denierten Enums MysqlCommandType werden die jewei-
ligen POST-Parameter an das PHP-Skript gesendet, welches wiederrum das entsprechende MySQLKommando ausführt. Die Antwort wird vom PHP-Skript im Datenformat JSON
16 gesendet und an-
schlieÿend von dieser Klasse geparsed.
Folgender Code-Ausschnit soll den Einsatz dieser Klasse verdeutlichen:
1
2
3
4
PhpRequest request = new PhpRequest ( MysqlCommandType . delete_devices_room ) ;
request . setRoomName ( this . roomName ) ;
request . setFloorLevel ( this . floorLevel ) ;
request . start () ;
Zuerst wird eine Instanz der Klasse erstellt, wobei im Konstruktor der CommandType übergeben wird,
in diesem Fall sollen also alle Geräte eines bestimmten Raumes gelöscht werden. Es müssen also der
Name des Raums festgelegt werden sowie das Stockwerk, in dem sich der Raum bendet. In der letzten
Zeile wird der Thread gestartet und der HTTP-Post wird an das PHP-Skript geschickt, welches die
MySQL-Statements ausführt.
Das Sequenz-Diagramm in Abbildung 5.6 soll die Kommunikation zwischen App und Mysql-Server
noch einmal genau erläutern.
15
16
http://developer.android.com/reference/org/apache/http/client/methods/HttpPost.html
JavaScript Object Notation - http://www.json.org/
Seite 67 von 91
Diplomarbeit KNXApp
Abbildung 5.6.: Kommunikationsablauf zwischen der App und dem MySQL-Server
5.2.4. Entities
Dieses Package beinhaltet nur die Klasse Device, die an dieser Stelle genauer beschrieben wird.
Device
Diese Klasse stellt ein KNX-Gerät bzw. eine Webcam dar.
Sie hat daher folgende Attribute:

id
Die Id des Geräts.

gad
Die Gruppenadresse des Geräts.

name
Der Name des Geräts.

dataPoint
Der Datentyp des Geräts.

value
Der Wert des Geräts.

log
Gibt an, welchen Wert das log -Attribut in der Linknx-Kongurationsdatei haben soll.

init
Gibt an, welchen Wert das init -Attribut in der Linknx-Kongurationsdatei haben soll.
17 -Methoden.
Weiters besitzt diese Klasse noch die zugehörigen Getter-und Setter
17
Methoden, welche die Änderung eines Attributwerts ermöglichen.
Seite 68 von 91
Diplomarbeit KNXApp
5.2.5. Facade
Dieses Package beinhaltet ebenfalls nur eine Klasse, doch auf Grund der Wichtigkeit dieser Klasse,
wurde dieses Package dennoch als notwendig empfunden.
KNXFacade
Diese Klasse beinhaltet wichtige Attribute und Methoden, welche von allen anderen Klassen verwendet/aufgerufen werden können.
Die Klasse enthält unter anderem:

Alle Einstellungen, sodass diese global verfügbar sind.

Eine Liste, welche alle bereits hinzugefügten KNX-Geräte sowie Webcams enthält.

Eine Liste, welche die KNX-Datentypen aller verfügbaren Geräte enthält.

Eine Liste mit den Namen (z.B.: Sensor, Lampe, ...) aller verfügbaren Geräte.
Nachfolgend eine Auistung inklusive Beschreibung aller Methoden dieser Klasse, wobei Methoden mit
dem gleichen Nutzen zusammengefasst werden:

getDevice
Gibt ein Gerät mit einer bestimmten ID aus der Liste zurück.

setNoticationDevice
Setzt eine Notication für ein Gerät, also einen neuen Wert, der vom Linknx-Server empfangen
wurde.

getLamps, getWebcams, getSensors, getDimmers, getDimmerValues
Geben jeweils eine Liste mit den jeweiligen Geräten zurück. (z.B.: Liste aller Sensoren)

getKnxDataPoint, getKnxDeviceName
Gibt den KNX-Datentyp bzw. den Namen eines bestimmten Geräts zurück.

checkId, checkGad
Überprüft, ob die ID bzw. die Gruppenadresse eines Geräts bereits existiert oder nicht.

setDevice, setWebcamDevice
Erstellt ein neues KNX-Gerät bzw. eine neue Webcam.

updateWebcam
Ändert die Eigenschaften einer Webcam.

deleteAllDevices
Löscht alle Geräte der Liste.

deleteDevice
Dient zum Löschen eines Geräts mit einer bestimmten ID.

getDevices
Gibt die komplette Liste mit allen Geräten zurück.
Seite 69 von 91
Diplomarbeit KNXApp

checkIfGadExsists
Überprüft ob eine Gruppenadresse schon vorhanden ist. Wenn die angegebene Gruppenadresse
schon verwendet wird, liefert diese Methode false zurück.

isGad, isCorrectId, isCorrectName
Überprüft, ob es sich beim übergebenen String um eine/n korrekte/n Gruppenadresse/Id/Namen
handelt.
Seite 70 von 91
Diplomarbeit KNXApp
5.2.6. Activities
Dieses Package beinhaltet alle sogenannten Activities. Die Grundlagen von Activities wurden bereits
in Abschnitt Android genauer erklärt.

AssignRoomActivity

CongurationActivity

KNXAppActivity

MainMenuActivity

ManageDevicesActivity

ManageRoomsAndFloorsActivity

RoomViewActivity

SettingsActivity
Nun sollen die eben aufgezählten Klassen etwas näher beschrieben werden. Die Reihenfolge, in der die
Klassen beschrieben werden, richtet sich nach der Bedienung der App. Also in der Reihenfolge, in der
der Benutzer beim Start der App mit den verschiedenen Oberächen interagiert.
KNXAppActivity
Diese Activity erscheint beim Start der App. Hier werden groÿteils andere Klassen/Methoden aufgerufen. Der grundsätzliche Ablauf sieht folgendermaÿen aus:

Überprüfung der Eingabe von IP-Adresse/Port des Linknx-Servers auf Korrektheit/Erreichbarkeit

Erstellen einer Instanz der Klasse ConnectionToServer, welche die Verbindung mit dem LinknxServer herstellt

Bei einem fehlgeschlagenem Verbindungsversuch wird eine entsprechende Fehlermeldung ausgegeben

War die Verbindung erfolgreich, werden IP-Adresse und Port gespeichert, sodass diese beim
nächsten Start nicht erneut eingegeben werden müssen

Erstellen der notwendigen MySQL-Tabellen mit Hilfe der Klasse Php-Request.
War dies erfolgreich, wird eine Instanz der Klasse GetData erstellt, welche die Kommunikation
mit dem Linknx-Server startet.

Starten der Activity MainMenuActivity, welche das Hauptmenü darstellt.
Abbildung 5.7 beschreibt die Kommunikation mit dem Linknx-Server beim Start der Applikation.
Seite 71 von 91
Diplomarbeit KNXApp
Abbildung 5.7.: Kommunikation mit dem Linknx-Server, nachdem der Verbinden -Button gedrückt
wurde
MainMenuActivity
Diese Activity wird also wie bereits erwähnt bei einer erfolgreichen Verbindung aufgerufen. Sie soll
eine Art Menü darstellen und enthält nur 2 Image Buttons, welche zur AssignRoomActivity bzw. zur
CongurationActivity weiterleiten und hat daher keinerlei sonstige Funktionalitäten.
AssignRoomActivity
Diese Activity wird aufgerufen, wenn der ImageButton mit dem Text Geräte steuern geklickt wird.
Beim Start dieser Activity wird je nach ausgewähltem Stockwerk der jeweilige Grundriss (falls vorhanden) angezeigt. Die Grundrisse müssen direkt auf die SD-Karte kopiert werden und mit der Ebene des
jeweiligen Stockwerks benannt werden (0=Erdgeschoss,1=1.Stock,...). Unterstützt werden sowohl jpg
als auch png-Dateien. In dieser Klasse werden nun die vorhandenen Bilder von der SD-Karte eingelesen. Danach wird ein Ornder KNXapp auf der SD-Karte erstellt, in welchen die Bilder automatisch
verschoben werden.
Weiters werden mit Hilfe der Klasse Php-Request alle vorhandenen Stockwerke (welche zuvor in der
ManageRoomsAndFloorsActivity hinzugefügt wurden) sowie alle Räume des aktuellen Stockwerks und
die zugehörigen Koordinaten ausgelesen und angezeigt. Wird ein anderes Stockwerk ausgewählt, wird
der Vorgang wiederholt.
Die Klasse MyCustomDrawableView wird in dieser Activity aufgerufen und ermöglicht so das Ziehen
von Rechtecken. Nachdem man ein Rechteck gezogen hat, erscheint ein Dialog, in dem man auswählen
kann, welchem Raum man diese Fläche zuweisen will. Der jeweilige Raum muss natürlich bereits in der
ManageRoomsAndFloorsActivity erstellt worden sein und zum aktuell ausgewählten Stockwerk gehören. Sind für dieses Stockwerk keine Räume vorhanden, wird eine Fehlermeldung ausgegeben. Wurde
Seite 72 von 91
Diplomarbeit KNXApp
ein Raum gewählt und bestätigt werden wieder mit Hilfe der Klasse PhpRequest die jeweiligen Koordinaten in der MySQL-Datenhbank abgespeichert.
Auÿerdem besitzt die Klasse mehrere wichtige Methoden, die nachfolgend aufgelistet und kurz beschrieben werden:

llListView
Selektiert alle bereits hinzugefügten Stockwerke aus der Datenbank und fügt sie als Listeneinträge
hinzu.

createFolderAndFetchPictures
Diese Methode sucht nach Bildern auf der SD-Karte und erstellt den KNXapp-Ordner.

setBackground
Setzt den Grundriss für das aktuelle Stockwerk.

checkBounds
Überprüft ob sich das Rechteck innerhalb des vorgesehenen Bereichs bendet

getUnassignedRooms
Selektiert alle noch nicht zugewiesenen Räume für das aktuelle Stockwerk aus der Datenbank.

getRoomByLocation
Selektiert den Raum aus der Datenbank, in dem sich die übergebenen Koordinaten benden.

selectFloor
Diese Methode sorgt dafür, dass beim Auswählen eines anderen Stockwerks die zugehörigen
Räume gezeichnet werden sowie dass der zugehörige Grundriss angezeigt wird.
Weiters gibt es in dieser Klasse mehrere Event-Listener, unter anderem folgende:

OnTouchListener
Der User hat eine Touch-Geste begonnen, beendet bzw. die Koordinaten haben sich während
einer Touch-Geste geändert.

OnClickListener
Signalisiert ein Klick-Event auf ein Objekt. (z.B. Button-Klick)

OnItemClickListener
Es wurde auf ein List-Item geklickt. (z.B.: Eintrag einer Liste)

OnLongClickListener
Es wurde ein langer Klick auf ein Objekt getätigt. (z.B. Auf einen Button)

OnCheckedChangedListener
Der Zustand einer Checkbox hat sich geändert.

DialogInterface.OnClickListener
Es wurde auf ein Objekt in einem Dialog geklickt.
Seite 73 von 91
Diplomarbeit KNXApp
AssignRoomActivity
Diese Activity wird aufgerufen, wenn im Hauptmenü der ImageButton mit dem Text Konguration
verwalten geklickt wird.
Sie enthält ebenfalls eine Art Navigation mit zwei Image Buttons, welche zur ManageRoomsAnd-
FloorsActivity bzw. zur ManageDevicesActivity weiterführen.
ManageRoomsAndFloorsActivity
Diese Activity wird aufgerufen, sobald der Image-Button mit dem Text Stockwerke und Räume verwal-
ten geklickt wird. Wie der Name sagt, können hier die Stockwerke sowie die Räume verwaltet werden.
Hauptbestandteil dieser Klasse ist eine sogenannte ExpandableListView, also eine Liste mit aufklappbaren Gruppen, welche die Stockwerke (Hauptgruppen, auch Groups ) sowie die Räume (Untergruppen,
auch Childs ) enthält.
Einige wichtige Methoden dieser Klasse sind:

createExpandableListView
Erstellt die ExpandableListView mit den Stockwerken und Räumen aus der Datenbank.

createExpandStateArray
Erstellen eines Arrays, das abspeichert, ob ein Item ausgeklappt ist oder nicht. Die Liste würde
ansonsten beim Hinzufügen/Löschen von Einträgen immer alle Elemente einklappen, was mitunter nicht sehr benutzerfreundlich wäre.

getFloorItems
Selektiert alle vorhandenen Stockwerke aus der Datenbank, welche dann beim Hinzufügen eines
neuen Raumes ausgewählt werden können.

getRoomItems
Gibt alle Stockwerke zurück, welche noch nicht existieren, diese stehen dann beim Hinzufügen
eines neuen Stockwerkes zur Auswahl zur Verfügung,

setExpandState
Setzt die mit Hilfe der Methode createExpandStateArray gespeicherten Expand-States, welche aus
dem Array ausgelesen werden. Diese Methode muss also jedesmal, wenn ein Eintrag
hinzugefügt/gelöscht wird, aufgerufen werden.

getFloorLevel
Gibt die Ebene des Stockwerks/Raums zurück, auf das in der Liste geklickt wurde.
Nachfolgend einige wichtige Event-Handler:

onGroupCollapse
Eine Gruppe wurde zusammengeklappt. Dieser Event-Handler wird nur benötigt, um die ExpandStates speichern zu können.

onGroupExpand
Eine Gruppe wurde aufgeklappt. Dieser Event-Handler wird ebenfalls nur benötigt, um die
Expand-States speichern zu können.
Seite 74 von 91
Diplomarbeit KNXApp

onCreateContextMenu
Es wurde ein lange andauernder Klick auf ein Listenelement durchgeführt. In diesem Handler
wurde das Kontext-Menü zum Löschen eines Stockwerks/Raumes ausprogrammiert.

onContextItemSelected
Ein Eintrag aus dem eben erwähnten Kontext-Menü wurde ausgewählt. Hier werden die entsprechenden Datenbank-Operationen zum Löschen eines Stockwerks/Raums durchgeführt.

OnReadyListener
Eigener Listener, welcher signalisiert, dass ein Dialog bestätigt wurde. Hier werden die entsprechenden Datenbank-Operationen zum Hinzufügen eines Stockwerks/Raums durchgeführt.

onClick
Bei Aufruf dieser Methode werden nur die jeweiligen Dialoge zum Hinzufügen eines Raums/Stockwerks angezeigt.
ManageDevicesActivity
Diese Activity wird aufgerufen, wenn der Image-Button mit der Aufschrift Geräte verwalten gedrückt
wurde. Im Gegensatz zur zuvor beschriebenen Activity enthält diese nur einfache Liste (ListView genannt).
Der Hauptbestandteil dieser Klasse sind Dialoge, welche beim Hinzufügen von Geräten angezeigt werden, sowie die Überprüfung der Eingabe auf Korrektheit (z.B.: korrekte Gruppenadresse, eindeutige
ID, ...). Weiters enthält auch diese Klasse die jeweiligen Event-Handler, welche jedoch nicht mehr näher
beschrieben werden sollen.
Je nach Operation werden die Klassen PhpRequest zur Kommunikation mit der Datenbank sowie
GetData zur Kommunikation mit dem Linknx-Server verwendet.
RoomViewActivity
In dieser Klasse wird das Hinzufügen von Geräten zu einem bestimmten Raum realisiert. Dazu wurde
ein sogenanntes TableLayout verwendet, wobei in jede Zelle ein Gerät mittels Drag and Drop hinzugefügt werden kann. Auch die Logik für die Drag and Drop Funktionalität wurde in dieser Klasse
umgesetzt. Weiters ist zu erwähnen, dass die verschiedenen Geräte als sogenannte ImageViews realisiert
wurden, wobei sich standardmäÿig in jeder Zelle der Tabelle eine ImageView bendet. Je nachdem,
ob sich ein Gerät in der entsprechenden Zelle bendet, wird die Bitmap für die jeweilige ImageView
angezeigt, das Gerät ist also sichtbar.
Nun sollen wieder die wichtigsten Methoden dieser Klasse näher beschrieben werden:

getDevices
Selektiert alle Geräte, die bereits zum jeweiligen Raum hinzugefügt wurden aus der Datenbank
und schreibt diese in eine Liste.

llData
Diese Methode zeigt alle Geräte eines Raums in der jeweiligen Zelle der Tabelle an. Dazu wird
der jeweilige Tabellenindex des zugehörigen Geräts aus der Datenbank selektiert. Weiters wird
in dieser Methode für alle Geräte ein sogenanntes Tag gesetzt, welches die eindeutige ID des
Seite 75 von 91
Diplomarbeit KNXApp
jeweiligen Geräts enthält. Dies ermöglicht das Identizieren eines Geräts in der Tabelle, falls auf
dieses geklickt wurde.

addDeviceToTable
Diese Methode fügt ein bestimmtes Gerät zur Tabelle hinzu. Sie wird immer aufgerufen, wenn
der Benutzer den Dialog zum Hinzufügen eines Geräts bestätigt.

getCellByLocation
Diese Methode berechnet an Hand der übergebenen Koordinaten die jeweilige Zelle der Tabelle,
was von hoher Wichtigkeit ist, da bei jedem Klick des Benutzers die zugehörige Zelle ermittelt
werden muss.
Nachfolgend noch die wichtigsten Events dieser Klasse:

onTouch
In diesem Event werden alle Berührungen des Touch-Screens registriert. Dabei wird überprüft,
ob der Benutzer ein Gerät berührt. Falls dem so ist, wird ein sogenannter DragShadow erstellt
und das Drag and Drop wird gestartet, sodass es für den Benutzer so aussieht, als würde dieser
das Gerät bewegen können.
onDrag
In diesem Event können mehrere verschiedene Aktionen, die während des Drag and Drop auftreten, abgefangen werden. Folgende wurden in dieser Klasse verwendet:
ACTION_DRAG_LOCATION
Die Position des DragShadows (also des Geräts) hat sich geändert. In diesem Event werden
die jeweiligen Koordinaten des Geräts gespeichert.
ACTION_DRAG_ENDED
Der DragShadow (das Gerät) wurde losgelassen. Falls dies der Fall ist, wird zuerst überprüft,
ob das Gerät innerhalb der Tabelle losgelassen wurde oder ob sich in der jeweiligen Zelle
bereits ein Gerät bendet.
SettingsActivity
Die Aufgabe dieser Activity ist das Speichern sowie das Laden der Einstellungen. Diese werden mit Hilfe
sogenannter SharedPreferences
18 gespeichert, welche in Form sogenannter Key/Value-Pairs gespeichert
werden. Also jeweils ein eindeutiger Schlüssel (in Form eines Strings) mit dem zugehörigen Wert. Zu
den unterstützten Datentypen gehören sämtliche primitive Datentypen
19 . Zu erwähnen ist noch, dass
in Android jede Applikation einen eigenen privaten Ordner besitzt, auf den nur diese zugreifen kann
(auch nicht der Benutzer). Standardmäÿig sieht der Pfad zu den Einstellungen folgendermaÿen aus
/data/data/<package_name>/shared_prefs/<package>_preferences.xml.
18
19
http://developer.android.com/reference/android/content/SharedPreferences.html
boolean, oat, int, long, string
Seite 76 von 91
Diplomarbeit KNXApp
5.3. Beschreibung der Applikation
Als Name für die Android-Applikation wurde KNXApp gewählt. Die Applikation wurde für Tablets
20 veröentlicht.
mit der Android Version 3.1 bzw. 3.2 entwickelt und zusätzlich im Google Play Store
Das KNXApp benötigt einen Server, der konguriert werden muss. Die Kongurationsschritte, die
eingeleitet werden müssen, können in den Abschnitten Installation Server und Konguration Server
nachgelesen werden. Weiters ist es wichtig, dass das mobile Endgerät eine aktive Netzwerk-Verbindung
zum Server hat.
In Abbildung 5.8 ist das Logo der Applikation zu sehen:
Abbildung 5.8.: KNXApp-Logo
20
https://play.google.com/store
Seite 77 von 91
Diplomarbeit KNXApp
5.3.1. Menüführung
Die Abbildung 5.9 zeigt die Menüführung der Applikation. Die Pfeile zeigen das Fenster, das erreicht
wird wenn auf den entsprechenden Button gedrückt wird.
Abbildung 5.9.: Menüführung der Applikation
Nachfolgend werden nun alle wesentlichen Features des Programmes erklärt und die Bedienung der
Applikation erläutert.
Seite 78 von 91
Diplomarbeit KNXApp
5.3.2. Verbindung zum Server herstellen
Sobald die Applikation installiert ist, kann sie gestartet werden. Nach dem Start gelangt man in das
Verbindungs-Menü. In diesem Fenster kann die IP-Adresse des Linknx-Servers eingeben werden. Über
den Einstellungen -Button gelangt man in ein Menü, das es ermöglicht, verschiedene Informationen anzugeben. Werden alle Einstellungen ausgefüllt, so kann man wieder zurück in das Verbindungs-Fenster
wechseln und dort mit dem Verbinden -Button eine Verbindung zum Server aufbauen. Der AboutButton führt zu einem Dialog, der Informationen zu den Entwicklern bzw. der Version enthält.
Abbildung 5.10 zeigt das Verbindungs-Menü:
Abbildung 5.10.: Verbindungs-Menü
Im Einstellungen-Menü müssen folgende Informationen angegeben werden:
Automatisch verbinden
Wird diese Checkbox aktiviert, so werden beim nächsten Start die Einstellungen übernommen
und die Applikation versucht sofort eine Verbindung aufzubauen.
Linknx
IP-Adresse/Hostname und Portnummer des Linknx-Servers
Webserver
IP-Adresse/Hostname des Webservers
MySQL
IP-Adresse/Hostname des MySQL-Servers. Zusätzlich muss noch der Benutzername und das
Passwort eines Datenbankbenutzers, der ausreichend Rechte hat, angegeben werden.
Seite 79 von 91
Diplomarbeit KNXApp
Es wichtig, dass alle Einstellungen vollständig ausgefüllt werden, da nur dann eine erfolgreiche Verbindung zum Server möglich ist.
In Abbildung 5.11 ist die Oberäche der Einstellungen zu sehen.
Abbildung 5.11.: Einstellungen
5.3.3. Hauptmenü
Wenn die Applikation eine erfolgreiche Verbindung aufgebaut hat, so gelangt man ins Hauptmenü der
Applikation. In diesem Menü sind 2 Buttons die zu den weiteren Funktionen der Applikation führen.
Geräte steuern
Dieser Button führt zu der Übersicht der Stockwerke. Dort wird ein Grundriss des jeweiligen
Stockwerkes angezeigt und es können Räume hinzugefügt oder gelöscht werden.
Konguration verwalten
Dieser Button führt zu einem weiteren Untermenü, das auch als Kongurationsmenü bezeichnet
werden kann.
Diese zwei Buttons führen zu den Hauptfeatures der Applikation. In den folgenden Abschnitten
sollen diese Features erklärt und gezeigt werden.
Seite 80 von 91
Diplomarbeit KNXApp
In Abbildung 5.12 ist das Hauptmenü zu sehen.
Abbildung 5.12.: Hauptmenü
5.3.4. Konguration verwalten
Die Applikation bietet die Möglichkeit, Geräte zu verwalten. Das heiÿt, es können Geräte hinzugefügt, geändert und gelöscht werden. Über den Button Geräte verwalten kommt man in ein
Menü, wo man diese Features einsetzen kann.
Weiters können auch Räume bzw. Stockwerke verwaltet werden. Diese Räume und Stockwerke
können danach in der Stockwerksübersicht verwendet und weiterverarbeitet werden. Die Verwaltung der Stockwerke und Räume kann über den Button Räume/Stockwerke verwalten aufgerufen
werden.
Seite 81 von 91
Diplomarbeit KNXApp
Die Abbildung 5.13 zeigt das Menü zum Verwalten der Konguration.
Abbildung 5.13.: Konguration
Geräte verwalten
Das Geräte verwalten Menü besteht aus einer Liste mit Geräten und Buttons auf der rechten
Seite, die das Einfügen neuer Geräte bzw. neuer Webcams ermöglichen. Die Geräte, die zum
Einfügen zur Verfügung stehen, sind folgende:
Lampe
Dimmer
Dimmer Wert/Rückgabe Wert
Sensor
Um eine neues Gerät anlegen zu können, muss ein Name, eine Gruppenadresse und eine Id
angegeben werden. Diese Id ist eindeutig und wird als Primärschlüssel eingesetzt. Zusätzlich gibt
es noch zwei Checkboxen, die es ermöglichen den aktuellen Wert des Gerätes in der Datenbank
zu speichern, oder alle Änderungen des Gerätes mitzuloggen.
Wenn eine neue Webcam eingefügt werden soll, muss ein Name, eine URL, die zur Webcam führt,
sowie eine Id angegeben werden.
Seite 82 von 91
Diplomarbeit KNXApp
Abbildung 5.14 zeigt den Dialog zum Einfügen eines neuen Geräts.
Abbildung 5.14.: Beispiel: neues Gerät einfügen
Wenn man lange auf ein Gerät in der Liste drückt, önet sich ein Kontextmenü. In diesem Menü
besteht die Möglichkeit, ein Gerät zu löschen, oder die Eigenschaften eines Gerätes zu ändern.
Drückt man kurz auf ein Element in der Liste, so erscheinen nähere Informationen zum Gerät in
Form eines Dialoges.
In Abbildung 5.15 ist das Kontextmenü eines Geräts zu sehen.
Abbildung 5.15.: Kontextmenü des Gerätes Innen Temperatur
Alle Geräte, die hier deniert werden, können später einem Raum zugewiesen und dort gesteuert
werden.
Seite 83 von 91
Diplomarbeit KNXApp
Räume und Stockwerke verwalten
Über den Button Räume und Stockwerke verwalten gelangt man in ein Menü, wo die Räume und die
Stockwerke hinzugefügt und gelöscht werden können. Hierbei ist es möglich mittels Buttons, die auf
der rechten Seite platziert sind, die Räume und Stockwerke hinzuzufügen. Über ein Kontextmenü, das
durch langes Drücken auf ein Stockwerk oder einen Raum erscheint, können Räume oder Stockwerke
gelöscht werden. In Abbildung 5.16 ist das Menü zum Verwalten der Räume und Stockwerke zu sehen.
Abbildung 5.16.: Fenster zum Verwalten der Räume und Stockwerke
Um ein neues Stockwerk einzufügen, ist es erforderlich, die Ebene des Stockwerks anzugeben. Diese
Ebene gibt an, um welches Stockwerk es sich handelt(0=Ebene 0, 1=Ebene 1, 2=Ebene 2,. . . ). In
Abbildung 5.17 ist der Dialog zum Hinzufügen eines neuen Stockwerks zu sehen.
Abbildung 5.17.: Hinzufügen eines neuen Stockwerkes
Für einen neuen Raum wird ein Raumname benötigt. Zusätzlich muss eine Ebene angegeben werden.
Diese Eingabe wird benötigt, um den neuen Raum, dem entsprechenden Stockwerk zuordnen zu können.
In Abbildung 5.18 ist der Dialog zum Hinzufügen eines neuen Raums zu sehen.
Abbildung 5.18.: Hinzufügen eines neuen Raumes
Seite 84 von 91
Diplomarbeit KNXApp
Durch Klicken auf ein Stockwerk besteht die Möglichkeit, die dazugehörigen Räume in der Liste anzuzeigen, oder zu verbergen.
5.3.5. Geräte steuern
Die Applikation kann nicht nur KNX-Geräte verwalten, sondern auch steuern. Hierbei sind 2 Fenster
vorgesehen:
Grundriss
Hier können Räume zugewiesen und verwaltet werden
Raum
Hier werden die Geräte einem Raum zugewiesen und gesteuert.
Grundrisse
Klickt man auf Geräte steuern, so gelangt man in ein Menü, wo der Grundriss eines Stockwerks erscheint. Hier können alle Stockwerke angezeigt werden, die im Menü Räume/Stockwerke verwalten
deniert wurden.
Die Grundrisse der Stockwerke müssen auf die SD-Card des Tablets kopiert werden. Hierbei genügt es,
wenn die Grundrisse direkt auf der SD-Card abgespeichert werden. Die Applikation verschiebt diese
Bilddatei danach in den entsprechenden Applikationsordner. Es ist wichtig, dass sich für jedes denierte Stockwerk ein Grundriss auf der SD-Card bendet. Die Bilddatei muss eine PNG-Datei oder
JPEG-Datei sein. Der Name der Bilddatei muss nun dieser Syntax entsprechen: <Ebene des Stockwer-
kes>.png. (Beispiel: 0.png für den Grundriss der Ebene 0)
Bei richtiger Konguration erscheint nun ein Grundriss eines Stockwerkes. Am oberen Bildrand ist
der Stockwerksname zu sehen. Am rechten Bildrand kann durch Auswahl einer Ebene zwischen den
denierten Stockwerken gewechselt werden.
Seite 85 von 91
Diplomarbeit KNXApp
In Abbildung 5.19 ist ein Grundriss mit bereits zugewiesenen Räumen zu sehen.
Abbildung 5.19.: Grundriss mit zugewiesenen Räumen
Es können nun die denierten Räume zugewiesen werden. Durch Aufziehen eines Rechtecks per Touchgeste kann die Gröÿe des Raumes deniert werden. Wird das Aufziehen beendet, so erscheint ein Dialog,
der es möglich macht, einen Raum der ausgewählten Fläche zuzuweisen. Hierbei können alle Räume
zugewiesen werden, die für dieses Stockwerk deniert wurden.
In Abbildung 5.20 ist der Dialog zum Zuordnen eines Raums zu sehen.
Abbildung 5.20.: Raum wird einer Fläche im Grundriss zugeordnet
Die zugewiesenen Räume werden mit grauen Rechtecken visualisiert. Es besteht auch die Möglichkeit
eine Raum zu erweitern, indem man ein Rechteck von einem bestehenden Raum aus wegzieht. Ist dies
erfolgt, erscheint ein Dialog, wo die Erweiterung des Raumes bestätigt werden kann.
Die grauen Rechtecke können durch eine Checkbox am rechten oberen Bildrand ausgeblendet werden.
Die zugewiesenen Räume können durch ein Kontextmenü gelöscht werden. Dieses Kontextmenü kann
wieder durch langes Drücken auf einen Raum erreicht werden. Löscht man nun einen Raum, so wird nur
die Zuweisung an der entsprechenden Stelle im Grundriss gelöscht. Der gelöschte Raum kann jederzeit
wieder durch Aufziehen eines Rechteckes zugewiesen werden.
Seite 86 von 91
Diplomarbeit KNXApp
Raum
Klickt man nun auf einen zugewiesenen Raum, so gelangt man in ein neues Fenster. In diesem Fenster
benden sich Kacheln, welche bei einem neu zugewiesenen Raum noch leer sind. Es gibt 40 Kachel,
daraus ergibt sich eine maximale Anzahl von 40 Geräten pro Raum.
Abbildung 5.21 zeigt einen leeren Raum ohne zugewiesene Geräte.
Abbildung 5.21.: leerer Raum ohne zugewiesene Geräte
Den Räumen können nun die KNX-Geräte zugeordnet werden. Es stehen hierbei wieder nur diese Geräte zur Verfügung, die im Menü Geräte verwalten deniert wurden. Ein Gerät kann durch Drag&Drop
dem Raum zugewiesen werden. Mit Hilfe dieses Features ist es möglich, dass man auf ein Gerät auf
der rechten Seite klickt und dieses danach auf einem beliebiges Kachel im Raum zieht. Sobald man
das Gerät auf einem Kachel platziert hat, erscheint ein Dialog, der einen dazu auordert ein Gerät
dieses Typs auszuwählen. Zieht man beispielsweise eine Lampe in einen Raum, dann muss ausgewählt
werden welche Lampe nun zugeordnet werden soll. Diese Vorgehensweise ist bei den anderen Geräten
ähnlich.
Abbildung 5.22 zeigt den Dialog zum Hinzufügen einer neuen Lampe.
Abbildung 5.22.: Auswählen welche Lampe zugeordnet werden soll
Wird ein Gerät ausgewählt und hinzugefügt, dann kann dieses gesteuert werden. Durch klicken auf
den Kachel des entsprechenden Gerätes erscheint ein Dialog, der es ermöglicht, eine Lampe ein- oder
auszuschalten oder zu dimmen. Klickt man auf einen Sensor, so erhält man eine aktuellen Sensordatenverlauf des Sensors, klickt man auf die Webcam, so erscheint das aktuelle Bild der Webcam. Durch
Seite 87 von 91
Diplomarbeit KNXApp
langes Drücken auf einen Kachel önet sich ein Kontextmenü, welches es ermöglicht, das Gerät vom
Raum zu löschen oder sich nähere Informationen zum Gerät anzeigen zu lassen.
Abbildung 5.23.: Kontextmenü bei Klicken auf ein Element im Raum
Klickt man auf Eigenschaften des Geräts anzeigen, so werden alle relevanten Informationen zum Gerät
angezeigt.
Abbildung 5.24.: Eigenschaften eines Gerätes (Innen Temperatur )
Lampen können ganz einfach durch Klicken auf die Glühbirne gesteuert werden.
Abbildung 5.25.: Lampe steuern
Seite 88 von 91
Diplomarbeit KNXApp
Ein Dimmer kann mit Hilfe eines Schiebereglers gesteuert werden. Es stehen auch Buttons zur Verfügung mit denen hinauf- bzw hinabgedimmt werden kann. Klickt man auf die Glühbirne wenn der
Dimmer ausgeschaltet ist, so wird Dimmer auf 100% gedimmt. Klickt man auf den Dimmer wenn er
schon eingeschaltet und gedimmt wurde, dann wird der Dimmer auf 0% gedimmt, also abgeschaltet.
Abbildung 5.26.: Dimmer steuern
Für einen Sensor wird der Sensordatenverlauf angezeigt. Es wird zusätzlich eine Information über den
aktuellen Wert ausgegeben.
Abbildung 5.27.: Sensordaten anzeigen
Wird eine Webcam einem Raum zugewiesen, so ist es möglich, sich diese anzuzeigen. Es wird ein Bild
angezeigt, dass sich alle 500ms aktualisiert.
Abbildung 5.28.: Webcam anzeigen
Seite 89 von 91
Diplomarbeit KNXApp
Es ist nicht möglich, dass auf einem Kachel mehrere Geräte platziert werden. Es ist auch nicht möglich, dass ein Gerät im selben Raum doppelt zugewiesen wird. Abbildung 5.29 zeigt einen Raum mit
zugewiesenen Geräten aller Gerätetypen.
Abbildung 5.29.: Raumübersicht am Beispiel des Wohnzimmers
5.4. Fazit
Speziell bei der Programmierung gab es eine Menge Herausforderungen. Besonders die Netzwerkkommunikation musste gut durchdacht werden, um die Applikation so ressourcenschonend wie möglich zu
programmieren. Bei der Netzwerkverbindung mit dem Linknx-Server gab es zu Beginn Probleme, da
dieser nicht auf die gesendeten Pakete antwortete. Der Grund dafür war, dass das ASCII-Zeichen EOT
jedem Linknx-Befehl angehängt werden muss, sodass dieser das Ende des Befehls erkennen kann.
Ein weiteres Problem, welches erst spät erkannt wurde, ist der Umstand, dass statische Variablen in
Android auch nach Beendigung der Applikation nicht sofort zerstört werden und somit beim nächsten
Start den alten Wert beinhalten. Die Schwierigkeit dieses Problems lag viel weniger in der Behebung
als in der eigentlichen Erkennung dieses Umstands.
Weiters wurde auf eine saubere Programmierung geachtet und der Source Code wurde ausführlich
mit Kommentaren versehen, um eine eventuelle Erweiterung der Applikation so leicht wie möglich zu
machen.
Seite 90 von 91
Diplomarbeit KNXApp
6. Zusammenfassung
Die Diplomarbeit war für die beiden Diplomanden eine wertvolle Bereicherung ihres Wissens, denn
sie konnten nicht nur ihre technischen Fähigkeiten ausbauen, sondern auch im Projektmanagement
wertvolle Erfahrungen sammeln.
Da die Projektmitglieder noch keine Erfahrungen mit Bussystemen hatten, musste selbstständig Wissen
aufgebaut werden. Eine weitere Herausforderung war die Planung des Systems. Es wurden verschiedene
Lösungen analysiert und danach entschieden, wie das System aufgebaut wird. Weiters wurde darauf
geachtet, dass die entwickelte Software für möglichst viele Gebäudesituationen eingesetzt werden kann.
Bei der Realisierung wurde besonders auf die Adaptierbarkeit auf andere Systeme und Gebäudesituationen geachtet. Die Applikation wurde auf einem Testboard mit verschiedenen KNX-Geräten getestet.
Das Testboard wurde von Betreuer DI Christian Hammer zur Verfügung gestellt. Die Konguration
des Servers, sowie die Programmierung der mobilen Applikation wurden von Grund auf selbst erstellt
und entwickelt. Die zur Buskommunikation eingesetzten Programme sind frei und kostenlos einsetzbar.
Das KNXApp in der Version 0.1 läuft auf Tablets und könnte für Smartphones adaptiert werden.
Hierbei müsste besonders auf die kleineren Bildschirme geachtet werden und darum sollte auf die
Implementierung von den Grundrissen verzichtet werden. Ein weiterer Punkt, der noch umgesetzt werden könnte, ist die Implementierung neuer KNX-Geräte. Es gibt noch unzählige KNX-Geräte (z.B.
Rolläden, Heizungssysteme,. . . ) die noch in die Applikation implementiert werden könnten.
Seite 91 von 91
A. Struktur der Tabellen
Dieser Abschnitt beschäftigt sich mit dem Aufbau und der Struktur der Tabellen des Datenbankschemas.
A.1. Tabelle oors
Diese Tabelle beinhaltet alle hinzugefügten Stockwerke.
Die Struktur ist in Tabelle A.1 zu sehen.
Spalte
Typ null Besonderheiten
oor_id
int
nein
Primary Key, AUTO_INCREMENT
oor_level
int
nein
Unique
Tabelle A.1.: Tabelle oors
Sie besteht aus einem Primary Key oor_id und einem eindeutigen Attribut oor_level, welches die
Ebene des jeweiligen Stockwerks beinhaltet.
A.2. Tabelle rooms
Diese Tabelle beinhaltet alle hinzugefügten Räume. Die Struktur ist in Tabelle A.2 zu sehen.
Spalte
Typ
null Besonderheiten
oor_level
int
nein
Primary Key, Foreign Key
room_name
varchar(30)
nein
Primary Key
room_is_assigned
int
ja
Default 0
room_pos_start_x
int
ja
-
room_pos_start_y
int
ja
-
room_pos_end_x
int
ja
-
room_pos_end_y
int
ja
-
Tabelle A.2.: Tabelle rooms
Bei dieser Tabelle bilden der Name des Raums und das Stockwerk gemeinsam den Primärschlüssel.
Das bedeutet, innerhalb eines Stockwerks dürfen nicht mehrere Räume mit dem gleichen Namen vorkommen. Weiters gibt das Attribut room_is_assigned an, ob ein Raum bereits zugewiesen wurde (1),
oder nicht (0). Die letzten vier Attribute der Tabelle speichern die Eckkoordinaten eines zugewiesenen
Raums. Weiters stellt das Attribut oor_level einen Fremdschlüssel dar, welcher auf das zugehörige
Attribut der Tabelle oors verweist. Wichtig ist hierbei, dass bei diesem Fremdschlüssel die ON DE-
LETE CASCADE -Klausel hinzugefügt wurde. Das bedeutet, dass das Löschen eines Stockwerks zur
Folge hat, dass auch alle zugehörigen Räume (und deren Geräte) gelöscht werden.
I
In dieser Tabelle werden sowohl alle Linknx-Geräte, als auch alle Webcams abgespeichert, welche einem
Raum zugewiesen wurden.
Die Struktur ist in Tabelle A.3 zu sehen.
Spalte
Typ
null Besonderheiten
device_id
varchar(100)
nein
Primary Key
oor_level
int
nein
room_name
varchar(30)
nein
index_x
int
nein
-
index_y
int
nein
Tabelle A.3.: Tabelle devices
Das Stockwerk, in dem sich ein Gerät bendet, sowie der Name des Raums und die ID des Geräts bilden
zusammen den Primärschlüssel. Das bedeutet, es darf im gleichen Raum das gleiche Gerät nicht öfter
als einmal vorkommen, in einem anderen Raum darf das gleiche Gerät jedoch existieren. Weiters stellen
die Attribute oor_level und room_name gemeinsam einen Foreign Key dar, welcher auf die Tabellen
oors bzw. rooms verweist. Zusätzlich wurde auch hier wieder die ON DELETE CASCADE -Klausel
hinzugefügt.
Da es auch möglich sein soll, zu einem bereits bestehenden Raum eine beliebige Fläche hinzuzufügen,
wurde dafür eine eigene Tabelle angelegt.
In Tabelle A.4 ist wieder die Struktur zu sehen.
Spalte
Typ
null Besonderheiten
room_expand_id
int
nein
Primary Key, AUTO_INCREMENT
room_pos_start_x
int
nein
-
room_pos_start_y
int
nein
-
room_pos_end_x
int
nein
-
room_pos_end_y
int
nein
-
room_name
varchar(30)
nein
Foreign Key
oor_level
int
nein
Foreign Key
room_is_assigned
int
ja
Default 1
Tabelle A.4.: Tabelle room_expand
Den Primärschlüssel bildet das Attribut room_expand_id, welches automatisch inkrementiert wird.
Auÿerdem werden wie bereits in der Tabelle rooms die Eckkoordinaten der jeweiligen Fläche gespeichert, sowie ein Attribut welches angibt, ob die Fläche zugewiesen ist oder nicht. Weiters bilden auch
hier wieder das Stockwerk sowie der Name des Raums gemeinsam einen Fremdschlüssel, wobei ebenfalls eine ON DELETE CASCADE -Klausel hinzugefügt wurde. Wird also ein Raum gelöscht, werden
alle zugehörigen Erweiterungen ebenfalls gelöscht.
II
A.5. Tabelle webcams
Da alle KNX-Geräte in der Linknx-XML-Kongurationsdatei gespeichert werden, was jedoch mit den
Webcams nicht möglich ist, musste für diese eine eigene Tabelle erstellt werden.
In Tabelle A.5 ist wieder die Struktur der Tabelle zu sehen.
Spalte
Typ
null Besonderheiten
webcam_id
varchar(30)
nein
Primary Key
name
varchar(30)
nein
-
url
varchar(100)
nein
Tabelle A.5.: Tabelle webcam
Den Primärschlüssel stellt das Attribut webcam_id dar, welches vom Benutzer selbst ausgewählt werden kann. Der Name der Webcam kann ebenfalls durch den Benutzer bestimmt werden, muss jedoch im
Gegensatz zur ID nicht eindeutig sein. Auÿerdem muss die URL für die Webcam ebenfalls abgespeichert
werden.
A.6. Tabelle log
In dieser Tabelle werden Informationen zu Objekten gespeichert, die in der linknx-Konguration den
Wert log=true gesetzt haben. Dies kann zur Überwachung eines Objektes dienen.
Tabelle A.6 zeigt wieder die Tabellenstruktur.
Spalte Typ
null Besonderheiten
ts
timestamp
nein
Primary Key, CURRENT_TIMESTAMP
object
varchar(256)
nein
Primary Key
value
varchar(256)
nein
Tabelle A.6.: Tabelle log
Den Primärschlüssel stellt das Attribut ts gemeinsam mit dem Attribut object dar. Die Spalte ts hat den
dazugehörigen Datentyp timestamp. Zusätzlich zur aktuellen Zeit, wird noch der linknx-Objektname
sowie der Wert des Objektes abgespeichert.
III
Die Tabelle persist speichert für alle Objekte, die in der linknx-Konguration den Wert init=persist
gesetzt haben, den aktuellen Wert. Das heiÿt diese Tabelle hält immer den aktuellen Wert eines Objekts.
In Tabelle A.7 ist die Struktur der Tabelle zu sehen.
Spalte Typ
null Besonderheiten
object
varchar(256)
nein
Primary Key
ts
timestamp
nein
CURRENT_TIMESTAMP
value
varchar(256)
nein
Tabelle A.7.: Tabelle persist
Diese Tabelle hat ein ähnliches Schema wie die Tabelle log. Doch den Primary Key bildet in dieser
Tabelle nur die Spalte object, da diese schon eindeutig ist. Neben den linknx-Objektnamen wird noch
ein Timestamp und der aktuelle Wert des Objektes gespeichert.
IV
B. Management
Das Management ist während der Projektdurchführung sehr wichtig. Sowohl Planung als auch klare
Arbeitsteilung sind für eine positiven Projektabschluss essentiell. Jedoch muss gerade bei neuartigen
Projekten darauf geachtet werden, dass die Planung eventuell auch während der Entwicklung angepasst
werden muss. Dies kann beispielsweise durch eine falsche Aufwandseinschätzung passieren.
B.1. Team
Abbildung B.1 zeigt das Organigramm des Teams:
Abbildung B.1.: Organigramm des Teams
Das Projektteam besteht aus Michael Eder und Markus Hinterleitner. Beide Teammitglieder sind
gleichberechtigt und haben die gleichen Aufgaben und Pichten. Besonders in einem so kleinen Team
eignet es sich gut, dass beide Mitglieder gleichberechtigt sind.
Die Betreuer während der Diplomarbeit waren DI Christian Hammer und DI Rudolf Kashofer.
V
B.2. Zeitplanung
Abbildung B.2 zeigt die Zeitplanung die während des Projektes erstellt wurde.
Abbildung B.2.: Zeitplanung
VI
B.3. Aufgabenverteilung
Eder M. Hinterleitner M.
Kennenlernen des Bussystems
X
X
Recherche von verschiedenen Lösungen (mit/ohne Server)
X
X
Arbeiten mit der ETS Programmiersoftware
X
X
Herstellen einer Netzwerkverbindung mit dem KNX-Bus
X
X
Analyse Calimero Library
X
Analyse EIBD
X
Erstellen einer Testapplikation mittels Calimero
X
Installation einer OpenSuSe VM mit eibd, linknx und knxweb
X
Inbetriebnahme weiterer Busgeräte
X
Erstellen von Verläufen verschiedener Sensorwerte
X
SMS und E-Mail Benachrichtigung via Linknx
X
Kommunikation zwischen App und Linknx-Server
X
X
Kommunikation zwischen App und MySQL-Server
Webcam
X
X
X
Einstellungen
X
Geräte verwalten
X
Räume/Stockwerke verwalten
X
Raumansicht
X
Stockwerksansicht
X
X
Grak/Design
X
Datenbanksystem
X
Dokumentation - Einleitung
X
Dokumentation - Grundlagen von Bussystemen
X
Dokumentation - Analyse
X
X
Dokumentation - Realisierung Server
X
Dokumentation - Realisierung mobile Applikation
VII
X
HÖHERE LEHRANSTALT FÜR INFORMATIONSTECHNOLOGIE (IT-HTL)
YBBS AN DER DONAU
Abteilung:
Informationstechnologie
Ausbildungsschwerpunkt: Netzwerktechnik
DIPLOMARBEIT
DOKUMENTATION
Namen der
Verfasser/innen
Eder Michael
Hinterleitner Markus
Jahrgang / Klasse
Schuljahr
5.Jahrgang / 5AHITN / 2011/2012
Thema der Diplomarbeit
Kooperationspartner
Aufgabenstellung
Entwicklung einer Tablet-Applikation zur Gebäudesteuerung
-
Es soll eine Applikation für mobile Geräte entwickelt werden, welche
die Steuerung von Geräten eines Bussystems ermöglicht. Besonderer
Wert soll dabei auf die Flexibilität der Applikation gelegt werden,
sodass die Steuerung beliebiger Systeme möglich ist.
Die Applikation wurde für Tablets mit dem mobilen Betriebssystem
Android (Version 3) entwickelt.
Wie für Android-Applikationen üblich, wurde die Programmiersprache
Java verwendet. Die Speicherung der Daten wurde mit einer MySQLDatenbank realisiert. Die Kommunikation zwischen der AndroidApplikation und dem MySQL-Server erfolgt dabei über ein PHP-Skript,
welches die MySQL-Statements ausführt.
Realisierung
Zusätzlich wurde ein eigener Server zur Steuerung des Bussystems
sowie ein XML-Server zur Verwaltung der Busgeräte verwendet.
Mit Hilfe eines dazwischenliegenden WLAN-Routers wird die
Kommunikation des Android-Geräts mit diesen Servern und folglich
auch die Steuerung des Bussystems ermöglicht.
Die Applikation ermöglicht sowohl die Steuerung von Lampen und
Dimmern, als auch das Anzeigen von Sensorwerten/Verläufen und
Webcams. Die Webcams stehen dabei in keinerlei Zusammenhang mit
dem Bus.
Ergebnisse
Am Ende der Diplomarbeit stand eine voll funktionsfähige AndroidApplikation zur Steuerung von Busgeräten eines KNX-Bussystems zur
Verfügung.
Seite 1 von 2
HÖHERE LEHRANSTALT FÜR INFORMATIONSTECHNOLOGIE (IT-HTL)
YBBS AN DER DONAU
Abteilung:
Informationstechnologie
Ausbildungsschwerpunkt: Netzwerktechnik
Kommunikation zwischen den einzelnen Komponenten
Typische Grafik, Foto etc.
(mit Erläuterung)
Menüführung der Applikation
Möglichkeiten der
Einsichtnahme in die Arbeit
Die Applikation kann aus dem Google-Play-Store heruntergeladen
werden. https://play.google.com/store?hl=de
Die schriftliche Arbeit befindet sich in der Bibliothek der IT-HTL Ybbs.
Prüfer/in
Abteilungsvorstand / Direktor/in
Approbation
(Datum / Unterschrift)
Seite 2 von 2
COLLEGE of ENGINEERING
YBBS AN DER DONAU
Department:
Educational focus:
Information technology
Network technology
DIPLOMA THESIS
Documentation
Author(s)
Eder Michael
Hinterleitner Markus
Form
Academic year
5AHITN / 2011/2012
Topic
Co-operation partners
Assignment of tasks
Tablet application for building control
-
The goal is to develop an application for mobile devices, which enables
the control of devices of a bus system. Great emphasis has to be put
on the flexibility of the application, to make the control of arbitrary
systems as easy as possible.
The application was developed for tablets running on the mobile
operating system Android (Version 3).
The application was written in Java, a programming language which is
very common for Android applications. The storing of the data was
realized with a MySQL database. The communication is achieved by a
separate PHP-script, which executes the MySQL statements.
Realization
In addition, own servers were used for the communication with the bus
system and the maintenance of the bus devices. An intermediate
WLAN router enables the communication between the Android device
and the bus system.
The application allows the control of lamps and dimmers as well as the
displaying of sensor values and webcam pictures.
Results
The result of the diploma thesis was a fully functional Android
application, which enables the control of KNX bus systems.
Seite 1 von 2
COLLEGE of ENGINEERING
YBBS AN DER DONAU
Department:
Educational focus:
Information technology
Network technology
Communication between the different components
Illustrative graph, photo
(incl. explanation)
Menu navigation of the application
Accessibility of
diploma thesis
The application can be downloaded from the Google-Play-Store.
https://play.google.com/store?hl=de
The diploma thesis itself is accessible in the library of the IT-HTL
Ybbs/Donau.
Examiner
Head of Department / College
Approval
(Date / Sign)
Seite 2 von 2
Literaturverzeichnis
[1] knx.org. http://www.knx.org/at/, 2012. 5
[2] wikipedia.org. http://de.wikipedia.org/wiki/knx-standard, 2012. 6
[3] knx.ch. http://www.knx.ch/wdeutsch/seiten/was_ist_konnex.php. Was ist KNX?, 2012. 7, XIV
[4] wikipedia.org. http://de.wikipedia.org/wiki/europäischer_installationsbus, 2012. 7, 10
[5] KNX-User-Forum. http://knx-user-forum.de, 2012. 7
[6] kabelscheune.de.
http://www.kabelscheune.de/kabel-leitungen/eib-knx-installationskabel/eib-
leitung-j-y-st-y-2x2x0-8-mm-gruen.html, 2012. 8, XIV
[7] Frank Sokollik Werner Kriesel, Jens Rennefahrt.
EIB für die Gebäudesystemtechnik in Wohn-
und Zweckbau. Hüthing, 2003. 9, 12, 14, 15, 17, XIV, XVI
[8] aycontrol.com.
http://aycontrol.com/de/eib-knx-iphone-ipad/support/knx-knowledge-
base/knxnet-ip-tunneling-routing, 2012. 18
[9] IT-GmbH. http://www.it-gmbh.de/de/products/ets/index.htm, 2012. 19
[10] eibkalk.at. http://www.eibkalk.at/index.php?option=com_content&view=article&id=273&itemid=144,
2012. 26, XIV
[11] Datenblatt ABB Dimmaktor UD/S.4.210.1. 28, 29, XIV
[12] Datenblatt ABB Schaltaktor SA/S 8.16.6.1. 29, XIV
[13] Datenblatt LinggJanke Netzteil-Schaltaktor mit Schnittstelle NTA6F16H+USB. 30
[14] Technische Produktinformationen GAMMA instabus, 2008. 30
[15] siemens.com. Gebäudeautomation, 2012. 30, XIV
[16] Datenblatt Siemens Taster-Schnittstelle UP 220/03 und UP 220/13. 31
[17] Datenblatt Elsner Elektronik Thermo-Hygrometer KNX TH-UP basic. 31, 32, XIV
[18] Datenblatt Elsner Elektronik Temperatursensor. 32, XIV
[19] samsung.at. http://galaxytab.samsung.at/at/galerie, 2012. 33, XIV
XII
[20] http://sourceforge.net/apps/mediawiki/linknx/index.php?title=Main_Page. Linknx wiki, 2012.
45
[21] Martin Kögler. Free development enviroment for bus coupling units of the european installation
bus. In BCU SDK Edtion, March 2011.
[22] android.com.
http://developer.android.com/resources/dashboard/platform-versions.html, 2012.
56
[23] wikipedia.org. http://en.wikipedia.org/wiki/android_(operating_system), 2012. 56
[24] android.com. http://developer.android.com/guide/basics/what-is-android.html, 2012. 57, 58, 59,
XIV
[25] wikipedia.org. http://en.wikipedia.org/wiki/dalvik_(software), 2012. 59
[26] android.com. http://developer.android.com/sdk/installing.html, 2012. 59
[27] android.com. http://developer.android.com/guide/developing/devices/emulator.html, 2012. 62
[28] android.com. http://developer.android.com/guide/topics/fundamentals/activities.html, 2012. 62
[29] android.com. http://developer.android.com/guide/topics/intents/intents-lters.html, 2012. 63
[30] android.com. http://developer.android.com/guide/topics/manifest/manifest-intro.html, 2012. 63
XIII
Abbildungsverzeichnis
1.1.
Grundsätzlicher Aufbau des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2.1.
KNX-Bussystem mit Steuerungsnetz und Stromversorgungsnetz[3]
. . . . . . . . . . .
7
2.2.
KNX-Leitung[6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.
Busklemme mit darunterliegendem Busankoppler am Beispiel eines Innentemperatursensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.
Adressfeld der physikalischen Adresse [7, Seite 49]
2.5.
Ereignis löst die Datenübertragung aus [7, Seite 50]
9
. . . . . . . . . . . . . . . . . . . .
12
. . . . . . . . . . . . . . . . . . .
14
2.6.
Aufbau eines Telegramms [7, Seite 50] . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.7.
KNX-IP Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.8.
ETS3-Hauptansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.9.
Temperatur Parameter bearbeiten
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.10. Gruppenadresse Temperatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.11. erfolgreiche Busverbindung
23
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.12. Programmierung der Busgeräte
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.13. Programmierknopf am Beispiel eines Auÿentemperatursensors . . . . . . . . . . . . . .
24
2.14. Busmonitor
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.15. Zennio ZAS Touchpanel [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.1.
Testboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2.
ABB Dimmaktor[11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.3.
ABB Schaltaktor [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.4.
Lingg&Janke Netzteil-Schaltaktor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.5.
Siemens 4-fach Taster[15]
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.6.
Siemens Taster-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.7.
Innenraumsensor KNX TH-UP basic weiÿ[17]
32
3.8.
Temperatursensor KNX T-AP[18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.9.
Samsung Galaxy Tab 10.1[19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.10. Aufbau bei der direkten Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.11. Aufbau bei der Kommunikation mittels Server . . . . . . . . . . . . . . . . . . . . . . .
36
4.1.
Netzplan des Systems
39
4.2.
Oberäche von phpMyAdmin
4.3.
Temperaturverlauf
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.4.
Feuchtigkeitsverlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.5.
Stromverlauf
51
4.6.
Aufnahme der Webcam
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.7.
Datenbankmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.1.
Oberäche von Android Ice Cream Sandwich
5.2.
Architektur von Android [24]
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
. . . . . . . . . . . . . . . . . . . . . . .
57
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
XIV
5.3.
Android SDK-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.4.
AVD-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
5.5.
Android Emulator
62
5.6.
Kommunikationsablauf zwischen der App und dem MySQL-Server
5.7.
Kommunikation mit dem Linknx-Server, nachdem der Verbinden -Button gedrückt wurde 72
5.8.
KNXApp-Logo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.9.
Menüführung der Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.10. Verbindungs-Menü
. . . . . . . . . . .
68
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.11. Einstellungen
5.12. Hauptmenü
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.13. Konguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
5.14. Beispiel: neues Gerät einfügen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.15. Kontextmenü des Gerätes Innen Temperatur . . . . . . . . . . . . . . . . . . . . . . . .
83
5.16. Fenster zum Verwalten der Räume und Stockwerke . . . . . . . . . . . . . . . . . . . .
84
5.17. Hinzufügen eines neuen Stockwerkes
84
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.18. Hinzufügen eines neuen Raumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
5.19. Grundriss mit zugewiesenen Räumen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
5.20. Raum wird einer Fläche im Grundriss zugeordnet . . . . . . . . . . . . . . . . . . . . .
86
5.21. leerer Raum ohne zugewiesene Geräte
. . . . . . . . . . . . . . . . . . . . . . . . . . .
5.22. Auswählen welche Lampe zugeordnet werden soll
. . . . . . . . . . . . . . . . . . . . .
5.23. Kontextmenü bei Klicken auf ein Element im Raum
5.24. Eigenschaften eines Gerätes (Innen Temperatur )
87
87
. . . . . . . . . . . . . . . . . . .
88
. . . . . . . . . . . . . . . . . . . . .
88
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
5.26. Dimmer steuern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.25. Lampe steuern
5.27. Sensordaten anzeigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.28. Webcam anzeigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.29. Raumübersicht am Beispiel des Wohnzimmers . . . . . . . . . . . . . . . . . . . . . . .
90
B.1. Organigramm des Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
V
B.2. Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VI
XV
Tabellenverzeichnis
2.1.
Prioritätscodierung[7, Seite 47] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.2.
Auszug aus den KNX-Datentypen [7, vgl. Seite 158]
. . . . . . . . . . . . . . . . . . .
17
3.1.
Technische Spezikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.1.
Hardwarekomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2.
Softwarekomponenten
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.3.
Ports des eibd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
A.1. Tabelle oors
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2. Tabelle rooms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I
I
II
II
A.5. Tabelle webcam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III
A.6. Tabelle log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III
IV
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XVI