Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AndroidAppReport

206 views

Published on

  • Be the first to comment

  • Be the first to like this

AndroidAppReport

  1. 1. MyHome: Smart Home Control System Akchay Srivastava, Christopher Liffner, Icaro Alzuru University of Florida {a.srivastava, cliffner, ialzuru}@ufl.edu 1. Introduction and Motivation Smart Phones, Smart TVs, Smart Watches, and other Smart gadgets seem to be creating a vogue to add friendly internet and computational capabilities to any device. Houses or homes (as a whole unit) seem to have fallen behind of this smart fever and there are different points of view about what is considered a Smart Home. Some authors [1] consider a Smart Home like a self-maintained entity which tells you automatically when to pay the bills or what food to buy. Other authors [2], consider that it should be a high tech, ecological and always-convenient entertainment center, and that it should be able to respond to environmental changes. We believe in part of these interpretations but we think they are separated applications and not a holistic point of view of what a Smart Home should be. Nowadays we see that there are smart appliances in our homes, like smart refrigerators or smart TVs, but the house is not conceived like the entity that is going to be “Smartified”: The Smart Home is today a group of expensive gadgets that do not collaborate or work together in behalf of specific and global goals. We present a system: MyHome, a small and simple Cloud based Android application, which establish the starting point of what it can be a real and complete Smart Home System. MyHome permits to supervise and manage the state of some simple elements of the house, but what is most important, it permits to define smart actions to events and allows the user to interact and react in a more intelligent way to what is happening in the house. The system comes with some predefined common actions to certain events, but allows users to set their own actions, like alarms or changes in the status of other devices. This freedom in the action's settings permits the user utilize the system with multiple objectives in mind: saving energy, helping somebody with disabilities, saving time, easy your life, remembering things, improving the security of the home, controlling some appliances remotely, and in general MyHome expands the possibilities of what people can do with their homes. The approach consists in creating a network of sensors and actuators for some devices in a home, all these devices are connected to a central unit, implemented through a Raspberry Pi (RPi) computer with a XBee Radio Frequency module. The central unit uses the sensors to get the changes in the state of the devices, this activity is registered in a database in the Cloud, implemented with Google App Engine. An Android application shows the user the state of the devices and allows him/her defining and executing actions over them, these actions are passed to the central unit through the cloud database. 2. Related Work In [5], the authors classified smart home network technologies into two types: 1) Wiring systems, and 2) Wireless systems. Nowadays, it could be considered bothersome or inappropriate asking the client to cable all his/her home in order to control some devices. In MyHome we use XBee wireless modules because of their range and resilience to interferences. [13] In [6], the authors have proposed a project known as smart home energy management system using IEEE802.15.4 and ZigBee developed smart home control system. The project is based on two main considerations 1) energy savings and 2) user happiness. It minimizes the domestic energy waste and can be adapted according to the user habits. Wires from the lighting control were removed which lead to significant savings in installation. In our project too, we have not used any wires for interconnection. We have used Wifi card or Xbee for the same. In this project, when a person entered a room in the daytime, the system opened the drapes instead of turning ON the lights, but in the night the lights were turned ON
  2. 2. when a person came in and they were turned off when there was no one in the room. Thus energy was saved. In our app, we have tried to integrate the different components of the Smart Home but we have not used the energy-saving aspect extensively, instead kept the system simple and financially reasonable. For example, in our project if a person enters the room, then the light will be switched ON and when a person leaves the room, then the light will be switched OFF. Thus we are also applying energy-saving but on a smaller scale. In [7], the authors have proposed a system known as Framework for Cloud-based smart home. The cloud provide web services. There were six main applications which were environmental, security, entertainment, domestic appliances, information and communication and health. This project is really good for future demands as all of today’s data is gradually moving to the Cloud. The system can quickly adapt to changing load requirements. Our project is much simpler than this project and serves useful for those people who do not want/can’t afford all the extravagant services, but instead just want to control the lights or camera or movements. Our project also makes use of Cloud-based services. In [8] the authors have proposed a project known as Computer-aided design software for smart home device based on cloud computing service. The project offered visual simulation by applying the interface to construct a real smart home. In our project, we are not using any visual simulation because providing such a facility requires use of newer, complex and expensive technology. The major difference between other projects and our project is based on the idea of “Integration among different components of the Smart Home”. In many projects based on Smart Home, the Smart Home consists of really expensive smart devices and smart appliances which are saving energy or doing actions which are smart. But these devices tend to work independently and separately without cooperation. In this project, we have tried to amalgamate and integrate all of the components together. For example, if a person enters the room (known by movement sensors) then the lights will be switched ON (lights control) and the camera of the room will be switched ON too (camera control). What we are trying to do is to let the devices talk among themselves and cooperate with each other in activities. We have tried to keep the cost of the system to be extremely reasonable (so that everyone can buy it) and at the same time tried to provide the most important functions of controlling and monitoring lights (for people having disability), cameras (for security) and movements (for energy-saving). Moving ahead, let us now talk about the different Android Apps which have been launched in the marketplace. The first one is Control4 MyHome mobile app. Our app is very similar to this app, except that Control4 Myhome app is more extensive in the sense that the user can control temperature, television, microwave and other home appliances. Any interested user has to buy the entire kit even if he just wants to control the lighting of the home. This is a disadvantage in terms of cost. The Control4 MyHome app makes use of wireless Control4 switches, wireless Control4 dimmers, Control4 fan speed controller and all equipment’s of Control4. On the other hand, our application is generic in the sense that we make use of a standard bulb and a standard manual switch. The only extra thing required is some hardware like Xbee and Relay for wireless communication. Keeping in mind the time limitation, simplicity, and cost our app just focuses on controlling the lights, cameras and movements of the home. Next comes, another app known as Belkin Wemo app for Android Home Automation. All of the equipment’s used by this app is of Wemo. It uses Wemo light switch, Wemo switch and Wemo Motion. This app focuses mainly on controlling the lights of the home and some other electronic appliances like fans and heaters. The app is similar to our app, in terms of simplicity and expected cost. 3. System Architecture We provide a large-scale view of the system design in Figure 1. To best demonstrate the flow and function of the system, two examples will be presented. The first example will show the system flow of a user initiated command. The second example will demonstrate the flow of an automated feature of MyHome. Let’s suppose the user is out of the house and wishes to turn on an outside light as night approaches. She accesses the MyHome app on her smartphone and selects the appropriate option. The smartphone sends the state change command to the MyHome Cloud, where both user settings and sensor information are stored.
  3. 3. Figure 1 – System flow. The user’s light activation command is transmitted to her modem at the house. The Raspberry Pi is wirelessly connected to the modem and receives the command. From this point, the Raspberry Pi communicates with the Coordinator XBee, to which it is directly connected. The Coordinator XBee sends the command to the appropriate Remote XBee. In this case, the Remote XBee is wired to the outlet which provides power to the outside light the user wishes to turn on. The Remote XBee sends the appropriate signal and activates the light. The automated features of MyHome involve the storing of sensor data in the cloud. Any peripheral sensors integrated into the MyHome system would essentially flow counter to the first example. The sensor would be connected to a Remote XBee and the information would be stored to the cloud via the previously mentioned path. However, the camera, being that it is connected directly to the Raspberry Pi, is unique and merits a brief example. By default, the camera is set to record upon motion detection. Let’s suppose the user is expecting a package, but is away from the house. When the mail person arrives to drop the package off, the motion sensor will detect movement. This sensor is connected directly to the Raspberry Pi. The Raspberry Pi will send the command to start recording to the camera. The data recorded by the camera will be sent back to the Raspberry Pi. This data will be uploaded to the cloud via the modem. At this point the user will be able to view the video and confirm delivery of the package. 3.1 Hardware This section presents the hardware of the MyHome system. While a modem and smartphone are essential to the function of the entire system, they are not designed or provided by MyHome and are not considered MyHome hardware. Similarly, a cloud server is required to store data, but the hardware of the server will not be discussed. The Central Unit is comprised of the Raspberry Pi (RPi), camera, motion sensor, and Coordinator XBee. There are primarily two types of end devices – the outlet and the sensor. Both types include a Remote XBee. 3.1.a. Raspberry Pi From a hardware perspective, the Raspberry Pi is the brains of the system. Commands are sent from the Raspberry Pi and sensor data is transmitted to it. It provides a GPU to better handle the high-definition video from the camera.
  4. 4. It also has WiFi capability (with the addition of a WiFi dongle) allowing for a more flexible system. The Raspberry Pi model B was selected over the model A for its additional memory (512 MB vs 256 MB), which may be helpful in handling the video data. 3.1.b. Camera and Motion Sensor A camera and motion sensor are connected directly to the Raspberry Pi. The primary objective of the motion sensor is to activate the camera. However, it could potentially be used for other functions, such as turning on a light. Because the camera is wired to the Raspberry Pi, a fast and reliable transfer of data is achieved without any additional WiFi requirement. 3.1.c. XBee RF Modules We use 1 mW series 1 XBee RF Modules in our system. These units have a range of 100m and use a 2.4GHz frequency. MyHome does not require complicated mesh networks and therefore does not require the series 2 models. The Coordinator XBee is connected directly to the Raspberry Pi via the GPIO pins. This XBee is responsible for taking the commands of the Raspberry Pi and transmitting them to the appropriate Remote XBees. Additionally, the Coordinator XBee also receives sensor data from the Remote XBees and sends this to the Raspberry Pi. In the outlet style end device, the unit consists of a Remote XBee, 120V AC to 3.3V DC transformer, as well as a 120V wall outlet and a relay. The relay allows the Remote XBee to activate or deactivate the outlet. The XBee is powered by the AC to DC converter. The sensor style end device contains a Remote XBee, AC to DC converter and a sensor. The nature of the sensor is up to the user, but one such application is the detection of an open door or window. The roles of the cloud and Android application have been described in the beginning of the section. The details of these components will be discussed in the subsequent section. 4. System Design and Implementation During the technologies exploration or evaluation process, after considering the System Architecture, we realized that the system involves the integration of three different pieces of software: The service that is going to run in the Central Unit, the Database in the Cloud, and the Android (client) application. The decision we made was trying to work with technologies where the possibility of integration was demonstrated and a reduced amount of different tools to accelerate the learning and adoption process. Because of these considerations, we decided to implement the service in the Central Unit as a Java Service running on Debian Linux, to configure the the Database in the Cloud through the Google App Engine service, and to use Android as the smartphone operating system. 4.1 Hardware sensors and actuators Thinking of clients and of the cost of the whole MyHome solution, it seems to be clear that users should spend the less amount of money possible and the sensors and system should be easy to configure. For this reason it was decided not requiring the user to change their home devices by new ones, but inserting sensors that could act and sense the existent devices. Following the same principle, it was preferred connecting the sensors and the Central Unit through a wireless network and not through a wired one, and basically because of the required amount of job for cabling a house only to put some sensors in it. Because of their power to communicate through objects like walls, the chosen device to create the wireless network was the XBee [3]. Through the XBee, the commands from the Central Unit (CU) will be sent to the actuators and from the actuators to the CU. In the case of lights, the actuator is a Beefcake Relay Control Kit, which controls when to turn on/off the light. The combination of voltages provided by the XBee to the relay kit will indicate to it the action to take. For the detection of the state (open or close) of the doors and windows, an Infrared Proximity Sensor is used whose variations in voltages will indicate the state of doors and windows to the CU. 4.2 Central Unit (CU) The Central Unit is the computer with the responsibility of: a) Getting the data from all the sensors, and in case if there is a change in the state of the
  5. 5. house appliances, updating the database in the cloud. b) Reading the updates made by the Android application in the database, and applying those commands: changes of state or actions, to the actuators and devices. The chosen computer was a Raspberry Pi because of its price ($ 39.95) and the possibility of running Linux and the Java Virtual Machine. The CU runs a Java Service, configured to read and update every 10 seconds, in a round robin fashion, the state of each home device. 4.3 "Database" in the Google's Cloud Datastore In Google App Engine does not exist the possibility of creating a common relational database. The system is designed to work with big data and the Relational Model does not perform well at that scale [4]. Following the model proposed by Google, we create 6 types of Entities, the equivalent concept to a Table in the Relational Model. The Types of Entities (and Fields) were the following: • ACTION (HomeID, ID, ActionType, SensorID, SensorType, State) • CAMERA (HomeID, ID, Location, State, UpdateTime) • LIGHT (HomeID, ID, Location, State, UpdateTime) • MOVEMENT (HomeID, ID, Location, State, UpdateTime) • OPENCLOSE (HomeID, ID, Location, State, UpdateTime) • USER (HomeID, ID, FirstName, LastName, Address, Cellphone, Email, Login, Password) The fields HomeID and ID are used to identify uniquely the sensor in the supervised houses. ACTION is used to store the smart behavior of the system, reacting in programmed ways to the changes of the state of the home. Because this is a prototype, we included only these types of actuators and sensors, but it can include many other types. 4.4 Android Application In our project we have created an Android App which has the capability of connecting with Google App Engine. The app provides basic functionalities like logging in, performing actions (ON/OFF) on lights and camera and detecting movements. Initially the schema of the database was made in the Google App Engine, which has been described above. The tables or entities were populated with proper data by running the Java code on the client phone. As far as the Android App interface is concerned, we have created a handful number of screens. When the app is opened by the user, the Login Screen opens up. This screen accepts the login information of the user such as user name and user password. If the user provides correct information, the user is logged in and is taken to the next screen. This next screen contains the option to Supervise Lights and Supervise Cameras. When the Supervise Lights button is clicked, the control goes to the Lights Screen. In this screen, there are options for performing actions on different kinds of lights for example the Bedroom light or the Kitchen light. Any particular light can be made ON or OFF by pressing the suitable radio buttons. When the ON/OFF radio button is touched/clicked in the Android App, the state of that particular light is changed in the database existing in the cloud. To get this change reflected in Google App Engine, a time of about less than 1 second was required. The Raspberry Pi is periodically reading the data from the cloud and as soon as it detects a change in the state of the light, it passes a suitable signal to the XBee. After some relaying action, the light is turned ON or OFF. Similarly when the Supervise Cameras button is clicked, the control goes to the Cameras Screen and rest of the functionality remains the same. As soon as a movement is detected in the home through movement sensors, the light of that particular room can be made to switch ON/OFF depending upon the corresponding action. If the user wants to record the live happenings upon movement detection, then he can switch ON the camera of the room. This action relates to our novel concept of “Integrating different components of the Smart Home”. As far as the Interface is concerned, the interface is a simple one with required functionality. Other cosmetic features and convenient settings can be further incorporated to make the App elegant in the market. The screenshots of the Android App are shown below:
  6. 6. Figure 2 – Login screen. Figure 3 – Devices screen. 5. Performance Evaluation A very accurate performance evaluation was not performed, considering the activities that can be initiated from the cell phone are not affected by a couple of seconds of delay. Obviously, depending on the use a potential client gives to the system, in the future, response time could be a concern for a specific application. Approximate response times for the differents steps of the flows of information are: a) From the sensor to the Android app: - Sensor response: 1 s. - Data transfer from the Sensor (via XBee) to the RPi (via XBee): 1 s. - Data transfer from the RPi to the Cloud: 3 s. - Refresh rate of the data in the Android app: 10 s. - Data transfer of the data from the Cloud to the Android app, and visualization of it: 1 s. These times were timed manually and are good only as a rough estimation. Considering these times, the total response time for the communication from the sensor to the Android app can be estimated in 16 seconds approximately. b) From the Android app to the actuator. - Data transfer from the Android app to the Cloud: 1 s. - Refresh rate of the RPi: 10 s. - Data transfer from the Cloud to the RPi: 3 s. - Data transfer from the RPi (via XBee) to the actuator (via XBee): 1 s. - Actuator and device activation: 1 s. In the same way, these times were timed manually and are good only as a rough estimation. Considering these times, the total response time for the communication from the Android app to the actuators or devices can be estimated in 16 seconds approximately. It is obvious that the system is sensitive to a fail in the Internet connection and there is some uncertainty in the response time when the media is the Internet. Moreover, there is a tradeoff or conflict between the response time and the overload produced by a sort refresh rate, which in the case of the Android app, could affect the energy consumption of the cell phone. In general, we consider a response time of 16 seconds is acceptable, considering the nature of the application. 5.1 Experimental Setting After merging the different components of the project, we began the experimentation. The setting mirrored a household environment. Internet access was required for the Central Unit
  7. 7. (it can be wired or wireless) and for the cell phone. The elements used were: - Outlet Device: As described in section 3.1.c. - Central Unit: The Raspberry Pi (RPi) computer is running the RaspBian operating system. Python scripts (version 2.7) were developed to get the values from the sensors and to send commands to the actuators. These scripts are run periodically by a service which reads the data from the cloud too. In order to use the RPi, was required a USB keyboard, a USB mouse, and a USB Wireless Adapter, because RPi has only 2 USB ports, it was necessary a USB Hub to connect all the devices. - Cloud System: It was set up a Google App Engine project. It was defined the 6 entity types defined in point 4.3 and it was load the Java Backend with the Endpoint definition (classes) for these six entities. - Android App: A simple Android application was developed to validate the credential of the user and reading and modifying the entities of the cloud database. The Android App was tested in a Samsung Galaxy S3. 5.2 Performance Metrics There are 3 main performance metrics: cost, speed, and reliability. MyHome should be priced at or below similar systems which incorporate video access over the internet. The system must respond with reasonable speed. No specific value is provided, as the response rate is only important for the convenience of the customer, not for the function of the system. Reliability is the final and most important measure. The system may take time to respond, but eventually the command must be received. 5.2.a Cost Comparison One important criterion of the project was cost. The total cost of the central unit is itemized below: Raspberry Pi model B – $49.95 Raspberry Pi Camera Module – $29.95 Xbee 1mW series 1 – $22.95 Motion Sensor – $9.95 Raspberry Pi Case – $5.95 Total: $118.75 The central unit can be used by itself. Again the central unit is comprised of a motion detector, video camera, and Raspberry Pi. These components are sufficient to act as a video surveillance unit. Similar devices that can capture 1280 resolution high definition video are sold for around $180 dollars[14].If our unit was sold at the same price a $60 profit margin would remain. However this value is highly conservative as we have price the components based on single unit purchases. Obviously, in higher volume the cost would be greatly reduced leaving an even greater gap in price. The full benefit of the MyHome system is not realized without its complementary end devices. These are what make MyHome unique and not directly comparable to other products. The sensor end devices are difficult to place a price on as this will vary with the particular sensor used. However the outlet devices are uniform in design. The pricing of the outlet devices is itemized below: Xbee 1mW series 1 – $22.95 2 x Solid State Relay – $9.90 AC to DC converter – $5.95 Total: $38.80 The cost of the outlet devices can be further offset if the user is able to make better use of the Remote XBee within. The XBees have 8 I/O lines which can be utilized, but the outlet only requires 2. If the user is able to use these lines for his sensors or to wire additional outlets to the same XBee, additional value can be obtained. The AC to DC converter is only required for the Remote XBee therefore optimizing the Remote XBee is optimizing the AC to DC converter, as well. A single relay is only able to control one outlet, but this is the least expensive component. The aspects of MyHome which can be compared to other products have been shown to be priced at a comparable rate. Because MyHome adds even more functionality we have evaluated the cost comparison as a success. We have designed an affordable system, providing the customer with the ability to scale as simply or as intricately as he desires. 5.3 Experimental Results Due to the nature of the project and how it was implemented, failures are extremely rare. In the majority of cases success is achieved on the first try. If for some reason it is not, the user would never know as the system would continue the attempt until it was achieved. For example, the 1
  8. 8. mW XBees we are using have a range of 100m. Obviously, this is not an immediate drop of the signal. As the distance approaches and goes beyond 100m, more packets are lost. However, our system only sends 1 bit of data to the XBees -- 1 or 0. Moreover, this state is held. So, if the signal does not get through the first time, it is mere milliseconds until another attempt is made. Because our system is not time sensitive this has no effect on the overall success. Even the motion detector proved 100% successful in our trials. At a distance of 10’ from the motion detector, a brief hand-waving gesture was performed 50 times. The motion was detected every time. After the motion ceased, the sensor would indicate no motion, but quickly indicate a false positive. This happened on nearly every occasion and was determined to be a resetting period. The need for the reset was compensated for in the coding by using a delay after motion was detected. These type of approaches were implemented throughout the project. Because of this failures were virtually eliminated. The occasional failure has occurred due to a broken wire. 6. Current Progress and Project Management 6.1 Current Status Sensors and actuators tested during the project: (100%) - Motion sensor: It can be detected when there is movement in a specific area. - Camera: The camera can be turned on and off. - Light Relay: The relay, hence the light can be turned on and off. Why 100%: We wanted to test more kinds of sensors. But we think with these we can demonstrate the viability of the idea. Central Unit: (85%) The Central Unit and the devices are communicating using XBees in a reliable way. The Central Unit was implemented through a Raspberry Pi card which runs a service and is in charge of reading the state of the sensors and reading the action from the cloud. Why 85%: The service can be improved. After the testing process and implementation, we realized it is a better idea to store a copy of the actions for the events in the Central Unit, this was not implemented. For example, if it is detected some movement in a room, it should not be read from the cloud what to do, this could take about 6 seconds, what it could be too much to capture a good image of what is happening. It could be tested also other devices similar to the Raspberry Pi and alternative communication options to the XBees, in order to reduce the price of the system. Cloud Database and Backend: (90%) The cloud system is working using Google app engine. The “database” or entities were created with the Data Store application and allows to store the last values of the variables. The backend was written in Java and gives response to the requests. Why 90%: The model of the events and the actions need some improvement. It is recommended to use a more complex logic model for taking decisions. Android App: (85%) Validates the credentials of the user, allows to execute actions over the devices and to read the status of them from the cloud. Why 85%: The events and actions model can be improved. The interface does not adapt automatically to new devices added to the home. 6.2 Team Coordination In this project the responsibilities were divided as follows: Akchay Srivastava: Android Application, Cloud Backend. Chris Liffner: Hardware installation and related code. Icaro Alzuru: Cloud Backend, Cloud Database, Central Unit service. Because of this division of the responsibilities, it was possible working independently. Only two activities: Cloud Backend and Central Unit Service needed some moment of integration. For this reason, the GitHub projects, mentioned in the next section, were not created till the final integration phase of the project.
  9. 9. 6.3 Milestones, Weekly Plans, and Deliverables 02/03 - 02/07 Hit Design and create a database in Google App Engine Learn how to create a service in Linux 02/10 - 02/14 Hit Hello World Android app that connects to Parse Design the interfaces in Android Assemble a Wireless Light 02/17 - 02/21 Hit Develop a program that connects the Raspberry Pi with the XBee Develop a program that connects to Google App Engine 02/24 - 02/28 85% Development of the engine to define a Home and its sensors Complete the programs that connect the Raspberry Pi to the devices and App Engine. 03/03 - 03/07 Hit Integrate Android app, Google App Engine, Services, and Devices Development of a first version of the supervision module in Android 03/10 - 03/14 Hit Test the product and fix bugs Prepare the Project Midterm Presentation 03/17 - 03/21 Hit Add alarms and actions to the setup module Assemble another kind of sensor 03/24 - 03/28 Hit Complete the development of the Central Unit module 03/31 - 04/04 Hit Integration of the whole product. Testing alarms and actions. 04/07 - 04/11 Hit Interface improvement, Fixing bugs, Completing development 04/14 - 04/18 04/18 - 04/20 95% Testing the product and fixing bugs. Presentation, final report, and final coding. Updated Midterm Weekly Plan/Milestones: The following milestones were set and accomplished during the project: Hit- 17th - 23rd March: Android App: Finalizing of Interface (incorporating some new states/activities found out later in the stage). Enhancing the Interface with new features like flash, animation or external effects. Hardware: Access RPi GPIO pins and interface Coordinator XBee. Hit- 24th - 30th March: Android App: Connecting the Android Application with the Google App Engine. The Android App should be able to read the data from the Google App Engine. Proper exchange of data between App and App Engine should take place. Hardware: Develop camera activation (due to motion detection) software. Hit- 31st March - 6th April: Connecting the Hardware components with the Cloud System. 95%- 7th April-13th April: Bringing the entire system work together i.e. Amalgamation of Hardware components, Cloud System and Android Application. Fix connectivity bugs if any. 90%- 14th April-29th April: Catch up on any overdue deadlines. System testing and reporting. Deliverables: In order to share the code, were created the following GitHub projects: - https://github.com/ialzuru/MyHome: Android App with the interface and the logic of the program. - https://github.com/ialzuru/MyHome-AppEngine: Cloud Backend. - https://github.com/ialzuru/MyHome-CentralUnit: Hardware code and Central Unit service.
  10. 10. REFERENCES [1] W. Plasencia. Home smart home. Hispanic pp. 66. 2004. Available: http://search.proquest.com/docview/237028600? accountid=10920. [2] Wu, Z.L.; Saito, N., "The Smart Home [Scanning the Issue]," Proceedings of the IEEE, vol.101, no.11, pp.2319, 2321, Nov. 2013 [3] Ayars, E.; Lai, E., "Using XBee transducers for wireless data collection," American Journal of Physics, vol.78, pp.778, 781, 2010 [4] Chang, F.; Dean, J.; Ghemawat, S.; Hsieh, W.; Wallach, D.; Burrows, M.; Chandra, T.; Fikes, A.; Gruber, R., "Bigtable: A Distributed Storage System for Structured Data," ACM Trans. Comput. Syst. 26, 2, Article 4, June 2008 [5] Manfred Huber, 2006, “Smart Home Technologies” [Online], Available http://ranger.uta.edu/~huber/cse4392_SmartHo me [2012, October 18]. [6] Inji Ibrahim Attia and Hamdy Ashour, “Energy saving through smart home” The online journal on power and energy engineering [Electronic], Vol.2, No.3, pp. 223-227. [7] Xiaojing Ye and Junwei Huang, 2011, “A Framework for Cloud-based Smart Home”, International Conference on Computer Science and Network Technology, December 24-26, Chongqing, China, pp. 894-897. [8] Molly Edmonds, “How Smart Homes Work” [Online], Available: http://home.howstuffworks.com/smart- home4.htm [2012, October 19]. [9] Jackie Craven, “What Is a Smart House?” [Online], Available: http://architecture.about.com/od/buildyourhous1/ g/smarthouse.htm [2012, October 18]. [10] iT24Hrs, 2012, “Smart room, smart home” [Online], Available: http://www.it24hrs.com/2012/smart-room-smart- roomautomation [2012, October 18]. [11] Paul Lin, “Disadvantages of a Smart Home” [Online], Available: http://www.ehow.co.uk/list_7631272_disadvanta ges-smarthome.html [2012, October 19]. [12] Barthold, Jim, 2005, “Changing the Way Houses Operate” [Online], Available: http://articles.castelarhost.com/smart_home_tec hnology.htm [2012, October 18]. [13] Digi International Inc., “XBee - Connect Devices to the Cloud” [Online], Available: http://www.digi.com/xbee/ [2014, April 20]. [14] Best Buy, Home Security Camera Search [Online], Available: http://www.bestbuy.com/site/home-security- safety/home-surveillance- cameras/pcmcat254000050005.c?id=pcmcat254 000050005 [2014, May 18].

×