IoT BASED FACIAL RECOGNITION DOOR ACCESS CONTROL WITH VIDEO

STREAMING

FACULTY OF SCIENCE AND TECHNOLOGY

CHAPTER 4: RESULTS AND DISCUSSION

BY

CHRISTABEL TRACY KHUMBULA

(R2212776F)
Chapter 4: Results and Discussion

4.1 Introduction

This chapter presents the implementation, testing and evaluation of the developed smart access
control system. Building on the system architecture discussed in the previous chapter, the focus
here shifts to the practical integration of the hardware and software components, particularly the
ESP32-CAM image capture module, the Python-based facial recognition pipeline and the
liveness verification mechanism.

The implementation was aimed at translating the proposed system framework into a functional
real-time security system capable of detecting authorized users, verifying facial liveness and
triggering the door locking mechanism. Particular attention was given to the interaction between
the ESP32-CAM and the server-side application, since reliable communication between these
components is essential for stable operation.

To assess system performance, several tests were conducted under practical operating conditions.
These tests focused on the accuracy of face recognition, the effectiveness of the liveness
detection process in resisting spoofing attempts, the response time of the end-to-end access
control cycle and the reliability of the solenoid lock actuation after successful verification.

The chapter therefore presents the testing procedures used, the results obtained from
implementation and a discussion of the findings in relation to the project objectives and existing
approaches in biometric access control systems.

4.2 Test Procedures / Model Testing

The testing phase was conducted to evaluate the ability of the developed system to distinguish
between a live authorized user and a spoofing attempt while maintaining stable communication
between the ESP32-CAM hardware and the python-based recognition server. The evaluation
focused on three key aspects which are communication reliability, liveness verification accuracy
and hardware actuation.

4.2.1 Hardware Prototyping and Circuit Setup

The physical implementation used an AI-Thinker ESP32-CAM module as the image acquisition
unit. The module was connected to a local wireless hotspot created by the host computer in order
to reduce network congestion and minimize frame transmission delay.

For the locking mechanism, the ESP32 CAM GPIO Pin 12 was interfaced with a 5V relay
module to drive the 12V solenoid door lock. No audible alert modules or buzzers were integrated
into the circuit layout to preserve the available GPIO pins for the camera and memory hardware
interfaces. To improve stability during operation, separate power sources were used. The ESP32-
CAM was powered through a regulated 5V supply, while the solenoid lock was connected to an
independent 12V source. This separation prevented voltage drops during relay activation and
ensured consistent system operation.

4.2.2 Software Testing Procedure and Test Runs

To evaluate the system practically, testing took place under live operating conditions. The
software environment was implemented in Python 3.10 using Flask for server communication,
OpenCV for face recognition and MediaPipe for facial landmark analysis.

A total of 50 test runs were carried out to assess system performance.

 Authorized user trials (30 runs): These tests evaluated whether the system could correctly
recognize an enrolled user and successfully verify liveness before granting access.

 Spoofing attack trials (20 runs): These tests used high-resolution facial photographs and
prerecorded video displayed on a mobile device to assess whether the liveness
mechanism could reject presentation attacks.

The live system prototyping evaluation involved a testing cohort of 5 distinct human participants
(3 males and 2 females) to provide structural data variation. For registration and enrollment, a
baseline dataset of 250 total facial images was established by capturing exactly 50 localized
facial samples per participant under varying head angles. The live testing matrix consisted of 30
authorized entry attempts distributed equally among these 5 registered participants and 20
unauthorized presentation spoofing attacks using static reproductions.

Network performance was also observed during testing. Initial trials were conducted over a high-
traffic wireless network, after which the system was moved to a dedicated hotspot connection.
This allowed communication through a private local IP address and improved the consistency of
frame delivery between the ESP32-CAM and the recognition server.

[Link] Algorithmic Selection Rationale

Deep learning architectures like Convolutional Neural Networks (CNNs) and FaceNet provide
high feature extraction accuracy, but require heavy computational processing, specialized
graphics hardware and large memory spaces. Such frameworks are unviable for this specific
deployment due to the hardware limitations of the edge nodes and the requirement for an
affordable, offline local processing gateway. The Local Binary Patterns Histograms (LBPH)
algorithm was selected because it treats facial recognition as a local texture matching problem.
LBPH extracts spatial structures by comparing pixels with their neighbors, generating small,
compact histogram vectors. This allows the Python gateway server to perform identity matching
efficiently with minimal processor overhead, matching the low-cost design goals of this
residential security system.

4.2.3 Sequential Liveness Verification Logic

The prototype evaluates liveness through a two-step sequence instead of a single static
movement. Once a recognized face was detected, the system first required the user to blink and
then open the mouth. Access was granted only after both physiological actions were successfully
completed in the required order.

The liveness verification was executed in the Python 3.10 environment.

def check_liveness_mediapipe(frame):
global liveness_tracker

rgb_frame = [Link](frame, cv2.COLOR_BGR2RGB)

results = face_mesh.process(rgb_frame)

if not results.multi_face_landmarks:
return "No Face Detected"

face_landmarks = results.multi_face_landmarks[0].landmark
 h, w, _ = [Link]

# Step 1: Blink Detection

left_ear = get_ear(face_landmarks, LEFT_EYE, w, h)
right_ear = get_ear(face_landmarks, RIGHT_EYE, w, h)
avg_ear = (left_ear + right_ear) / 2.0

if avg_ear < EAR_THRESHOLD:

liveness_tracker["eye_closed"] = True
elif liveness_tracker["eye_closed"]:
liveness_tracker["blink_done"] = True
liveness_tracker["eye_closed"] = False

# Step 2: Mouth Opening Detection

mouth_ratio = get_mouth_ratio(face_landmarks, w, h)

if mouth_ratio > 0.05:

liveness_tracker["mouth_done"] = True

# Sequential Decision Logic

if not liveness_tracker["blink_done"]:
return "Please Blink"
elif not liveness_tracker["mouth_done"]:
return "Please Open Mouth"
else:
return "Passed"

The algorithm first verifies a blink using the Eye Aspect Ratio (EAR). Once blinking is
confirmed, the system proceeds to check mouth opening using facial landmark separation around
the lips. Access is granted only after both conditions have been satisfied.
This challenge-response approach handles spoofing risks since static media cannot replicate
consecutive facial changes. This order of operations adds an extra layer of verification against
presentation attacks.

4.2.4 Hardware Response Verification

During each test run, the complete control loop was observed from image capture to hardware
actuation. Once facial recognition and liveness verification were both successful, the Flask server
issued an HTTP GRANT command to the ESP32-CAM. This command activated the relay,
which in turn energized the solenoid lock and unlocked the door.

[Link] Access Grant Trigger

if liveness == "Passed":
system_state["access"] = "Access Granted"
send_esp32_command("GRANT", cooldown=5.0)

This code limits the unlock signal so it sends only when both conditions match successfully.
Success required both a 'Passed' software status and physical movement of the lock components.
Tracking these events showed the prototype operating as an integrated access unit rather than just
an isolated program.

In addition to relay activation, an LED indicator was also used during testing to provide
immediate visual feedback on access decisions. The LED changed state whenever a grant or
deny command was issued, allowing quick confirmation that the control signal had been
successfully transmitted from the flask server to the ESP32-CAM.

4.2.5 Enrolment and Sample Capture

To build the recognition model, the system captured multiple facial samples during enrolment.
This ensured that the LBPH recognizer had enough variation in lighting, expression and slight
pose changes.

[Link] Enrolment Sample Capture

if now - enroll_state["last_capture"] > ENROLL_CAPTURE_INTERVAL:

[Link](image_path, face_roi)
 save_sample_record(person_id, image_path)
enroll_state["count"] += 1

This code stored the detected facial region at fixed intervals until the required number of samples
was collected. In this project, 50 facial samples were captured for each enrolled user before the
recognition model was trained.

4.3 Results Presentation

The results obtained from the 50 test cycles were analysed to determine the effectiveness of the
developed smart access control system in recognizing authorized users, rejecting spoofing
attempts and maintaining stable real-time operation.

The evaluation focused on three main aspects: recognition accuracy, liveness verification
performance and network response time.

4.3.1 System Performance Metrics

The system was subjected to empirical testing to evaluate its operational accuracy and biometric
verification capabilities under real world conditions. The system was evaluated using 50 test runs
to measure the accuracy of the LBPH face recognizer and the MediaPipe liveness detection
system. These trials were split into authorized entries and spoofing attacks to check for errors.
Table 4.1 summarizes the outcomes of the recognition and liveness detection tests

Table 4.1: Recognition and liveness detection results

Test Category Total Trials Successful

Failed/Rejected Accuracy Rate
Access
Authorized User
30 28 2 93.3%
(Live)
Photo Spoofing
20 0 20 100%
Attack
Total 50 28 22 96.0%
The system achieved an overall accuracy of 96.0% across all test runs. For the authorized user
trials, the system successfully granted access in 28 out of 30 attempts. The two failed attempts
occurred under poor lighting conditions, where facial landmark detection became unstable and
the blink action was not reliably captured.

For the photo spoofing trials, the system correctly rejected all 20 attempts. In each case, the
access state remained at the liveness challenge stage because the static image could not satisfy
the required physiological response.

The data shows that adding liveness checks increases security while maintaining recognition
performance.

4.3.2 Physical Prototype Integration

To validate the design requirements, the hardware was assembled into a functional unit. Figure
4.1 shows the final integration of the components used during the testing phase.
Figure 4.1: Final Hardware Prototype Integration.

This figure illustrates the physical integration of the ESP32-CAM, the 5V relay module and the
12V solenoid lock. To ensure stability, the actuation circuit is powered by a separate 12V battery
source, preventing voltage drops (brownouts) from resetting the microcontroller during the
unlock cycle.

4.3.3 Latency and Network Evaluation

Variations in network setups directly altered system responsiveness. During early testing on a
shared wireless network, the average response time was approximately 3.5 seconds. This
introduced frame delays and occasional timeout errors, which negatively affected the smoothness
of real-time interaction.

After switching to a dedicated local laptop hotspot, the average response time decreased to
approximately 0.4 seconds. This provided a more stable live video stream and allowed near-
immediate transmission of hardware control commands. The reduction in latency was further
supported by the software design. Frames were resized early in the pipeline to reduce processing
load, while the use of separate camera reading and frame processing threads prevented the
recognition logic from interrupting frame acquisition.

4.3.4 Liveness Detection Performance

The sequential liveness verification method produced strong anti-spoofing performance during
testing. Static photographs were unable to pass the verification stage because they could not
perform the required physiological actions in sequence:

 Blink detection, which depended on changes in the Eye Aspect Ratio (EAR).

 Mouth opening detection, which depended on vertical lip landmark separation measured
using MediaPipe facial landmarks.

The sequential challenge improved security because both actions had to be completed in the
required order before access could be granted. Even if a spoofing image passed the face
recognition stage, it could not satisfy the liveness verification process.

The inclusion of voice prompts also improved usability during testing. Audible instructions
helped guide the user through the verification stages, especially when the camera was positioned
at a distance from the host computer screen.

4.3.5 Hardware Integration and Reliability

The communication bridge between the flask server and the ESP32-CAM remained stable
throughout the tests. Once recognition and liveness verification were both successful, the server
issued a grant command to the ESP32-CAM. This triggered the relay and activated the solenoid
lock. The solenoid only activated when the liveness state reached passed, confirming that
hardware access remained strictly dependent on successful verification.

The use of a dedicated power supply also improved reliability. Earlier tests showed that
powering both the camera and the locking mechanism from a single unstable source caused
occasional resets. Separating the power sources eliminated this problem and resulted in
consistent hardware response. An LED indicator provided additional visual confirmation of
access decisions. During testing, the LED changed state whenever a grant or deny command was
issued, making it easier to verify correct transmission of control signals.

4.3.6 Access Logging

An SQLite3 database logged each interaction during the evaluation phase. For each access
attempt, the system captured the detected person name, recognition confidence value, liveness
verification status and timestamp of the event. This created a complete audit trail of system
activity, which is important in practical access control environments such as offices, laboratories,
hospitals or restricted retail areas.

Figure 4.6: Database audit logs interface displaying recent system entry activity.

Figure 4.6 illustrates the web application dashboard interface pulling data fields from the
SQLite3 database. The log history provides an exact record of system access decisions recorded
during the testing loops. Each database row documents the parameters used to verify an entry,
including user ID, authentication status, LBPH confidence scores, and MediaPipe results. The
log trace confirms that for the user christa, successful entries returned highly stable confidence
distance scores averaging between 72.2 and 79.6, while an higher score of 102.1 was captured
during minor postural shifts. The timestamps confirm that entries are logged in order, making it
easy to review system activity.

4.3.7 Comparative Scenario Analysis

Unlike standard ESP32-CAM configurations relying only on 2D matching, this prototype

introduces a significantly higher level of protection against spoofing attacks. Basic recognition
systems can often be deceived by a static printed photograph or a facial image displayed on a
mobile screen. In contrast, the proposed system requires the user to perform two live
physiological actions in sequence a blink followed by mouth opening before access is granted.
This ensures that the entity being scanned is a live person rather than a physical or digital
reproduction.

The following table summarizes the system's performance when presented with different
verification scenarios, highlighting how the MediaPipe-based sequential check effectively filters
out non-human or non-live entities:

Table 4.2: Performance comparison across verification scenarios

Test scenario Recognition Liveness stage 1 Liveness stage 2

Access decision
status (blink) (mouth)
Live authorized Passed (EAR < Passed (Ratio >
Identified GRANT
user 0.18) 0.05)
High-res photo Failed (No N/A (Blocked at
Identified DENY
(Print) blink) Stage 1)
Digital photo Failed (Static N/A (Blocked at
Identified DENY
(phone) image) Stage 1)
Failed
Video playback Failed (Out of
Identified (Inconsistent DENY
(Tablet) sequence)
EAR)
Live Unknown N/A (Blocked at N/A (Blocked at DENY
 unauthorized
ID) ID)
user
4.3.8 Computational Efficiency and Responsiveness

A key advantage of this architecture is the distribution of the processing load. Instead of
performing all image processing directly on the ESP32-CAM, the embedded device handles only
image acquisition. The computationally intensive tasks specifically facial recognition and
MediaPipe landmark analysis are executed on the more powerful Python server. This hybrid
approach reduces the processing burden on the microcontroller, effectively mitigating the
thermal and memory constraints of the ESP32-CAM, resulting in improved real-time
responsiveness and system stability.

4.3.9 Discussion of Technical Anomalies

Evaluating the system exposed two main environmental factors that affected operational
performance:

 Lighting Sensitivity: It was noted that extreme backlight could occasionally interfere with
the mouth ratio calculation by obscuring the inner lip landmarks (13 and 14). This
observation confirms that consistent lighting is a prerequisite for high-accuracy biometric
systems.

 Network Jitter: On busy, shared wireless channels, the camera stream would occasionally
exceed the maximum frame age boundary of 2.0 seconds. To maintain security integrity,
the system is programmed to temporarily pause until a fresh frame is received, ensuring
that access decisions are never based on frozen or outdated video data. This network lag
is why the system was moved to a dedicated hotspot to ensure fast operation.

4.4 Discussion of Findings

The implementation and testing results indicate that the hybrid architecture is a practical solution
for real-time access control on resource constrained hardware. The findings show that combining
ESP32 CAM image acquisition with python based recognition and liveness processing improved
both security and operational stability.
4.4.1 Analysis of Recognition and Liveness Performance

The test results showed that facial recognition alone is not sufficient for secure authentication.
Although the LBPH recognizer was able to correctly identify enrolled users in most trials, the
addition of liveness verification was necessary to distinguish a live subject from a spoofing
attempt. The system successfully rejected all photographic spoofing attempts, confirming that the
sequential liveness procedure strengthened access control. A static image could match facial
features during recognition, but it could not satisfy the required blink followed by mouth opening
sequence.

The small failure rate observed during authorized user testing was mainly associated with poor
lighting conditions. Under low illumination, facial landmarks became less stable, particularly
around the eyes, which affected the accuracy of Eye Aspect Ratio (EAR) measurements. This
indicates that illumination remains an important factor in the performance of vision-based
biometric systems.

[Link] Biometric Performance Analysis

A confusion matrix was created to evaluate system performance across the 50 trials (30
authorized entries and 20 spoofing attempts).

Table 4.4: Biometric Performance Confusion Matrix

Category Predicted class: Authorized Predicted class: Unauthorized

Actual: Authorized 28 (True Positive) 2 (False Negative)
Actual: Unauthorized 0 (False Positive) 20 (True Negative)

Table 4.4b: Summary of Operational Biometric Error Rates

Biometric Indicator Operational System

Calculated Percentage
Implication
False Acceptance Rate (FAR) 0.00% Out of 20 spoofing attacks,
zero unauthorized entities
 bypassed the physical lock.
Out of 30 valid approaches,
False Rejection Rate (FRR) 6.67% the system incorrectly denied
entry twice under poor light.
Combined success rate of the
Overall Classification
96.00% system across all 50
Accuracy
operational trial runs.

Although the system achieved a 0% False Acceptance Rate (FAR) across 50 trials, this does not
guarantee absolute invulnerability. Because testing occurred under controlled conditions with a
limited sample size, these metrics reflect preliminary prototype performance rather than
commercial-grade standards.

Calculating these performance metrics relied on standard biometric equations using data from the
50 trials:

 False Acceptance Rate (FAR): This measures the probability that the system incorrectly
grants access to an unauthorized person or a spoofing attempt.
FP 0
FAR= ×100= ×100=0 %
FP+TN 0+ 20
 False Rejection Rate (FRR): This measures the probability that the system incorrectly
denies access to an authorized user.
FN 2
FRR= ×100= ×100=6.67 %
TP+ FN 28+ 2
 Precision: This indicates the proportion of positive identifications that were actually
correct.
TP 28
Precision= ×100= ×100=100 %
TP+ FP 28+ 0
 Recall (Sensitivity) This measures the ability of the system to find all the authorized
users.
TP 28
Recall= × 100= × 100=93.33 %
TP+ FN 28+2
  Accuracy: The overall effectiveness of the system in correctly classifying both authorized
and unauthorized attempts.

TP+ TN 28+20
Accuracy= ×100= ×100=96 %
Total trials 50

[Link] Algorithmic Thresholds and Confidence Analysis

The system utilizes the Local Binary Patterns Histograms algorithm for identity verification.
Unlike other models where a higher percentage equals a better match, LBPH calculates the
Euclidean distance between the feature vectors of the live capture and the stored model. In this
implementation, a confidence value is generated where a lower number represents a closer
match.

Through iterative testing, a threshold of 115.0 was established. Any distance measured below
this value is classified as a match, while values above 115.0 are categorized as unknown to
prevent unauthorized entry. As shown in the software interface validation traces, a successful
recognition of the authorized user christa returned a score of 76.5. This indicates a high fidelity
match, being well within the secure boundary of the 115.0 threshold.

4.4.2 Technical Challenges and Framework Transition

One of the most important findings was that the ESP32 CAM alone was not sufficient for the
computational demands of the project. Initial attempts to perform more advanced processing
directly on the embedded hardware resulted in unstable frame rates and reduced responsiveness.
The ESP32 CAM could not efficiently handle simultaneous video streaming, face recognition
and facial landmark analysis due to strict hardware memory limits.

Moving the computationally intensive tasks to a python flask processing server significantly
improved performance. This allowed the system to make use of MediaPipe facial landmark
tracking while keeping image capture on the ESP32 CAM. The result was more stable real time
performance and improved liveness verification accuracy. These findings suggest that for low
cost embedded security systems, a hybrid edge to server architecture is more practical than fully
embedded processing when advanced biometric analysis is required.

[Link] Component-wise Latency Evaluation

To evaluate the efficiency of the distributed architecture, the time taken for a complete access
cycle from initial face detection to the physical clicking of the solenoid lock was measured over
10 successful trials.

Table 4.5: Component-wise transaction latency profile

Process stage Average duration (Seconds) Responsible node

Image capture and
2.5s ESP32-CAM (Edge)
transmission
Facial landmark extraction 0.8s Gateway server (Python)
Liveness check (Blink and
6.0s User / Gateway
Mouth)
Identity verification (LBPH) 0.5s Gateway server (Python)
Command transmission &
0.2s ESP32-CAM / Relay
actuation
Total End-to-End Latency 10.0s System total

[Link] Latency Analysis and Discussion

The collected transaction data indicates that the liveness verification phase takes up 6.0 seconds
of the total 10.0-second cycle. This delay is not caused by server lag, but by the time it takes a
user to blink and open their mouth inorder to pass the landmark checks. However, an overall
10.0-second wait time to unlock a door is a noticeable operational limitation for a residential
entry point. This 10.0-second delay is an operational limitation for a residential entrance door.
While the local Python backend server processes the matching task in just 0.5 seconds, the
overall throughput is slowed down by the human reaction time required to perform the blink and
mouth actions, alongside the frame-rate limits of the ESP32-CAM hardware. Future versions will
need to focus on optimizing this timeline to make entry faster for the user.
4.4.3 Security Robustness and Anti-Spoofing Results

To check how well the system resists unauthorized entry, spoofing tests were conducted using
digital photographs. The system correctly recognized the authorized user's features from the
presentation samples, but it successfully kept the locking mechanism in a waiting state during all
spoofing attempts. This is because the static image could not provide a changing Eye Aspect
Ratio (EAR) value, proving that simple facial recognition alone is not enough to unlock the door
without a live person present. During testing with an unauthorized phone-based photo, the
system maintained a 0% False Acceptance Rate for unlocking the door.

[Link] Cybersecurity Vulnerability Analysis

Because the prototype is built for low hardware costs, the communications between the ESP32-
CAM and the Python gateway server run over standard unencrypted HTTP web sockets. This
design choice introduces several cybersecurity risks that must be addressed:

 HTTP network sniffing: Since data transfers occur in plain text, an attacker who
successfully gains access to the local Wi-Fi network could intercept the network packets
to capture live MJPEG streaming frames or read system logs.
 Lack of API authentication: The current Flask web backend handles incoming image
payloads and triggers the /GRANT control path without checking specialized API tokens
or secret keys. An attacker could easily forge a malicious HTTP POST request to
manually cycle the door relay.
 Lack of replay protection: The network control messages lack cryptographic salts,
random nonces, or frame timestamps. This makes the system vulnerable to a replay
attack, where an attacker captures a valid GRANT packet stream and rebroadcasts it later
to unlock the mechanism without a face present.
 Lack of encryption: The local SQLite3 database lacks cell-level encryption, meaning
physical access to the server storage exposes all user logs and registration data. Moving
the prototype to a production environment will strictly require using HTTPS, token-based
API authentication headers and flashing firmware that supports basic AES-128 payload
encryption.
4.4.4 System Power and Thermal Stability

Separating the power infrastructure via a 5V/2A adapter for the ESP32-CAM and a 12V battery
for the solenoid prevented the common camera reset issue caused by voltage drops during relay
actuation. Continuous operation of the microcontroller wireless radio and camera sensor resulted
in moderate heat dissipation. However, by disabling the wireless sleep state and optimizing
JPEG quality to 15, the chip maintained a stable operating temperature without performance
throttling.

4.4.5 Comparative Performance: Standalone vs. Distributed Gateway

To justify moving from a standalone setup to a hybrid server model, a performance comparison
was conducted. The standalone configuration attempted to run recognition logic directly on the
ESP32-CAM, while the distributed model utilized the Python-Flask gateway.

Table 4.6: Technical performance comparison of system architectures

Performance metric Standalone (ESP32 Distributed (ESP32 + Improvement

only) Python)
Average Frame Rate
1.5 - 2.0 FPS 10.0 - 15.0 FPS +600%
(FPS)
Face Recognition
3.5s 0.5s 85.7% Faster
Speed
System Stability Frequent Memory High (Stable
Significant
Crashes connectivity)
Liveness Support Not Supported Fully Integrated Required

The data confirms that the Standalone architecture was unable to meet the project's security
requirements. Due to the limited SRAM of the ESP32-CAM, simultaneous video streaming and
facial landmark analysis resulted in frequent system reboots. By offloading these tasks to the
python gateway, the system achieved the necessary frame rate to capture physiological
movements (blinks) reliably. This transition was the key factor in achieving the sub-15-second
access goal.

4.4.6 Iterative Design and Technical Refinements

During the prototyping phase, the following technical hurdles were identified and resolved:

 Buffer Backlog Optimization: Initial tests showed the video stream lagging behind reality
by several seconds. This was resolved by implementing a Last In First Out (LIFO) queue
logic in the Python backend, which discarded stale frames to ensure liveness detection
was performed on the most recent biometric data.
 Actuation Power Stability: A camera reset issue was observed when the solenoid lock
triggered. This was diagnosed as electromagnetic interference and voltage drop. The final
iteration implemented Power Isolation, separating the 5V logic circuit from the 12V
actuation circuit to ensure 100% uptime during the unlock cycle.

4.4.7 Environmental Robustness and Boundary Testing

To ensure the system is reliable in real world conditions, boundary testing was performed across
three variables which are lighting, distance and network stability.

Table 4.7: System environmental boundary testing results

Variable Test Condition Recognition Liveness

Result/Observation
Success Success
Lighting Bright Indoor
100% 100% Optimal performance.
(500 lux)
EAR calculation becomes
Low Light (<
Lighting 70% 40% unstable; requires front-
50 lux)
facing LED.
Distance 0.5 Meters 100% 100% Fast landmark extraction.
Distance 2.5 Meters 60% 20% Resolution (CIF) is too low
for blink detection at this
 range.
Shared Lab Wi- High packet loss; system
Network 30% 10%
Fi timeouts > 30s.
Dedicated
Network 100% 100% Stable 10s latency achieved.
Hotspot

Testing indicates that the system works best at a distance of 0.5 to 1.5 metres under standard
indoor lighting. The failure at 2.5 metres is a hardware limitation of the OV2640 sensor focal
length and image size resolution. Most importantly, the transition to a dedicated 2.4 GHz mobile
hotspot was the deciding factor in meeting the under 10 second latency goal, as it eliminated the
jitter and packet collisions found in the shared laboratory network.

4.4.8 Impact of Network Stability

Network reliability had a direct effect on system performance. During initial tests on a shared
wireless network, noticeable fluctuations in latency were observed. In some cases, delayed frame
delivery caused the recognition pipeline to stall, which led to temporary freezing of the live
video stream. After switching to a dedicated local hotspot connection, frame transmission
became more consistent and overall responsiveness improved significantly. The more stable
network reduced delays between image capture, recognition, liveness verification and hardware
actuation.

This finding shows that for real-time biometric systems, stable local communication is more
important than general internet speed. Even when processing algorithms are efficient, unstable
frame delivery can negatively affect the entire authentication process.
Figure 4.2: Network diagnostic ping echo response latency trace.

As illustrated in the network diagnostic trace in Figure 4.2, the shared infrastructure exhibited a
25% packet loss and a maximum latency of 3194ms. These fluctuations directly impacted the
network response time goal, necessitating the transition to a dedicated local hotspot to ensure
stable operational execution.
Figure 4.3: System dashboard under network stress

Figure 4.3 illustrates the monitoring dashboard during initial testing on a shared university
wireless network. A critical observation is the frozen status indicated in the upper right corner.
This significant latency occurred when the high packet loss identified in the ping diagnostics
prevented the continuous delivery of MJPEG frames from the ESP32 CAM to the processing
gateway.

During this period of network congestion, the system state remained in a paused decision mode,
as the lack of fresh image data meant the Haar Cascade detector could not isolate a face to begin
the sequential liveness challenges. The interface logs confirm the processing bottleneck caused
by shared network routing, as dropping frames pauses the recognition script regardless of
algorithm speed. These findings provided the technical justification for transitioning to a
dedicated local hotspot, which eliminated this 35 second lag.

4.4.9 Hardware Reliability and Control Integration

The hardware integration tests confirmed that the communication bridge between the Flask
server and the ESP32 CAM was reliable. The use of an HTTP based control mechanism allowed
access commands to be sent immediately after successful verification. The solenoid lock
responded consistently whenever the system reached the passed state.

Another important observation was the effect of power stability. Earlier tests showed occasional
resets when the camera and locking mechanism shared the same power source. Using separate
power supplies for the ESP32 CAM and the solenoid lock eliminated this problem and improved
operational reliability. The inclusion of an LED indicator also proved useful during testing, as it
provided immediate visual confirmation of access decisions and made it easier to verify that the
correct hardware signal had been transmitted.

4.4.10 System Unit Testing Phase

Figure 4.4: Liveness detection unit testing.

A sequential liveness check handles potential presentation attacks. The dashboard interface in
Figure 4.4 displays the tracking script checking for an initial blink event. Once the EAR
threshold falls below the 0.18 parameter boundary, the system triggers the next stage, requiring
the user to open their mouth to confirm physiological presence. This state machine tracking
ensures that a static photo cannot trigger an access grant.

4.4.11 System Integration Testing Phase

Figure 4.5: Successful identification confirmation and lock control authorization.

Upon completion of the liveness sequence and a confidence score of 76.5 (well within the
acceptable threshold of 115), the system status updates to Access Granted. The terminal logs
confirm the transmission of the HTTP GRANT command to the ESP32-CAM at port 82,
resulting in the physical retraction of the solenoid.

4.4.12 Ethical, Privacy and Accessibility Considerations

Using facial recognition systems in residential homes raises important privacy concerns
regarding personal identity data ownership. Because the SQLite3 database logs exact
timestamps, names and feature confidence values, securing the server hardware is critical to
prevent unlawful surveillance tracking of residents. Biometric storage must comply with regional
data protection principles by ensuring that all captured facial templates are kept purely on local
hardware drives without any external network leaks.

Biometric vision systems also encounter practical challenges involving systemic bias and
physical accessibility. The underlying Haar Cascade and LBPH algorithms rely heavily on pixel
intensity gradients to detect facial features. Testing revealed that low ambient light levels
degrade verification rates significantly, dropping liveness success down to 40%. This technical
drop-off presents an ethical accessibility issue, as vision models statistically struggle to
consistently detect facial landmarks on individuals with darker skin tones or under poor, uneven
indoor lighting conditions. Additionally, forcing a user to complete a strict behavioral sequence
(blinking and opening the mouth) presents clear accessibility barriers for children, elderly
residents, or individuals with mobility impairments. A inclusive deployment would require an
alternative PIN pad bypass to avoid complete lockout.

4.5 Summary

This chapter presented the implementation, testing and performance evaluation of the developed
smart access control system. The results showed that the proposed hybrid architecture,
combining ESP32 CAM image acquisition with Python based face recognition and liveness
verification, successfully addressed the processing limitations of the embedded device while
maintaining real time operation.

Through 50 test cycles, the system demonstrated reliable performance. It achieved an accuracy
of 93.3% during authorized user trials and successfully rejected 100% of photograph based
spoofing attempts. The use of sequential liveness verification, requiring both a blink and mouth
opening, proved effective in strengthening protection against static presentation attacks.

Testing also showed that network stability played a major role in overall system performance.
Moving from a shared wireless network to a dedicated local hotspot connection significantly
reduced latency and improved the consistency of frame delivery between the ESP32 CAM and
the recognition server. Overall, the implementation confirmed that the developed system was
capable of completing the full access control cycle from face detection, recognition and liveness
verification to hardware actuation of the solenoid lock. The processing metrics remained
consistently within the targeted 10.0 second operational threshold.

The next chapter presents the overall conclusions drawn from the project and provides
recommendations for future improvements to the proposed biometric access control system.