This repository is the deCONZ REST plugin, a C++/Qt plugin that turns a ConBee/RaspBee Zigbee USB gateway into a full-featured IoT controller. It exposes a REST API (emulating Philips Hue) to manage lights, sensors, groups, scenes, rules, schedules, alarms, and devices over Zigbee (ZCL, ZDP, Green Power). The architecture is a monolithic Qt plugin running inside the deCONZ application, with a dedicated event loop, WebSocket server, and persistent SQLite database. Key entry points include `DeRestPlugin` (plugin interface), `DeRestPluginPrivate` (core logic), and REST handlers in files like `rest_lights.cpp`, `rest_sensors.cpp`, `rest_groups.cpp`. Device support is largely externalized via JSON Device Description Files (DDF) and embedded JavaScript (Duktape) for vendor-specific parsing. External dependencies include Qt 5/6, OpenSSL (dynamically loaded), Duktape, and system utilities (tar, gzip). The codebase is actively maintained with frequent commits, but contains technical debt from legacy device quirk handling and dual (DDF vs. legacy) initialization paths.
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.