Smart Drawer Anti-Theft System

The Smart Drawer Anti-Theft System is an embedded security system designed to protect a drawer, box, or small storage compartment against unauthorized access. The system uses an ESP32 microcontroller and detects suspicious activity using two complementary methods:

• motion and vibration detection using an I2C accelerometer;
• light detection using three LDR sensors placed inside the protected drawer.

The idea is based on the fact that a closed drawer is normally dark and still. If the drawer is opened, light enters and the LDR readings change. If the drawer or box is moved, the accelerometer detects motion or vibration. When the system is armed and one of these events is detected, the ESP32 activates a passive buzzer and sends a notification to a PC application through Bluetooth Low Energy.

The project is useful because it combines multiple embedded systems concepts in a practical application:

• analog sensor reading using ADC;
• I2C communication with a digital accelerometer;
• PWM control for a passive buzzer;
• transistor-based actuator driving;
• Bluetooth Low Energy communication;
• finite state machine control;
• PC-side monitoring and control using a Python desktop application.

The final goal is to obtain a low-cost, breadboard-compatible anti-theft prototype that can be armed and disarmed remotely and that can detect drawer opening, movement or vibration.

The system is built around an ESP32 LOLIN32 Lite board. The ESP32 reads the three LDR voltage dividers through ADC pins, communicates with the accelerometer through I2C, controls a passive buzzer through PWM and a 2N2222 transistor, and exposes a BLE GATT service for communication with a PC.

The user interface is implemented as a Python desktop application. The embedded device has no display and no physical keypad. The user can scan for the ESP32 device, connect to it, arm or disarm the system, request status, calibrate sensors and view logs from the GUI.

The system has three main states:

• DISARMED - the system does not trigger the alarm. Sensors may still be read for status/debugging. The buzzer is off.
• ARMED - the system monitors the accelerometer and the LDR sensors. If motion or light is detected, the system enters the alarm state.
• ALARM - the buzzer is active and the ESP32 sends an alarm notification. The system remains in this state until a correct DISARM <PIN> command is received.

The main supported commands are:

• ARM <PIN>
• DISARM <PIN>
• STATUS
• CHANGE_PIN <old_pin> <new_pin>
• GET_LOG
• CALIBRATE_LIGHT
• CALIBRATE_MOTION
• PING

The default PIN used during development is:

1234

The system contains the following modules:

• ESP32 LOLIN32 Lite - central controller, BLE server, sensor reader and alarm controller.
• LDR sensor module - three LDR voltage dividers connected to ADC pins.
• Accelerometer module - I2C digital accelerometer used for motion/vibration detection.
• Buzzer driver - passive buzzer driven through a 2N2222 NPN transistor.
• BLE communication layer - command/status/log communication between ESP32 and PC.
• Python desktop application - graphical user interface for the user.
• State machine firmware - implements DISARMED, ARMED and ALARM behavior.

The three LDR sensors are used for redundancy. The firmware uses a two-out-of-three voting rule for light detection. This reduces false alarms caused by noise or uneven light distribution inside the drawer.

The accelerometer is used to detect motion, vibration or sudden displacement. This is useful because someone may move the drawer or the entire box without fully opening it.

GPIO34 and GPIO35 are input-only pins, which is acceptable for the LDR voltage dividers because the firmware only needs ADC input. GPIO32 is also ADC-capable and is used for the third LDR. GPIO23 and GPIO22 are used as custom I2C pins for the accelerometer. GPIO17 is used for PWM because the buzzer is passive and must be driven with a square wave.

Each LDR is connected as a voltage divider powered from 3.3 V:

3.3V ---- LDR ---- ADC_PIN ---- 10 kOhm ---- GND

The ADC pins are:

The firmware stores a dark baseline during calibration and then checks the absolute difference between the current ADC value and the baseline. This works even if the voltage divider orientation causes the ADC value to decrease instead of increase under light.

The light detection rule is:

lightDetected = at least 2 of 3 LDR sensors changed more than the configured threshold

The accelerometer module is connected to the ESP32 using I2C:

ESP32 GPIO23  ->  SDA
ESP32 GPIO22  ->  SCL
ESP32 3.3V    ->  VCC
ESP32 GND     ->  GND

The firmware performs an I2C scan at startup and reads the WHO_AM_I register. During testing, the sensor was detected as:

I2C address: 0x19
WHO_AM_I:   0x33
Type:       LIS3DH-compatible

This startup check is important because the accelerometer module appearance was not enough to identify the exact chip with certainty.

The passive buzzer is controlled through a 2N2222 NPN transistor, not directly from an ESP32 GPIO pin. The ESP32 generates a PWM signal on GPIO17, and the transistor works as a low-side switch:

ESP32 GPIO17 --- 1 kOhm --- 2N2222 base
2N2222 emitter ----------- GND
2N2222 collector --------- buzzer negative terminal
buzzer positive terminal - 3.3 V

The buzzer is passive, therefore it requires a PWM/tone signal. The transistor protects the ESP32 GPIO and allows the buzzer current to be switched externally.

The electrical diagram should show:

• all modules powered from 3.3 V;
• common GND rail for ESP32, sensors and buzzer driver;
• three independent LDR voltage dividers;
• accelerometer connected over I2C on GPIO23/GPIO22;
• buzzer connected through a 2N2222 transistor and a 1 kOhm base resistor;
• no ADC input connected to a voltage higher than 3.3 V.

The assembled hardware prototype is shown below. The breadboard implementation contains the ESP32 LOLIN32 Lite board, the LDR voltage divider circuits, the I2C accelerometer module and the transistor-driven passive buzzer.

Current Serial Monitor evidence:

Smart Drawer Anti-Theft System boot
[LOG] 221 BOOT
[LOG] 1578 I2C 0x19 accel=LIS3DH-compatible addr=0x19 who=0x33
[LOG] 1579 LDR raw1=939 base1=937 deltaThreshold=450
[LOG] 1864 BLE advertising SmartDrawerAlarm

This proves that the ESP32 is running uploaded firmware, the I2C accelerometer is wired correctly, the ADC reading for the LDR circuit is functional and BLE advertising starts successfully.

• All sensors are powered from 3.3 V.
• ADC pins must not receive voltages higher than 3.3 V.
• GPIO34 and GPIO35 are input-only pins, which is suitable for LDR readings.
• The buzzer is controlled through a transistor because it should not be powered directly from an ESP32 GPIO.
• All modules must share a common ground.
• USB is used for firmware upload, serial debugging and power during development.
• After firmware upload, the ESP32 can be powered from an external USB power bank.

During development, the ESP32 is powered through the USB cable connected to the laptop. The same cable is used for firmware upload and Serial Monitor debugging. After the firmware has already been uploaded, the board can also be powered from an external USB power bank, because the alarm logic runs directly on the ESP32.

All external sensors are connected to the 3.3 V rail, not to 5 V. This is important because the ESP32 GPIO and ADC inputs are not 5 V tolerant. The LDR voltage dividers are also powered from 3.3 V, so the ADC input voltage cannot exceed the safe range of the ESP32.

The buzzer is not powered directly from a GPIO pin. GPIO17 only drives the base of the 2N2222 transistor through a 1 kOhm resistor. The transistor switches the buzzer current separately, while all components share a common GND reference.

The hardware was verified incrementally instead of connecting all modules and assuming they work. The bring-up order was:

1. connect the ESP32 through USB and verify firmware upload;
2. open Serial Monitor at 115200 baud and verify the boot message;
3. scan the I2C bus and read the accelerometer WHO_AM_I register;
4. verify that at least one LDR ADC value is printed;
5. verify that BLE advertising starts as SmartDrawerAlarm;
6. add the remaining LDR voltage dividers on GPIO35 and GPIO32.

The most important hardware proof at this stage is the Serial Monitor output showing:

• firmware boot;
• I2C device detected at 0x19;
• WHO_AM_I = 0x33, corresponding to a LIS3DH-compatible accelerometer;
• LDR raw ADC value;
• BLE advertising started.

The remaining hardware calibration work is threshold tuning. The final light and motion thresholds must be adjusted after the sensors are mounted in their final physical position inside the drawer, because ambient light, sensor placement and drawer movement influence the measured values.

The firmware is developed using:

• PlatformIO inside VS Code;
• Arduino framework for ESP32;
• NimBLE-Arduino for Bluetooth Low Energy communication;
• Wire library for I2C communication.

The PC application is developed in Python and uses:

• bleak for BLE client communication;
• tkinter / ttk for the desktop GUI;
• JSONL logs for local event recording.

The selected libraries were chosen to keep the project reliable, understandable and suitable for an ESP32 student prototype:

The novelty of the project is not a single sensor or a simple buzzer alarm, but the combination of multiple detection and interaction layers:

• light detection uses three LDR sensors instead of one sensor;
• the firmware uses 2-out-of-3 voting for LDR detection, reducing false alarms caused by one noisy or badly lit sensor;
• motion detection is added using an I2C accelerometer, so the system can detect both drawer opening and physical movement;
• the ESP32 exposes a BLE GATT interface instead of requiring a serial cable for normal use;
• the user controls the system through a Python GUI instead of manually typing BLE commands;
• the laptop application can optionally send one email alert per alarm session.

This makes the project closer to a complete smart security prototype than to a single-sensor lab exercise.

The firmware is organized into multiple modules:

The main state machine is:

DISARMED -> ARMED
    condition: ARM <PIN> with correct PIN

ARMED -> ALARM
    condition: light detected by at least 2 LDRs or motion detected

ARMED -> DISARMED
    condition: DISARM <PIN> with correct PIN

ALARM -> DISARMED
    condition: DISARM <PIN> with correct PIN

The alarm remains active until the correct PIN is received.

The main firmware file creates one object for each subsystem:

EventLogger logger;
LdrSensorArray ldrSensors;
MotionSensor motionSensor;
BuzzerController buzzer;
SecurityStateMachine security;
BleCommandService ble;

This keeps the firmware modular. Sensor code, BLE communication, buzzer control and state transitions are separated into different files instead of being written as one long sketch.

The firmware startup sequence is:

1. start Serial at 115200 baud;
2. initialize the event logger;
3. configure the buzzer PWM output;
4. configure and calibrate the LDR sensors;
5. initialize I2C and identify the accelerometer;
6. start the BLE GATT service;
7. publish the initial status and log messages.

The main loop is intentionally short:

buzzer.update();
pollSensors periodically;
notify status periodically;

The firmware avoids long blocking loops during normal operation. Sensor polling is controlled with millis() using SENSOR_POLL_INTERVAL_MS, and periodic status messages use STATUS_NOTIFY_INTERVAL_MS. This allows BLE commands to remain responsive while the system is armed or while the buzzer is active.

The ESP32 receives commands through the BLE command characteristic. The command handler normalizes the command, extracts tokens and then executes the requested action.

For ARM <PIN>, the firmware:

1. checks the PIN;
2. calibrates the LDR dark baseline;
3. calibrates the accelerometer baseline;
4. switches the state machine to ARMED;
5. stops the buzzer in case it was active;
6. sends OK ARMED.

For DISARM <PIN>, the firmware:

1. checks the PIN;
2. switches the state machine to DISARMED;
3. stops the buzzer;
4. sends OK DISARMED.

For calibration commands, the firmware recalculates baselines and returns a status string with the current sensor information. For invalid commands or wrong PINs, the firmware returns explicit error messages such as ERR WRONG_PIN or ERR INVALID_COMMAND.

The LDR sensors are calibrated by measuring the dark baseline. After calibration, each sensor is checked using:

detected[i] = abs(current_value[i] - baseline[i]) > threshold

The three-sensor voting rule is:

lightDetected = count(detected sensors) >= 2

The firmware uses ACTIVE_LDR_COUNT = 3 and LIGHT_VOTE_REQUIRED = 2. This means that one noisy LDR is not enough to trigger the alarm. At least two sensors must detect a significant light change. Each LDR reading is averaged over multiple ADC samples, which reduces small fluctuations.

The LDR threshold is currently:

LIGHT_THRESHOLD_DELTA = 450

This value is a starting point and must be tuned experimentally for the final drawer, because the raw ADC values depend on the physical placement of the sensors and the amount of ambient light.

The accelerometer is calibrated by reading the baseline acceleration magnitude while the drawer is still. Motion is detected by comparing the current magnitude with the baseline:

magnitude = sqrt(x*x + y*y + z*z)
delta = abs(magnitude - baselineMagnitude)
motionDetected = delta > threshold

At startup, the firmware does not assume the accelerometer type only from the physical module. It scans all I2C addresses, reads register 0x0F and classifies known WHO_AM_I values:

The detected module currently reports 0x33, so the firmware treats it as LIS3DH-compatible. The motion threshold is currently:

MOTION_THRESHOLD_RAW = 1800.0

This threshold must also be tuned experimentally after the accelerometer is fixed in the final drawer position.

The buzzer is passive, so the firmware uses PWM. The alarm pattern is non-blocking and uses millis() timing:

1000 Hz for 200 ms
pause for 100 ms
1500 Hz for 200 ms
pause for 300 ms
repeat until DISARM

This avoids blocking the firmware loop, so BLE commands and sensor reads can continue while the buzzer is active.

The buzzer state machine is separate from the main security state machine. When the alarm is triggered, the firmware calls buzzer.setAlarmActive(true). After that, buzzer.update() is called continuously from the main loop and advances the pattern based on elapsed time. When a valid DISARM command is received, buzzer.stop() immediately turns the PWM duty cycle off.

The ESP32 advertises as:

SmartDrawerAlarm

BLE service UUID:

12345678-1234-5678-1234-56789abcdef0

BLE characteristics:

Supported commands:

ARM <PIN>
DISARM <PIN>
STATUS
CHANGE_PIN <old_pin> <new_pin>
GET_LOG
CALIBRATE_LIGHT
CALIBRATE_MOTION
PING

Example responses:

OK ARMED
OK DISARMED
ERR WRONG_PIN
ERR INVALID_COMMAND
STATUS DISARMED
STATUS ARMED
STATUS ALARM
ALARM LIGHT
ALARM MOTION
ALARM LIGHT_AND_MOTION
PONG

Status messages include the current state, alarm reason, BLE connection state, detected accelerometer type and LDR values. This makes debugging easier because the PC application can show live information without requiring Serial Monitor.

Example status message format:

STATUS ARMED reason=NONE ble=connected accel=LIS3DH-compatible who=0x33 LDR raw1=... base1=... raw2=... base2=... raw3=... base3=... deltaThreshold=450

When a client disconnects, the ESP32 restarts BLE advertising, so the PC application can reconnect without resetting the board.

The Python GUI replaces the manual command-line workflow. It provides:

• BLE scan and connect/disconnect controls;
• manual BLE address input if scanning is unreliable;
• PIN input;
• ARM, DISARM and STATUS buttons;
• CHANGE PIN form;
• live state display with DISARMED / ARMED / ALARM badge;
• sensor/status values parsed from firmware messages;
• diagnostics buttons for PING and calibration;
• event log panel with timestamps;
• mock mode for testing without the ESP32;
• optional email notification when an alarm is detected;
• a Linux desktop executable and launcher for running the application without manually typing Python commands.

The GUI communicates with the ESP32 over BLE. USB is used only for firmware upload, serial debugging and power during development.

The email notification feature is implemented only on the PC side. The ESP32 does not store email credentials and does not connect to Wi-Fi. When the GUI receives an ALARM event through BLE, it can send one email through an SMTP server. The application sends only one email per alarm session, then resets this protection after the system leaves the ALARM state, normally after a valid DISARM command.

The GUI also has a mock mode. This allows the interface, buttons, logs and alarm behavior to be tested without the physical ESP32 connected.

The desktop executable was generated with PyInstaller. On Linux, the application can be started using a .desktop launcher and a custom project icon.

Several optimizations were applied in the firmware and PC application:

• The buzzer pattern is non-blocking and uses millis(), so the ESP32 can still process BLE commands while the alarm is active.
• Sensor polling is periodic instead of continuously blocking the main loop.
• Status notifications are sent periodically, not on every loop iteration.
• LDR readings are averaged over multiple ADC samples to reduce noise.
• The 2-out-of-3 LDR voting rule reduces false alarms caused by one unstable sensor.
• NimBLE-Arduino was chosen because it uses fewer resources than the classic ESP32 BLE stack.
• The firmware is split into modules, which makes each subsystem easier to test and modify.
• The Python GUI uses a background worker thread for BLE operations, so scanning and commands do not freeze the interface.
• Email alerts are handled on the laptop, not on the ESP32, avoiding Wi-Fi configuration and credential storage on the microcontroller.

Current verified results:

• The firmware builds successfully in PlatformIO for WEMOS LOLIN32 Lite.
• The firmware was uploaded to the ESP32 through USB.
• The Serial Monitor shows that the firmware boots correctly.
• The accelerometer is detected over I2C at address 0x19.
• The accelerometer WHO_AM_I value is 0x33, indicating a LIS3DH-compatible device.
• LDR ADC readings are visible in the Serial Monitor.
• BLE advertising starts with the device name SmartDrawerAlarm.
• The Python GUI application was implemented for controlling and monitoring the system.
• A mock mode was implemented so the GUI can be tested without physical hardware.
• The GUI supports optional email alerts for alarm events.
• A local Linux desktop executable and launcher were generated for easier demo usage.
• The project source code was uploaded to GitHub.

Example Serial Monitor output:

Smart Drawer Anti-Theft System boot
[LOG] 221 BOOT
[LOG] 1578 I2C 0x19 accel=LIS3DH-compatible addr=0x19 who=0x33
[LOG] 1579 LDR raw1=939 base1=937 deltaThreshold=450
[LOG] 1864 BLE advertising SmartDrawerAlarm

Tests still to be completed or tuned:

• final light threshold tuning for all three LDRs;
• final motion threshold tuning after mounting the system in the drawer;
• complete alarm demonstration using the passive buzzer;
• long-term BLE reconnect stability test;
• real SMTP email delivery test with the final email account.

The following video demonstrates the complete Smart Drawer Anti-Theft System workflow, including the physical prototype, the ESP32 firmware behavior and interaction with the desktop application:

• Smart Drawer Anti-Theft System - Demo Video

The project currently has a working hardware prototype, modular ESP32 firmware and a Python desktop GUI. The ESP32 can boot the uploaded firmware, detect the accelerometer through I2C, read LDR values and advertise through BLE. The firmware implements the planned security states, sensor logic, BLE command protocol and buzzer alarm pattern.

The most important design decision was to combine two detection methods: light detection using three LDR sensors and motion detection using an accelerometer. This improves reliability compared to using only one sensor type.

Future improvements may include persistent PIN storage in ESP32 NVS, better threshold calibration tools, a cleaner final enclosure and more extensive long-term BLE stability testing.

The project source code is available at:

• https://github.com/MarinescuCalin/Smart-Drawer-Anti-Theft-System

Main project structure:

firmware/SmartDrawerAlarm/     ESP32 firmware
pc_app/smart_drawer_client/    Python BLE CLI client
pc_app/smart_drawer_gui/       Python desktop GUI
assets/icons/                  Application icons
packaging/linux/               Linux desktop launcher
tools/                         Build scripts
platformio.ini                 PlatformIO project configuration
tutorial.md                    Short run tutorial

Important run/build commands:

pio run
pio run -t upload
pio device monitor --baud 115200

cd pc_app
source .venv/bin/activate
python -m smart_drawer_gui.main_gui
python -m smart_drawer_gui.main_gui --mock

cd ..
tools/build_gui_executable.sh

• ESP32 LOLIN32 Lite PlatformIO board documentation: https://docs.platformio.org/en/stable/boards/espressif32/lolin32_lite.html
• ESP32 LOLIN32 Lite pinout reference: https://www.mischianti.org/2021/07/30/esp32-wemos-lolin32-lite-high-resolution-pinout-and-specs/
• NimBLE-Arduino documentation: https://h2zero.github.io/NimBLE-Arduino/
• Bleak documentation: https://bleak.readthedocs.io/
• Python smtplib documentation: https://docs.python.org/3/library/smtplib.html
• PyInstaller documentation: https://pyinstaller.org/
• ST LIS3DH datasheet: https://www.st.com/resource/en/datasheet/lis3dh.pdf
• ST LIS3DSH datasheet: https://www.st.com/resource/en/datasheet/lis3dsh.pdf
• ST H3LIS331DL datasheet: https://www.st.com/resource/en/datasheet/h3lis331dl.pdf
• DokuWiki syntax reference: https://ocw.cs.pub.ro/courses/wiki/syntax
• PM project template: https://ocw.cs.pub.ro/courses/pm/pm/prj2021/template