feat: ZigBee on Host

[Nerivec]

Goal for 2025: Open Sourcing ZigBee on all fronts! 😉

Adapter implementation for https://github.com/Nerivec/zigbee-on-host
Overview of current status: https://github.com/Nerivec/zigbee-on-host?tab=readme-ov-file#current-status

Important

This is obviously NOT production ready. There is quite a bit of road ahead before it can be. But in the meantime, feel free to experiment with it, and provide feedback & support! More details to come!

CC: @kirovilya @puddly @darkxst @tube0013 @antst @chris-1243 @Ricc68 @mundschenk-at @fir3drag0n @lawrencedudley

[antst]

Wow, interesting!

[Ricc68]

@Nerivec I have parsed quickly through the code, just to have a high level idea about the scope.
Just to confirm or correct my understanding:

• it will be a software implementation of the Zigbee stack from the hdlc raw protocol up
• the RCP will be the device's radio (dongle or networked) which implements raw spinel protocol over hdlc and bit stuffs the radio with the data coming through from the host Zigbee stack
• RCP can be anything implementing the raw spinel so I understand any radio that runs silabs fw, over serial or TCP

That's so far what I have understood for now (correct me if I misunderstood something).

This is a big aim and I see in future it may bring extensive advantages like simplify the radio side releasing Zigbee stack resources that can be used to improve stability on the device MCU firmware, improve the stability of the Zigbee stack that runs on a less resource constrained host cpu, make debugging easier on both Zigbee level and spinel/hdlc level, and more (for example I have seen that in the spinel protocol there's provision for offloading of buffers from RCP to the host).

[Nerivec]

The Spinel protocol was defined here: https://datatracker.ietf.org/doc/html/draft-rquattle-spinel-unified
Note: some Spinel features are Thread-only and/or NCP-only, hence not relevant to this implementation. Only a minimal implementation is required for raw control over the radio.

Silabs has a graph for NCP vs RCP here: https://www.silabs.com/documents/public/user-guides/ug103-03-fundamentals-design-choices.pdf#unique_5

The implementation aims to provide the following layers:

• HDLC + Spinel: to interface with the OT RCP firmware (mostly via STREAM_RAW)
• 802.15.4 MAC + ZigBee NWK (regular/GP) + ZigBee APS: to communicate over the radio with ZigBee

Most of those layers are already implemented (as far as encoding/decoding/encrypting/decrypting is concerned, and some logic for stuff like forming networks and joining & interacting with child devices). It's enough to test out various firmware, from various manufacturers, and confirm current capabilities, and shortcomings that will require fixes from manufacturers.
This is the current step we're at, feedback from anyone willing and able to build & test firmware is welcomed (note: Silabs is already confirmed)!

The remaining aspects to be implemented are centered around specific algorithms of the ZigBee layers (like routing) and a few items that require slightly different requirements than regular ZigBee (Touchlink, GP).

The main advantage of the OT RCP base is that any manufacturer implementing it should be supported (Silabs, TI, Nordic, and more...), allowing the same ZigBee stack to run with all kinds of chips/adapters (and all the benefits that come from that!).

The ZigBee stack on the host offers a... host of new possibilities 😬

• can move from one adapter to another without having to care about backup compatibility, manufacturer, or spec
• the host can store/process much more information than a resource-constrained NCP
• can fix bugs and implement new features without requiring firmware flashing, only a restart of the app
• everything Open Source! 😉
• and much more...

[Koenkk]

Firmwares for Texas instruments MCUs are now available (https://github.com/Koenkk/OpenThread-TexasInstruments-firmware) (CC: @Hedda)