Seeing Motion, Not Just Frames: Building a DIY Security System Around Real-Time Detection
Security systems look simple until multiple things need to happen at once. Video has to stream. Detection has to run continuously. Controls have to respond immediately. Even in a small project, those pieces start fighting each other.
This started as a learning project around real-time computer vision, but it became more about coordination than detection. The interesting part was not getting a pretrained model to recognize a person. It was making vision, voice commands, and a web dashboard live inside one Python program without blocking each other.
Making Concurrent Pieces Behave
The core loop used MobileNet-SSD to process webcam frames and filter for people with a confidence threshold above 0.5. When the system was armed and a person appeared, it captured timestamped screenshots with a cooldown to avoid flooding storage.
The part I cared about most was threading. Flask ran for the dashboard. A separate voice listener waited for arm and disarm commands. The detection loop kept processing frames. Getting those pieces to coexist cleanly mattered more than adding more features.
- Running the video feed as MJPEG through Flask so monitoring stayed lightweight
- Using a shared security state between voice commands, web controls, and detection logic
- Enabling CUDA when available to keep inference responsive on compatible hardware
None of this was large scale. The codebase was under two hundred lines. But fitting those systems together taught me more than writing a larger app would have.
Small Decisions That Mattered
One detail I liked was the five second screenshot cooldown. It is a tiny constraint, but without it a single detection event could fill storage fast. That kind of detail makes toy projects feel a little closer to real systems.
Voice control was another interesting experiment. Saying arm security and changing state hands free felt simple, but connecting speech recognition into a live loop introduced reliability questions I had not thought about before.
What Broke First
Voice recognition was the weakest part. It depended on an external speech API and struggled in noisy conditions. That made it feel more like a prototype feature than something trustworthy.
Security was also incomplete. The web interface had no authentication. The armed state was not persistent across restarts. A lot of parameters were hardcoded, including thresholds and model paths. Those shortcuts were fine for learning, but I would not keep them in a second version.
If I rebuilt it, I would focus less on adding detections and more on robustness. Persistent state. Multi camera support. Authentication. Local voice handling instead of depending on the network.
What It Represented
This was one of the first projects where software felt like a system instead of a script. Not because it was huge. Because timing mattered. Inputs came from different places. Failures were messy and physical.
A person in a frame is easy to detect. Making the rest of the system react well is where the real work starts.