Controlled Via App or Web
Discover how these Cornell students built an Internet-connected door security system with wireless monitoring and control through web and mobile applications. The article discusses the interfacing of a Microchip PIC32 MCU with the Internet, and the application of IoT to a door security system.
The idea for an Internet of things (IoT) door security system came from our desire to grant people remote access to and control over their security system. Connecting the system with the Internet not only improves safety by enabling users to monitor a given entryway remotely, but also allows the system to transmit information about the traffic of the door to the Internet. With these motivations, we designed our system using a Microchip Technology PIC32 microcontroller (MCU) and an Espressif ESP8266 Wi-Fi module to interface a door sensor with the Internet, which gives the user full control over the system via mobile and web applications.
The whole system works in the following way. To start, the PIC32 tells the Wi-Fi module to establish a connection to a TCP socket, which provides fast and reliable communication with the security system’s web server. Once a connection has been established, the PIC32 enters a loop to analyze the distance sensor reading to detect motion in the door. Upon any detection of motion, the PIC32 commands the Wi-Fi module to signal the event to the web server. Each motion detection is saved in memory, and simultaneously the data are sent to the website, which graphs the number of motion detections per unit time. If the security system was armed at the time of motion detection, then the PIC32 will sound the alarm via a piezoelectric speaker from CUI Devices. The alarm system is disarmed at default, so each motion detection is logged in the web application but no sound is played. From both the web and mobile application, the user can arm, disarm and sound the alarm immediately in the case of an emergency.
DESIGN
The PIC32 acts as the hub of the whole system. As shown in Figure 1, each piece of hardware is connected to the MCU, as it detects motion by analyzing distance sensor readings, generates sound for the piezoelectric speaker and commands the Wi-Fi module for actions that pertain to the web server. The distance sensor used in our system is rated to accurately measure distances of only 10 to 80 cm [1]. That’s because motion detection requires us only to measure large changes in distances instead of exact distances, the sensor was sufficient for our needs.
In our design, the sensor is facing down from the top of the doorway, so the nearest object to the sensor is the floor at idle times, when there is no movement through the door. For an average height of a door, about 200 cm, the sensor outputs a miniscule amount of voltage of less than 0.5 V. If a human of average height, about 160 cm, passes through the doorway, then according to the datasheet [1], the distance sensor will output a sudden spike of about 1.5 V. The code on the PIC32 constantly analyzes the distance sensor readings for such spikes, and interprets an increase and subsequent decrease in voltage as motion through the door. The alarm sound is generated by having the PIC32 repeatedly output a 1,500 Hz wave to the piezoelectric speaker through a DAC. We used the DMA feature on the PIC32 for playing the alarm sound, to allow the MCU to signal the alarm without using an interrupt-service-routine. The alarm sound output therefore did not interfere with motion detection and receiving commands from the web server.
The Wi-Fi module we used to connect the PIC32 to the Internet is the ESP8266, which has several variations on the market. We chose model number ESP8266-01 for its low cost and small form factor. This model was not breadboard-compatible, but we designed a mount for the device so that it could be plugged into the breadboard without the need for header wires. Figure 2 shows how the device is attached to the breadboard, along with how the rest of the system is connected.
The module can boot into two different modes, programming or normal, by configuring the GPIO pins during startup. To boot into programming mode, GPIO0 must be pulled to low, while GPIO2 must be pulled high. To boot into normal mode, both GPIO0 and GPIO2 must be pulled high. Programming mode is used for flashing new firmware onto the device, whereas normal mode enables AT commands over UART on the ESP8266. Because we only needed to enable the AT commands on the module, we kept GPIO0 and GPIO2 floating, which safely and consistently booted the module into normal mode.
— ADVERTISMENT—
—Advertise Here—
SENDING COMMANDS
Before interfacing the PIC32 with the Wi-Fi module, we used a USB-to-TTL serial cable to connect the module to a computer, and tested the functionality of its AT commands by sending it commands from a serial terminal. The most basic command the module can accept is “AT,” which elicits the response “OK” from the module and has no purpose other than testing that the device is functional. There are more complex commands, each with its own parameters, responses and functions. For example, to connect the module to Wi-Fi, we first sent “AT+CWLAP”, which lists available access points for the module, then “AT+CWJAP= ssid, pwd” which connects the module to the given access point. We connected the module to Cornell University’s RedRover network even before interfacing it with the PIC32, so that at startup, the module would automatically connect to the RedRover network. For setting up the module, we relied mainly on a guide from MIT [2], and we used a list of AT commands from a Github post from room-15 [3].
The PIC32 communicates with the ESP8266 in the same way as the computer, through AT commands over UART. Sending commands involves storing the intended command in a string buffer and then sending the contents of that buffer byte by byte over the MCU’s UART channel. Receiving messages on the PIC32 involves reading from its serial buffer byte by byte. Because a function must be called to receive messages from the Wi-Fi module, we had to disable the echo feature of the ESP8266, to prevent it from filling the PIC32’s serial buffer with echoed commands and making it difficult to parse out the expected response. To do this, the command “ATE0” is sent at system startup. The PIC32 then sends “AT+CIPCLOSE” to close any existing TCP connection on the Wi-Fi module, so the security system can successfully connect to the web server. “AT+CIPMUX=0” is sent to configure the module for a single TCP connection before “AT+CIPSTART= type, addr, port” is sent with the parameters connection type, IP address and port to establish the TCP connection with the web server.
After each command, we made sure that the PIC32 was receiving the correct response from the ESP8266 by comparing the received message with the expected message. If all the above commands proceed without error or timeout, then the security system has connected itself to the web server successfully, and the user has been granted full wireless control over the system.
Once the TCP connection is established, the PIC32 begins to alternate between two separate threads. One thread detects motion and notifies the web server when it has detected motion, and the other thread receives instructions from the web server and generates the sound for the alarm.
UART COMMUNICATION
There were several nuances to the process of setting up UART communication between the PIC32 and the ESP8266. First, there must be a delay of about 10 ms after sending a command from the PIC32 to the ESP8266, to receive the appropriate response message from the module successfully. If the PIC32 tries to send a second command too quickly, the module will go into a state of unspecified behavior, and the MCU will have difficulty parsing the module’s response to confirm that it received the correct command.
Commands sent to the ESP8266 must end with a carriage return line feed, but responses from the module do not necessarily end the same way. For most cases, it is most reliable to split responses based only on the line feed character. However, with the CIPSEND command, which is used to send data through existing connections, the module does not immediately respond with a message followed by a line feed character. Instead, it responds with the “>” character to indicate its readiness to receive the message to be sent to a server, as shown here:
AT+CIPSEND=4// set the data length which will be sent, such as 4 bytes
>test// enter the data
The example comes from the ESP8266 documentation on AT commands [4], which is consistent when the module is connected directly to a serial port on a computer. However, when connected to the PIC32, the data length must be set to 1 byte longer than the actual length. When the above commands are sent from the PIC32, only “tes” will be received by the server. So, in this example it would be necessary to set the data length to 5 in the PIC32’s code.
There is some non-deterministic behavior related to receiving messages from a server. The ESP8266 will prompt the message below when it has received some data from the server, but if you are sending a longer message, it will non-deterministically chunk the message into multiple UART transmissions in the format below. Adding delimiters to the data sent from the server makes it easier to parse the data received.
— ADVERTISMENT—
—Advertise Here—
+IPD,n:xxxxxxxxxx // received n bytes, data=xxxxxxxxxxx
The design on the server side is simple. The socket server is a Node.js TCP socket that reads for the motion detection notifications sent from the Wi-Fi module, and in turn, notifies the web server of the new event. The web server is a Node.js HTTP API for arming, disarming, playing sound on demand, and subscribing to Server Sent Events (SSE) so the frontend can receive real-time data efficiently. The mobile application is made for Android and is a simple application written in Kotlin [5], a relatively new language by JetBrain. It runs on the Java Virtual Machine, with two toggle buttons tied to HTTP requests sent to the web server to perform the appropriate action—namely arming, disarming and sounding the alarm.
RESULTS
We were pleased by the low-latency performance of our system. From the user side, all the controls from the web and mobile application feel instant to the user, and the web application displays data both accurately and efficiently. We tested the system by waving our hands in front of the sensor several times. Even with quick, subsequent simulated entries or exits, the website was able to graph the number of motion detects accurately by seconds (Figure 3) and minutes (Figure 4).
The door security system was tested by attaching it to the doorway of one of Cornell’s engineering laboratories, and measuring motion detections hourly for 8 hours (Figure 5). Note that our system does not discern the difference between an entry and an exit, so the motion detections depicted in the graph can be either.
A screenshot of the control panel from the web application is shown in Figure 6. This control panel has the same functions has the mobile application shown in Figure 7. The only difference between the two is that the mobile application does not show the charted data.
To verify that our security system works reliably, we tested it extensively in different configurations with subjects moving past it. When the sensor is attached to the top of the doorway, we found that it can detect both tall people (causing the distance sensor to spike up considerably), and people trying to crawl past it (causing a smaller spike). In addition, because the sensor has a 15-degree field of view, it can also detect people trying to sneak past it by moving along the edge of the doorway. Further testing needs to be done to see how wide a door the distance sensor can accommodate.
FALSE POSITIVES
Our sensor rarely failed to detect someone moving past it, but there were some false positives. In a trial of over 100 door pass-throughs, we observed a 98% hit rate, with 2% being false positives. In a real-world setting, this would guarantee the security of any entryway. Because the web and mobile interfaces work seamlessly with the system, the user can easily disable any false alarms by disarming the system using either application.
In terms of performance, sensor data are read at a rate of once per 10 ms, thus ensuring that no subject could ever travel past the sensor undetected. As a result, the time between sending a command from the web frontend or the Android app and receiving it on the PIC32 is not discernible.
Some usability improvements can be added to the security system. Our motion detection algorithm relies on the falling edge of the voltage spike, meaning that motion is only detected after the object has left the entryway. Theoretically, an intruder could cover the sensor while it was armed and not trigger the alarm. One way to alleviate this problem is to log motion detection at the rising edge of voltage.
We have not yet developed an interface for the user to change Wi-Fi networks on the system. In addition, we have not implemented a mechanism for the security system to work without Wi-Fi, so it is currently not possible to arm and disarm the system without Internet access. Adding hardware buttons on the system itself to arm, disarm and sound the alarm would act as a fail-safe, such that the system would not completely depend on a Wi-Fi connection.
Currently, the security system requires power from an electrical outlet. Making the system battery powered would greatly improve its portability, as it would not need to be attached to a doorway near an outlet. The battery could also act as a backup power source in the event of a power outage. Furthermore, web security practices could be implemented to secure the socket connection to ensure that attackers cannot hijack the TCP socket or website.
CONCLUSIONS
By fully enabling communication between the PIC32 MCU and the ESP8266 Wi-Fi module, we are able to extend any hardware device to the Internet. With only a distance sensor and speaker, we were able to connect a simple door alarm to the Internet to increase its functionality as a security system. Most importantly, we developed a group of functions that easily allows a PIC32 developer to leverage the AT commands of the Wi-Fi module to further extend the PIC32’s integration with the Internet.
Extending the functionality of the security system now not only refers to improving the hardware of the security system, but also improving the capabilities of the web server to which it is connected. With this system as a baseline, we believe a similar design process could be used to add more analog sensors, such as a temperature sensor or light sensor, and build a full-fledged smart home system solution such as those offered by Nest labs, ADT or Frontpoint. This project demonstrates not only the importance of the IoT, but also how simple it is to extend a system’s functionality by connecting it to the Internet. 
RESOURCES
References:
[1] Sharp, “GP2Y0A21YK0F Datasheet,”
<https://www.pololu.com/file/0J85/gp2y0a21yk0f.pdf>
[2] Massachusetts Institute of Technology, “Serial to Wi-Fi Tutorial Using ESP8266,”
< http://fab.cba.mit.edu/classes/863.14/tutorials/Programming/serialwifi.html>
[3] fuho, “ESP8266 – AT Command Reference,” room-15, March 26, 2015.
< https://room-15.github.io/blog/2015/03/26/esp8266-at-command-reference>
[4] Espressif Inc., “ESP8266 AT Command Examples,” 2017.
< https://www.espressif.com/sites/default/files/documentation/4b-esp8266_at_command_examples_en.pdf>
[5] JetBrains, “Reference,”
<https://kotlinlang.org/docs/reference/>
— ADVERTISMENT—
—Advertise Here—
Microchip Technology, “PIC32 Peripheral Libraries for MPLAB C32 Compiler,” 2007.
Espressif Systems, “ESPRESSIF SMART CONNECTIVITY PLATFORM: ESP8266,” Oct. 2013. < https://nurdspace.nl/images/e/e0/ESP8266_Specifications_English.pdf >
Matthew Ford, “Using ESP8266 GPIO0/GPIO2/GPIO15 pins”, Apr. 2018.
< http://www.forward.com.au/pfod/ESP8266/GPIOpins/index.html >
Bill of Materials:
| Part Name | Part Number | Manufacturer |
| PIC32 Microcontroller | PIC32MX250F128B | Microchip Technology |
| Wi-Fi Module | ESP8266-01 | Makerfocus |
| Distance Sensor | GP2Y0A02YK0F | Sharp |
| Piezoelectric Speaker | CEP-1141 | CUI Devices |
| Digital-To-Analog Converter | MCP4822 | Microchip Technology |
PIC32 Microcontroller
MCP4822 Digital-To-Analog Converter
Microchip Technology | www.microchip.com
ESP8266 Wi-Fi Module
Espressif Systems | www.espressif.com
GP2Y0A21YK0F Distance Measuring Sensor
Sharp Corporation | www.sharp-world.com
CEP-1141 Piezoelectric Speaker
CUI Devices | www.cuidevices.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • DECEMBER 2018 #341 – Get a PDF of the issue
Sponsor this Article
Norman Chen (nyc7@cornell.edu) is an undergraduate at Cornell, majoring in Electrical and Computer Engineering. He is interested in the financial markets and is always looking for connections between his engineering coursework and finance. In his free time, he enjoys playing and watching basketball, tennis and eSports.
Ram Vellanki (rsv32@cornell.edu) is an undergraduate at Cornell, majoring in Computer Science and minoring Electrical and Computer Engineering. He loves programming and is passionate about technology. In his spare time, he enjoys playing basketball, watching TV and hanging out with friends.
Giacomo Di Liberto (gvd8@cornell.edu) is currently studying Electrical and Computer Engineering at Cornell University. His main interests lie in the field of computer architecture, but he is considering law school as a path to becoming an intellectual property attorney. Aside from coursework, Giacomo enjoys cooking and is an avid soccer fan.
