How does the Ziggurat project compare as a Zigbee stack against the Zigbee-on-Host project from Nerivec?

[Hedda]

Out of curiosity, how does the Ziggurat project technically compare as a Zigbee-stack against the Zigbee-on-Host project from Nerivec?

• https://github.com/Nerivec/zigbee-on-host

versus

• https://github.com/zigpy/ziggurat

Both are open-source Zigbee stack implementations in early development (alpha/pre-alpha stage), and both are designed to run on a host computer and communicate with a radio co-processor (RCP) that runs OpenThread RCP firmware to provide compatibility with any chip manufacturer that supports it.

The obvious differences that can be userstood right away without looking at any of the code is that the "Zigbee-on-Host" project from Nerivec is written in TypeScript, carries a strong copyleft GPL 3.0 license), and currently just have adapter integration in zigbee-herdsman for use with Zigbee2MQTT, while the "Ziggurat" project is instead written in Rust, carries a more permissive and business-friendly Apache2.0 license, and currentky only has an adapter integration with zigpy for use with the ZHA component in Home Assistant (i.e. Home Assistant's built-in Zigbee gateway integration) as well as further integrations with Home Assistant. Also, the the Ziggurat project is part of the zigpy organization which is govered by the Open Home Foundation which also governs Home Assistant (and ESPHome) so might be part of a larger roadmap, while I understand that the the Zigbee-on-Host project is developed by Nerivec as a passion hobby project in his spare time.

• https://github.com/zigpy/zigpy-ziggurat

  • https://github.com/zigpy/addons

[Hedda]

Since I am still curious about and and this is not yet answered, I promted Claude (Opus 5.5 Max) go through the source code of both stacks, as well as build a side-by-side comparison with (bellows and zigpy-znp) radio libraries since Ziggurat would replace those for ZHA users.

Everything below comes from Claude reading through the full source code of ziggurat and zigbee-on-host plus the commits listed at the end (snapshot of 2026-10-22), (so not only the README files, but every link is pinned to that commit from snapshot as of 2026-10-22).

I believe you may find this analysis interesting (and some of you might also be interested that posted a reverse analysis for ZoH here too):

TL;DR

• Same core idea, different trade-offs. Both are host-side Zigbee stacks driving an OpenThread RCP via Spinel STREAM_RAW. Both are effectively coordinator/Trust Center only, and both describe themselves as pre-production ("early alpha" vs. "work in progress").
• Ziggurat is narrower on Zigbee spec features today. Compared to Nerivec's zigbee-on-host (ZoH) stack, Ziggurat is currently missing:
  • no Green Power support
  • no APS fragmentation
  • no network-key rotation
  • no application link keys
  • no Remove-Device
• Ziggurat is further along on integration and plumbing. That covers:
  • migration in and out through standard zigpy backups, including EZSP/Z-Stack hashed trust center link keys (TCLKs)
  • network scan and packet capture exposed through zigpy
  • host routing hints, send cancellation and broadcast rate limiting
  • fuzzed frame parsers
  • the option to run the same stack on-chip (ESP32-C6, EFR32MG24)
• Against bellows / zigpy-znp, the zigpy-facing API is already at or above parity for most hooks. The remaining gaps are mostly things the vendor NCP firmware does internally (APS fragmentation, network-key handling), plus force_remove and regional TX-power limits, which bellows has. Green Power isn't wired into any of the three zigpy radio libraries yet.
• Licensing nuance: Ziggurat and zigpy-ziggurat are Apache-2.0, but the ZHA path still runs through zigpy (GPL-3.0). bellows, zigpy-znp and zigpy-cli are also GPL-3.0. ZoH is GPL-3.0-or-later, while zigbee-herdsman itself is MIT. The permissive license matters most for anyone embedding the Ziggurat stack itself, e.g. in firmware.

Legend: ✅ implemented· 🟡 partial / caveats· ❌ missing ·🔒 handled inside vendor NCP firmware, not in host library· ➖ not applicable

1. Project and architecture

	Ziggurat	Zigbee-on-Host (ZoH)	bellows	zigpy-znp
Host language	Rust stack (~25k lines, 14 crates) + Python radio lib zigpy-ziggurat	TypeScript on Node ≥ 22, zero runtime deps (~18k lines)	Python	Python
Where the Zigbee stack runs	Host by default, or on-chip: ESP32-C6 (README); also an EFR32MG24 OpenThread RCP build that embeds Ziggurat behind a vendor Spinel property (glue, build)	Host only	NCP (EmberZNet)	NCP (Z-Stack)
Radio firmware	OpenThread RCP, any vendor; serial or raw TCP	OpenThread RCP (Silabs/TI; Nordic pending); serial or TCP	EmberZNet NCP, EZSP v4–v19 + XNCP extensions	Z-Stack ZNP (CC2652/CC1352, legacy CC2531)
Host-facing API	Binary request/event protocol (wire.rs) over WebSocket, COBS serial, or a Spinel vendor property	In-process library (OTRCPDriver)	EZSP over ASH	MT over UART
Integration	zigpy → zha → ZHA. HA core dev lists it in RECOMMENDED_RADIOS (not auto-probed). Runs as an HA app or plain Docker	zigbee-herdsman zoh adapter → Zigbee2MQTT	zigpy → ZHA (auto-probed)	zigpy → ZHA (auto-probed)
Where network state lives	Nowhere on the stack: it is stateless, and zigpy's DB/backups act as the NVRAM. NWK/APS frame counters are streamed to the host	zoh.save next to Z2M's database.db	NCP NVRAM (+ zigpy backups)	NCP NVRAM (+ zigpy backups)
Replacing the radio stick	✅ transparent: IEEE and all state come from zigpy	✅ EUI64 is set by Z2M, not the firmware	🟡 backup → restore (may need a one-time IEEE overwrite)	🟡 backup → restore
License	Apache-2.0 (ZHA path also uses GPL-3.0 zigpy)	GPL-3.0-or-later (herdsman: MIT)	GPL-3.0 + vendor firmware	GPL-3.0 + vendor firmware
Self-declared status	"early alpha"; HA app experimental v0.3.1	"Work in progress"; v0.3.2; live networks "pending"	1.1.0	1.1.1

2. Zigbee stack features

Feature	Ziggurat	ZoH	bellows	zigpy-znp
Coordinator / Trust Center	✅	✅	🔒	🔒
Router role	🟡 scaffolding only: NodeRole::Router exists, but there is no join-by-association; the README lists it as future work	❌	➖ zigpy always runs as coordinator	➖
AODV route discovery / repair	✅	🟡 route repair ~60%	🔒	🔒
Many-to-one + source routing	✅ plus host route hints (hint/force next hop or source route)	✅ multi-path scoring (~80%)	🔒 + XNCP source-route override	🔒 concentrator + DataRequestSrcRtg
Sleepy children (indirect TX)	✅ RCP source-match table, ED timeout, Parent_annce	✅ (~90%)	🔒	🔒
Link status, rejoin, address conflicts	✅	✅	🔒	🔒
Install codes	✅	✅	✅	✅
Unique TCLKs (R21 Request/Verify/Confirm-Key)	✅	✅	🔒	🔒
Application link keys	❌ requests are ignored	🟡 implemented, disabled by policy	🔒	🔒
Network-key rotation	❌ no API; inbound Switch-Key is ignored	🟡 Transport-Key + Switch-Key done, no scheduler (~50%)	🔒 firmware can; zigpy has no API	🔒 same
TC-initiated device removal (force_remove)	❌ no-op; inbound Remove-Device not handled	✅ sendRemoveDevice	✅ EZSP removeDevice	❌ no-op ("Z-Stack does not have any way to do this")
APS fragmentation	❌ fragmented frames are rejected	✅ TX + RX reassembly	✅ host-side RX reassembly	❌ not handled in zigpy-znp
Green Power (GPDFs received by the coordinator)	❌ README TODO	🟡 ~80%: the GP handler feeds Z2M's Green Power support	🟡 EZSP GP commands defined, not wired into zigpy	🟡 ZGP subsystem defined, not wired into zigpy
InterPAN / Touchlink	❌ rejected	❌ 0% (adapter rejects)	➖ no zigpy API	➖ no zigpy API
R23 / Zigbee 4.0	❌ "planned", low priority	🟡 ~40% (e.g. Relay Message Downstream)	🔒 firmware-dependent	🔒 firmware-dependent

ZoH percentages come from its own README status tables, which it notes are Copilot-estimated. Neither host stack implements Spinel IIDs, so one radio serves Zigbee or Thread, not both at once.

3. Network management and tooling (what the integration exposes)

Capability	Ziggurat	ZoH	bellows	zigpy-znp
Backup / restore	✅ via zigpy (the stack is stateless)	🟡 own zoh.save; Z2M never writes coordinator_backup.json	✅	✅
Migrate in from EZSP / Z-Stack	✅ ordinary ZHA migration; carries over the EZSP hashed TCLK or Z-Stack TCLK seed plus the key table (source, wire)	🟡 dev:z2z script imports NWK key, counters and devices, but resets the TC link key to ZigBeeAlliance09 and does not import per-device link_keys	✅	✅
Migrate out	✅ standard zigpy backup	🟡 manual (only a readable dev:z2r dump)	✅	✅
Energy scan	✅	🟡 in the driver; zigbee-herdsman has no energy-scan API	✅	✅ (ZDO loopback)
Network (beacon) scan	✅	❌	✅	🟡 standalone tool only
Packet capture	✅ via zigpy; capturing disrupts the running stack	🟡 driver sniffer + ZEP→Wireshark dev tool; not exposed in Z2M	✅ mfglib	❌
Channel migration	✅	✅	✅	✅
TX power	🟡 set once at configure (default 8 dBm); no _set_tx_power or regional limits	🟡 transmit_power option (default 5 dBm)	✅ runtime + country-based maximum	🟡 tx_power config option
Send control	✅ cancellation, priority queue, broadcast token budget with retry_in_ms, per-send verdicts	❌	🔒	🔒
Runtime tunables	✅ 41 via SetTunable	🟡 small JSON stack config (EUI64, CSMA/CCA)	🟡 EZSP config values	🟡 NVRAM items
zigpy-cli support	❌ not selectable	➖	✅ ezsp	✅ znp

4. Quality and maturity (Ziggurat vs ZoH)

	Ziggurat	ZoH
Tests	48 Rust unit tests + 12 cargo-fuzz targets (every frame parser, with round-trips); 89 tests in zigpy-ziggurat	~670 Vitest cases, ~95% coverage per README
CI	fmt, check, build, strict clippy, zizmor; no cargo test or fuzzing	Biome, build, tests with coverage, CodeQL
Docs	README + heavily commented wire protocol	README + architecture doc + TypeDoc
History	First commit Mar 2025; 149 commits (112 in June 2026)	First commit Jan 2025; 219 commits

What's missing in Ziggurat (roughly by user impact in ZHA)

1. Green Power. This is the only unchecked item on the README checklist, and the gap users will notice most (Hue Tap, Friends of Hue / EnOcean switches).
   • zigpy 2.4.0 (tagged 2026-10-21) adds a Green Power manager (zigpy/zgp). It handles proxy-tunnelled GP notifications for any radio, and exposes gp_packet_received() / permit_gp() for radios with a local GP stub.
   • zigpy already does the GP decryption, commissioning and proxy configuration in Python. So on the Ziggurat side the work is mostly recognising GPDFs (NWK protocol version 3) on the receive path and forwarding them in a new wire notification, which zigpy-ziggurat then hands to that hook.
   • For comparison, ZoH's GP support is ~800 lines (frame codec + handler). Neither bellows nor zigpy-znp implements the hook yet, so Ziggurat could be first.
2. Device removal. force_remove is a no-op and inbound Remove-Device isn't handled. bellows implements it via EZSP removeDevice, and ZoH has sendRemoveDevice. zigpy-znp has the same gap as Ziggurat.
3. Network-key rotation: Transport-Key to routers, then a broadcast Switch-Key. This also needs a zigpy API, since no zigpy radio exposes it today.
4. APS fragmentation. The parser comments that it isn't seen in the wild, but RX reassembly is cheap insurance against silently dropped frames (bellows does it host-side).
5. Runtime / regional TX power. Implement _set_tx_power / _get_maximum_tx_power as bellows does; today the TX power is only set at configure time.
6. Application link keys. Currently ignored. Rare in HA, but part of complete R21 key management.
7. Router role. The scaffolding is there; finishing it would enable the multi-instance CI testing the README describes.
8. R23 / Zigbee 4.0. Planned; ZoH is at ~40%.
9. InterPAN / Touchlink. Neither host stack has it and zigpy has no API for it.

Ecosystem / tooling

10. zigpy-cli can't drive Ziggurat. Its radio list is hardcoded (ezsp, deconz, xbee, zigate, znp), even though zigpy-ziggurat already registers the new zigpy.radio entry point defined in zigpy. Adding ziggurat, or discovering entry points, would immediately give backup, restore, energy-scan, network-scan and packet-capture, because zigpy-ziggurat implements all the underlying hooks.
11. CI. Run the existing cargo test suite and short fuzz runs on PRs.
12. Small docs drift:
    • The ESP32-C6 section of the README still mentions the JSON API, which app 0.3.0 replaced with the binary API.
    • The app DOCS say socket://local_ziggurat:9999 while the README says ws://local-ziggurat:9999. zigpy-ziggurat only selects the WebSocket transport for ws://, wss:// or ws+unix://, so a socket:// URL would go down the Spinel-serial path.
    • The README says HA 2026.7.0, but the app manifest requires 2026.8.0b0.

Where Ziggurat is already ahead of ZoH

• The same stack can run on-chip (like for example on EFR32MG24 or ESP32-C6) without external host.
• Migration in and out goes through standard zigpy backups, including EZSP/Z-Stack TCLK derivation, with no converter script.
• Network scan and packet capture are exposed end to end, and there is a tool to re-key captures before sharing them.
• The send pipeline is richer: routing hints for fast startup, cancellation, priorities, a broadcast budget and per-send delivery verdicts.
• 41 runtime tunables.
• Fuzzed parsers in memory-safe Rust.

Where ZoH is ahead of Ziggurat

• Green Power.
• APS fragmentation.
• The network-key rotation mechanism.
• Application link keys.
• Partial R23 support.
• Remove-Device.
• A much larger test suite, plus architecture docs.

Method and exact commits analysed

Line counts are from wc -l and include comments. A feature is marked ✅ only when the code path exists, not just a frame definition. zigpy hook coverage was checked against the method definitions in each library's application.py.

Repo	Commit / version
zigpy/ziggurat	913a5c2 (2026-10-16)
zigpy/zigpy-ziggurat	7a6bc8b (v1.1.1+)
zigpy/addons	7f3df6b (Ziggurat app 0.3.1, pins ziggurat 816f633)
Nerivec/zigbee-on-host	c9358c5 (v0.3.2+)
Koenkk/zigbee-herdsman	c1dcb11 (v11.1.1, depends on zigbee-on-host ^0.3.2)
zigpy/bellows	aea9248 (1.1.0)
zigpy/zigpy-znp	926626c (v1.1.1+)
zigpy/zigpy	f9bb752 (2.4.0)
zigpy/zigpy-cli	e808e1e (v2.0.0+)
zigpy/zha	9d740ee
home-assistant/core	8a75c7d (dev)