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.
This repository is a sample application for the Google Home Local SDK, demonstrating how to create a local fulfillment for a smart light device. It consists of three main parts: the local home app (in the `app` directory) that discovers and controls the device using various network protocols (UDP, mDNS, UPnP for discovery; UDP, TCP, HTTP for control); a virtual device (in the `device` directory) that simulates a smart light using the Open Pixel Control (OPC) protocol and supports the same discovery and control protocols for testing; and a Cloud Function (in the `functions` directory) that acts as a placeholder for the cloud-to-cloud backend, handling account linking and returning placeholder responses for SYNC and QUERY intents (while deferring EXECUTE and QUERY to the local fulfillment). The local home app uses a strategy pattern to delegate discovery and execution handling to protocol-specific implementations. The virtual device encapsulates the OPC protocol logic in a reusable component that is independent of the underlying transport mechanism.
This repository is a curated 'awesome list' of Internet of Things (IoT) resources, not a software application or data pipeline. It consists primarily of a large README.md containing categorized links to IoT frameworks, libraries, platforms, tools, protocols, hardware, and educational resources. Two Python utility scripts support maintenance: metadata.py fetches GitHub star counts and update dates for listed projects, and toc.py auto-generates a table of contents from markdown headings. The repo serves as a reference directory for IoT developers, with no runtime code, APIs, or data transformations. The dominant character is a reference list; it is not a deployable application or a data research project.
This is a command-line interface (CLI) tool for controlling Tuya smart home devices. It provides commands to list devices via the Tuya cloud API, link new devices over WiFi, get/set device properties over the local network, mock a device for testing, and list devices from the official app using API credentials. The tool is a Node.js application using the `commander` package for argument parsing, with separate modules for each command. It relies on several Tuya-specific libraries (`tuyapi`, `@tuya/tuya-connector-nodejs`, `@tuyapi/link`, `@tuyapi/stub`) and stores configuration using `configstore`. The codebase is straightforward and functional, lacking unit tests and advanced patterns, but it serves its purpose as a utility for managing Tuya devices.
This repository distributes precompiled binary libraries (static archives) for the ESP32 series WiFi stack, used as a submodule within the Espressif IoT Development Framework (ESP-IDF). It contains no source code for the WiFi stack itself; instead, it provides archived .a files for various ESP32 variants (ESP32, ESP32-S2, ESP32-C3, etc.) and a set of shell scripts and CI configurations to manage library updates, fix symbol collisions (e.g., printf redefinition), and run build and feature tests. The repository acts as a binary release artifact, not a standalone application or library with reusable software components. Its primary purpose is to be checked out as a submodule in ESP-IDF to supply the low-level WiFi, mesh, and networking layers.
This repository provides the firmware and desktop tools for Petoi's quadruped robots (Bittle, Nybble, Chero). The core is an Arduino-based firmware (OpenCat.ino) running on ATmega328P (NyBoard) that handles servo control, gait generation, IMU integration, sensor processing (IR, ultrasonic, gesture, voice), and skill execution via pre-programmed motion sequences. A Python desktop application (pyUI) offers firmware upload, joint calibration, skill composition, and debugging. A Python serial API (serialMaster, OpenCatPythonAPI) enables scripting robot behaviors. The architecture is monolithic firmware with conditional compilation for multiple hardware variants and sensor options. While the project has a large user base and extensive documentation, the codebase shows signs of technical drift: it is explicitly legacy (development moved to OpenCatESP32), relies on outdated libraries, has duplicated code (e.g., three copies of IRremote), and uses global state and hardcoded paths. The skill system and serial protocol are well-defined patterns, but overall reusability is limited by tight coupling to specific hardware and board versions.
The ZeroClaw-Android repository is an archived Android application project that was intended as an experiment to create a home for AI agents on Android. The README explicitly states the project is archived due to scope concerns and safety issues with the largely AI-generated codebase. No actual source code is visible in the provided file tree beyond the README and a ZIP archive (ZeroClaw-Android-main.zip) whose contents cannot be inspected. The repository consists almost entirely of Git metadata, indicating the source code is not directly accessible for analysis. Without access to the application code, it is impossible to assess architecture, functionality, or code quality. The project is marked as abandoned with no maintenance activity.