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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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/ Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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] Michael Eder, Markus Hinterleitner 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- Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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] Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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: Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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/ Michael Eder, Markus Hinterleitner 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: Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner Seite 50 von 91 Diplomarbeit KNXApp Abbildung 4.4.: Feuchtigkeitsverlauf Abbildung 4.5.: Stromverlauf Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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] Michael Eder, Markus Hinterleitner 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: Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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] Michael Eder, Markus Hinterleitner 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] Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Folgende Klassen sind in diesem Package enthalten: 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 Michael Eder, Markus Hinterleitner 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/ Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Folgende Klassen sind in diesem Package enthalten: 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. Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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 Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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. Michael Eder, Markus Hinterleitner 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 A.3. Tabelle devices 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 Primary Key, Foreign Key room_name varchar(30) nein Primary Key, Foreign Key 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. A.4. Tabelle room_expand 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 A.7. Tabelle persist 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3. Tabelle devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.4. Tabelle room_expand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I I II II A.5. Tabelle webcam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III A.6. Tabelle log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III A.7. Tabelle persist IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVI