Phase 2 · self-hosted · in progress
A home security system you actually own. An ESP32 sensor network, a touchscreen console, and a Raspberry Pi that watches the camera itself — with no monthly bill and nobody else holding your footage.
209
Commits
4
Contributors
5
Devices in the chain
$0
Monthly cost
Interactive 3D disabled — the full breakdown is written out below.
Ring and Nest work beautifully, right up until you stop paying — and then your recordings are gone. This started from one stubborn question: what would it take to own every layer instead?
Motion and door sensors are ESP32-WROOM nodes, and they never touch your home Wi-Fi. They join a separate access point published by the console — so a compromised sensor cannot reach your laptop.
A single sensor trip crosses two microcontrollers, a Raspberry Pi and your phone. Every hop is a different processor, a different network and a different failure mode. Deciding who owns what — state, credentials, the camera — was most of the actual engineering.
The console's radio and its display talk over bare UART, so the protocol is ours to define: a sync word, a command byte, a length, the payload, a checksum. Framing and integrity had to be specified before a single byte moved.
The Pi runs MobileNet-SSD through OpenCV and only raises an alert for a person. A pet or a moving curtain produces frames but never a notification — which is exactly the failure mode that makes naive motion detection unbearable to live with.
Your Wi-Fi password, the sensor network's key, a per-sensor identity and the disarm PIN are deliberately separate things. Collapsing network trust and application trust into one shared password is how these systems usually fail.
Phase 1 leaned on a rented server and object storage. Phase 2 moved the hub into the house: the Pi owns the camera, fans one feed out to live video and recording, and pushes clips to your own Drive.
Every new device — window sensors, a curtain that closes when an alert fires, a local siren — is worth building only because the event pipeline underneath is already the same for all of them.
Every claim carries its real status. Nothing is called shipped unless you can run it today.
Five components with genuinely separate responsibilities across three networks: sensor nodes, a console, a Pi hub, a mobile client and storage. Boundaries are explicit — the Pi owns the camera and system state, the console owns the keypad and the PIN.
Pi hub, mobile client and storage run today
Console-to-hub transport still an open decision
SYNC · CMD · LEN · PAYLOAD · CRC — framing, a defined
command set, length-prefixed payloads, integrity checks, timeouts,
acknowledgements and explicit handling for corrupt frames.
Specified in full before implementation, because debugging an
unframed serial link is misery.
Complete specification in the architecture document
Firmware is receive-only so far
MobileNet-SSD via OpenCV's DNN module, running on the Pi against the shared camera feed. Detection is class-gated, not motion-gated: only a person raises an event, and a cooldown collapses one intruder into one alert instead of twenty.
Two decisions made it survivable. Inference is decoupled from frame rate, so a slow model never backs up the video buffer. And it reads the network stream rather than the camera device, because exactly one process is allowed to own the hardware.
17 unit tests, no camera required to run them
Model weights verified by checksum, never committed
Failures are enumerated rather than lumped into "connection failed": missing network, weak signal, serial timeout, a device rebooting mid-provision. Retries back off, then stop and report — instead of spinning forever and hiding a dead component behind a busy log.
Shipped and unit-tested in the detector
Firmware failure table not fully implemented
An unconfigured device publishes its own setup network with unique-per-unit credentials, takes Wi-Fi details over that isolated link, then generates and distributes a sensor-network key. Credentials live in memory during setup and in flash afterwards — never in the repository.
Setup wizard, PIN and key generation run today
Per-sensor identity not in firmware yet
A security system that stops working when the internet does is not a security system. One process owns the camera and fans a single feed out to live view, recording and detection at once. All three are local; the network is only needed to tell you.
One publisher, three consumers, no contention
One command pushes the hub to the Pi, runs the test suite before installing, and manages three services with a boot rule that stops the setup server and the product hub ever fighting over the same port. Health and detector state are queryable over HTTP.
Scripted deploy, service units, tests gate install
No hosted CI pipeline yet
The same product rebuilt twice, each time to remove a dependency we didn't want to live with.
Built at HackED 2025. A Raspberry Pi and a cheap camera, an ESP32 for Wi-Fi provisioning, a Node.js backend on a rented EC2 instance storing clips in S3, and an Android app in Jetpack Compose. Alerts arrived over server-sent events in under a second: a full-screen "was it you?" prompt, one tap from a 911 call.
It worked end to end — hardware to cloud to phone. It also arrived with a monthly bill and someone else's servers holding the footage.
Everything Phase 1 did, with the rented infrastructure removed. The Pi is the hub: it owns the camera, publishes one feed that live video, recording and detection all share, caches clips locally and uploads to your Drive. Remote viewing goes through a private tunnel.
And the thing Phase 1 listed as future work is now real: OpenCV object detection runs on the Pi and tells a person from a pet before deciding to wake you. The sensors grew into a proper ESP32-S3 console with a touchscreen and keypad, and the app was rebuilt in React Native.
The event pipeline is the product. Phase 3 plugs more of the house into it: window and door contacts on the same relay, a smart curtain that physically closes when an alert fires, zone arming so you can sleep with the upstairs disarmed, and a local siren so the house still responds with the internet down.
The infrastructure work that unlocks it: closing the console-to-hub transport, over-the-air firmware updates, and letting the camera and the sensor network corroborate each other instead of alerting independently.
Phase 1 was built at HackED, and the writeup ends with a list of what we wanted next — including "an AI layer that can tell the difference between a person and a cat before it wakes you up at 3am."
That line is now a shipped feature with tests.
Read the Devpost writeupIntegration was the hardest part. Every layer worked fine in isolation and broke the moment it had to talk to the next one.
Anurag Koushik
92
@sinisterchiller
Safir Habib
58
@safirhabib
Neaz Mohammad Zahir
32
@NeazMZ06
Ishayat Arik Chowdhury
27
@Ishayat17
The architecture document is the source of truth, and the open decisions are written down rather than hidden — including the one blocking the console-to-hub link. That's the most useful place to start.