Home Assistant Core is the open-source home automation platform that powers millions of smart homes. It provides a unified event-driven architecture for integrating, controlling, and automating IoT devices, services, and voice assistants. The system runs as a Python async application with a modular component system: each integration (e.g., lights, sensors, climate, locks) is a self-contained Python package under `homeassistant/components/`, following a consistent pattern of config entries, data update coordinators, and entity platforms. Key entry points include the CLI (`hass`), the web-based frontend (served via aiohttp), WebSocket API, and REST API. Data flows are event-driven: state changes, service calls, and automation triggers propagate through a central bus. External dependencies include hundreds of third-party libraries for device communication (BLE, Zigbee, Z-Wave, MQTT, HTTP), cloud services (Nabu Casa, Google Assistant, Alexa), and media playback (Cast, DLNA). The architecture is a monolith with a plugin system, not microservices, but supports horizontal scaling via separate instances and the 'recorder' component for persistent state history.
Frigate is a production-grade, full-stack Network Video Recorder (NVR) with real-time AI object detection. It ingests IP camera streams, performs motion detection, object detection (via TFLite/ONNX/OpenVINO/TensorRT on CPU/GPU/NPU), tracking, and recording. The backend is Python with FastAPI, Peewee ORM, and ZMQ-based inter-process communication. The frontend is a React/TypeScript single-page application with live views, timeline review, config editing, and GenAI enrichments (face recognition, license plates, semantic search, chat). It supports hardware acceleration across a wide range of devices (Coral, Intel iGPU, NVIDIA Jetson, Hailo, Rockchip NPU, etc.) and integrates deeply with Home Assistant. While primarily an application, it contains substantial data/research components including ML model runners, embedding pipelines, and post-processing logic for classification and transcription.
Tasmota is a monolithic firmware application for ESP8266/ESP32 microcontrollers that enables local control of IoT devices via MQTT, HTTP, Serial, or KNX protocols. It provides a web-based configuration interface, OTA update capabilities, automation features (timers/rules), and runtime extensibility through the Berry scripting language. The architecture integrates numerous hardware drivers, networking stacks, GUI components (LVGL), audio processing, and cryptographic implementations into a single firmware image built with PlatformIO. Key entry points include the web server for configuration, MQTT client for telemetry/control, serial command interface, OTA update mechanism, and hardware abstraction layer for peripherals. Data flows involve configuration persistence, sensor telemetry transmission, command reception for actuator control, and firmware update streams.
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.
This is a large polyglot monorepo for WiFi-based human sensing (WiFi-DensePose) that turns commodity WiFi routers into spatial intelligence systems. It captures Channel State Information (CSI) from ESP32 nodes to detect presence, estimate 17-keypoint body pose, measure breathing and heart rate, and track movement through walls without cameras or wearables. The system integrates deeply with Home Assistant via MQTT and Matter, provides a HomeKit bridge, and exposes multiple surfaces: a Rust backend workspace (v2/crates) with 50+ crates for signal processing, privacy shielding (VEIL/BFLD), pose physics, and home automation; Python bindings (PyO3) for ML training and inference; TypeScript CLI and MCP tools for AI agent integration; ESP32-C6/S3 firmware with adaptive sensing; React Native mobile app; Lit-based dashboard; and Tauri desktop app. The architecture is event-driven with a streaming engine, coherence-gated privacy layers, and deterministic verification via SHA-256 golden files. The codebase is heavily ADR-driven with extensive test coverage including cross-language parity gates. While primarily an application, it also contains substantial research code (benchmarks, physics simulations, SOTA surveys) and is best described as a research-informed production platform.
This repository is a Home Assistant custom component that adds OpenAI-compatible text-to-speech to a HA instance. It is distributed as an integration for HACS and registered as a config-flow service integration. In production it exposes TTS entities, an `openai_tts.say` service that announces text to media players with automatic volume save/restore and optional chimes, and an `openai_tts.set_api_key` service for credential rotation. The architecture is a HA integration split into focused modules: config flow and profile subentries, a streaming TTS engine, a sentence-level audio pipelining layer, an ffmpeg-based loudness pipeline, push-driven API health tracking, cache and validation logic, repairs, diagnostics, and a large announcement orchestration module. Provider support is driven by declarative presets for OpenAI, Mistral, Groq, Lemonfox, Kokoro, Chatterbox, and custom OpenAI-compatible endpoints, and the code intentionally modern-targets HA's streaming TTS contract rather than retaining legacy fallback paths.
This is a Prometheus exporter for AVM Fritz! home network devices (routers, repeaters, mesh, DECT smart home) that exposes metrics via a TR-064 SOAP API and the AVM AHA HTTP API. Production deployment is a standalone Python service listening on a configurable address:port (default 127.0.0.1:9787) and registering Prometheus metric families (fritz_*). The architecture is a single-process monolith with a clean capability discovery framework: each metric group is defined as a FritzCapability subclass that declares its TR-064 requirements, probes the device at startup, and generates metrics on each scrape. Devices are configured via a YAML file or environment variables, validated through attrs-based data classes. The exporter handles multi-device mesh scenarios, connection timeouts, offline devices with retry logic, and a concurrent scrape lock to avoid deadlocks. It also includes a data donation mode (--donate-data) that collects all available TR-064 actions from a device, sanitizes sensitive fields, and uploads anonymously to a project endpoint — a hybrid feature supporting both operational monitoring and community-driven compatibility research. External dependencies include the fritzconnection library for TR-064, prometheus_client for metric exposition, defusedxml for secure XML parsing, PyYAML for configuration, and requests for HTTP transport.
TeslaMate is a self-hosted data logger for Tesla vehicles that collects telemetry via the Tesla API (both polling and streaming), stores data in PostgreSQL, and provides visualization through a Phoenix LiveView web interface and Grafana dashboards. It integrates with home automation systems via MQTT and supports importing historical vehicle data from CSV files (TeslaFi format). The application uses a supervision tree to manage background processes for data collection, MQTT publishing, import tasks, and update checking. Key features include geofencing for location-based cost tracking, encrypted storage for API tokens using Cloak, internationalization via Gettext, and custom Ecto expressions for geographic calculations. The architecture is monolithic with clear separation of concerns through Phoenix contexts (Log, Vehicles, Settings, Locations).
openHASP is an embedded firmware framework for home automation touch panels, built around LVGL for GUI rendering. It provides a configurable dashboard for controlling IoT devices via MQTT, with support for ESP32, STM32, and other microcontrollers. The system features hardware abstraction layers for displays and touch controllers, modular services (MQTT, HTTP, FTP, Telnet, WireGuard VPN), OTA updates, and a JSON-based configuration system. It integrates with home automation platforms like Home Assistant through auto-discovery and state topics, while offering local UI interaction via touchscreen. The architecture separates concerns into HAL, GUI, networking, storage, and services, enabling cross-platform deployment.
LedFx is a networked LED light effect controller that synchronizes multiple addressable LED devices (e.g., WLED, LIFX, Nanoleaf, Art-Net, DDP) to real-time audio analysis. It runs as a Python asyncio application with a built-in aiohttp REST API and a prebuilt React frontend served on port 8888. The system captures audio from system loopback, microphone, or network streams (Sendspin), processes it through FFT/melbank/beat detection, and drives audio-reactive effects on virtual LED strips and matrices. It also integrates with now-playing services (MPRIS, SMTC, Sendspin) to extract album art gradients and apply them to effects. The architecture is plugin-based: effects, devices, integrations, and API endpoints are registered via a `BaseRegistry` pattern with voluptuous schema validation. The core runtime (`LedFxCore`) orchestrates device discovery, virtual management, scene/playlist systems, and configuration persistence. The codebase is well-structured with clear separation of concerns, but some modules (e.g., `core.py`, `virtuals.py`) are large and handle multiple responsibilities. The project is actively maintained with comprehensive CI/CD, extensive test coverage (including API integration tests), and detailed documentation for users and developers.
This repository implements a DIY smart lock controller for ESP32 hardware, enabling Apple HomeKey NFC authentication, HomeKit integration, and MQTT connectivity for Home Assistant. The architecture is a hybrid embedded system: a C++ backend built on ESP-IDF (FreeRTOS) handles hardware interaction (NFC, GPIO, Ethernet) and protocol stacks (HomeSpan, mbedTLS), while a Svelte 5 frontend hosted on the device's LittleFS provides a web-based configuration and monitoring interface. The system manages configuration persistence in NVS using MessagePack/JSON serialization and streams real-time logs via WebSocket. Engineering quality is high, featuring RAII wrappers for memory safety in C++, template-based configuration management, and a decoupled event-loop architecture. However, the codebase carries significant security debt, explicitly acknowledging the lack of flash encryption and plain-text password storage in configuration. Hardware support is fragmented across ESP32 variants and NFC modules, requiring hardcoded pin presets that limit portability. Despite 52 open issues, the recent commit activity and modern tech stack (ESP-IDF 5.x, Svelte 5) indicate active development.
This repository provides a custom firmware and backend system for the Sonoff NSPanel smart touchscreen switch, replacing its stock interface with a Home Assistant Lovelace-like UI. The system consists of three core components: a Nextion display firmware (HMI files) rendered on the panel, a Tasmota Berry driver that handles serial communication and flashing, and a backend application running as an AppDaemon app in Home Assistant or as a standalone MQTT manager. The backend processes YAML configuration, manages localization across 38 languages, maps icons to Unicode glyphs, and synchronizes entity states between Home Assistant and the panel via MQTT. The repository also includes extensive documentation, CI/CD workflows for building Docker images and validating HMI changes, and integration examples for ioBroker and IP-Symcon. While primarily an application, it contains substantial data artifacts such as translation JSON files and icon mapping tables that support the UI.
This repository is a Homebridge plugin for Xiaomi Miot devices, allowing control of various smart home devices through Homekit. It supports a wide range of device types, including fans, heaters, humidifiers, air purifiers, and more. The plugin integrates Miot devices into Homekit, enabling control from the native Homekit iOS app and Siri.
MicroLink v2 is a production-ready Tailscale VPN client for ESP32-S3 devices that establishes secure WireGuard tunnels through Tailscale's control plane. It implements the full Tailscale protocol stack including Noise protocol for control plane encryption, HTTP/2 framing, DISCO peer discovery, STUN for NAT traversal, DERP relay fallback, and WireGuard encryption via wireguard-lwip integration. The architecture uses a multi-task FreeRTOS design with separate tasks for coordination, WireGuard management, DERP transmission, network I/O, and application logic, communicating via message queues and event groups. Key features include WiFi/cellular network failover with health monitoring, zero-copy WireGuard receive option for high-throughput scenarios, NVS-based peer caching with LRU eviction, and an HTTP configuration server for runtime management. The code demonstrates strong protocol fidelity through direct reference to Tailscale's Go source files while adapting to embedded constraints.
This is a Home Assistant custom integration for controlling TP-Link Tapo cameras, doorbells, and chimes entirely locally. It provides a comprehensive set of entities (camera, binary sensor, sensor, switch, select, number, button, siren, light, update) and a media source for browsing and playing recordings. The integration communicates with devices via the pytapo library over local IP, using RTSP, proprietary streaming, ONVIF for motion events, and UDP for doorbell presses. It features a multi-step config flow with reauthentication, options flow for fine-tuning, and a background media synchronization system with hot/cold storage and thumbnail generation. The codebase is well-structured with clear patterns (base entity classes, mixins, capability detection) but suffers from a monolithic utils.py (~1500 lines) and a high config flow version number (25) indicating frequent breaking changes. It is actively maintained with recent commits and responsive issue triage, though it relies on undocumented Tapo APIs that may break with firmware updates.
This is a personal Home Assistant configuration repository for automating a smart home. It uses Home Assistant's core automation system supplemented with AppDaemon for complex Python-based automations, HACS for managing community integrations, and Lovelace for custom UI. The configuration controls lighting, climate, security, media players, vacuum robots, and plant monitoring, with integrations for devices like Philips Hue, Xiaomi Aqara, KEF speakers, LG OLED TV, and Roborock. The repository demonstrates good organization through modular includes for reusable configuration snippets, functional separation of automations by domain, and clear separation between YAML-based and Python-based automation approaches.
ESPHome Designer is a Home Assistant custom component that provides a visual drag-and-drop editor for designing display layouts on ESP32/ESP8266 devices running ESPHome. It supports multiple rendering protocols including native ESPHome C++ lambdas, LVGL, OpenEPaperLink (OEPL), and OpenDisplay (ODP). The editor features a canvas with zoom/pan, snap-to-grid, drag-and-drop, lasso selection, and a property panel for configuring widget attributes. Widgets are organized as plugins, each providing render, export, and lifecycle hooks for all supported output formats. The system can generate complete ESPHome YAML configurations including hardware definitions, sensor registrations, font loading, and display lambdas. The architecture is split between a Python backend (Home Assistant integration) and a JavaScript frontend (Vite-built SPA). The backend provides REST APIs for layout CRUD, entity history proxying, image/RSS proxying, hardware profile management, and PNG rendering. The frontend manages state via an AppState singleton with undo/redo, communicates with the backend through a bridge, and supports offline YAML parsing. An AI integration allows generating layouts from natural language prompts using multiple providers (Gemini, OpenAI, OpenRouter). The codebase demonstrates strong engineering practices with a plugin-based architecture, adapter pattern for multi-format export, schema-driven property panels, and extensive test coverage (200+ Vitest tests plus Python tests). It is actively maintained with CI/CD pipelines, quality gates, and regular releases. While the widget plugin surface is large and some legacy modules coexist with newer code, the overall design is modular and extensible.
DSMR-reader is a production-grade Django web application for reading, storing, and visualizing Dutch Smart Meter (DSMR) data from the P1 port. It parses electricity, gas, and water consumption telegrams via serial or network socket, computes hourly/daily statistics with cost calculations, and provides a comprehensive web dashboard with interactive ECharts graphs, a REST API (v1/v2), and integrations with MQTT, InfluxDB, Dropbox, PVOutput, MinderGas, and notification services (Pushover, Telegram, Prowl). The application is container-first (Docker/Podman) and requires PostgreSQL 14+. It exhibits a modular Django app architecture with a signal-driven service layer, singleton settings via django-solo, and extensive test coverage. The frontend is built with Bootstrap 3, jQuery, and Font Awesome 7.2.0 but carries significant technical debt (legacy libraries, unused CSS, jQuery UI), and the project maintains a detailed tech-debt document tracking planned upgrades.
Local Deep Research is a self-hosted, privacy-focused AI research assistant that performs deep, agentic research using multiple LLMs and web searches. It provides a full-stack web application (FastAPI + JavaScript), a programmatic API, and a Model Context Protocol (MCP) server. The system ingests user queries, decomposes them, executes parallel searches across web and academic sources (SearXNG, Google, arXiv, PubMed, Semantic Scholar, etc.), fetches and extracts content, evaluates evidence, and synthesizes reports with citations. It features per-user encrypted SQLCipher databases, a settings system with environment variable overrides, a RAG library with FAISS vector store, journal quality scoring, news subscriptions, and extensive security controls (egress policy, SSRF protection, credential scrubbing). The codebase is heavily tested with unit, integration, UI, accessibility, and security tests. It is a hybrid of a web application and a research data pipeline, but the dominant character is a production-grade application.
This repository provides a Home Assistant custom component (solax_modbus) that integrates solar inverters from multiple brands (SolaX, Growatt, Sofar, Solis, SRNE, etc.) via Modbus TCP/serial/RTU. It exposes real-time sensor data, battery status, energy totals, and control entities (numbers, selects, switches, buttons, time) into Home Assistant. The component features a plugin architecture where each inverter brand has its own module defining entity descriptions, register maps, and inverter detection logic. It includes an energy dashboard virtual device that aggregates grid, solar, battery, and home consumption for the native Home Assistant Energy Dashboard. Advanced capabilities include remote power control (VPP modes), autorepeat loops, parallel master-slave support, and automatic bad-register quarantine. The codebase is well-tested with unit tests and CI/CD, but suffers from some duplication across plugins and hardcoded register maps.