IoT Door Security System Uses Wi-Fi

Control 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.

By Norman Chen, Ram Vellanki and Giacomo Di Liberto

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 entire 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. 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.


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.

Figure 1
The schematic of the security system. Note that the door sensor runs on 5  V, whereas the rest of the components run on 3.3 V

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.

Figure 2
The full system is wired up on a breadboard. The door sensor is at the bottom of the photo, and is attached facing down from the top of a doorway when in use. The device at the top of the figure is the PIC32 MCU mounted on a development board.

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.


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. …

Read the full article in the December 341 issue of Circuit Cellar

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Places for the IoT Inside Your Home

It’s estimated that by the year 2020, more than 30 billion devices worldwide will be wirelessly connected to the IoT. While the IoT has massive implications for government and industry, individual electronics DIYers have long recognized how projects that enable wireless communication between everyday devices can solve or avert big problems for homeowners.

February CoverOur February issue focusing on Wireless Communications features two such projects, including  Raul Alvarez Torrico’s Home Energy Gateway, which enables users to remotely monitor energy consumption and control household devices (e.g., lights and appliances).

A Digilent chipKIT Max32-based embedded gateway/web server communicates with a single smart power meter and several smart plugs in a home area wireless network. ”The user sees a web interface containing the controls to turn on/off the smart plugs and sees the monitored power consumption data that comes from the smart meter in real time,” Torrico says.

While energy use is one common priority for homeowners, another is protecting property from hidden dangers such as undetected water leaks. Devlin Gualtieri wanted a water alarm system that could integrate several wireless units signaling a single receiver. But he didn’t want to buy one designed to work with expensive home alarm systems charging monthly fees.

In this issue, Gualtieri writes about his wireless water alarm network, which has simple hardware including a Microchip Technology PIC12F675 microcontroller and water conductance sensors (i.e., interdigital electrodes) made out of copper wire wrapped around perforated board.

It’s an inexpensive and efficient approach that can be expanded. “Multiple interdigital sensors can be wired in parallel at a single alarm,” Gualtieri says. A single alarm unit can monitor multiple water sources (e.g., a hot water tank, a clothes washer, and a home heating system boiler).

Also in this issue, columnist George Novacek begins a series on wireless data links. His first article addresses the basic principles of radio communications that can be used in control systems.

Other issue highlights include advice on extending flash memory life; using C language in FPGA design; detecting capacitor dielectric absorption; a Georgia Tech researcher’s essay on the future of inkjet-printed circuitry; and an overview of the hackerspaces and enterprising designs represented at the World Maker Faire in New York.

Editor’s Note: Circuit Cellar‘s February issue will be available online in mid-to-late January for download by members or single-issue purchase by web shop visitors.

Workspace for Coding and Control System Development

Not every engineer’s workspace includes a recliner and a Chihuahua—but this setup works for David Cass Tyler, a retired embedded systems engineer from Willard, NM. Tyler’s “work environment” enables him to “do things at his own pace.”


“This is my normal working environment,” Tyler said. “My assistant is a 3-year-old Chihuahua that believes he is essential for me to correctly code.”

Tyler explained his work setup via e-mail:

When I require extra space to spread out, I move into the spare bedroom and use the desk in there to set up the hardware.

Almost all of my projects are developed to be distributed and accessible through the network. When I need to program on a different computer, I tend to use the remote desktop to program on other Windows-based systems. There is seldom a time when I have to physically move to one of the other systems, so this keeps my dog happy.


Tyler’s 256 I/O channel hardware simulator is shown. “This 24-VDC system has enough channels to comfortably simulate the hardware of almost any of my projects,” he explained.

Tyler is currently working on a 256 I/O channel hardware simulator. He says the PC/104 hardware stack gives him 256 channels of I/O, including 64 analog inputs, 24 analog outputs, and 168 digital I/Os, all in a single compact stack.

He provided some background detail about the system:

In 1995, I was a supervisor with ATK. I designed and had my crew build this system to provide hardware inputs to a control system we were developing for a government customer. I personally programmed the base system and others in my crew used it to develop the hardware simulator.

We also had a 3U 19” rack-mounted box that contained six Rabbit Semiconductor BL2100s, which were the actual controllers used in the system. They enabled us to build the control system before the actual hardware being controlled was delivered. This was the only time in my 30-plus year career that the system was delivered, the controllers were hooked up, and the system ran right out of the box. Of course we had some tweaking and tuning to do, but the system came up under control. There were subsystems that were potentially dangerous to human life, but, with the controllers in place, we were able to safely start up without hurting anyone and without breaking expensive custom equipment.

CassTylerBottom of Canister

The system connectors to Tyler’s 256-channel hardware system are shown.

Tyler also listed some advantages to using the system:

  • You can build the control system without having possession of the actual system.
  • During code coverage and fault testing, you can simulate faults that would be expensive or dangerous to test otherwise.
  • You can continue to develop components after the actual system has been delivered.
  • When writing the simulator, you can understand the interactions better and more completely.
  • You can do virtually all of the training on the simulator, using the exact actual software that will be delivered to the customer.
  • You can respond to many customer requests without having be present at the customer’s site.
CassTyler1553 Box

Tyler’s 1553 system

Tyler’s “workspace” includes several development systems from Rabbit Semiconductor and NetBurner as well as Microchip Technology PIC microcontrollers. He also has a MIL-STD-1553 system with a bus controller and a remote terminal, both controlled by Advantech PCM-3350 CPUs.

Tyler described some of his projects by saying:

I use a combination of hardware and software simulation to develop my control systems. Using hardware simulation, you can feed expected values to controllers to calibrate them and check their functionality. Using software-only functionality, you can develop systems anywhere. With virtual computers, you can test control systems distributed between multiple “computers.” Using this technique, you can deliver control systems, ready for final debugging, at the same time the system hardware is delivered—all from the comfort of your easy chair.

He provided a final thought about built-in web servers:

You can now embed web servers that enable you to run your system without installing anything on the user’s system. With ample available storage, you can put all the datasheets, manuals, and data files directly on the embedded controllers so they are always available, even without an Internet connection. Usually, you can also put some degree of manual control on the web server so you can perform at least rudimentary diagnostics and control.

Tyler is the owner and author of The Control Freak, which he uses to share back to the community. His is currently working on a Standard Commands for Programmable Instruments (SCPI) parser.

Tyler recently wrote a two-part article about Calibration. Part 1 will appear in Circuit Cellar’s November issue.