3. Use Cases
Lights Subsystem
• Turning on/off lights (individually)
• Visualizing the state: What lights are on and what lights are off.
• Controlling all the lights: Defining modes (all turned on, all turned off, something specific).
Camera Subsystem
• Motion detection and definition of actions: Recording or not, by time.
• Live streaming by demand of a specific camera.
Access/Movement Subsystem
• Definition of alarms when a door or window is opened.
4. Modules
Hardware sensors and actuators: Wireless Switch, Camera, or Sensor; send data and receive
orders from the “Central Unit”.
Central Unit: Small computer which communicates with each device and stores the information
in the cloud. Receives the order from the remote application through the cloud system.
Cloud System - Database: Third party system to intercommunicate the Central Unit and the
Remote application, and to store the historic data of the whole system.
Android Application: Visualize and control the states of the home devices. Modifies and reads
the data in the cloud.
5. Module
Hardware sensors and actuators
Lights Subsystem
• Components required: Device, Actuator, Sensor, Wireless (RF) Connector.
Camera subsystem
• Similar to the Lights subsystem but with a camera and a motion sensor.
6. Module
Hardware sensors and actuators
• XBee
• Peer-to-peer communication
• Designated Coordinator and Remote modules
• Raspberry Pi
• WiFi connected
• Camera integration
• Python Service to sense the devices
7. Module – Central Unit
•Implemented with a Raspberry Pi board.
•Linux operating system: Raspbian.
•Service (Daemon):
• Reading data from sensors and submitting that data to the cloud.
• Reading the commands to be applied to the devices from the cloud, and passing those
commands to the corresponding devices.
•The Central Unit is going to connect to the Internet through UTP cable or WiFi and is going to connect
to the devices through a XBee.
•In the setup process, the sensors are mapped to variables in the database.
•Maintains a copy of the last states of the devices.
8. Module – Cloud System
The cloud system was implemented with Google App Engine
“Database”:
• USER (HomeID, ID, FirstName, LastName, Address, Cellphone, Email, Login, Password)
• CAMERA (HomeID, ID, Location, State, UpdateTime)
• LIGHT (HomeID, ID, Location, State, UpdateTime)
• MOVEMENT (HomeID, ID, Location, State, UpdateTime)
• OPENCLOSE (HomeID, ID, Location, State, UpdateTime)
• ACTION (HomeID, ID, ActionType, SensorID, SensorType, State)
Backend:
• Java Web service to access the entities.
9. Android App
● The Android App “MyHome” is connected to the Google App Engine.
● The App consists of a handful of screens. When the App is opened by a user, the Login Screen
opens up.
●This screen accepts the login information of the user such as the user name and user password.
If the user provides correct information, the user is logged in and is taken to the next screen
which is the Supervise Screen.
● The Supervise Screen consists of two parts: Lights and Cameras.
● Option of Adding Lights and Adding Cameras.
● Two Buttons for Supervising Lights and Supervising Cameras.
12. Android App
• When the “Supervise Lights” button is clicked, the control goes to the Lights Screen.
• Options for performing actions on different kinds of lights is provided.
• A particular light can be made ON or OFF by pressing on the suitable radio button.
• When the ON/OFF radio button is touched/clicked, the state of that particular light is changed
in the database of the Google App Engine. To get this change reflected in the google App
Engine, about less than a second is required.
• The Raspberry Pi will be periodically reading the data from Google App Engine and as soon as
it detects a change in the state, it will pass the signal to the Xbee. After some relaying action,
the light would be turned ON/OFF.
15. Performance Metrics
• Time Delay- The time difference between the event of pressing the ON radio button and the event
when the light glows completely. Ideally the Time Delay should be zero, but due to latency between
hardware components, a non-zero time delay is expected → a response time of 16 s:
- 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
•Reliability- While some time delay is tolerable, the system must eventually respond accordingly.
16. Performance Metrics
Cost- The entire cost of the system which includes the cost of Hardware and Software.
• Central Unit ($118.75)
• Raspberry Pi = $39.95
• Camera = $29.95
• XBee = $22.95
• Motion Sensor = $9.95
• RPi Case = $5.95
• Outlet Unit ($38.80)
• XBee = $22.95
• AC to DC converter = $5.95
• 2 x Solid State Relay = $9.90
17. Success Evaluation Criteria
•Android App running properly in synchronization with the Google App Engine and Hardware
components.
•When ON radio button pressed – Light glows.
•When OFF radio button pressed – Light fades off.
•The total product cost is reasonable for a prototype.
18. Team Coordination
•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.
19. Original Weekly Plan
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.