Bluetooth Sensor Node Occupancy Dynamics Mark Kurtz

Washington University in St. Louis1 Brookings Drive,

St. Louis MO 631301 (618) 791 5937

MKurtz@wustl.edu

Tushar MatthewWashington University in St. Louis

1 Brookings Drive, St. Louis MO 63130

1 (314) 793 5176Mathew@wustl.edu

Ethan GlassmanWashington University in St. Louis

1 Brookings Drive, St. Louis MO 63130

1 (650) 575 9193Ethan.glassman@wustl.edu

ABSTRACTMapping occupancy dynamics helps enable home automation systems to behave more efficiently by providing specific information about the number of persons in a specific location within a home. In this paper we discuss the performance and implementation of a home occupancy dynamics system using simple sensors and neural networks to provide room level local estimation, extendable to rudimentary activity recognition. Results from the project using simple data collection, capturing and algorithm training methods are demonstrated. We discuss several improvements on the system, including noisy data elimination and real time estimation and demonstrate the results from a simulated environment.

CCS Concepts Hardware

o Communication hardware, interfaces and storage

Sensors and actuators Wireless integrated network sensors

Machine Learningo Learning paradigms

Supervised learningo Machine learning approaches

Neural networks

Keywords

Tensor Flow; Machine Learning; Occupancy Dynamics; Lightblue Bean; Raspberry Pi; Node-RED

1. INTRODUCTIONOne of the basic issues faced by today’s intelligent homes is to figure out how to detect if someone is in the room at a given point in time. This automatic detection can prove to be very challenging just because of the different ways in which humans interact with their surroundings and the home environment. Human-home interaction coupled with the need for non-obtrusive sensing led us to implement a proof of concept project using motion sensors and capacitive bed sensors in order to predict when motion is expected in a specific room in real time and predict what kind of activity is taking place.

The information gathered from our sensor setup and prediction algorithms has a number of exploitable benefits to a homeowner in terms of sustainability, cost savings and energy conservation. Consider a homeowner who takes a shower before getting to work at 7am every morning. It would prove highly energy efficient if the home automation system could predict this activity and turn on the water heaters fifteen minutes before 7am rather than running the heating system throughout the night. Such a system could save the homeowner a lot of money on one hand as well as time on the other as he would not need to switch on the heater manually. In general the movement patterns of persons living within a home layout is crucial to determine the home occupancy status and to improve home automation efficiency.

This project uses machine learning techniques to infer data collected from “simple” sensors placed strategically in rooms within an apartment such that they have the best field of vision of the rooms to automatically recognize human presence. Existing sensor networks and infrastructures that are used for mapping room occupancy employ models based on security systems. However these systems can be very intrusive and comes at a privacy, computational, and monetary cost and hence are not really suitable for the regular home. With this project we examine the use of PIR sensors primarily and capacitive bed sensor as a second cross validation sensor to show that such sensors are enough to tell us which rooms are occupied and which rooms are not.

2. Goals

Our goal was to implement a smart home occupancy dynamics system. A focus of the project was to use a central processing computer, and simple sensor nodes. By placing the heavy lifting on the central processing computer, we could use identical inexpensive BLE chips, with sufficient onboard processing to analyze the output from the sensor at each node, and alert the central computer that the occupancy had changed. A main goal was to avoid the use of any system that would require a user to carry a smartphone or any similar hardware, but it would be possible to naturally navigate the home and have the home intelligently adjust based on where people are located.

3. SystemThe system is comprised of hardware and software components. The hardware deals with the collection of sensor data and enabling the processing and storage of the data. The software is made up of several different parts which are broken into different sections. The first part is the software running on the sensors and central processor which is described in subsection 3.2. The second part is the user interface and software behind it that allowed for recording training data and comparison data for the system. This is given in subsection 3.3. Finally, there is the machine learning algorithm that powered the occupancy detection technique. Because of the scope, this is broken into a separate section altogether, section 4.

3.1 HardwareThe central processing computer was a Raspberry Pi 3 with built in Wi-Fi and BLE chips. This computer is sufficiently powerful to run Tensor Flow machine learning code, and has all of the necessary hardware included out of the box, avoiding the need to use 3rd party, often poorly supported, Bluetooth antennas. We ran the Raspberry Pi connected to Ethernet for ease of setup and to make as robust of a test system as possible, but it is not necessary to be connected to the internet, which would make it much easier to secure the occupancy tracking against any hackers.

For our sensor nodes, we chose to use the Punchthrough Lightblue Bean [6]. This board has an onboard ATmega328p microcontroller @ 8 MHz, with 8 GPIO pins paired to a Texas Instruments’ CC2540 system on chip for Bluetooth. The Bean can be purchased in individual quantities for $30/board, and we chose it because it is Arduino compatible and ready to use out of the box. For larger deployments, the CC2540 is available for $5/chip and the ATmega328p for $3/chip, so it would be possible to reduce the cost to <$10/sensor node.

We are currently using two types of sensors. The first is a generic HC-SR501 PIR sensor, purchased from Amazon. These are available from a number of sources, we spent $2/sensor. The PIR sensor requires 4.5 - 20V and have an onboard voltage regulator so we powered the sensor and node from a single 9v battery. When the sensors are triggered by motion, the signal pin is pulled from 3.3v -> ground. These PIR sensors are used in each room and would be augmented by specialized sensors.

Our second sensor is chosen to provide increased accuracy when the residents are asleep. A PIR sensor does a poor job of recognizing motion under a blanket, and so we selected an Adafruit Standalone 5-Pad Capacitive Touch Sensor Breakout - AT42QT1070 [7] with solid core wires threaded through a bedsheet. These sensors are available for $6/sensor in quantity from Adafruit, but use an Atmel AT42QT1070 which is available for $1.50/chip in quantity, and it would again be possible with some engineering effort to make a more inexpensive sensor in larger deployments.

3.2 SoftwareThe software for data collection is fairly simple. On each Lightblue Bean we iterate over any attached sensors and if they have been triggered, print the sensor ID to serial. On the Raspberry Pi we use a Node-RED server to listen over Bluetooth to the serial output. When a message is printed to serial by the Lightblue Bean, the Node-RED server appends a timestamp to the message and writes to CSV. This CSV file can then be run through a machine learning code and predict count of occupants in each room. This is explored in detail in section 4.

3.2.1 Lightblue BeansCode is provided for each sensor as a downloadable Arduino file. The Lightblue Beans code is nearly identical across nodes. We need only iterate across sensor inputs, and if a sensor input has been triggered, a formatted string is printed to serial.

3.2.2 Raspberry PiDetails on how to setup Node-RED server are given in supplementary INSTALL-RPI document. The Node-RED server listens to the Serial port on each Lightblue Bean, and if the sensor node prints a formatted string to serial, the Node-RED server appends a timestamp and writes that string to a CSV file for processing.

3.3 UIA user interface was created to allow for the writing of data used to train the machine learning algorithms explored later as well as for evaluating them. This was created in the form of an Android Application appropriately named Where’s Ethan since data collection was done in Ethan’s apartment. The interface consisted of five buttons, one for each room type, and a scrolling list of already recorded points sorted in order of most recent first. The points tied a room type, a list of which is given in Table 1, to a time in milliseconds since the unix epoch. Upon clicking one of the buttons, a data point would be added to the list of recorded data points. This consisted of adding the data point to the UI as well as adding the data point to a local sqlite database. If one of the data points were clicked, it would be deleted from the local database as well as from the UI allowing for correction of mistakes in data recording. Finally, an export button would convert the data stored on the device to a json string for each point and then write it to a text file on the root of the virtual SD card on the device. A screenshot of the application can be found in Figure1.

Table 1: A list of room types in the tested apartment.

Room Type String

Room Type

ConstantAway 1

Main 2

Kitchen 3

Bedroom 4

Bathroom 5

Figure 1: The android application used for recording training and evaluation data.

4. Machine Learning

The ability to detect occupancy was powered by machine learning techniques. The use of machine learning allowed for the capability of expansion of sensors and addition of new types of sensors. In fact, as discussed later, the types of sensors were not used in the algorithms. Ultimately the techniques pursued gave good results by learning from the data provided by the hardware described in section 3. The techniques and the rationale behind them is explained below.

4.1 Data CreationSupervised and unsupervised learning techniques were used to achieve the best results. For both, some consistent method of describing the generated data is required. For the former, some method of labeling the generated data is required. The importance of this is at the core of machine learning, and the data put through the algorithms can severely affect the accuracy achieved. This section explores the methods of generating data that were used and the effects each data description method.

4.1.1 ParsingBefore the machine learning data could be created, the data created from the sensors described in Section 3.2 (sensor data) needed to be cleaned and parsed. The data created from the UI Android Application described in Section 3.3 (label data) also needed to be parsed. The sensor data recorded was not in the proper JSON format, so find and replace with regex was used to correct this. An example of the change is now given:

Before – {"value":"{'id':42,'type':3}\r","date":`1459985074300}

After - {"id":42,"type":3,"date":1459985074300}

The sensor data file was then manually inspected for any lines that were not corrected by the find and replace because of some data corruption that happened on the server while recording the data point. This ended up happening with an occurrence of roughly one corrupted data point per one thousand data points. Code was then set up in python to read through each line in the sensor and label data and convert the JSON representation to python tuples with a particular order. The code to do this is provided in parse.py.

4.1.2 FeaturesFeatures are very important for machine learning, as they allow the techniques to properly learn from the data. There are many ways to create feature vectors, and in this section the choices of features as well as the results of those choices are explored. The final data generated from the discussion of this section can be found in the room_#_generated.txt files under the Dataset folders. Also, the python code that generated the text files can be found in generate.py and the files can be created by running generator.py.

4.1.2.1 Time PeriodAn important part for time dependent data is making sure that the features used are comparable between each other. This led to our initial and continued use of feature vectors built from constant time periods. So, all data to be used in the generation of the feature vectors had to fall within and including a final time and a start time given by Equation 1.

Equation 1: Final time t f is related to some start time t s and a constant time period α .

t f =t s+α

The constant time periods used were 15 minutes and 30 minutes. It was found during testing that there was no statistical difference between the accuracy achieved using 15 minutes and 30 minutes independent of the other parameters used to create the feature vectors.

It is important to note that early on the label data, explored in detail in section 4.1.3, was used to define the earliest and latest possible time for the time ranges. Since the labels were started and ended before the sensor data, this led to some feature vectors being filled out with all zeros despite the fact that the label stated that the room was occupied. Therefore the minimum and maximum possible times were determined from the sensor data.

Future work for this includes the exploration of checking for occupancy for time periods less than what the data was trained on. This can be introduced by setting in values that are not included in the intersection of the time period desired and the time period trained on to 0. The unknown part in this is how the machine learning algorithms will perform with this type of data.

4.1.2.2 Time BucketsWith constant time periods setup as described in 4.1.2.1, a way of condensing the data was needed to build feature vectors with. An initial thought was to have the feature vectors built with a point for each millisecond or 10 milliseconds within the time range. Each point in the vector would then be equal to the id of the sensor that was triggered the most. This led to worries of loss of data as well as large, sparse feature vectors of roughly 500,000 ~ 1,000,000 points. These sizes are not unheard of for images, but this seemed far too large for the data we were exploring. Therefore the concept of time buckets was built out. Time buckets define a subset of the time range to go through and then keeps a total count per sensor id of how many times each sensor was triggered. Thus the feature vectors are made up of multiple of these time buckets. This allowed for orders of magnitude reduction in the dimensions of the feature vectors with roughly 100 points or less depending on how the time buckets were defined. Two options for the time buckets were explored in parallel to find the combination that gave the best results and are explored next.

The first option was whether to use a series ordering of the time buckets, or a parallel ordering of the time buckets. An illustration of what is meant by this is given in Figure 2. Both can be found from the other by some linear combination of the time buckets in the other. For that reason, results were expected to be independent of the method chosen. This, however, was not the case. The series ordering consistently performed better than the parallel ordering. The exact magnitude of how much better depended on many other parameters in the data; however, an increase of a few percentage points in accuracy was common. The most likely reason for this, despite both being linearly comparable, was that the parallel buckets had overall higher variance between the points which made it harder for the optimization algorithms to quickly find a local minimum for training off the data.

Figure 2: An illustration of the ordering of time buckets tested.

The second option was how to define the time ranges between each bucket. Two main options were initially either having the total time range as described in 4.1.2.1 divided into some amount n different time buckets. The other was to have the total time range divided into doubling time ranges for each bucket. For example, the first time bucket may be 1 second. The next would then be 2 seconds followed by 4 seconds and so on. After evaluating both of these with all other options consistent, the doubling time ranges outperformed the equal distribution of time buckets. The exact degree of how much better depended on the data and options used in the data; however, an increase in roughly 5 percent accuracy was common. The likely reason behind this was too much loss of data. The sensors being triggered at a more recent time are more indicative if someone is in the room than the sensors being triggered at a later time. The choice of doubling time buckets was explored in more detail in parallel with this, and a walk through is given next.

A big question for the doubling time buckets was what should the starting time bucket be. 1 second, 15 second, and 30 second options were explored. Ultimately the best accuracy came from a starting time bucket of 1 second. The reasoning behind this is thought to be the same as the choice over constant time buckets before as it allows for less condensing of the data earlier on in time where triggering of the sensors has a higher probability of correctly predicting a person is in the room. It is quite possible that an even smaller initial time bucket would lead to higher accuracies; however, the size of the data was also a concern as well as observations that the first parts of the feature vectors corresponding to the first time buckets were generally very sparse. This could be explored in future work.

4.1.2.3 Random TimeWhen dealing with data that is time dependent, it is important to create features that are independent of time. [8] The concern is that the machine learning algorithms will train on patterns in the data due to time rather than how the sensors were triggered. Because of this concern, random start times between the range of valid time values were chosen using pythons random function. This ensured there was no discernable pattern between feature vectors and in the data generated as a whole.

4.1.2.4 Time CoverageAlong the same lines as the issue discussed in 4.1.2.3, the data needed to cover a significant portion of possible times within the testing range. With thorough coverage of the data we could ensure the results were independent from time and were thus valid and accurate no matter the time period tested on. Also, generating more data increased the accuracy results significantly while testing. By increasing from a maximum (maximum because the starting points are randomly determined) 4% coverage of all the possible starting seconds in a dataset to 40% coverage, the accuracy increased by over 10 percent on average.

Future work could improve the maximum coverage to 100 percent to see the effects on the overall accuracy. The reason for not doing so now was due to time and resource limitations. It takes a decent amount of time to generate the data points.

4.1.2.5 Time Features

As much as has been said about wanting the data to be independent of time. An attempt at features that would pick up patterns in time was implemented. This was more for curiosity out of the results than any rigorous mathematical reasoning. The start and end time that each feature vector was being built for was added to the beginning of the feature vectors. Unfortunately since the times were much larger in value than the other points in the features it had the effect of creating large variance in values between runs depending on how the weights in the machine learning algorithms were initialized. One run came out to around 20 percent accuracy while a following run, without changing the dataset, came out to around 80 percent accuracy. Because of the high variance and lower accuracy, this method was quickly abandoned.

4.1.3 LabelsAs mentioned at the very beginning of this section, labels are required for supervised learning. The labels allow the machine learning algorithms to train and converge to the optimal solution while also allowing for evaluation and accuracy of the techniques used. The main method for generating the labels came from creating a percentage of time a room was occupied over a given time period. Since a percentage can have many different values, this was going to be hard to predict without using something like logistic regression. The reasons for not using logistic regression or similar approaches is given in section 4.2. So, the percentage was converted to a 1 or 0 depending on the value. If the percentage was greater than or equal to 50% then the room was considered occupied and the label was set to a 1. Otherwise the label was set to a 0. This gave more freedom for picking a proper machine learning algorithm for the task.

4.1.4 DatasetsThree datasets were created using the previous descriptions in 4.1.1 - 4.1.3. The datasets can be recreated by running generator.py with the appropriate options. The first and second datasets were collections of data over 40+ hour continuous time periods. The third dataset was a collection of data over a 3+ hour continuous time period. The first dataset was generated early on in the process. Therefore it does not contain information from sensors added on later in the process. The second dataset contains information from all of the sensors and, because of the length, is fairly representative of normal activities that occur in the apartment. The third dataset also contains information from all of the sensors, but its purpose was created as a validation set. Because of the length of time of the third dataset combined with the goal of creating varied data for every room, it may not be entirely representative of typical apartment use. This third dataset was not used for training, and therefore the results from it are predictive of, and possibly a lower bound of, what could be achieved using this technique in real time.

4.2 Clustering

Clustering algorithms were explored to see if there were common patterns that could be learned from the data. It also has implications as to whether there are any clear decision boundaries present in the data. The k-means algorithm was implemented in python and then the second generated dataset from 4.1.4 was put through the algorithm with 5 means. The rationale behind 5 means came from the number of room types. The third generated dataset from 4.1.4 was used as a validation set to see if the learned means gave similar results on untrained data. The results can be duplicated by running the kmeans.py python script with the appropriate inputs for training and validation data as described above.

The results from the k-means algorithm are given in Table 2 and Table 3. The tables give the overall percent breakdown of each room type matched to the nearest mean. The interpretation of this data is that each mean did not correspond to a specific room type. In other words, there is a lot of overlap between data points. Also, because there is at least one mean from each dataset that is nearest to none of the labels, five distinct means could not be found. This rules out many supervised learning techniques that work along the same lines of finding linear decision boundaries such as k nearest neighbor, SVM, linear and logistic regression, etc. With these results, efforts were continually focused on neural networks which can find nonlinear relationships between the data as described in section 4.3. Future work may use the results in this section to expand what supervised learning techniques are used. Possible explorations for new algorithms could be testing kernelized SVM or gaussian processes.

Table 2: K means results on dataset 2 with percent of closest room types.

Away Main Kitchen Bedroom Bathroom

First Mean

Overall % 0.04% 1.92% 0.93% 0.06% 0.16%

Mean Normalized % 1.15% 61.69% 29.90% 2.02% 5.23%

Second Mean

Overall % 0.70% 4.29% 0.86% 2.56% 0.82%

Mean Normalized % 7.56% 46.51% 9.31% 27.78% 8.84%

Third Mean

Overall % 12.75% 8.38% 0.14% 57.45% 93.30%

Mean Normalized % 7.41% 4.87% 0.08% 33.40% 54.24%

Fourth Mean

Overall % 0.20% 3.77% 1.30% 0.87% 0.20%

Mean Normalized % 3.22% 59.40% 20.46% 13.71% 3.22%

Fifth Mean

Overall % 0.00% 0.00% 0.00% 0.00% 0.00%

Mean Normalized % 0.00% 0.00% 0.00% 0.00% 0.00%

Table 3: K means results on dataset 3 with percent of closest room types.Away Main Kitchen Bedroom Bathroom

First MeanOverall % 0.00% 1.69% 0.27% 0.50% 0.09%

Mean Normalized % 0.00% 66.25% 10.58% 19.72% 3.45%

Second Mean

Overall % 0.00% 4.05% 0.47% 1.66% 0.28%

Mean Normalized % 0.00% 62.77% 7.29% 25.68% 4.26%

Third MeanOverall % 0.00% 0.47% 0.18% 0.21% 0.15%

Mean Normalized % 0.00% 46.80% 18.00% 20.60% 14.60%

Fourth MeanOverall % 0.00% 0.00% 0.00% 0.00% 0.00%

Mean Normalized % 0.00% 0.00% 0.00% 0.00% 0.00%

Fifth MeanOverall % 0.00% 0.00% 0.00% 0.00% 0.00%

Mean Normalized % 0.00% 0.00% 0.00% 0.00% 0.00%

4.3 Neural NetworksNeural networks have received a lot of attention lately due to the success of deep neural networks on many different machine learning problems that have been traditionally hard for other algorithms. This attention led to many different frameworks available that can perform neural network computations. For the purposes of this paper, Tensorflow by Google [9] was used. It is written in python, and due to a forked version, it can be run on the 32bit processor of a raspberry pi [10]. This section walks through the implementations, training, and selection of hyper parameters using this library. The code used can be found in hidden_nn.py. The final results for the implementation of the neural networks running on the different datasets can be found in section 4.3.2.

4.3.1 SetupIn this paper, a feedforward network with one hidden layer was used. Originally, this was planned to be the starting point and then move into deeper neural networks using convolutional techniques. This plan was not followed due to time constraints combined with high accuracy results from just the single hidden layer network. An illustration of the type of network is given in Figure 3. An in depth explanation of the hyper parameters chosen for the network is given below.

Figure 3: Example of a single hidden layer network.

4.3.1.1 Weight InitializationThe weights in a neural network are what allows it to learn. For an illustration, they can be seen in Figure 3 as the arrows going from each node to another. The weights for each input to the individual neurons were initialized using the Xavier method. This has been shown in practice to allow the neural network to converge quicker to optimal values when compared with initializing the weights with a normal distribution. [11] Essentially, the Xavier method gives higher weights to earlier layers of the network. This effectively allows more information to be passed through and trained on early in the process. This was the only initialization method implemented as this subject has been studied extensively before.

4.3.1.2 Activation FunctionThe activation function for a neural network takes in all of the inputs to a node and outputs a value, generally 0 to 1. This function is an important part of the networks as it is the process behind learning complex patterns in data. The sigmoid function is the traditional activation function, but for this implementation, the tanh function was used. As in 4.3.1.1, this has been shown in practice to work better and also allows the optimization in back propagation to work better.4 The intuition behind this is that the tanh function approximates the actual function that occurs in the brain closer than the sigmoid function. Since this has been explored in far more detail before, experimentation with other activation functions was not done.

4.3.1.3 Input Output NodesThe number of nodes in the input and output layers are entirely determined by the data. Since there are two possible labels, occupied or not occupied, the network was set up with two output nodes. The input layer needed to match the number of features in the data. Therefore, the number of input nodes was set to 80.

4.3.1.4 Hidden NodesThe number of hidden nodes is variable and it was tuned to increase the accuracy from training and decrease variance of accuracy between runs. The number of nodes was started at 2 and doubled for each trial. This method of doubling stopped seeing steady improvement in the training accuracy at 32. Doubling again did not give a noticeable improvement in accuracy. The most likely reason for this peak came from the number of epochs the data was trained on, which was 2. Epochs are explored more in 4.3.1.5. The neural network was most likely not training long enough to optimize the increased number of variables. Less than 32, especially less than or equal to eight, saw an increase in variance on training runs. The most likely cause of this was the algorithm being initialized randomly. The randomness caused different local mins to be found in the fewer variables.

Future work would explore the effect of adding more nodes while increasing the epoch training length to ensure the optimization had time to settle on a minimum in the training error.

4.3.1.5 EpochsAn epoch for neural networks is a single pass through the entire dataset. By increasing the number of epochs, the neural network trains for longer as converges further to a local minimum of the training error. Since the networks train on the test data for longer, there is a risk of overfitting the training data. Also as the number of epochs increases, so does the training time.

For the first dataset, the number of epochs for training was set to two. This gave good results, as can be seen in section 6. More epochs were not used due to fear of overfitting the data. For the second dataset, the number of epochs was varied from two to twenty with dataset three used as a validation set. With a validation set in place, the fear of overfitting the data was reduced. The accuracy steadily increased for each epoch tried until twenty. Twenty was the highest number tested since the testing training time was taking close to a minute for each room. The results are given in 4.3.2.

4.3.1.6 Test train splitAn 80 percent training and 20 percent testing split was used during testing. No other test train splits percentages were used due to this percentage being typically used and well based in Pareto Optimality. It has been explored in much more detail by others, so it was not explored for this paper [12].

4.3.2 ResultsThe final results from training on each data are given here. The accuracies for datasets one and two by training on part of the data and evaluating the accuracy on the remaining data in each dataset. The details of this are explored in 4.3.1.5. These can be visualized in Table 4 and Table 5. For dataset three, the training from dataset two was used to evaluate accuracy on the entire dataset. These can be viewed in Table 6. This way of evaluation gave good indication as to what would be expected if the system were to be running in real time.

Table 4: Average accuracy of neural networks on dataset one.

Room Type Accuracy

Away 85.61%

Main 93.23%

Kitchen 97.78%

Bedroom 82.76%

Bathroom 99.02%

Table 5: Average accuracy of neural networks on dataset two.

Room Type Accuracy

Away 87.34%

Main 96.08%

Kitchen 98.01%

Bedroom 87.11%

Bathroom 99.42%

Table 6: Average accuracy of neural networks on dataset three.

Room Type Accuracy

Away 98.71%

Main 82.38%

Kitchen 95.48%

Bedroom 91.81%

Bathroom 96.69%

5. ImplementationThe implementation of this took place in Ethan’s apartment as mentioned earlier in the paper. All of the machine learning code run on the generated data was run on a MacBook pro. A thorough description of this is now given.

5.1 Apartment LayoutThe apartment is located in St. Louis, near Washington University. The apartment contains three distinct rooms: main room with kitchen attached, bedroom, and bathroom. It is a typical single person apartment for the area. An illustration of the layout can be seen in Figure 4.

Figure 4: Layout of Ethan's Apartment with labeled sensors.

5.2 Hardware LocationsThe sensor locations were chosen to maximize the coverage of each room. The locations for dataset one can be seen in Figure 4 where the included sensors are 41, 42, 43, and 44. The locations for dataset two and three can also be found in Figure 4. The included sensors are 42, 42, 44, proposed sensor 1, proposed sensor 2, proposed sensor 3, proposed sensor 4. Note, these are all the sensors with the exception of 41.

A raspberry pi 3 was also set up in the main room. It was connected to all of the blue beans powering the sensors and had good signal strength from them. The raspberry pi 3 would then record the data taken in from blue beans.

5.3 ProcessingAll data processing and machine learning was run locally on a MacBook pro. Ideally, the processing and evaluation of the data would take place on a server or locally on the raspberry pi 3. This could be implemented in future work, but was not necessary to evaluate the validity of the idea. The datasets from the sensors and the label application were loaded onto the MacBook pro. Also, all the code to do processing and machine learning was written in python. With the code written, the code would then be called from the command line with the appropriate arguments such as the locations of the datasets.

6. AnalysisOverall the system worked reliably and gave high accuracy for predicting occupancy of a single person in each room of an apartment. It also worked well for predicting if the apartment as a whole was not occupied.

6.1 SensorsThe sensors appeared to be very accurate for detecting motion in the case of PIR and capacitance in the case of the bed sensor. No in depth testing was done to determine exact detection accuracies for these.

6.2 Wireless Blue BeansThe wireless blue beans drained a 9V battery after around three days of testing. Clearly, better life is desired. Experimentations with optimizing the code, as discussed before, were taken. However, anytime the Bluetooth module was powered down it was unreliable in reconnecting to the raspberry pi 3. A step to fix this issue would be switching to a different data protocol such as Wi-Fi for communications between the wireless beans. Additionally the sensors could be designed to plug into common wall sockets for freedom from power issues. More is explored in section 8.

6.3 Raspberry Pi 3The raspberry pi 3 ran well through testing. No issues with server up time came into effect. There were problems with initially connecting to the Bluetooth beans, as discussed in 6.2, however. Another issue was data corruption that happened in the sensor files. It occurred at a rate of 1 incorrectly formatted point for every 1000 data points recorded. This most likely was an error happening in the Node-RED server that was running on the pi 3. This issue was not looked into any further other than analyzing the errors occurring and fixing the issues after the data was pulled from the pi.

6.4 Machine Learning

The clustering algorithm performed poorly on the dataset. As discussed in 4.2. This came from the lack of clearly defined boundaries between the data points. However, this poor performance was recovered with the neural network. The results of the clustering algorithm allowed focus to be directed to bettering the neural network setup rather than exploring other machine learning algorithms that would not have performed well on the data. The neural network results are explored in more detail below.

6.4.1 Dataset OneThe first dataset had issues detecting occupancy in the bedroom. Associated with the lower accuracy in the bedroom was the lower accuracy in away. The issue was due to the nature of the bedroom where there is often little movement due to sleeping. Also, the environment is commonly dark when it is occupied and people are generally covered up during sleep. Naturally this made it hard to predict when the sensors were only being sporadically triggered, matching the no occupancy for the room. All of the other rooms performed very well. The bathroom and kitchen accuracies were so high because not much time was spent in those rooms. Therefore the algorithm only had to correctly predict no occupancy in the rooms.

6.4.2 Dataset Two

The second dataset included additional sensors because of the issues mentioned in 6.4.1. Also, to address the other issue of dataset one, care was taken to make sure all rooms were occupied for significant amounts of time. As can be seen from the results, the additional sensors combined with improvements in the neural network setup improved over the first dataset. The bedroom accuracy, and thus the away accuracy, could most likely be improved with another sensor placed in the room. This judgment is based on the improvement in accuracy from adding the bed sensor.

6.4.3 Dataset ThreeThe third dataset, as discussed before contained the same amount of sensors as dataset two. It was a smaller time period, nearly 3 hours, and care was taken to be sure every room was occupied. The kitchen and bathroom accuracies are expected and respectable results for data that the neural network had not seen at all for training. The bedroom accuracy is higher than expected because during collection of the data there was a lot of movement in the room and no sleeping that took place. From this result combined with the results for the kitchen and bathroom, an accuracy similar to dataset two would be expected for the bedroom. The main room is significantly lower than it had been. This came from the rooms centrally connected location. Because care was taken to be in every room, this involved traveling through the main room a lot. That triggered the sensors in the main room to match the room when it was occupied for longer lengths of time. Finally, the higher accuracy of the bedroom combined with never leaving the apartment during the recording of data led to a higher than expected value for away.

7. Related WorksThere are many works out there that tackle occupancy detection including commercial systems. Some use machine learning like our methods, and others use a variety of methods including Bluetooth beacons. From research and searching, there were not many that used different types of sensors for training and none used that combination with neural networks. The occupancy tracking for energy efficiency project [1] discusses Motion Planning strategies that are used to capture minimal information necessary to detect wasteful states of occupants utilizing a sensor network consisting of inexpensive distance, light, temperature sensors. The project uses a similar implementation of machine learning and IR sensors. Research by J. Yun and S. Lee [2] describes the empirical study of human movement detection and identification using a set of PIR sensors. Research by Ghai S.K., Thanayankizil L.V and Seetharam D.P [3] presents a novel approach for occupancy detection using only context sources that are commonly available in commercial buildings such as area access badges, Wi-Fi access points, Calendar, and Instant Messaging clients. They present models to conduct a situation-centric profiling using such sources and evaluate results of those models. The Dream Green House project [4] maps presence of people in rooms and this information is then be used by a ‘Home Control System’ to make informed decisions and ultimately be able to predict events and take pre-emptive action. [5] Discusses using Bluetooth beacon technology to do the same in a workplace setting.

8. Possible Improvements

Identifying and cornering out the weak spots in certain rooms will help us know and zero in on the complementary sensors that are required to improve the accuracy in those rooms. An example of such an improvement was observed in the bedroom as shown in the data. The accuracy before the bed-sensor was added was 82.76% and that after the bed-sensor was added was 87.11%.

Seasonal changes and environmental changes are known to affect human environment interaction and behavior over time and these changes need to be factored in to make it a well-rounded solution. As of now these variables have not been factored in and so the accuracy levels might change albeit less, due to such factors.

A filtering stage can be added within the sensor modules to delay the sensor trigger to avoid certain false positives that can present itself as good data for certain room transitions. These false positives can be mainly isolated to movement between two rooms through an intermediate room. In the demonstrated setup, such movement would trigger all sensors in all three rooms thus reducing the predictive accuracy in the intermediate room as the person's presence in the intermediate room is in truth negligible and can be ignored. A possible solution would be to filter out this data point before it is processed by the probabilistic inference algorithm by ignoring this intermediate room sensor trigger if the sensors in the two end rooms are triggered in close succession.

This paper explores the first step towards the larger goal of home automation and monitoring with low cost sensors and a basic machine learning algorithm. The addition of different types of such low cost sensors (such as door-mat sensors and light sensors) to this system will only improve the predictive abilities of the algorithm. With more complex information and data, predicting complex human behaviors and activities with more accuracy is possible.

9. ConclusionConstrained by cost and a minimal number of sensors we were able to detect home occupancy to a good degree of accuracy. Our machine learning framework was discussed in detail. We showed that our learning algorithm can accurately detect and predict the presence of a person in the room. We learned that the location of these sensors need better placement strategy and that more sensors for cross validation can greatly improve the occupancy detection algorithm.

REFERENCES

[1] T. Carmenate.; M. Novo. : Occupancy Tracking for Energy Efficiency. A machine learning semester project, Available online: http://users.cs.fiu.edu/ [2] J. Yun.; S. Lee. : Human Movement Detection and Identification Using Pyroelectric Infrared Sensors. Article in Sensors 2014.[3] Ghai, S. K.; Thanayankizil, L. V.; Seetharam, D. P. & Chakraborty, D. (2012), Occupancy detection in commercial buildings using opportunistic context sources., in 'PerCom Workshops' , IEEE Computer Society, pp. 463-466.[4] Dream Green House. An occupancy and presence project Available online: http://dreamgreenhouse.com/projects[5] Using beacon technology & Bluetooth LE applications in a workplace setting. A blog by Sparsh Khandelwal, Available online at: http://www.3pillarglobal.com/insights/using-beacon-technology-bluetooth-le-applications-in-workplace[6] The LightBlue bean and its general description. Available online: https://punchthrough.com/bean

[7] Standalone 5-Pad Capacitive Touch Sensor Breakout - AT42QT1070. Available online: https://www.adafruit.com[8] Machine Learning Strategies for Time Series Prediction, Slides by Gianluca Bontempi, Available online: http://www.ulb.ac.be/[9] Tensorflow, General description, Available online: http://www.tensorflow.org/

[10] Tensorflow on raspberry pi, repository, Available online: https://github.com/samjabrahams/tensorflow-on-raspberry-pi[11] An Explanation of Xavier Initialization, Available online: http://andyljones.tumblr.com/post/110998971763/an-explanation-of-xavier-initialization[12] Yaochu Jin, "Pareto-optimality is everywhere: From engineering design, machine learning, to biological systems," Genetic and Evolving Systems, 2008. GEFS 2008. 3rd International Workshop on, Witten-Bommerholz, 2008, pp. 1-1.