Internet Of Things - Door Lock

ECED 4513 - Communication Networks

Final Report - Winter 2018/19
Submitted on - 10th April, 2019.
─

Submitted By:
Kaartikeya Pandey
B00688371
Brett Matthew Leard
B00746527
 1

Project Overview
As a part of the mandatory Communication Networks project, our team has decided to
choose an implementation project.
We have decided to create a Internet of Things (IoT) product utilizing the NodeMCU
development platform which is capable of delivering highly integrated Wi-Fi SoC solution to
meet our demands for efficient power usage, compact design and reliable performance in
the Internet of Things industry. Our project aims to create a device which when connected
to the same router as our phone, can be communicated with and tasked to perform certain
functions. Specifically, we are trying to create a sliding door lock which we can interface
with through our phones via the same WiFi network.
Motivated by today's world where mostly all household appliances are being automated
and connected to one network, it is becoming common for unique devices and their need.
People can now program devices such that they can share information between each
other.
Our project plan is simple. After we decide on what specific protocols that we want to
utilize, we will begin to work on developing the required software and hardware for the
project. It is a relatively simple design to achieve, so we are confident that we can achieve
the communication networks we need to establish to complete this project.
 2

Technical Details
Using the NodeMCU development board, the Arduino IDEA, and a handful of programming
libraries made the software for getting this project running easily obtainable. There was
three main parts to the software: Initialization, data capture, and action output. For the
initialization phase we essentially connect to the local area Wi-Fi using the correct
credentials. The servo motor and serial monitor is also initialized here. Once the ESP8266 is
connected, the IP address and UDP port it is connected to is printed to the serial monitor as
shown below.

The UDP object is utilized to parse the data packet, if data is available phase 2 of the code is
executed in which the data is read and processed to determine the servo motor action
where “OPEN” moves the servo into the unlocked position and “CLOSE” moves the servo
to the locked position. Test data was sent using Packet Sender,

By inserting the correct IP address and UDP port we can ensure that the data is being sent.
Received data is printed to the serial monitor of the ESP8266, proving that the software is
working correctly.

This data can also be analysed in wireshark,

 3

Here we can see the internet traffic created by this device as well as he ascii coded data
that is being sent to the device from the packet sender. We can also see the reply packet
being sent using wireshark.

This further confirms the data transmission between the device and test packet. After with
Packet Sender, we were able to find UDP packet sender app which enabled the device to be
accessed from a smartphone.

Comparison to State of the Art

A NodeMCU development board was easily obtained online for a low price of $10.99, which
when paired with their open source software enabled us to easily program the
development board in the Arduino programming language and IDE.
The board makes use of the low-power ESP8266 module, which is an even more affordable
stand alone module.
The ESP8266 has a few compatible network protocols, IPv4, TCP, HTTP and UDP. The board
appeared to be a rising star in the electronics and hobbyist industry due to this and thus
made the decision of choosing a Wi-Fi enabled microcontroller easy. The TCP/IP stack is
available in its entirety and can be easily interfaced with the various open source Arduino
programming libraries available. The ESP8266 has a strong online community that will aid
us with any issues that may occur, including a heavily supported community for said
Arduino libraries. We are beginning to decide which wireless communication protocol we
would like to use for this device, many options are available and simple to program such as
 4

the TCP, UDP, HTTP. An online source was found that outlined a lot of this information,
providing an excellent source to help decide which route to go. We decided to utilise UDP
for the sake of this project.

UDP on the other hand, doesn't guarantee that every packet reaches its destination, it does
check for errors however, but when it finds one, it just destroys the packet, without
re-sending it. This means that it's not as reliable as TCP, but it's faster, and has a much
lower latency, because it doesn't require an open connection to send messages, like TCP
does. That's why it's used in voice and video chats, and
for example in online games.

UDP is connectionless, meaning that we do not need to

make connection first before sending out data, with
more control over when to send the data. UDP has a
16-bit checksum, which is not that reliable. UDP does not
attempt to compensate for lost packets. It also does not
guarantee the correct order of packet delivery since
there is no congestion control. Thus, it will try to cram all
the packets, therefore resulting in more packets getting
dropped.

In the figure alongside we can see a screenshot of a screen from the mobile application
“udpsend”. This app lets us create our own programmable basic UI. We made two buttons,
which would send UDP packets on our house network

A current competitor of the Espressif ESP8266 module is the Air602 WiFi Development
Board which is based on Air602 Wi-Fi module and integrated USB interface and Antenna. If
you plug this board into your computer, it will be recognized as an Ports (COM & LPT), so
that you can code it with a simple Serial Port application. This module support
IEEE802.11b/g/n and AT command. THis module also supports twice as many protocols as
the ESP8266, including ICMP, DHCP and DNS. For its cheap price, low power consumption,
this module is a definite improvement on the Espressif ESP8266. Future iterations of this
project should definitely consider using the

Goals and Deliverables

Our goals and deliverables are organized relative to what our expected design process
would be.
1. Understand the protocols our NodeMCU is compatible to operate with.
2. Build hardware for door lock with hobby servo motor.
 5

3. Successfully integrate developed software with hardware.

4. Functioning proof of concept.
As one can see from the video we recorded that we met all of our expected goals and met
the deliverable.
In addition to these, we knew that the product itself, the IoT Door Lock is far from market
ready. Yes, the software and the hardware are operational, but there are plenty of steps
remaining to perfect the device. An appropriate housing unit, with an extremely sturdy
mounting piece would need to be designed for the device. Since the scope of this project
was to study the network activity and understand basic usage of TCP/IP stack of protocols,
we decided to not go ahead and work on designing a housing unit.

Milestones
Our milestones in this project are closely related to our goals and deliverables.
1. Decide which protocol within the TCP/IP stack would be best suited for this
application (​March 15th​)
After much discussion and research we determined that UDP would be an efficient
protocol for this project. Some issues arose when using this protocol in NodeMCU low
power mode, as it is only able to receive packets when connected to the network. Meaning
this device would not be able to simply “poll” for data for a limited amount of time before
going back into sleep mode as data that is sent, before the board establishes connection
with the network, is lost.
2. Develop software that enables local devices to communicate securely with the
ESP8266 module (​March 22nd​)
This portion of the project was quite simple due to the large amount of Arduino libraries
and online support for the platform. This gave us more time to research more into the
physical workings of the UDP protocol. The software was compiled and tested with Packet
Sender early on in the development of the project.
3. Test this software thoroughly, analyzing the network activity with Wireshark
taking note of any interesting events or potential improvements (​April 1st​)
After the initial test of the software we were able to analyze the network traffic generated
by the device using wireshark. Data was sent using Packet Sender from an arbitrary port to
the specified port in the written ESP8266 software. The IP of the device also had to be
retrieved and inputted which could easily be done with the WiFI object method “localIP()”.
Using wireshark we were able to confirm that the data had been sent from the correct
address and retrieved by the NodeMCU module.
 6

4. Implement software to operate a small 5V hobby servo motor to interact with

a sliding door lock (​April 7th​).
Implementation of a hobby servo motor was done using the servo.h library provided by the
Arduino IDE. By using the PWM functionality of the NodeMCU board we were able to
output a control signal to the servo motor. We also decided to install a manual push button
for use of the door lock without the need of a phone. This switch will only be accessible to
the user once inside the building.

Code
#include <ESP8266WiFi.h>

#include <ESP8266WiFi.h>
#include <WiFiUdp.h>
#include <Servo.h>

// Enter network credentials here

const​ ​char​* ssid = ​"_______"​;
const​ ​char​* password = ​"*********"​;

WiFiUDP Udp;
unsigned​ ​int​ localUdpPort = ​4210​; ​// local port to listen on
char​ incomingPacket[​255​]; ​// buffer for incoming packets

Servo myservo; ​// create servo object to control a servo

unsigned​ ​int​ locked = ​0​; ​// Variables used to store pos values for servo
unsigned​ ​int​ unlocked = ​180​; ​// "
unsigned​ ​int​ readPin = ​14​; ​// GPIO and a button is used to override lock without
a UDP packet
char​ servoPos = ​0​; ​// Used to track servo lock position (1 for locked, 0 for
unlocked)

void​ ​setup​() {
myservo.attach(​2​); ​// attaches the servo on GIO2 to the servo object
pinMode(readPin, INPUT);

Serial.begin(​115200​);
Serial.println();

Serial.​printf​(​"Connecting to %s "​, ssid);

 7

WiFi.begin(ssid, password);
​while​ (WiFi.status() != WL_CONNECTED) {
delay(​500​);
Serial.print(​"."​);
}
Serial.println(​" connected"​);

Udp.begin(localUdpPort);
Serial.​printf​(​"Now listening at IP %s, UDP port %d\n"​,
WiFi.localIP().toString().c_str(), localUdpPort);

myservo.write(​180​);
}

void​ ​loop​() {
​if​(!(digitalRead(readPin))) {
​if​(servoPos) {
Serial.println(​"Unlocking door!"​);
myservo.write(unlocked);
servoPos = ​0​;
delay(​2500​);
} ​else​ {
Serial.println(​"Locking door!"​);
myservo.write(locked);
servoPos = ​1​;
delay(​2500​);
}
}

​ nt​ packetSize = Udp.parsePacket(); ​// Returns size of packet if packet

i
available, 0 if not
​if​ (packetSize) {
​// receive incoming UDP packets
Serial.​printf​(​"Received %d bytes from %s, port %d\n"​, packetSize,
Udp.remoteIP().toString().c_str(), Udp.remotePort());
​int​ len = Udp.read(incomingPacket, ​255​);
​if​ (len > ​0​) {
incomingPacket[len] = ​0​;
}
Serial.​printf​(​"UDP packet contents: %s\n"​, incomingPacket);

​// Process data

 8

​if​(!(​strcmp​(incomingPacket, ​"OPEN"​))) {
​// send back a reply, to the IP address and port we got the packet from
Udp.beginPacket(Udp.remoteIP(), Udp.remotePort());
Udp.write(​"Welcome home! Unlocking door."​);
Udp.endPacket();

Serial.println(​"Unlocking door"​);
myservo.write(unlocked);
servoPos = ​0​;
} ​else​ ​if​(!(​strcmp​(incomingPacket, ​"CLOSE"​))) {
​// send back a reply, to the IP address and port we got the packet from
Udp.beginPacket(Udp.remoteIP(), Udp.remotePort());
Udp.write(​"Have a nice day! Locking door."​);
Udp.endPacket();

Serial.println(​"Locking door"​);
myservo.write(locked);
servoPos = ​1​;
} ​else​ {
​// send back a reply, to the IP address and port we got the packet from
Udp.beginPacket(Udp.remoteIP(), Udp.remotePort());
Udp.write(​"You are not welcome, go away!"​);
Udp.endPacket();
}
}
}

Conclusion
The NodeMCU development board proved to be an excellent choice for this project. As
expected, it provided a simplistic software development environment which allowed us to
focus more on the network activity of such a device.
If we were given the opportunity to start this project from scratch again, we would try to
dig deeper into the software of the ESP8266 module, as using other protocols from the
TCP/IP stack may have allowed data to be sent to the unit while in sleep mode and also
with some more sophisticated error checking. Nonetheless we were able to create an
operating device and perform analysis on the network traffic generated from it. Giving us
an insight into how communication system analysis can play a role in practical devices.
 9

References
ESP8266 Datasheet:
https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.
pdf
ESP8266 Arduino Core’s Documentation:
https://arduino-esp8266.readthedocs.io/en/2.5.0/index.html
NodeMCU Documentation:
https://nodemcu.readthedocs.io/en/master/
ESP8266 Network Protocols:
https://tttapa.github.io/ESP8266/Chap05%20-%20Network%20Protocols.html

______________________________________________________________________________________________
_