Build an AI-Assisted Security and Alert System

Before you begin

You have a working LED bridge and the trained pedestrian-detection example.

• Connect AI Object Detection to Arduino Outputs
• Read a Button and Control an LED

Build a box monitor, not a promise of protection

Place a magnetic reed switch on a small storage box. When the lid opens, the switch changes state. A nearby camera can add context: did a person-shaped object appear in its view? This is a useful experiment in combining sensors, but it cannot prove who opened the box or whether anything was stolen.

A switch supplies a clear electrical event while vision supplies an uncertain estimate. Combining them does not magically make the result certain. A person may be outside the frame, a model may miss them, or a magnet may hold the switch closed. Write the prototype's boundaries in plain language before trying to improve its score.

Use your own box in a private test area with participants' agreement. This lesson analyzes frames in memory and prints an event label; it does not save pictures, stream video or send alerts to anyone. Detection identifies a class, not a person's identity. Never use this experiment as the only protection for people or property.

Reed switch → Uno → opening event
                              ↓
Camera → computer: person detector → event label → Uno LED

Prepare the computer and the LED bridge

The reference board is an Arduino Uno R3 connected by USB. Start with its built-in LED, so this output needs no external circuit. A laptop performs inference; the Arduino accepts a tiny set of commands. A Raspberry Pi can replace the laptop after its Python setup works. No cloud service is required.

Download bridge.py beside your Python script and the LED sketch. Save the sketch in a folder named led_bridge, open it in Arduino IDE, select Uno and your port, then upload. Close Serial Monitor before opening the port from Python. The kit guide supplies Windows and Raspberry Pi setup alternatives.

On macOS or Linux, create an environment with python3 -m venv .venv, activate it with source .venv/bin/activate, and install the serial library using python -m pip install pyserial. Find your port with python -m serial.tools.list_ports; replace the sample port in the code. Never install a package called bridge: that module is the downloaded file.

Commands are newline-terminated text at 115200 baud. LED_ON means illuminate the indicator; LED_OFF and STOP turn it off. The firmware acknowledges valid messages and turns the LED off after 600 milliseconds without a refreshed light command. Bridge.hold refreshes a requested action for a bounded interval and then sends STOP. An acknowledgement proves a message was parsed; looking at the board checks the physical output.

Add a normally closed test input

Connect a simple normally-open reed switch between D2 and GND. Mount its magnet so closing the box makes the switch conduct. The firmware's internal pull-up means closed reads0 and open reads1. Test those exact values by calling board.read() before involving the camera; product wording about ‘normally open’ can be confusing when the magnet is present.

Keep this a signal circuit with only the Uno's input pull-up. Do not connect an alarm supply to D2. A loose wire reads the same as an open switch, which is why an opening event may also mean a connection fault. Add a short debounce check if the contacts produce multiple changes.

Use a supported USB camera pointed at the agreed test area. Install OpenCV in your environment and place vision.py beside the script. Camera permissions, background lighting and a person's distance all affect whether inference has usable input.

Keep uncertainty visible in the event label

The program checks one opening event rather than running unattended. An open box with no detection is unconfirmed, not safe. Camera failure remains an error. This naming prevents a missing rectangle from being presented as evidence that nothing happened.

import cv2
from bridge import Bridge
from vision import people

with Bridge('/dev/ttyACM0') as board:
    _, _, switch = board.read()
    if switch == 0:
        print('Box closed at this check')
    else:
        camera = cv2.VideoCapture(0)
        try:
            ok, frame = camera.read()
            if not ok:
                raise RuntimeError('Opening detected; camera unavailable')
            count = len(people(frame))
            label = 'person detected' if count else 'visual check unconfirmed'
            print('Opening:', label)
            board.hold('LED_ON', 1.0)
        finally:
            camera.release()

Measure what each sensor contributes

Test a closed box, an open box with a visible participant, an open box with nobody in view, and a disconnected camera. Record the switch state, camera availability, detection result and final label separately. Those columns show which part failed instead of collapsing every problem into ‘the AI is wrong.’

For a longer experiment, store event times and labels without images. Use a cooldown so contact bounce or a box left open does not flood your log. If you later add notifications, require explicit recipient configuration and test with your own account first. Do not let a model choose recipients or publish camera frames.

Sensor fusion should serve a defined decision. Here it adds context to an opening event. Requiring both sensors before any warning would reduce some false alarms but also hide real openings missed by vision. That tradeoff is a design choice you must explain, not a universally better setting.

Important terms

Sensor fusion

Combining information from more than one sensor.

Reed switch

A magnetically operated electrical contact.

Debounce

Filtering short repeated contact transitions.

Unconfirmed event

An event with insufficient supporting evidence for a stronger claim.

Data minimization

Keeping only information needed for the stated purpose.

Mini project: Test four different event states

1. Verify closed0/open1 directly from the switch.
2. Run the four controlled scenarios described in the lesson.
3. Record raw observations and the final label separately.
4. Explain why a missing person box must not cancel an opening event.

Common mistakes and debugging

• Labeling no detection as ‘secure’: a model can miss someone.
• Collecting video merely because a camera is available: this test only needs transient frames.
• Ignoring disconnected inputs: an open wire may resemble an open box.

Independent challenge

Add a short event log with time, switch state and result. Avoid saving images, and cap the number of records so an accidental loop cannot fill storage.

Check your understanding: 10 questions

1. What event triggers the visual check?

2. Does a pedestrian box establish identity?

3. Why pulse the LED even when vision is unconfirmed?

4. What should camera failure produce?

5. What is the main purpose of using two sensors here?

6. In your own words, what does “Sensor fusion” mean?

7. In your own words, what does “Reed switch” mean?

8. In your own words, what does “Debounce” mean?

9. In your own words, what does “Unconfirmed event” mean?

10. In your own words, what does “Data minimization” mean?

Quiz answers

Summary

A useful alert prototype preserves the difference between measurements, uncertain interpretation and faults. Local processing and minimal records make the experiment easier to inspect and less intrusive.

Continue learning

Next, add carefully bounded movement while keeping perception separate from the robot's stop controls.

• Build an AI-Controlled Arduino Robot Car
• Build an AI Security Camera With Raspberry Pi
• How to Verify AI Answers and Detect Mistakes

Sources and further reading

• Arduino input pull-up example
• OpenCV pedestrian detector

Prepared 2026-09-18. Editorial draft. Primary documentation checked; hardware, camera and audio behavior still require a physical test.