Smart Skins- Embedded Sensor Networkcse400/CSE400_2013_2014/...Smart Skins- Embedded Sensor Network Dept. of CIS - Senior Design 2013-2014 Sunny Shah [email protected] Univ. of

Smart Skins- Embedded Sensor Network

Dept. of CIS - Senior Design 2013-2014∗

Sunny [email protected]

Univ. of PennsylvaniaPhiladelphia, PA

Joel [email protected]

Univ. of PennsylvaniaPhiladelphia, PA

Geoffrey [email protected]. of Pennsylvania

Philadelphia, PA

ABSTRACTSmart Skins attempts to solve the problem of home automa-tion. The problem is addressed in an object-oriented fashionwhere real-world objects are represented and interacted withas programming objects. The objects have various propertiesreflecting levels of temperature, vibration, sound and light.These properties are then utilized to make if/then statementsdependent on object properties.

The goal of Smart Skins is to provide a platform throughwhich a user can intelligently interact with their appliances.It accomplishes this goal by utilizing a network of multi-purpose sensing devices that transmit sensor data to a webinterface which, using a set of algorithms, displays the in-formation in a manner that allows the user to gain an un-derstanding beyond the core data.

Furthermore, the system is calibrated to preserve batterywithout negatively effecting performance. This helps supportour ‘̀pull’́ use-case where the user does not need to constantlyinterface with the Smart Skins device. Instead, the devicewill push useful information to the user at the appropriatetime.

1. INTRODUCTIONUbiquitous Computing and Smart Homes have been an

active research area since Mark Weiser coined the term andits value proposition to users in a landmark paper [21]. Hisvision predicted that computing will infuse everyday objectsto become ‘smart objects’ that unobtrusively and invisiblyautomate routine tasks on behalf of users. The vision ledto much excitement in the Computer Science community.As a result, several university ‘live labs’ and a plethora ofindustry standards around sensor operating systems, net-work protocols and data interchange formats were createdto jump start this new industry around home monitoringand automation [11, 4, 9]. Yet, in the two decades since thewriting of Weiser‘s paper, there has been limited businesssuccess in the market.

We believe this lack of a business impact is in large partbecause the technology architectures around smart homeshave high switching costs. Previously, the only way to ‘smarten’an appliance was to dispose of it and buy a new (and sub-stantially more expensive) ‘smart appliance’. By extension,the only way to convert a home to a smart home is to re-place appliances with new and smart counterparts. Mostconsumers have thousands of dollars of sunk cost in theirhome appliances, and the potential dream of a smart home

∗Advisor: Zachary Ives ([email protected]).

is inadequate to lead them to make such a large capital in-vestment. The “Internet of Things” market was validatedto a greater extent in late 2013, early 2014 with the $3.2billion acquisition of Nest by Google as well as the fact thatover $1 billion in U.S. venture capital money (3% of the to-tal) has been invested into this market [18]. Nest has shownthe power of organic replacement of a few key objects withsmart counterparts (e.g. Thermostat and carbon monoxidedetector). Twine has been first to the market in demon-strating the ability to enhance legacy appliances with smartskins [10, 13].

Smart Skins fits into the scope of the “Internet of Things”market where physical objects are made ‘smart’ throughsome type of interface with software. The device utilizessound, light, vibration and temperature sensors connectedto a WiFi enabled micro-controller to gather appliance datawhich is then passed to a web interface where it is analyzedand acted upon. This project predicts that Twine style ap-pliance skins will be the most effective method of smarteningappliances and as such aims to improve on appliance skinperformance in the following ways:

• Smart Wake Up: Constant operation of sensor hard-ware is expensive and wasteful in terms of (battery)power. Most household washing machines run lessthan 5% of the week, and a sensor that is monitor-ing them 100% of the time is likely to require frequentbattery replacement. Of course, this is unacceptablewhen considering the maintenance cost-to-device ben-efit ratio. Smart Skins utilizes a set of algorithms todetermine the necessary amount of sensory data andthrough a feedback loop updates the device code sothat the device posts only when necessary.

• Smarter Device Models: While appliance state dataprovides an interesting interface for the user, the abil-ity to act on the data enhances the use cases for aconsumer. Smart Skins, through Twilio and the BelkinSmart Switch allows users to receive text messages andtoggle a switch based on the state of an appliance, mul-tiple appliances, time of day and other parameters [7,5]. The design of Smart Skins also allows for easy ad-dition of other actuators and additional logic.

• Monitor Device Collectives: Frequently, fulfilling a homemonitoring need requires coordination across multiplesmart objects. An example of this would be a washerand dryer, if the washer has completed its cycle andthe dryer is off then this is valuable information tothe user. Facilitating such device collectives requires

a ‘workflow’ layer, so that a combined behavior acrossa collection of devices can be verified for the end user.Smart Skins flexible cloud based implementation al-lows for a seamless workflow layer, where logical state-ments can be applied utilizing the IFTTT protocol andmultiple appliance data.

2. RELATED WORKThe related work to Smart Skin falls into four categories

• Projects that have utilized contactful sensors similarto Smart Skins

• Projects that have utilized contactless sensors for de-tection

• Advancement in component technologies that are ap-plicable to Smart Skins

• Sensor industry standards that have end goals relevantto Smart Skins but have had mixed records of successin jump starting a Home Monitoring industry.

In the first category of similar system architectures, thereexists Twine and Spotter as notable Smart Skins datapoints.Twine and Spotter rely on contactful skinning where the skinis tethered to the device it is monitoring and each device hasits own skin. Smart Skins uses these projects as a basis forthe desired level of effectiveness while improving the batterylife and implementing additional capabilities.

In contrast to the contactful technologies, TinyEARS hasadopted audio based technologies for contactless skinning,where the appliance skin can listen in on the appliance with-out being tethered to it. This technology allows for fewersensors to be used, but is more susceptible to random noise.While there is long-term potential of well executed contact-less sensing, there are formidable noise interference chal-lenges that make audio sensing unsuitable as a near to mediumterm goal for the industry. The advancement in componenttechnologies allows sensor skins to exist as they do. Thecontinuing shrinking of microcontrollers as well as sensorsallow these skins to comfortably fit on appliances withoutbeing obtrusive. The advancements in low-power Wi-Fi al-low the skins to run wirelessly for longer periods of time[19]. The combination of these improvements makes SmartSkins a viable option. The final category consists of indus-try standards such as Zigbee that were explicitly targetedtowards the home but did not gain traction, perhaps becausethey were too complicated and both chip and software lev-els to provide a return on investment in the end-markets ofhome automation [16]. Active RFIDs were similarly seen asa promising technology for an “Internet of Things” but haveyet to take off because of challenges within the open sourcecommunity. The community was unable to motivate rapiduse and build compelling apps around these ideas. SmartSkins is designed on the belief that technologies that arewidely deployed in the industry and/or have a strong fol-lowing in the open source community have a better chanceof being the basis for a home monitoring industry.

3. SYSTEM MODELThe Smart Skin system is made up of three main compo-

nents, the hardware device, the server with which the deviceand web application communicate and the web applicationitself.

Figure 1: Model-View-Controller

3.1 OverallThis Smart Skins system consists of a network of sensor

embedded devices linked to a remote web server. This webserver interacts with a web application. Overall, this sys-tem can be represented within the Model-View-Controller(MVC) software pattern with slight modifications. The modelis composed of the database, the view is the web applica-tion and the controller is the all of the scripts running on aserver. The sensor network touches only the controller, butboth provides input like a user and is manipulated by thecontroller like the model. More specifically the data can bethought of as traveling through three layers, the input laterthe API/Scripts layer and the database layer. This dataflow is illustrated in Figure 1.

3.2 Input LayerThe input layer is made up of the web application and the

device. The web application allows for the user to both pro-vide input (create account, login, set time zone, add device,delete device, change appliance for a device) and observeoutput (current state of appliances, previous state of appli-ances). A majority of the display and user interface of theweb application has been developed, and allows for the easeof both user input as defined above and system output asdefined above. The web application will be where users canspecify additional workflow layers. The user can select de-sired notifications such as time-based notifications as well asnotifications based on the states of multiple appliances. Itwill also be where the user can create relationships betweentheir appliances. If the user would like to pair the washerand dryer so that they are notified when both are off or whenone is on and the other is off, this can be done through theweb application.

The other component of the input layer is the Smart Skinsdevice. The device’s main functionality is collecting dataand posting it to the server. As such the device consistssolely of the necessary sensors and a WiFi enabled micro-controller through which it can post the data to the server.As shown in the data flow diagram, Figure 3, the devicesends its data to the API and then parses the feedback forupdated post frequency and measurement frequency. Thisprocess limits the functions performed on the device as wellas conserves power by limiting both how often measurementsare taken as well as how often the device posts to the server.

3.3 Server and API LayerTo keep the Smart Skin module small and simple, Smart

Skins relies heavily on scripts on the server to perform alloperations that are CPU or Memory intensive. The APIparses the data from the device and user interface and addsit into the database. Simultaneously scripts for detectingdevice state and device sensitivity are run. State detectionis performed using the algorithm described in section 3.4. Ifit is determined that the appliance state has changed, theAPI sends a notification back to the user interface, alert-ing the user to the state change in the desired form. Thedevice sensitivity is determined by checking for recent sin-gle state changes. Single state changes are not necessarilythe same as appliance state changes as Smart Skins looksfor multiple single states to determine the appliance state.If there is a change between single states the sensitivity isincreased in turn increasing the post frequency and/or mea-surement frequency. These updated values are sent back tothe Smart Skins device and updates the post and measure-ment frequency in the code on the device. Since appliancestates last for some time, the system uses that knowledge tominimize polling and promote intelligent power usage. Forinstance, a dishwasher Smart Skin device is aware that adishwasher’s wash cycle lasts at least 5 minutes. This in-telligent power usage is what allows Smart Skins to betterutilize the devices battery.

3.4 AlgorithmThere are two possible ways to analyze the data for states;

the more robust and complex approach is the time-seriesanalysis of a short stream of the data from a Smart Skinsdevice. The regression results are compared to the appliancemodel, and the regression with the best fit is deemed to bethe state. The more simplistic way is to use an approximatematching method similar to a vector distance comparisonor hamming distance calculation, where the state of eachsensor is compared to all the base states and the closeststate is selected. [17] Since power efficiency is critical to theSmart Skin, we chose the simpler, approximate matchingmethod.

The approximate matching method is described furtherthrough an example with two known states each with threesensor measurements also illustrated in Figure 2. Knownstate “on” has sensor measurements 800, 780 and 310 forsound, vibration and temperature respectively, and knownstate “off” has sensor measurements 490, 370 and 300 forsound, vibration and temperature respectively. The devicetook measurements Xs, Xv and Xt for the sound, vibra-tion and temperature sensors respectively. There is also asensor weighting based on calibration testing which furtherimproves the probabilistic accuracy of our algorithm. In thisexample, the weightings are 30%, 60% and 10% for soundvibration and temperature respectively. For each state thedistance D from the unknown state to the known state iscalculated as follows.

D =∑i∈S

Wi|Ki −Mi| (1)

where S is the set of sensors, Wi is the weighting of sensori, Ki is the known state’s measurement of sensor i and Mi isthe unknown state’s measurement of sensor i. The distanceis equal to the sum over all of the sensors of the weightingof the specific sensor times the absolute value of the known

state for that specific sensor minus the unknown state forthat specific sensor. The minimum of all of these distancesis the assigned state.

Figure 2: Example of Algorithm with Dryer

The simple approach of matching a single, point wise sen-sor reading against an appliance model is data and power ef-ficient, but prone to outliers. An outlier event, such as some-one bumping into a washer, can lead to an erroneous statedetection. To reduce the errors while maintaining simplic-ity and power efficiency, we introduce the following heuris-tics: multi-polls, sensor weighting, and habit based analysis.Multi-polls avoid the above ‘washer bump’ problem by usingextra polls after state detection to confirm the state. Whilemulti-polls consume more power than a single poll, they arestill more power efficient than time-series methods. Sen-sor weightings, weight the importance of a particular sensor(e.g. light vs vibration) differently for different appliancedetectors. For instance for a television, the sound, and lightsensors are the most critical, and there state should havethe strongest influence on the state classification. While theexact weights have not been determined, a weighting of 40%sound, 30% light, and 15% vibration and 5% temperatureimproves the probability of correctly determining the stateof the TV. A final check to be implemented in future workis habit-based analysis. This analysis uses the informationgathered over time to determine the likelihood of an eventoccurring at a given time based on previous patterns. Forexample, if the washer claims to be running at 3 AM whileit is normally run at noon, this should be identified is ab-normal so the algorithm should be less certain of the state.

In order to limit the amount of calibration that will needto be done by the user, the Smart Skin will have an initialdatabase with data of appliance states. This database allows

the user to have an initial set of known state data to whichthe states can be compared. By doing this, the user doesnot have to calibrate each state during set up. The knownstate set will be modified as the Smart Skin gains data, toimprove the accuracy.

Figure 3: Flow Diagram of Information through thesystem. There are three layers of the Smart Skins’ssystem, the interface shown in green includes thedevice as well as a user via a web interface, the soft-ware layer shown in blue, which includes the APIendpoints as well as continuously running scripts,and the database layer shown in red which storesthe data.

4. SYSTEM IMPLEMENTATIONThe Smart Skin system is made up of three main compo-

nents, the hardware device, the server with which the deviceand web application communicate and the web applicationitself. This section will go over how each of these compo-nents are implemented. Specifically, the following sectionswill be elaborated upon: The sensor and hardware imple-mentation, database implementation, device/server interac-tion, the processes that occur on the server, how the serverinteracts with the web application and, finally, how exactlythe web application is implemented.

4.1 HardwareBecause the Smart Skin is a consumer appliance that is

attached to visible, legacy appliances, it has to be small andcheap. It has to be small enough to be unobtrusive, and aes-thetically attractive on appliances of varying sizes, shapesand ergonomics. Additionally, it has to be cheap enough tobe substantially cheaper than the replacement cost of theappliance. In terms of technical capability, the Smart Skinsdevice requires a hardware system that can sense the typicaloutputs of a working appliance - light, sound, vibration, andtemperature, and be able to communicate these to in-homeand cloud services. Practically, since we were also lookingfor platforms that were easy to enhance and commercially

Figure 4: Smart Skin Device

viable, we wanted to pick a platform that had the backingof influential industry participants, and a large and activeopen-source community. Arduino fulfilled the pragmatic re-quirements given its backing from Google, and a vibrantcommunity of both developers and hobbyists [15]. On thetechnology front, the Arduino Uno has the requisite sensors,can be Wi-Fi enabled, uses a standardized GNU Toolchainas the development environment, has an enthusiastic devel-oper community which has made over 2000 GitHub ‘com-mits’ (changes), and is priced at $20 in volume [2]. The in-ternet connectivity is handled by the Arduino WiFi Shieldwhich plugs directly into the Arduino Uno [1]. This enablesa request/response type interaction with a server instance.Connected to the Arduino are the light, temperature, soundand vibration sensors. For each sensor the cheapest optionwas selected to minimize cost and demonstrate that sim-ple sensors can be used for state detection. Because of thisdesign choice the Mini Photocell (light), TMP 36 (tempera-ture), Electret Microphone (sound) and Piezo Element (vi-bration) are used on the Smart Skins device as shown inFigure 4 [12].

4.2 DatabaseSince most of the reasoning around Smart Skins is data

intensive, it requires a simple cloud platform that supportsflexible data storage models, hosts customized programs tomanipulate this data, and provides simple but effective dash-boards to monitor the data. For this Smart Skins uses Parse,which provides a Backend-as-Service offering. Parse is a sim-pler alternative to building cloud services on top of AmazonWeb Services in that Parse provides a variety of built-in ca-pabilities for data modeling, data integrity checks, queries,and event/alert handling. [14]

4.3 Device to Server CommunicationEach device is connected to WiFi independently and func-

tions independently of each other device in the network.Additionally, each device will be paired with a unique id,which will be both hardcoded into the software of the de-vice and printed directly onto the exterior of the device foruser consumption. Before use the user will be required tonavigate to the web interface, create an account and linktheir device(s) to his/her account by entering device uniqueid(s). During regular use, after a specific amount of time(seconds), defined by the postFrequency variable, all of theraw sensor data measured since the previous HTTP POST,unique device id, timestamps, measurement frequency (thetime between sensor measurements), and post frequency issent via an HTTP POST to a server which runs a scriptto store and analyze the raw data. Additionally, this scriptprovides a response back to the device indicating both thesuccess of the HTTP POST request as well as returningvariables in a JSON string to modify device functionality.Specifically, the script returns, an integer indicating suc-cess or error as defined by w3 Hypertext Transfer ProtocolHTTP/1.1, optional boolean variables useLight, useSound,useVibration, useTemperature, for each sensor light, sound,vibration, temperature respectively, indicating if this sensorshould be used in subsequent measurements, optional inte-ger measurementFrequency representing the amount of timein seconds between sensor measurements, and an optional in-teger postFrequency representing the amount of time in sec-onds between raw data posts from the device to the server[20]. The optional variables that are returned are only in-cluded if their values in the database differ from that cur-rently on the device. This mismatch in variable values couldoccur if for example the appliance the sensor is paired withchanges as while a dryer may use sound, temperature andvibration, a refrigerator may use light and temperature.

Taking measurements from the sensors only when neces-sary will both improve the battery life and reduce the com-putational and storage requirements of the device. Addi-tionally, this transfer of variables from the database to thedevice allows for the device to vary both measurement fre-quency and post frequency as defined by the server script.This variability of both measurementFrequency and postFre-quency is key to maintaining the battery life of the device.The time between sensor measurements (measurementFre-quency) was chosen to be the same for all sensors (as opposedto variable between sensors) to reduce the data storage bur-den of the device, reduce the amount of data transferredsent via Wifi, and simplify the data extraction. The deviceis initially configured to make no sensor measurements (use-Light, useSound, useVibration, useTemperature all equal tofalse), and postFrequency of 25 seconds. Once the device hasbeen linked to a user account and an appliance selected, theresponse will contain the boolean variables for the propersensors to use as well as the measurementFrequency andpostFrequency.

4.4 Server ProcessesThe server processes contains three core scripts that run

continuously, PostDataFromDevice to receive and store thesensor data from a device and return the proper response,DetermineDeviceState to determine the state of the devicebased on device sensor data and other factors such as thetime of day, and DetermineStateChange to process the de-termined states and if necessary take the required user spec-ified action such as sending a text message. In addition to

adding the raw data to the proper database table, Post-DataFromDevice must return a response indicating successor failure as well as unsynced variables as defined above. Thescript will then query the database table DeviceInfo for therow with the specific device uniqueId and examine the sta-tus of applianceChanged a boolean variable indicating if theappliance has been changed by the user via web interface,and deviceSensitivityChanged a boolean variable indicatingif the state of the device has changed, if either of these areTRUE the device will have to be notified with the propervariables to change as explained earlier, and subsequentlyapplianceChanged and deviceSensitivityChanged will be re-set to FALSE. This feedback loop allows for the modificationof code running directly on the device. Through this intel-ligent modification of the post frequency and measurementfrequency the system is able to be both more efficient (interms of battery life), and effective (in regards to state de-tection success). DetermineStateChange checks for redun-dancy as explained earlier as appliances typically remain inone state for a long enough time to confirm a state changevia multiple measurements. Thus DetermineStateChangesequentially analyzes based on recency all states that havenot yet been reported to the user, and seeks two different setsof three consecutively consistent states, and incorporates thelogic and actions specified by the user such as flickering thelights.

4.5 Web ApplicationThe frontend takes advantage of some popular web de-

velopment and design libraries. Twitter Bootstrap is usedas a base for CSS and HTML code. The jQuery library isused to help with javascript development [8]. Additionally,the javascript display library d3 will be used to assist in thedisplay of the data to the end user.[3] Most of the web ap-plication will be custom code and design, as much of whatthis system involves has not been developed to this level.In the consumer grade web application the user will be ableto create an account, adjust the timezone, add devices andmanipulate devices and create relationships between the de-vices.

5. RESULTSThe Smart Skin was designed to detect the state of an

appliance while optimizing for cost and power performance.In order to understand the success of the Smart Skin, bothof the optimizations must be taken into account.

5.1 DeviceThe refrigerator, dryer and washer were used to test the

Smart Skin device. These appliances were selected as they,in aggregate, cover the spectrum of sensors used by theSmart Skin device and, as a result, present valuable usecases. 10 tests were run for each appliance. The tests forthe washer and dryer were on/off tests and the tests for therefrigerator were open/closed tests. The first 5 were basicdetection tests; in other words, no interference was addedto confuse the device. The next 5 added progressively moreinterference to attempt to demonstrate the ability of thesystem to look for consistency. Figure 5 shows the resultsof the 10 tests for each appliance. The results demonstratethe Smart Skins success. Because of the simplicity and con-sistency of a refrigerator, the device was able to correctlydetect the state 100% of the time. The only test that failed

Figure 5: Success Rate of State Detection

for the washer and dryer was that which added vibration,temperature and sound for 25 seconds. this failure is not abad failure as the time for 3 sensor readings was 30 secondsso the sound and vibration were present for the majorityof the 3 detections and remnants of vibration and tempera-ture caused the failure. While ideally the device would passthis test, its failure does not indicate a failure of the devicebut rather an edge-case that would confuse the Smart Skinsdevice. However, the scenario for this test is not one thatwould occur regularly in the lifetime usage of the Smart Skinand is not a failure that would appear in normal usage.

Along with device detection, the Smart Skin system hassuccessfully been integrated with Twilio for text alerts andthe Belkin Smart Switch [7, 5]. The integration of both theseactuators demonstrates the potential for acting upon the theinformation gained from the Smart Skin device. This alsoshows the potential for future integration with additionalactuators.

Figure 6: Table of Component Costs

5.2 CostSince the Smart Skin is designed with the a consumer

audience in mind, cost was a factor on which the design wasoptimized. For each sensor the cheapest option availableon SparkFun was used [12]. Figure 6 shows the cost of thedevice at retail and bulk costs. The total cost at bulk of$57 is satisfactory as it is less than similar products suchas Twine, with a minimum of $150, and Spotter, with a

minimum of $50 [13, 6].

5.3 Power ConsumptionThe goal of implementing a feedback loop was to allow the

device to intelligently post to conserve power. The SmartSkin successfully parses and updates its measurement fre-quency and post frequency based on the analysis done onthe server. While posts are limited to an as-needed basis,the device’s change in power consumption must still be mea-sured and analyzed to determine the effect these updateshave on the overall power consumption.

6. FUTURE WORKThe future work for Smart Skin falls into two categories:

consumerization and additional functionality. Given the de-vices nature as a household device visual appeal and sim-plicity is key for a standard user. Along with this additionalsensors and actuators will allow for more use cases so eachof these should be focused on.

6.1 ConsumerizationIn order for Smart Skins to go from a functional prototype

to a functional product it must be designed for a consumermarket. Two critical factors in consumerizing the designare encasing the product and improving simplicity. Whilein general encasing the product is a common process, thefact that there are sensors that need to be on the surfacemakes it more difficult. The sound and temperature tem-perature can be internal, but the light and vibration sensorsmust be on the surface thus this requires a more tailoreddesign. Combined with the visual aspect of the Smart Skin,the device must be simplified for consumer usage. This mainfocus of simplification is on battery life and set up. WhileSmart Skin improved its battery life with the limited postfrequency and measurement frequency, this needs to be fur-ther improved to make it viable for a user who does not wantto constantly charge the device.

Part of Smart Skins user benefit is that it allows the userto be alerted of the state of their appliance. In other words,they need not interact with Smart Skins at all unless some-thing unique occurs; the refrigerator being left open for morethan 30 seconds, for instance. If they must constantly moni-tor the devices power, the cost-to-benefit ratio necessary forthe user’s purchase decision will become skewed towards thehigher cost in terms of maintenance.

Another simplification that would greatly benefit the us-ability of Smart Skins is a simplification of the initial setup. While Smart Skins currently has an interface for set-ting the appliance on which the device is placed, it does nothave a simple way to set up Wi-Fi . This is an item whichfor testing purposes is easily set in the Arduino sketch, butfor consumer simplicity and security purposes Smart Skinswould not want to release the code and have the user ma-nipulating it.

6.2 Additional FunctionalityAs it exists now, the Smart Skins device consists of light,

sound, vibration and temperature sensors. These sensorsallow for detection of many core appliances, thus they werethe most appropriate choices for the initial device. Addi-tional sensors however would allow for additional function-ality. Augmenting the device with a moisture sensor couldallow for use with a shower or sump pump. Augmenting

it with a spectrometer could allow the device to be utilizedwith televisions, computers or any other appliance utilizinga color spectrum. Generally there are many additional de-tection cases that could be covered with additional sensorinputs. In tandem with this, additional actuators would in-crease the value of Smart Skins. Smart Skins currently cansend the user a text using Twilio or flicker the lights usingthe Belkin Smart Switch. These provide a good basis for ac-tion upon the state detection however there are many moreactions that would benefit the user. For example addingan actuator that could flip switches for a coffee machine ortelevision would allow the user additional functionality. Ontop of this adding additional logic such as time, weather ormulti-device based logic would help make Smart Skins morerobust.

7. ETHICSAs an in home device that transfers data to a remote ser-

vice, Smart Skins presents some ethical problems. Whilethe data that is recorded is not streaming it still presents anunderstanding of a household and its appliances. It is in noway intended to be invasive but it has the potential to trig-ger a feeling of being monitored. A potential solution to thiswould be to delete data after a certain period. Since statedetection is not a long term activity, there is no need to storehistorical data. This solution will quell some of the fear ofrecording, but due to the functionality of the device, thismay not be completely solvable problem. Another poten-tial ethical problem in the same vein is the fact that SmartSkins has access to light switches and phone numbers, aswell as any additional actuators that are linked to it. Thisgives Smart Skins a fair amount of control over a users homelife. A way to eliminate this issue is by forcing the user toauthenticate their actuators with Smart Skins before SmartSkins utilizes them. This limits Smart Skins liability as it isa user set process.

8. CONCLSUIONSmart Skins successfully addresses the issue of home au-

tomation in an object-oriented fashion. Over the courseof 30 test runs, legacy appliances including a refrigerator,washer and dryer were represented as and interacted with asprogramming objects. In other words, Smart Skins devicesplaced upon these appliances were able to collect tempera-ture, sound, light and vibration properties of the device andthen convert these into state-information that is useful forthe user i.e. the refrigerator door is open.

Smart Skins also played a role in actuation through in-tegration with the Twilio API as well as the Belkin SmartSwitch. This enabled actions such as the washer finishingits cycle to trigger reactions in the form of a text messageor flickering lights. This action and reaction cycle closes theloop in terms of home automation.

The system also handles battery life intelligently by lim-iting the frequency of POST requests that the device sendsto the web interface as well as the measurement frequencyof the sensors. The device’s WiFi shield is the main powerconsumer and, by limiting its usage, the system can limitits power consumption. This is achieved by taking in infor-mation regarding time of day, usage history as well as thecurrent stream of data and determining the likelihood of astate change. If a state change is detected, then the mea-

surement frequency as well as posting frequency increasesto deterministically state whether an appliance state haschanged from off to on, closed to open, etc.

9. REFERENCES

[1] Arduino.

[2] arduino. Arduino.https://github.com/arduino/Arduino.

[3] Mike Bostock.

[4] S. Helal. The Landscape of Pervasive ComputingStandards. Synthesis Lectures on Mobile PervasiveComputing. Morgan and Claypool Publishers, 2010.

[5] Belkin Inc.http://www.belkin.com/us/products/home-automation/c/wemo-home-automation/.

[6] Quirky Inc. http://www.quirky.com/shop/609.

[7] Twilio Inc. http://www.twilio.com/.

[8] The jQuery Foundation.

[9] Cory D Kidd, Robert Orr, Gregory D Abowd,Christopher G Atkeson, Irfan A Essa, BlairMacIntyre, Elizabeth Mynatt, Thad E Starner, andWendy Newstetter. The aware home: A livinglaboratory for ubiquitous computing research. InCooperative buildings. Integrating information,organizations, and architecture. Springer, 1999.

[10] Nest Labs. https://nest.com/.

[11] Joshua Lifton, Mark Feldmeier, Yasuhiro Ono,Cameron Lewis, and Joseph A Paradiso. A platformfor ubiquitous sensor deployment in occupational anddomestic environments. In Information Processing inSensor Networks, 2007. IPSN 2007. 6th InternationalSymposium on, 2007.

[12] Sparkfun LLC. Pro micro - 5v/16mhz.

[13] Supermechanical LLC. http://supermechanical.com/.

[14] Stephanie Mann. Backend as a service faqs.http://searchsoa.techtarget.com/feature/Backend-as-a-Service-FAQs.

[15] Daniel Melanson. Google announces android openaccessory standard, arduino-based adk.http://www.engadget.com/2011/05/10/google-announces-android-open-accessory-standard-arduino-based/,2010.

[16] Inc National Technical Systems. Top 5 reasons forfailures in zigbee deployments. NTS.

[17] Gonzalo Navarro. A guided tour to approximate stringmatching. ACM computing surveys (CSUR), 2001.

[18] Tomtunguz. Nest implications.

[19] S. Tozlu, M. Senel, Wei Mao, and A. Keshavarzian.Wi-fi enabled sensors for internet of things: Apractical approach. Communications Magazine, IEEE,2012.

[20] W3C.

[21] Mark Weiser. The computer for the 21st century.Scientific american, 265(3):94–104, 1991.