ESPectre is a production-grade Wi-Fi motion sensing system that runs on ESP32 microcontrollers. It captures Channel State Information (CSI) from Wi-Fi packets and runs on-device detection algorithms (Lightweight turbulence-based and High Accuracy neural network) to detect human motion without cameras or microphones. The system is designed for local-first operation with no cloud dependency, integrating with Home Assistant via ESPHome, MQTT, or Matter. The architecture is layered: a core sensing layer handles CSI capture, filtering, and feature extraction; a runtime layer manages lifecycle, configuration, and diagnostics; and multiple frontend adapters (native MQTT/HTTP, ESPHome, Matter, MicroPython) expose motion events to home automation systems. A Python CLI provides device discovery, flashing, monitoring, and dataset analysis tools. A web interface at espectre.dev offers browser-based device management. The repository also includes a significant data/research component: a published dataset of CSI recordings, ML training infrastructure, dataset quality validation pipelines, and performance benchmarking tools. These support the development and validation of the detection algorithms and ensure cross-language parity between C++ firmware and Python reference implementations. The codebase demonstrates strong engineering practices: interface-based design for testability, extensive unit and integration tests with coverage gates, cross-language parity enforcement, and a comprehensive CI/CD pipeline. Multiple frontends share a common core SDK, reducing duplication while allowing platform-specific optimizations.
MotionEye is a production-grade, self-hosted web frontend for the Linux motion daemon, providing a comprehensive management interface for IP and USB cameras. The system is implemented as a Python Tornado web server with a RESTful JSON API and a feature-rich single-page JavaScript UI. In production, it manages local and remote cameras, handles real-time MJPEG streaming, motion-triggered recording, scheduled timelapse generation, cloud uploads (S3, WebDAV, FTP, etc.), and notifications via email, Telegram, and webhooks. Configuration is stored in flat text files parsed and written by the motion daemon, with the web server acting as a configuration bridge. The architecture is a monolith: a single Tornado process serves all HTTP requests, manages subprocesses for media processing (ffmpeg), and controls the motion daemon lifecycle. Key entry points include the `meyectl` CLI (for daemon control and maintenance tasks) and the web UI served on port 8765. External dependencies include the motion daemon, ffmpeg/ffprobe, and system utilities for power management, SMB mounts, and WiFi control. While the codebase is large and has accumulated some technical debt (monolithic JavaScript file, hardcoded secrets, SHA1 usage), it demonstrates solid engineering with clear module separation, extensive test coverage for critical handlers, and a well-designed HMAC authentication scheme for server-to-server communication.