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.
This repository implements a Linux-based voice satellite for Home Assistant, acting as a local voice assistant that connects to Home Assistant via the ESPHome protocol (aioesphomeapi). The application runs as a Python asyncio service, handling wake word detection using TensorFlow Lite models (MicroWakeWord and OpenWakeWord), audio input via the soundcard library, audio output via libmpv, and optional WebRTC noise suppression/gain. It also provides a WebSocket-based Peripheral API (port 6055) that allows external hardware controllers (LED rings, buttons, HAT boards) to register entities and receive real-time state events. The system is deployed via Docker with docker-compose and includes example peripheral implementations for devices like the ReSpeaker HATs, Jabra Speak 410, and Satellite1 HAT. The architecture is modular, with separate modules for the ESPHome API server (api_server.py), core voice pipeline protocol (satellite.py), entity management (entity.py), wake word loading (wake_word.py), audio playback (player/libmpv.py), and peripheral integration (peripheral_api.py). The application is configured via environment variables and command-line arguments, with preferences persisted to a JSON file. The codebase includes unit tests for most modules, CI/CD workflows, and a Docker build pipeline. External dependencies include aioesphomeapi, websockets, soundcard, python-mpv, webrtc-noise-gain, pymicro-wakeword, pyopen-wakeword, and zeroconf. Key data flows: Microphone audio is captured, optionally processed by WebRTC for noise suppression and gain, then fed into wake word detection. Upon wake word detection, the voice pipeline sends audio to Home Assistant for speech recognition and intent handling. Responses (TTS, media) are received and played via MPV. The Peripheral API allows external hardware to send button events and receive state changes (e.g., listening, thinking, muted). The system supports multiple wake words, stop word detection, timers, and media playback with playlist support.
PyLoxone is a Home Assistant integration that enables communication with Loxone Miniserver systems. It allows Home Assistant to discover, monitor, and control Loxone devices (lights, switches, sensors, climate systems, etc.) through both HTTP API and WebSocket connections. The architecture separates Home Assistant-specific logic from the Loxone communication protocol via a dedicated pyloxone_api library. Key features include automatic token-based authentication with refresh capabilities, real-time state updates via WebSocket, entity creation across multiple Home Assistant platforms (sensor, binary_sensor, switch, cover, climate, media_player, etc.), and services for sending direct commands to Loxone devices. The integration handles connection lifecycle management, device discovery, and provides diagnostics and system health information.
HomePlate is embedded firmware for Soldered Inkplate e-paper displays, turning them into wall-mountable smart dashboards. It connects via WiFi to Home Assistant (through MQTT and screenshots) or TRMNL to display content such as Home Assistant dashboards, TRMNL screens, custom images, QR codes, and text messages. The firmware is built on PlatformIO with FreeRTOS, supporting deep sleep for battery life, OTA updates, and a captive portal web configurator. It uses MQTT for Home Assistant discovery, exposing sensors (WiFi RSSI, battery, temperature) and config entities. The architecture is activity-driven: an activity queue dispatches display modes (HomeAssistant, Trmnl, Info, etc.) triggered by MQTT, timers, or physical buttons. Power management is a core focus, with configurable sleep schedules, a wakelock system for critical operations, and always-on mode. The codebase is well-organized, includes unit tests, and has reusable components like a buffer stream wrapper and sleep scheduling logic. It is actively maintained with CI/CD, releases, and a web installer.
Gauge Card Pro is a Home Assistant Lovelace custom card that renders highly customizable gauge visualizations. It extends the native HA Gauge card with dual gauge layers (main and inner), gradient and severity modes, climate control features (HVAC, fan, swing, preset, temperature), template support, and a full visual editor. The card is built as a Lit web component and integrates deeply with Home Assistant's frontend, using internalized copies of HA and Mushroom dependencies for actions, entities, translations, and forms. Key entry points are `src/card/card.ts` (main card class) and `src/editor/editor.ts` (visual editor). Data flows from user configuration (YAML or UI) combined with HA entity state to compute gauge angles, gradient strings, indicators, and value displays. The system relies on external libraries like Lit, tinygradient, superstruct, and zod, and is distributed as a HACS plugin.
This is a Home Assistant add-on that provides automated backup functionality using rclone. The system consists of a Go-based scheduler that runs configured backup jobs (sync, copy, move, delete) against local paths and remote storage services. It features dual services: a scheduler for executing backup jobs and an rclone web GUI for remote configuration. The addon integrates with Home Assistant's event system to report job success/failure and handles backup file naming conventions specific to Home Assistant's backup format. Configuration is managed through Home Assistant's add-on system with options stored in /data/options.json.
HASSL is a compiler for the Home Assistant Simple Scripting Language (DSL) that transforms .hassl files into Home Assistant automation packages. The system parses HASSL syntax using Lark, resolves imports and packages, performs semantic analysis to build an intermediate representation, and generates YAML output including helpers, scripts, sync automations, rule automations, and schedule sensors. Key features include loop-safe context tracking, per-rule enable gates, template-based code reuse, and comprehensive schedule support with window syntax and holiday integration. The architecture is modular with distinct phases: parsing, transformation, analysis, and code generation, each handled in separate modules. The CLI orchestrates the process, handles dependency loading of imported files, and writes output to a directory structure suitable for Home Assistant's packages folder.
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.
This repository provides a complete custom firmware solution for the Sonoff NSPanel smart home touch panel, tightly integrated with Home Assistant via ESPHome and a Home Assistant Blueprint. The firmware is built on ESPHome, a platform for ESP32-based devices, and uses a Nextion display for the user interface. The architecture is modular: a core set of YAML configuration files defines hardware drivers (Wi-Fi, display, relays, buttons, temperature sensor) and page definitions (home, weather, climate, light, cover, alarm, media player, utilities, etc.). Optional add-on YAML packages extend functionality for cover control, climate thermostat, TFT upload, and Bluetooth proxy. The companion C++ component library (in `components/nspanel_ha_blueprint/`) implements the communication protocol between the ESP32 and the Nextion display, handles page logic, and fires Home Assistant events via the ESPHome API. The Blueprint (`nspanel_blueprint.yaml`) allows users to configure all entities and customizations without writing code. Prebuilt firmware binaries are provided for quick flashing. The project is actively maintained, with a large community and frequent releases, though it has significant duplication across HMI variants and some deprecated add-ons.
This repository implements a custom Lovelace card for Home Assistant that displays an interactive map of a robot vacuum's environment. It allows users to select zones, rooms, points, or paths for cleaning and sends corresponding service calls to the vacuum. The card supports multiple vacuum platforms (Xiaomi Miio, Roborock, Valetudo, Neato, Dreame, Roomba, etc.) via platform-specific templates that define map modes, tiles, and icons. It includes a visual editor, localization in 28 languages, pinch-zoom functionality, and a configurable tile/icon system. The architecture is a single-page web component built with LitElement, with modular internal components for map objects, map modes, generators, and UI elements. It relies on Home Assistant frontend internals and custom-card-helpers. The codebase is well-structured with reusable patterns like dependency injection (Context), coordinate transformation (CoordinatesConverter), and template-based service call generation (ServiceCallSchema). However, it has some technical drift due to deprecated rollup plugins, polyfills for legacy browsers, and tight coupling to HA APIs that may break with updates.
This is a Home Assistant custom component (integration) for controlling Gree-compatible air conditioners over the local network via UDP. It implements the Gree reverse-engineered protocol, supporting two encryption versions (AES-128 ECB and AES-128 GCM), device discovery, key negotiation, and full HVAC control (temperature, fan, swing, modes). The architecture follows Home Assistant's platform pattern: a climate entity as the core, with additional switch, sensor, number, and select entities for auxiliary features like X-Fan, lights, health mode, temperature step, and external temperature sensor selection. The integration communicates directly with the AC unit on UDP port 7000, encrypting commands with device-specific keys obtained during setup. It supports both UI config flow (with auto-discovery and cross-VLAN unicast scanning) and YAML configuration. The codebase is well-structured for a custom component, with clear separation of protocol logic (gree_protocol.py), temperature math (helpers.py), and entity definitions. Notable craftsmanship includes the TempOffsetResolver class for auto-detecting sensor offsets, the retry logic with progressive backoff and diagnostic failure classification, and the use of dataclass-based entity descriptions for switches and sensors. However, the main climate.py file is large (912 lines) and there are no automated tests, which is typical for community Home Assistant integrations.
Magic Areas is a Home Assistant custom integration that turns HA's area registry into an occupancy-aware automation layer. In production it listens to entity states across configured areas, computes presence from motion sensors, device trackers, and occupancy binary sensors, manages clear timers and secondary states (dark, sleep, extended), and publishes derived entities: area presence binary sensors, smart light/fan/cover/media groups, aggregate sensors, and feature-override switches. It is event-driven and tightly coupled to Home Assistant internals: the area/entity registries, dispatcher, event bus, async timers, and group entities.
BatMON is a Home Assistant add-on and standalone Docker application for monitoring battery management systems (BMS) over Bluetooth Low Energy (BLE) and serial connections. It decodes telemetry from ~25 BMS families (Daly, JK, ANT, Renogy, Seplos, etc.) and publishes normalized data to MQTT for Home Assistant, or directly to InfluxDB. The architecture is a Python asyncio application with a BMS abstraction layer (`bmslib`) that defines a common interface (`fetch()`, `fetch_voltages()`) and model-specific decoders. The main entry point is `main.py`, which dispatches to HA add-on or standalone mode via `entrypoint.sh`/`addon_main.sh`. Data flows from BMS hardware through BLE/serial adapters into decoder classes, then to MQTT/InfluxDB via a GUI wire format (`bmslib/wire/model.py`). External dependencies include bleak (BLE), paho-mqtt, influxdb, and Home Assistant add-on infrastructure (bashio, supervisor). The project includes a Helm chart, Docker multi-arch builds, and a test suite with known-answer vectors for CRC/AES and protocol decoders.
The system is a Home Assistant addon that enables backup creation and synchronization with OneDrive. Built with ASP.NET Core and Blazor Server, it provides a web UI for configuration and monitoring, scheduled backups with retention policies, file synchronization, and exposes Home Assistant sensor entities for status monitoring. The architecture follows a layered design with separate services for backup management, file synchronization, and external API integrations (Home Assistant and Microsoft Graph). Key entry points include Program.cs for application startup and the Orchestrator for coordinating scheduled tasks. Data flows involve creating backups via the Home Assistant API, uploading to OneDrive via GraphHelper, and synchronizing file changes bidirectionally.
This repository hosts the documentation website for the Home Assistant Community Store (HACS), built with mkdocs-material. It is a static site generator project, not a runtime application. The site is built from Markdown files with custom Python hooks for HTML tag modification, Plausible analytics integration, and shortcode processing. It includes a CI pipeline for linting and building, and uses dependabot for dependency updates. The codebase is well-structured for a documentation project, with clean, reusable hooks and thoughtful theme overrides. While it does not contain application logic or data pipelines, it demonstrates good software engineering practices in the context of documentation generation.
This repository is a large collection of Bash scripts that automate the deployment, configuration, and update of self-hosted services on Proxmox VE, primarily through LXC containers and VMs. It is a provisioning and automation framework rather than a runtime application: each ct/*.sh script declares resource variables (CPU, RAM, disk, OS template) and an optional update_script(), while install/*.sh scripts run inside an existing container to install a specific application. Usage is typically a one-line curl command executed as root on the Proxmox host, after which the script creates a container/VM, installs dependencies, generates credentials, writes systemd units or OpenRC init scripts, and configures databases and reverse proxies. The architecture is layered: hundreds of app-specific scripts wrap a smaller set of shared Bash function libraries in the misc/ directory (build.func, install.func, vm-core.func, core.func, error_handler.func). These shared functions handle common operations such as fetching GitHub releases, setting up language runtimes, creating databases, backing up configs before updates, and standardizing error handling. Update flows generally stop the service, back up configuration/data, fetch the latest release, restore the backup, run migrations, and restart the service. This consistency is the project's main strength and makes adding a new container recipe relatively straightforward. Weaknesses are typical of a large community-driven shell-script collection: no unit tests, heavy reliance on third-party installers fetched via curl|bash, some hardcoded versions, and external dependencies on GitHub release asset names and remote core-library URLs. Many scripts assume Debian/Ubuntu or Alpine bases and run as root with no signature verification. Despite these risks, the codebase is actively maintained, consistently formatted, and the shared function libraries are practical examples of reusable Bash abstractions for Proxmox automation.
This repository is a Home Assistant custom component that integrates Amazon Alexa/Echo devices into Home Assistant. It allows users to control media playback (play, pause, volume, source selection), manage alarms and timers, control smart home devices (lights, switches, sensors, alarm control panel for Alexa Guard), and send notifications (TTS, announcements, mobile push). The component authenticates with Amazon's unofficial internal API via the `alexapy` library, supporting OAuth, TOTP, and 2FA. Architecture follows Home Assistant's component pattern: a config flow for setup, multiple entity platforms (media_player, sensor, switch, light, alarm_control_panel, binary_sensor, notify), a `DataUpdateCoordinator` for polling with HTTP2 push fallback, and custom services. Data flows from Amazon's cloud to HA via either polling (configurable interval) or push updates (WebSocket/HTTP2), with caching and debouncing to reduce API calls. External dependencies include `alexapy`, `packaging`, `wrapt`, and `dictor`. The component is distributed via HACS (Home Assistant Community Store) and supports multiple Amazon accounts with extensive localization.
This repository is a Home Assistant custom integration for communicating with Solarman Stick Loggers to monitor and control solar inverters. It uses Modbus TCP/RTU to read/write inverter registers, exposing the data as Home Assistant entities (sensors, switches, etc.). The integration includes a device discovery mechanism via UDP broadcast, a configuration flow for setup, and a coordinator for periodic data updates. It also provides services for arbitrary Modbus register operations. The inverter definitions are stored in YAML files that specify the register mappings and sensor configurations for various inverter models.
This repository is a Home Assistant custom component that integrates a wide range of Xiaomi Mi smart home devices, including air purifiers, humidifiers, air fresh systems, and pedestal fans. It communicates with devices over the local network using the python-miio library, which implements the Xiaomi MiIO protocol. The component exposes devices as fan or climate entities within Home Assistant, providing controls for power, preset modes, child lock, buzzer, LED, target humidity, oscillation, and other device-specific features. It supports over 50 device models, each with tailored attribute mappings and feature flags. The architecture follows the Home Assistant platform pattern: configuration is provided via YAML, and the async_setup_platform function in fan.py (and climate.py for dehumidifiers) initializes the appropriate device class based on the model. Each device class extends a generic base (XiaomiGenericDevice) that handles common operations like on/off, buzzer, and child lock, while subclasses add model-specific capabilities. The component registers custom services for fine-grained control, such as setting favorite level, LED brightness, or PTC heating. State updates are performed via polling, with retry logic for transient network issues. Primary data flows are unidirectional from device to Home Assistant: the component periodically calls the miio device's status method, extracts relevant attributes, and updates the entity state. Commands from the user are translated into miio method calls via an async executor. External dependencies are limited to Home Assistant core, the python-miio library (>=0.5.12), and the construct library (>=2.10.68). The component does not rely on cloud services; all communication is local. The codebase is actively maintained, with recent commits, CI workflows for linting and validation, and support for the latest Home Assistant versions. It demonstrates solid engineering practices for a custom component: clear separation of device models, feature flag bitmasks to conditionally enable services, and consistent error handling. While tightly coupled to Home Assistant's entity model and the miio library, it is well-organized and serves as a reliable integration for Xiaomi devices.
This repository provides embedded firmware for the ESP8266 that bridges Chinese solar inverters (Voltronic/Axpert, PIP, EASUN, Deye, Anenji, Must PV/PH18) to MQTT and a local web interface. It communicates with inverters via RS232 serial (using proprietary ASCII protocols like PI30, PI18) or RS485 Modbus RTU, parses real-time status (grid, battery, PV, loads, faults), and publishes structured JSON to configurable MQTT topics including Home Assistant auto-discovery. The firmware also hosts a full web-based configuration portal with captive portal for WiFi setup, OTA updates, a live JSON endpoint, and LED status indication. Architecturally, it is a monolithic embedded application written in C++ for the PlatformIO build system. Key entry points are `src/main.cpp` (setup/loop), the web server endpoints, MQTT callbacks, and the serial/Modbus polling loop. The code is organized into a serial protocol handler (`PI_Serial`), an abstract Modbus device layer (`modbus_device`) with concrete implementations, a settings manager using EEPROM with versioning and fallback, and a chunked HTML serving mechanism to avoid heap fragmentation on memory-constrained ESP8266 devices. Notable strengths include the modular Modbus device interface that allows adding new inverter models by subclassing and providing register tables, and the auto-detection logic that probes protocols in sequence. The web UI is built with Bootstrap and jQuery loaded from CDN, and the project actively supports Home Assistant integration and multiple hardware configurations (Wemos D1 Mini, ESP-01, WiFi dongle). While the code is well-structured for an embedded project, it relies on dynamic `String` objects and large JSON documents on a limited memory platform, which could cause heap fragmentation over long periods. The license (CC BY-NC-ND 4.0) restricts commercial use and derivative works, limiting community contributions.