Valetudo is a production-grade, self-contained control web interface for robot vacuums. It replaces vendor cloud services by running directly on the vacuum's embedded Linux hardware and communicating with the robot over reverse-engineered local protocols (MiIO/MIoT for Dreame and Roborock, MSmart for Midea, and 3irobotix for Viomi). The backend is a Node.js/Express application that exposes a REST API with OpenAPI schemas, server-sent events for live state/map/log updates, MQTT integration for Home Assistant and Homie discovery, an updater for over-the-air firmware-style binary updates, timers, consumables, and map management. The frontend is a React/TypeScript SPA with a canvas-based interactive map renderer, manual control, provisioning, timers, updater UI, and configuration pages.
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.
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.
Tunet is a modern, responsive React dashboard for Home Assistant that provides a customizable interface for monitoring and controlling smart home entities. The application features a React/Vite frontend with an Express/Node.js backend, using SQLite for persistent storage of user configurations. It implements a modular card-based UI system with 20+ specialized card types (lights, climate, media, etc.), real-time WebSocket synchronization with Home Assistant, and extensive customization options including theming, layout configuration, and plugin-like extensibility. The application follows React best practices with custom hooks, context API for state management, and a well-organized component architecture.
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.
Awesome Home Assistant is a community-curated index (an awesome list) of third-party resources for the Home Assistant home automation platform. The repository contains a single massive README.md that serves as the canonical list, organized into sections for custom integrations, dashboard cards, themes, apps, DIY projects, community resources, and more. It is not a software application itself but a well-maintained documentation and curation project with a set of Python maintenance scripts and GitHub Actions workflows that validate entries, check for broken links, refresh star counts, and generate a static website via MkDocs. The repository is designed for contributors to propose additions via pull requests; automated checks enforce entry quality criteria (license, age, activity).
This repository is a Home Assistant custom component (integration) that provides a low-level toolkit for managing Zigbee devices over the ZHA (Zigbee Home Automation) stack. It exposes over 30 fine-grained services—attribute read/write, binding, reporting configuration, OTA firmware updates, coordinator backup/restore, and network scanning—to power users and automations that need direct access to zigpy/ZHA internals not exposed by the standard ZHA integration. It acts as a diagnostic and administrative layer for Zigbee mesh networks, delivering results via HA service responses, events, or exported state/CSV/JSON. The architecture is strictly service-driven. All commands are registered in `__init__.py` and routed through a dynamic dispatcher (`default.py`) that maps service names to modules (e.g., `attr_read` maps to `zcl_attr.command()`) via a naming convention. A shared parameter extraction layer in `utils.py` normalizes IEEE addresses, clusters, endpoints, retries, and event callbacks. Since it deeply probes the internal ZHA/zigpy stack, it relies heavily on version guards (`is_ha_ge`, `is_zigpy_ge`) and radio-specific libraries (Bellows, ZNP, EZSP), which makes it brittle across HA/zigpy releases but proactive about compatibility. The component uses HA's event bus for async feedback, supports state writing with Jinja2-like templates, and downloads OTA firmware from external repositories. While functionally strong and actively maintained, the codebase carries significant technical debt: it performs `importlib.reload` on its own modules per service call (discouraged by HA core guidelines), has thin test coverage (linting/HACS validation only), includes an undocumented user-supplied `_user.py` injection point, and contains many untested edge paths. The dynamic dispatcher and retry/parameter-util patterns are the most valuable, reusable pieces, but most modules are tightly coupled to HA configuration flow and zigpy internal APIs.
ioBroker.vis is a visualization adapter for the ioBroker smart home platform, providing a web-based dashboard editor and runtime. It renders interactive views composed of widgets that bind to ioBroker data points (states/objects) via a real-time socket.io connection. The architecture is monolithic: a single-page application served by an ioBroker adapter, with all editor and runtime logic bundled in global JavaScript files using jQuery, CanJS, jQuery UI, and a homebrewed binding DSL. The widget system supports inline transformations (math, date formatting, JSON extraction) and extensibility via external widget sets. Development of this version has been officially stopped in favor of the rewritten vis-2 adapter, and the repository only receives critical fixes. The codebase exhibits significant technical drift due to outdated dependencies (jQuery 1.x, deprecated AppCache, IE8 polyfills), a monolithic design with tight coupling, and a license inconsistency (CC BY-NC in source files versus MIT in package.json). It is functional but should not be used for new projects.