Department of Electrical Engineering and Information Technology Institute for Media Technology Distributed Multimodal Information Processing Group Prof. Dr.-Ing.
Author: Philip Parsch Address: Matriculation Number: Professor: Prof. Dr.-Ing. Eckehard Steinbach Advisor: Dipl.-Ing. Luis Roalter Prof. Dr. Matthias Kranz Begin: 05.10.2012 End: 01.03.
Department of Electrical Engineering and Information Technology Institute for Media Technology Distributed Multimodal Information Processing Group Prof. Dr.-Ing. Eckehard Steinbach Declaration I declare under penalty of perjury that I wrote this Diploma Thesis entitled Simulating and Deploying Home Automation Components in Intelligent Environments Simulation und Einsatz von Heim Automatiserungskomponenten in Intelligenten Umgebungen by myself and that I used no other than the specified sources and tools.
Kurzfassung In der Kurzfassung der Arbeit werden auf maximal einer Seite die Hintergründe, Motivation, Aufgabenstellung und Lösungsansätze und die die Ergebnisse zusammengefasst. Die Kurzfassung ist, sowohl auf Deutsch als auch auf Englisch, Bestandteil jeder Arbeit.
Abstract In the abstract, on a maximum of one page, the background, motivation, problem defition and pursued solution strategy are summarized. The abstract is in every thesis, in both English and German.
Contents Contents vi 1. Introduction 1 1.1. Motivation, Goals and possible Challenges . . . . . . . . . . . . . . . . . . . . . 1 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Related Work/Fundamentals 3 2.1. Intelligent Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Home Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1. Possibilities . . . . . . . . . . . . . . . . . .
CONTENTS 4.1.4. Ceramic antenna for WLAN vii . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1.5. Reprogramming of the RFM22B radio module . . . . . . . . . . . . . . . 41 4.1.6. Minor changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.1.7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2. Software Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3. Gateway driver . . . . . . . . . . . . . . . . .
Chapter 1. Introduction New technologies provide increased comfort and quality in all areas of our lives. With home and building automation, simple things like automatically raising the shutters in the morning as well as more complex environments can be created. Particularly noteworthy is Ambient Assisted Living (AAL), which enables the elderly and disadvantaged people to live independently.
Chapter 1. Introduction 2 Reuse: Already existing HA devices can be combined and reused. This reduces the installation time as well as overall costs. This work presents the integration of two exemplary HA systems, HomeEasy and Intertechno, to an IE that uses middleware ROS.
Chapter 2. Related Work/Fundamentals 2.1. Intelligent Environments Intelligent Environments (IE) are highly embedded, interactive spaces that aim to bring computation in to the real physical world [3]. They enhance the experience of everyday activities by integrating heterogeneously distributed sensor-actuator systems into the environment and provide ambient services. They attempt to hide the complexity of the system and enable natural interaction with it, such as voice, gesture, movement and context.
Chapter 2. Related Work/Fundamentals 4 2.2. Home Automation Home Automation (HA) describes the functionality provided by control systems to operate, supervise and regulate processes in private homes. It is a part of building automation with residential extension to match the needs of the home and its residents. HA aims to provide improved convenience, comfort, energy efficiency and security, through the provision of different services, such as intelligent automatic controls and graphical user interfaces.
Chapter 2. Related Work/Fundamentals 5 such as multimedia and entertainment features. However, these services play an important role in domestic life, consequently there are many HA systems that provide a wide range of these services.
Chapter 2. Related Work/Fundamentals 6 and take a picture of him. However, such disturbances can be prevented by simulating activities in the house by switching lights on and off or by making noises. These examples demonstrate the diversity of HA, by showing only a small part of all possibilities. Technical innovations and an expanding product range will reduce limitations step by step and enable its users to allow their dreams to come true. 2.2.2.
Chapter 2. Related Work/Fundamentals 7 two actuators. Connections are unidirectional, which means that actuators cannot send signals but just receive them. Due to the missing acknowledgement, sensors do not know, if the actuators received their signals and if they have switched to the desired state. Examples are Intertechno (section 2.2.4 on page 14) and HomeEasy (section 2.2.4 on page 12). In the network on the right hand side of figure 2.2, all nodes are connected bidirectionally over a bus-system.
Chapter 2. Related Work/Fundamentals 8 Security: Wireless systems are generally more insecure than comparable wired solutions. The wireless media can be easily accessed by unwanted listeners or other interfering systems. Most systems encrypt their data, but low-cost hardware often does not have this feature. Hence, this offers the possibility for attacks and vandalism.
Chapter 2. Related Work/Fundamentals 9 control of home appliances over the existing power grid. X10-based devices are inexpensive and easy to install and are therefore very popular, especially in North America. Power line Communication (PLC) offers good flexibility, allowing the user to relocate their devices to some extent. Nevertheless, X10 is not as flexible as comparable wireless systems, since the device must be placed near power plugs.
Chapter 2. Related Work/Fundamentals 10 ing machines, involving more complex controls. Other HA systems usually can only switch these devices on or off.
Chapter 2. Related Work/Fundamentals 11 ZigBee ZigBee is a specification for a suite of high level communication protocols based on IEEE 802.15.4 [14]: A Developing Standard for Low-Rate Wireless Personal Area Networks. It is targeted at applications that require a long battery life, secure networking and low data rates. Application and device profiles such as Home Automation, Smart Energy, Health Care and many others are provided to simplify the configuration effort of an installation.
Chapter 2. Related Work/Fundamentals 12 HomeEasy HomeEasy (HE) is a simple wireless home automation system produced by the British company CH Byron 5 . It is designed for simple tasks such as switching lights on and off and time scheduled switching; complex controls cannot be realized. HE devices are inexpensive and can often be found in local hardware stores. The product range includes devices to control: • Lights: on/off switching and dimming.
Chapter 2. Related Work/Fundamentals 13 connected until the memory is cleared by a manual reset. If the memory was full, connection will fail. Data is transmitted via 433.92 MHz using OOK modulation. Connections are unidirectional, which means that participants can either send or receive. As a result, transmitters are not aware of each other and the receiver cannot acknowledge received messages. This lowers costs, because radio modules are simpler, but it also leads to increased unreliability.
Chapter 2. Related Work/Fundamentals 14 "0" 980 "1" 320 320 980 275 1320 UK 275 275 EU Figure 2.6.: The bit timings of the UK and EU protocol types in µs. two address parts. It is uncertain which part of the address represents the group or the device code, however, bit 48 and 49 obviously describe the state code. on: 1100011110011011000111101001110001111101001101110011000111 off: 1100011110011011000111101001110001111101001101101011000111 fixed adress1 state adress2 Figure 2.7.
Chapter 2. Related Work/Fundamentals 15 There are two different types of devices: The classic system, which uses manual address selection and a newer system with learning function. In this work, only the manual system is considered. Figure 2.8.: Two IT receivers: classical devices with manual address selection on the left and a newer one with learning capability on the right. (source: www.intertechno.
Chapter 2. Related Work/Fundamentals 16 systems, above all to Asian products, where this IC is widely used due its low cost. This makes it possible to upgrade an automation system with non-Intertechno devices. Nevertheless, reliable cooperation cannot be guaranteed. IT devices form loosely connected networks, in which transmitters are normally linked to just one or two receivers. Due to the manual addressing, each device can theoretically be connected to an infinite number of counterparts.
Chapter 2. Related Work/Fundamentals Input Vss: „00” Input Vcc: „11” Input Float: „01” Sync: „0” Figure 2.11.: All possible bit combinations.
Medium Network size Data rate Range indoor[m] Range outdoor[m] Bi-/Unidirectionally Security Costs Connectivity Installation overhead RF 433 MHz 28 100 bit/s 5 30 uni none low low low RF 433 MHz 245 500 bit/s 5 30 uni none low low low PLC, RF 433 MHz 28 20 bit/s 30 (X10RF) 100 (X10RF) uni/bi none low low low X10 RF 868 MHz 232 125 kBit/s 30 300 uni/bi low high low low EnOcean RF2.4 GHz 216 250 kBit/s 10 75 bi medium (AES) medium medium low ZigBee Table 2.1.
Chapter 2. Related Work/Fundamentals 19 2.3. Home Automation Gateways A gateway is a linking device between two or more different network technologies. It provides unified interfaces and protocol conversion methods to enable different participants to communicate with each other. The gateway implies an abstraction layer, as the participants do not have to know details about the protocol and characteristics of the other side.
Chapter 2. Related Work/Fundamentals 20 Figure 2.12.: Three different gateways: RFXtrx433, TellStick and CUL. RFXCOM RFXtrx433 8 : USB transceiver for 433 MHz systems with an integrated antenna. It is supported by a great deal of commercial automation software and knows a very large number of different wireless protocols. A built in CSMA-CA mechanism enables collision detection and automatic resending of lost data packets.
Chapter 2. Related Work/Fundamentals 21 data between its interfaces, for example USB to SPI. Due to the integrated WLAN module, it can be accessed and controlled via internet without the need of an external computer. It has a low power consumption, an average of 0.5 W. Figure 2.13.: The WifiControl 433. 2.3.2. Comparison There are still much more devices on the market than the ones presented, but these give a good overview of available possibilities.
Chapter 2. Related Work/Fundamentals 22 2.4. Middleware Middleware describes software that facilitates data exchange between applications within the same environment, or across different hardware and network environments. It forms an abstraction layer that hides complexity and allows communication, without having detailed knowledge of the internal structure of the opposite site [16]. In addition, middlewares often come with tools and services to manage, monitor and administrate the system.
Chapter 2. Related Work/Fundamentals mBS Smart Home 11 23 is a platform-independent, Java-based framework, based on the OSGi middleware. It is optimized for use in embedded products, such as routers, gateways and mobile phones, and offers an SDK and other tools for product development. Various automation systems are supported such as ZWave, ZigBee, UPnP, KNX, X10, and another set of external hardware, for example Webcams.
Chapter 2. Related Work/Fundamentals 24 The philosophical goals of ROS can be outlined as13 : • Peer-to-peer topology avoids a central communication server, which will cause unnecessary traffic and can be problematic in heterogeneous networks. • Tools-based: As ROS is based on an adapted microkernel, it offers a large number of small tools to run and build ROS components as well as tools to manage complex systems.
Chapter 2. Related Work/Fundamentals 25 Services are for communication between two nodes, whereas topics are for many-to-many communication. Nodes can host a service server under a string name and a client can send a request and wait for the response. Services are composed of a name and a request and response message. They are synchronous and therefore do not abstract sender and receiver.
Chapter 2. Related Work/Fundamentals 26 There exist further useful tools and functions: Logging and Playback: ROS supports two different mechanisms for logging and playback of data: the rosout topic and bag files. The first mechanism is a topic called rosout. It will display information sent from all nodes and save them in textual log files. The second mechanism is called rosbags. In contrast to rosout, bags allow the storage of all published messages, not only the output of specific logging functions.
Chapter 3. Concept This chapter covers basic concepts and ideas about the integration of Home Automation (HA) components in Intelligent Environments (IE). It aims to give an insight into the decisions made to improve general understanding and prepare the reader for chapter 4 on page 36. 3.1. Basic structure Modern environments are often equipped with different technologies.
Chapter 3. Concept 28 These modules can only be used as a whole; no direct intervention is possible allowing communication only before or after the module. This strict division results in increased flexibility, allowing evaluating or changing each module separately. This is favourable for simulation or debugging, as every module can be replaced with a simulation or logging program that replaces the functionality.
Chapter 3. Concept 29 3.2. Hardware Many different HA systems are available on the market, but in this work only two of them are considered: HomeEasy (HE) and Intertechno (IT). HomeEasy was chosen because it has already been used at the research group.
Chapter 3. Concept 30 The device manager node connects HA protocols with a set of data, which contains the most important information about the device. The data is stored in a XML database. Special lookup and control functions allow the HA system to be managed by changing entries in the database. Thus, the device manager allows device handling without knowledge of their protocol codes and types (HE or IT) as well as keeping track of the current state of each device.
Chapter 3. Concept 31 devicelist wlan usb gateway_driver protocol data devicemanager visualization & namespace requests n/devicelist n/requests database database Hardware Protocol Device Namespace IT 000AA8 Protocol: IT Code: 000AA8 name: table_light type: light state: on location: myroom name: myroom/table_light state: on last seen: today, 12:20:48 Figure 3.4.
Chapter 3. Concept IT 000AA8 gateway protocoltype: IT data: 000AA8 gateway_driver 32 name: "table_light" id: 12 description: "light on my table" protocol: IT type: "light" state: off on default_state: off senderID_list: 3, 4 default_sender: 3 changed_by_ID: 3 3 myroom/table_light changed_to: on sender_used: myroom/remote1 visualization name: "remote1" id: 3 description: "Philip's remote" protocol: IT type: "remote" onCode: "000AA8" offCode: "000AA0" current time: 11:24 date+time date: 16.02.
Chapter 3. Concept 33 The assignment in different structures makes certain assumptions: On the one hand, transmitters do not have a state, which corresponds to IT and HE. Instead, they store the date and time of the last action, which are continuously updated. On the other hand, receivers do not have any on/off-codes and are therefore associated with transmitters that have these codes. This linkage grants both sides access to the data of the other side.
Chapter 3. Concept 34 low range and the range of the gateway is limited as well. The use of various gateways enables the control of larger systems and therefore the database will increase its size which will have a negative impact on the overall performance - more later on. The low data rate of the IT and HE systems is also beneficial for the performance of the software. Figure 3.6 shows the various transmission times.
Chapter 3. Concept 35 feature was not implemented. Nevertheless, it can easily be set up as another node on top of the software stack.
Chapter 4. Implementation This chapter deals with the implementation of the concepts as presented in the chapter 3. 4.1. Gateway There are many different suitable gateways on the market to connect both IT and HE to a computer. However, the decision was easy because the author chose his own gateway, the WifiControl 433, which was developed in the student project "Implementation of an Ethernet gateway for wireless home automation". It has already been introduced in section 2.
Chapter 4. Implementation 37 +5VDC RTC Power SPI USB FT232 USART RN171 WLAN USART XMEGA RFM22B usb-serial bridge 433MHz expansion port SPI 3 USART 22 I/O-Pins Figure 4.1.: The structure of WifiControl 433: The centerpiece is an Atmel ATXMega192A3, an 8 bit microcontroller, which is connected to peripheral hardware, such as a WIFI module, a USB-serial bridge and a 433 MHz radio. WLAN state JTAG USB Power WLAN operational LED expansion port RTC 433MHz radio Figure 4.2.
Chapter 4. Implementation yes hi false connect? PARSE ISR no true med USART, SPI reception 433Mhz reception, time control low helping functions, RTC normal data transmission, core priority buffer empty? 38 CONNECT Figure 4.3.: The program core on the left and the priority table on the right. The program core is an infinite loop for basic data management and processing.
Chapter 4. Implementation 39 Figure 4.4.: The WifiCtrl on the left and the MiniCtrl without its antenna on the right. Both models were generated by eagle3d and rendered with MegaPOV. Each version addresses different user groups: WifiCtrl is designed to offer the full scope of functions for professional use, whereas the MiniCtrl is a light weighted version of WifiCtrl with no WIFI, which is mainly designed to be low-cost and of small size.
Chapter 4. Implementation 40 4.1.3. USB-serial-bridge Replacement The USB-serial-bridge FT232RL was initially selected because it can easily be integrated into the circuit via serial interface and relieves the firmware due to its own processing unit and prefabricated functions. However, it is highly priced and can only operate as a virtual serial device. To reduce the costs and increase the flexibility of the USB, the ATXMega192A3 was replaced by a newer version with USB connectivity.
Chapter 4. Implementation 41 Another drawback of using the internal USB hardware, is the high memory use of almost 2 kB RAM and 10 kB ROM. The big ATXMega192A3U has enough memory to handle this, but it will cost 30% of ROM and 50% RAM of the small ATXMega32A4U. Therefore, the MiniCtrl firmware had to be optimized for memory, otherwise the code size was greater than the available memory.
Chapter 4. Implementation 42 RFM22B is a low-cost transceiver with a large functional range. Basically, it consists of the IC SI4432 from SiLabs with a preceding filtering circuitry. During normal operation, the configuration and data transmissions are done via SPI; however, in our case the module is put into the so-called "Direct Mode", which allows direct data transfer through IO pins. Some of these IO pins can serve as an output for interrupt notifications or important status messages.
Chapter 4. Implementation 43 result, not all data can be obtained and a compromise must be made, whether weak or strong signals are preferred. In this work, the settings were adjusted for medium range, allowing sense devices up to 50 cm to the gateway as well as enabling long ranges up to 10 m (indoor). Devices that are switched within this 50 cm range can be detected, but reliable detection is not guaranteed. Another disadvantage of the dynamic reference voltage is the ambient noise during intermissions.
Chapter 4. Implementation 44 Figure 4.9.: Different data streams recorded with the scanalogic 2 logic analyser. The blue trace is the reference data received with a RF Link receiver, the other three traces are from the RFM22B. The time delay between the reference and the deglitched output is due to the filtering algorithm. It is easy to recognize the impact of the AGC, as it causes rustling during intermissions or longer breaks.
Chapter 4. Implementation 45 time between now and the last call are measured to get the duration of each level. These times are then compared with a table consisting of the bit timings of HomeEasy and Intertechno (see figure 2.6 on page 14 and figure 2.11 on page 17) and at a match the state and the protocol type will be saved for the next function call.
Chapter 4. Implementation 46 Optimizations: The overall performance increased because of small changes in the structure and reprogramming of time consuming functions. 4.1.7. Conclusion Both WifiCtrl and MiniCtrl are an excellent choice for use in home automation or as a connection to intelligent environments. They are low-cost, multi purpose gateways which offer a wide range of functionality that is not customarily provided by devices of its kind.
Chapter 4. Implementation 47 4.2. Software Basics The next sections cover the implementation of the three ROS Nodes: gateway driver, device manager and visualization. In order to improve the general understanding, this section provides a short introduction of the used software and the Qt signal/slot mechanism. All nodes are implemented in C++ using the following external software: QT framework: Qt is a multi lingual, cross-platform application and UI framework.
Chapter 4. Implementation 48 Currently, only the gateways MiniCtrl and WifiCtrl are supported, but more gateways can be added because the software provides a template class. Figure 4.11 shows gateway driver with its interfaces. connect refresh serial gateway driver tcp protocol output other output raw output other protocol input subscriber raw input publisher service Figure 4.11.: The gateway driver with its ROS interfaces.
Chapter 4. Implementation 49 come from the interface converter service or the "send usb" and "send wlan"-command. Raw output: Emits all incoming data from the gateway. Equals an addition of the topics other output and protocol output, except that the HA messages are outputted in their raw string format. Raw input: sends all data directly to the gateway without further processing.
Chapter 4. Implementation 50 the RFM22B, the output streams are sometimes fragmented during CPU intensive tasks, such as the reception of HA protocols. These fragments are shorts breaks in the continuous data stream and cause the QextSerialPort to break it into smaller pieces sometimes. However, this problem does not occur with other serial programs.
Chapter 4. Implementation add receiver/ remove sender change 51 get device_list set switch receiver/ sender save device changed protocol input database changed device manager database changed protocol output switch receiver switch sender service subscriber publisher Figure 4.13.: The device manager with its ROS interfaces. by a call of remove and add, but this can unintentionally change the device ID. Calling the change service, however, will keep the device ID.
Chapter 4. Implementation 52 by the "switch sender/receiver"-services and topics. However, if the state was changed by direct manipulation via the "add/remove/change"-services, no message is published. Database changed: The "database changed"-publisher publishes a message, every time a database entry is changed by the "add/remove/change"-services to enable automatic synchronization of other device manager instances.
Chapter 4. Implementation 53 other thread is ready to exchange data. As a result, they are only suitable for large data transfers, such as the device list exchange within the “get device list” service. Small data exchange is best done via signals and slots, as signals are buffered and the thread has not to wait. Buffering large amounts of data would be slower than waiting for the other thread to finish its current operations, consequently both functions were used.
Chapter 4. Implementation 54 device ID to optimize the seek time. When accessing the database with those keys, the device ID is first fetched from the corresponding ID-conversion list and then the device structure is obtained with it. Otherwise, every entry of device list would have to be searched, which would be very slow. Pointers instead of the ID cannot be used in this case, as the QHash container changes memory addresses with each copy.
Chapter 4. Implementation receiver sender HE 1 IT 1 55 receiver sender receiver sender IT 1 HE 1 IT 1 HE 1 HE 2 HE 2 IT 2 IT 3 network 1 network 2 network 3 Figure 4.16.: Three different HA networks with connections between IT and HE devices. one of the difficulties of protocol translation: The on/off-code of the default transmitter can change further receivers and trigger other protocol translations.
Chapter 4. Implementation 56 MainWindow: The MainWindow is the graphical framework in which the two previously mentioned classes are embedded. It contains a set of functions and minor classes for basic functionality, such as graphical tools for manipulating the device database and logging. These three parts are described later in more detail in separate sections.
Chapter 4. Implementation 57 Switch receiver/sender: These services provide similar functionality as the "switch receiver/sender"-services from the device manager, but are able to resolve namespaces. You can either switch the device by sending only its name, such as "device1", or its full name with namespace, such as "scene1/device1". Get device: This service provides similar functionality as the "get device"-service from the device manager, but is able to resolve namespaces.
Chapter 4. Implementation 58 visualization main MainWindow visualization menu rosnode ros scene menu device manager XML database thread 1 thread 2 Figure 4.18.: The internal structure of the visualization node. 4.5.1. The MainWindow class The MainWindow class is the graphical framework for other graphical classes, such as the scene menu, visualization menu and is used here as a collective term for different classes and functions that do not belong to those two.
Chapter 4. Implementation 59 Figure 4.19.: The MainWindow displaying the start menu. manager node, the import function can either replace or merge the internal database with an external one. In case of merging, the “keep conflicting data”-checkbox asks whether conflicting elements should be ignored or accepted. The receive box is a logging output that displays messages whenever receivers are switched, an error occurred or an important operation has finished.
Chapter 4. Implementation 60 Figure 4.20.: The receiver dialog on the left and the transmitter dialog on the right. 4.5.2. Visualization Menu The visualization menu is a class for displaying the database of the device manager to provide a quick overview of the connections between devices and their state. Devices are listed in a simple tree model, which allows a clear and easily understandable structure and prevents overlapping connection arrows in more complex HA systems.
Chapter 4. Implementation 61 Figure 4.21.: The visualization menu showing the database in receiver view. reason, the visualization node contains a local copy of the database, in order to prevent high data traffic to the device manager node and to speed up access times. In order to further increase the overall performance, two QMultiHash containers were implemented to allow fast accessing single elements of the QGraphicsScene, as it does not provide functions for effectively searching for items.
Chapter 4. Implementation 62 user QGraphicsView QGraphicsScene key1: value1 key2: value2 receiver item receiver item sender item QMultiHash keyN: valueN key1: value1 key2: value2 sender item QMultiHash keyN: valueN Figure 4.22.: The main elements of the visualization menu. QGraphicsView is used to display the QGraphicsScene, which contains custom receiver and sender items for rendering.
Chapter 4. Implementation 63 Figure 4.23.: The scene menu with the example scene "dormitory", which contains three receivers: a light, a power plug for a computer and another power plug. A green background means the receiver is switched on, red means it is switched off. information of a selected element and offers functions to toggle its state or remove it from the scene. Figure 4.24.: The three tabs on the bottom right corner of the scene menu (see figure 4.23).
Chapter 4. Implementation 64 The internal structure of the scene menu is similar to the structure of the visualization menu, except that no QHash containers were used, as the scenes contain usually less than 30 elements. Only the handling of the background image was optimized in order to prevent lags between scene changes. All scenes are saved in a memory based database as shown in figure 4.25.
Chapter 5. Evaluation This chapter deals with the evaluation of different parts of the system. Two test scenarios are described, one office and one home environment as well as various simulations to test the system’s performance. 5.1. Benchmarking The individual components of the software were tested in terms of their latency, processing time and memory usage. All tests were performed on an Asus UL30VT-QX061V laptop with an Intel U7300 processor with 2 x 1.3 GHz and 4 GB Memory, running the Ubuntu 12.
Chapter 5. Evaluation 66 The following sections describe the benchmark results for each node in more detail. Each publisher, subscriber and service was called at least 100 times and the measured processing times were recorded and averaged. Gateway Driver: The gateway driver was tested with valid and faulty data from the simulation node and the WifiCtrl gateway.
Chapter 5. Evaluation 67 protocol_out 10.4ms gateway driver device_changed 1.8ms visualization & namespace devicemanager 45.8ms protocol_in device_changed_ns 2.2ms 7.8ms switch_device simulation node 6.9ms switch_device_ns Figure 5.2.: The latency of the complete system. Each time was measured 100 times and has been averaged. During normal operation, the maximum number of received protocols during a certain time is limited to a small number (see figure 3.6 on page 34).
Chapter 5. Evaluation 68 Office Window2 Contact switch Desk Window Table lamp Desk Contact switch PC Window1 Home Remote Lamp2 PIR Remote PIR central lamp PC Bed Lamp1 Door Light Door Contact switch switch remote A B PC light switch lamp1 lamp2 Contact switch Bedside lamp Light switch A remote B C D bedside lamp table lamp PC light switch central lamp Figure 5.3.: The structure of the software chain for testing the performance of the different nodes.
Chapter 5. Evaluation 69 IMAGE MISSING TEXT MISSING transmitter office day 1 day 2 on off on off home day 1 day 2 on off on off window contact door contact remote A remote B remote C remote D PIR light switch door 2 24 1 1 0 0 37 1 5 20 4 3 2 0 48 4 3 24 1 1 0 0 43 1 2 28 2 2 0 0 87 2 2 15 0 0 0 0 80 2 Table 5.2.
Chapter 6. Conclusion The goals of this work have been achieved: The presented soft- and hardware chain provides a unified framework between Intelligent Environments (IE) and two Home Automation (HA) systems Intertechno (IT) and HomeEasy (HE). The first part of this chain is a HA gateway that was adapted from a previous work of the author. Its disadvantages were almost completely eliminated and it is now a commercially viable system, which will further support its distribution.
Appendix A. Message, Topic and Service Files A.1.
Appendix A. Message, Topic and Service Files 72 A.2.
Appendix A.
Appendix A.
Appendix A. Message, Topic and Service Files 75 A.3.
Appendix B. Databases 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
Appendix B. Databases 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 < s c e n e l i s t>
/ b i n / i m a g e s / d o r m i t o r y .
X bytes (default 80) X µs with no data reception (default 2500 µs) occurrence of char ’X’ (default ’\0’) X = port Y = pin Z = level returns ’0’ or (A,B,C,D) (0..7) (0..1) ’1’, pin has high-impedance set spi close get spi set spi X Y set usartXY close get usartXY set usartXY Z X = mode (SLAVE, MASTER) Y = prescaler (2,4,8,16,32,64,128) close SPI and release IO pins returns connection state and prescaler X = port (C,D) Y = number (0..1) Z = baud rate (300..
protocol X date dd.mm.
List of Figures 2.1. Possible applications at home. (Adopted from: http://www.lingg-janke.de/ uploads/pics/eib-system-viele-funktionen.jpg . . . . . . . . . . . . . . 5 2.2. Two HA systems with different topologies: The left one is a loosely connected system, where each transmitter is assigned to only one or two receivers. The right system uses a bus network that connects the devices bidirectionally to each other. 6 2.3.
LIST OF FIGURES 81 3.3. The software part of the communication chain, which contains three ROS Nodes. ROS serves as a link between the nodes connecting them and offering the interfaces for the IE. The gateway, however, is not directly connected to ROS; instead it is connected to the gateway driver node, which allows indirect access over ROS. . . 29 3.4.
LIST OF FIGURES 82 4.9. Different data streams recorded with the scanalogic 2 logic analyser. The blue trace is the reference data received with a RF Link receiver, the other three traces are from the RFM22B. The time delay between the reference and the deglitched output is due to the filtering algorithm. It is easy to recognize the impact of the AGC, as it causes rustling during intermissions or longer breaks.
LIST OF FIGURES 83 5.2. The latency of the complete system. Each time was measured 100 times and has been averaged. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.3. The structure of the software chain for testing the performance of the different nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
List of Tables 2.1. The presented automation systems at a glance. . . . . . . . . . . . . . . . . . . 18 2.2. The differences between the presented gateways. . . . . . . . . . . . . . . . . . 21 4.1. The differences between WifiControl433, WifiCtrl and MiniCtrl. . . . . . . . . . . 39 5.1. The averaged benchmark results of the visualization node. . . . . . . . . . . . . 66 5.2. caption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
List of Acronyms IE Intelligent Environment HA Home Automation IT InterTechno HE HomeEasy HVAC Heating, Ventilation and Air Conditioning PLC Power Line Communication RTC Real Time Clock ISR Interrupt Service Routine FIFO First-In-First-Out PCB Printed Circuit Board MCU MikroControlling Unit ESD ElectroStatic Discharge EMI ElectroMagnetic Interference ASF Atmel Software Framework CDC Communication Device Class HID Human Interface Device AGC Automatic Gain Control GUI Graphi
Bibliography [1] M. Kranz, T. Linner, B. Ellmann, A. Bittner, and L. Roalter, “Robotic Service Cores for Ambient Assisted Living,” in 4th International Conference on Pervasive Computing Technologies for Healthcare (PervasiveHealth2010), pp. 1–8, Mar. 2010. [2] M. Weiser, “The Computer for the 21st Century,” Scientific American, vol. 265, no. 3, pp. 94–104, 1991. [3] M. H. Coen et al., “Design Principles for Intelligent Environments,” in Proceedings of the National Conference on Artificial Intelligence, pp.
BIBLIOGRAPHY 87 [12] KNX Association, KNX System Specifications, v3.0 ed., Jul. 2009. [13] A. Anders, “Energy for free - wireless technology without batteries,” 2006. Whitepaper. [14] E. Callaway, P. Gorday, L. Hester, J. Gutierrez, M. Naeve, B. Heile, and V. Bahl, “Home networking with IEEE 802.15.4: a developing standard for low-rate wireless personal area networks,” Communications Magazine, IEEE, vol. 40, pp. 70 – 77, Aug. 2002. [15] S. C. Ergen, “ZigBee/IEEE 802.15.4 Summary.” http://pages.cs.wisc.
BIBLIOGRAPHY 88 Proceedings of the 5th ACM/IFIP/USENIX international conference on Middleware, pp. 397– 416, Springer-Verlag New York, Inc., 2004. [25] M. Quigley, E. Berger, A. Y. Ng, et al., “STAIR: Hardware and Software Architecture,” in AAAI 2007 Robotics Workshop, Vancouver, BC, 2007. [26] M. Quigley, B. Gerkey, K. Conley, J. Faust, T. Foote, J. Leibs, E. Berger, R. Wheeler, and A. Ng, “ROS: an open-source Robot Operating System,” in ICRA workshop on open source software, vol. 3, 2009. [27] B. C.
