Technical Specification

Architecture

Users of our system will place sensor nodes on any appliance or device that they wish to monitor. These nodes will report information back to the main hub, which is responsible for hosting a web page and possibly sending out notifications to users based on the current status of their devices. The nodes must be designed to operate at very low power so as to last as long as possible without needing a recharge or change of battery.

System Description

Overview

This shows how we intend our sensor nodes to be used. We will have a small, cylindrical node stuck to an appliance with an adhesive. The node is intended to be there for a long time, so it doesn’t make sense to use something like a suction cup (weaker than an adhesive), or magnet (will potentially throw off our magnetometer). The piece has a solar cell on top to increase the lifespan of the device. Once placed, the user will not be interacting with the sensor at all.



This diagram displays a basic outline for our sensor nodes. A battery will provide power to our coprocessor, microcontroller and the sensors monitoring the appliance. The solar cell will recharge the battery; depending on the cell we use there may be a need for a small transformer or other device to manage the charging of the battery through the solar cell’s energy (current/voltage limit, etc). We currently plan to have four sensors monitoring the appliance. These sensors will send their data to the microcontroller to do some basic machine learning calculations and filtering. The microcontroller, based on some metrics in its code and information from the main hub, will decide whether to send this data to the coprocessor for further filtering or calculation, or just send the data to the hub with minimal changes. The coprocessor will be sleeping in a very low power state until the microcontroller gives it work/data. The node’s job is to survive as long as possible without requiring a battery change, and to periodically provide the main hub data to be processed. This is aided by the hub sending information about how often the node needs to send data, and which sensors may be powered off or ignored. The microcontroller can then manage the rest of the chip to help keep the device as low power as possible.



Our hub must receive data from the external nodes, train on the sensor data to know when an appliance is on or off, and host a web interface for users to see their current appliance state. We also require a method of storing data such as machine learning training profiles and device history so that our system continues to work if the hub is temporarily shut down. The hub is responsible for detecting whether a device is on or off based on the sensor data using machine learning.

Node Software

The node software’s goal is to keep any parts in a low power state that it can while maintaining all performance requirements. On the 802.15.4 communications microprocessor we will be running the 802.15.4 communication stack as well as controlling and buffering raw data from the sensors. At a dynamically schedulable time the communication microprocessor will send the bundled data to the computation coprocessor if this is needed for the desired metric. This will trigger an interrupt waking the co­processor. The computation processor will read the data, process it, and send back the results to the communications processor. The computation processor will then return to sleep mode.

Hub Software

The hub will be running a web­server that will display web pages dynamically based on the nodes’ states in its database. The hub webpage will include controls for training the node devices and monitoring their states. It will perform machine learning tasks on incoming information from nodes. After the completion of a machine learning task, it will save the 13 results to its database, and it will perform any programmed events based on state changes from the nodes. Specific softwares for this are documented in the design trade studies.

Machine Learning Techniques

We considered using a neural network, decision trees, and a support vector machine as possible techniques to determine the state of the appliance to which the sensor node is attached. A neural network would allow us use more than two states for the appliance, which could be useful if we wanted to expand the system later as part of a stretch goal to say more than whether the device is on or off. A use case for this would be to tell if a washing machine has started a spin cycle. If it turns out that certain appliances’ states are not related in a linear way to the features we collect. The biggest drawback from neural networks are that they can be slow to train with a larger number of features [1]. Decision trees had the advantage of producing a model that is very easy for a human to understand. This would allow us to get a feel for how our system was making decisions and possibly facilitate debugging. Decision trees can take both discrete and continuous features, and allow for more training for more than two categories. Decision trees had the drawbacks of tending to be less accurate than SVMs and neural networks, and training can be slow with a large number of continuous features [2]. For our application, we think that support vector machines make sense. They tend to at least as accurate as neural networks and can be used to quickly classify data [2]. Additionally, we think that support vector machines make sense in our use cases because the values of certain features should vary greatly between the “on” and “off” cases, so the data should be separable by a hyperplane. Once an SVM is trained, categorizing an instance is fast, meaning we could have the node categorize the state of the appliance. This could reduce the amount of information the node would have to transmit over time. SVMs are one of the slower models to train [1], but we don’t think this is an issue because the system is not going to be re­trained frequently, and the training process doesn’t need to appear instantaneous to the user.

Parts