# HAA (Home Accessory Architect): HomeKit firmware for ESP32 and ESP8266 boards > HAA is a C firmware that puts native Apple HomeKit support on ESP32 and ESP8266 hardware, including Shelly, Sonoff, Electrodragon and Tuya devices. It is aimed at people who want their own flashed board to appear in the Home app without a cloud bridge. **RavenSystem/esp-homekit-devices** — Advanced firmware to add native Apple HomeKit and custom configurations, compatible with any SoC based on ESP32, ESP32-S, ESP32-C and ESP8266 series. (Shelly, Sonoff, Electrodragon, Tuya...) - Repository: https://github.com/RavenSystem/esp-homekit-devices - Stars: 3,005 · Forks: 370 - Language: C - License: NOASSERTION - Published: 2026-09-24 · Updated: 2026-09-24 · Language: en - Canonical page: https://hysenlabs.com/projects/ravensystem-esp-homekit-devices ## What HAA solves for ESP32 and ESP8266 owners Most cheap smart-home hardware ships tied to a vendor app and a cloud account. HAA takes the opposite route: the README describes it as firmware that brings native Apple HomeKit support and custom configurations to any device based on ESP32, including all ESP-IDF WiFi compatible chips, and ESP8266 microcontrollers. Native means the accessory speaks HomeKit itself, so the Apple Home app talks to the board directly rather than through a vendor server. The audience is narrow and specific. You need a board you can flash, and you need to be comfortable reading a wiki. The repository names Shelly, Sonoff, Electrodragon and Tuya among the hardware families it targets, which is the set of devices people commonly reflash after removing vendor firmware. If you want a plug-in appliance with a support contract, this is not that. The project also ships commercial companion apps, HAA Home for HomeKit and Matter, and Home Bench, both linked from the README as purchases that support development. That is worth knowing before you assume the whole effort is unpaid volunteer work; the firmware itself is the open part. ## How the firmware is structured and what runs on the chip The top-level repository layout is the clearest signal of the architecture. There is an HAA/ directory alongside libs/, external_libs/ and sdk/, with .gitmodules at the root. That suggests the main firmware lives in HAA/, with third-party code pulled in as submodules rather than vendored copies, and an SDK directory holding the vendor toolchain components the build expects. The README states compatibility with any SoC based on ESP32, ESP32-S, ESP32-C and ESP8266 series. In practice that spans two different vendor SDKs, ESP-IDF for the ESP32 family and the older ESP8266 toolchain for the 8266 parts, which is why the repository carries an sdk/ tree instead of a single platform definition. The primary language is C. On the HomeKit side, the README points to a wiki page listing HomeKit service types, described as supporting many different service types with a lot of possibilities and customizations. That page, not the README, is where the accessory model is defined. The README does not document the pairing flow, the configuration storage format, or how a device is reset, so treat the wiki as the actual manual. ## Installing HAA and pairing a first accessory The README does not contain installation steps. It gives one instruction: go to the Wiki for additional information. Releases are published as tagged builds, with the most recent listed as HAA_12.19.0 (Home Accessory Architect v12.19.0 Merlin) dated 2026-09-18, preceded by 12.18.1 and 12.18.0. The release page is where the flashable binaries live. No flashing command appears in the README or the repository files, so there is no command to copy here. The release assets define the file names and the offsets, and the wiki is the place the project points to for the procedure. Read both before writing a flash command of your own. After flashing, the device is expected to expose a Wi-Fi setup access point so you can hand it your network credentials, then present a HomeKit pairing code. The README does not spell out that sequence, so confirm it on the wiki before you start. Configuration is where HAA differs from a fixed-purpose firmware. Instead of a compiled-in accessory definition, the project exposes configurable service types, so the same binary can present a light, a switch or a sensor depending on how it is set up. The exact keys and syntax are in the Service Types wiki page. If you own one of the commercial companion apps, the README notes it supports batch updates and enabling setup mode, which is the practical way to manage more than a couple of boards. ## Where HAA is the wrong choice The documentation gap is the first limitation, and it is structural rather than accidental. The README is a landing page: badges, a description, links to the wiki, links to two paid apps and a YouTube channel. It contains no install command, no configuration example and no troubleshooting section. Everything that matters for actually running the firmware sits in the wiki, which means the quality of your experience depends on wiki pages you have not read yet. The licence is the second issue. GitHub reports the licence as NOASSERTION, and the repository does contain a LICENSE file, but the README does not describe the terms in prose. If you plan to ship a product built on this firmware, read that file yourself before committing; NOASSERTION means the automated classifier could not map it to a known SPDX identifier, not that there is no licence. Third, the hardware scope is a hard boundary. The README lists ESP32, ESP32-S, ESP32-C and ESP8266 series. A board outside those families is not supported, and the wiki is the place to check a specific model. If your device is a finished product with no exposed flashing header, HAA cannot help you regardless of its chip. Finally, this is a HomeKit-only path. If your household runs on another ecosystem, the native integration the project is built around does not apply to you. ## How HAA compares with ESPHome and the HomeKit ADK The related searches around this project cluster on two alternatives: ESPHome and Apple's HomeKit ADK. The difference in approach is real in both cases. ESPHome is a general-purpose ESP firmware framework driven by YAML configuration files compiled into a firmware image, with HomeKit support arriving through a bridge component rather than as the native protocol implementation. HAA inverts that: HomeKit is the point, the firmware is distributed as prebuilt releases, and configuration happens on the device through service types rather than at compile time. If you want one toolchain for many protocols and integrations, ESPHome's model fits better. If you want a Sonoff or Shelly module to be a first-class HomeKit accessory, HAA's model is the more direct one. The HomeKit ADK is Apple's own reference implementation, aimed at accessory manufacturers building products, and it is a codebase you integrate and compile rather than a firmware you flash onto a cheap relay board. HAA sits above that layer as an end-user firmware with a configuration surface. Choosing between them is really a question of whether you are building a product or adopting one. A third option people search for is flashing a device with vendor-independent firmware and bridging it into HomeKit through a home hub running bridge software. That keeps the device firmware simple but adds an always-on host to the setup. HAA removes that host, at the cost of putting the HomeKit stack on each board. ## Release cadence, upgrades and what to check before flashing The release history is the best maintenance signal available. HAA_12.19.0 was published on 2026-09-18, HAA_12.18.1 on 2026-07-26 and HAA_12.18.0 on 2026-06-25. That is a release roughly every one to two months across that window, and the repository is not archived. Upgrade cost depends on how you manage devices. A single board can be reflashed over serial or over the air, but a fleet of them is where the README's mention of batch updates in the HAA Home app becomes relevant. The README does not document rollback, so if a new release misbehaves on your hardware, plan on keeping the previous binary from the releases page rather than assuming you can revert from the device. On licensing, the practical step is to open the LICENSE file in the repository and read it, because the README does not summarise it and GitHub's classifier returns NOASSERTION. That matters most if you intend to redistribute the firmware or sell hardware with it preinstalled. Nothing in the README addresses commercial redistribution. One more cost worth naming: because configuration lives in wiki-documented service types rather than in a single reference page, upgrading across several releases means re-reading the wiki for changes to the types you use. ## Conclusion HAA suits engineers and hobbyists who already own ESP32 or ESP8266 hardware and want it to appear natively in the Apple Home app, with service types and configuration handled through the project wiki. It is not for anyone who wants a managed cloud product, or who is unwilling to flash a device and read wiki pages rather than a manual. Before adopting it, verify three things: the exact chip in your board against the ESP32, ESP32-S, ESP32-C and ESP8266 families the README names, the service type you need in the Service Types wiki page, and the licence terms in the LICENSE file, whose SPDX identifier GitHub reports as NOASSERTION. ## FAQ ### What is HAA (Home Accessory Architect) and which devices does it support? HAA is firmware that adds native Apple HomeKit support and custom configurations to microcontrollers. The README lists ESP32, ESP32-S, ESP32-C and ESP8266 series chips, and names Shelly, Sonoff, Electrodragon and Tuya among the hardware families. ### How do I install HAA on an ESP32 or ESP8266 board? The README does not include install steps; it directs readers to the project Wiki for additional information. Flashable builds are published as tagged releases, with HAA_12.19.0 dated 2026-09-18 being the most recent listed. ### Is HAA free to use, and what licence does it carry? The repository contains a LICENSE file, but GitHub reports the licence as NOASSERTION and the README does not describe the terms. The README separately links two paid companion apps whose purchases support development. ### How does HAA differ from ESPHome for HomeKit? HAA is distributed as prebuilt firmware focused on native HomeKit, with configuration handled through service types documented in the wiki. ESPHome is a general-purpose framework driven by configuration files compiled into firmware, with HomeKit reached through a bridge rather than as the primary protocol. ## Sources - [Issues](https://github.com/RavenSystem/esp-homekit-devices/issues) - [RavenSystem/esp-homekit-devices on GitHub](https://github.com/RavenSystem/esp-homekit-devices) - [README](https://github.com/RavenSystem/esp-homekit-devices/blob/master/README.md) - [Releases](https://github.com/RavenSystem/esp-homekit-devices/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ravensystem-esp-homekit-devices