Open Hedda opened 4 months ago
darkxst
commented
4 months ago This pretty much requires wpantund to work? At which point not sure what the benefit is over the RCP. Although I suppose it might be useful for people who dont use Home Assistant.
Hedda
commented
4 months ago Yeah I think it would still be useful for other projects.
I have not researched too deeply into it myself (as do not yet have any Thread devices myself), however from what I understand the Open Thread Border Router integration that I believe uses the OpenThread Border Router Add-on for Home Assistant is currently only compatible with OpenThread RCP firmware, but I guess that might change in the future as I think it should technically be possible to make the Thread integration (that the Matter integration in turn depends on) work directly with OpenThread NCP firmware?
That is at least what I understood from this discussion that asks about using a CC2652 based adapter with the Open Thread Border Router integration for Home Assistant -> https://github.com/home-assistant/addons-development/issues/38
PS: slaesh for example offers both OpenThread RCP and OpenThread NCP firmware images for his CC2652 based adapter, with the mentioning that wpantund can be used with OpenThread NCP firmware:
darkxst
commented
4 months ago I think it should technically be possible to make the Thread integration (that the Matter integration in turn depends on) work directly with OpenThread NCP firmware?
I dont think the Openthread NCP is standalone like the Zigbee ones. You need wpantund to provide the ipv6 network layer, and then you may still require otbr daemon. However once those requirements are met, HA Thread (and otbr) integration should pick this up automatically as long as its in the same subnet.
Hedda
commented
3 months ago I dont think the Openthread NCP is standalone like the Zigbee ones. You need wpantund to provide the ipv6 network layer
As I understand it, you would still need host application to handle it but with OpenThread NCP the Spinel + HDLCLite protocols run onboard the SoC (dongle), so as long as it has power then it will remain active. OpenThread docunmentation specifically mention that NCP "design is useful for gateway devices" so might work better than RCP in some cases, see:
https://openthread.io/platforms/co-processor
Co-Processor designs are supported by OpenThread. When building OpenThread examples, a firmware image for each co-processor design is automatically created. For more information, refer to Binaries.
In an RCP design, the core of OpenThread lives on the host processor with only a minimal MAC layer "controller" on the device with the Thread radio. The host processor typically doesn’t sleep in this design, in part to ensure reliability of the Thread network.
Communication between the RCP and the host processor is managed by OpenThread Daemon through an SPI interface over the Spinel protocol.
The advantage here is that OpenThread can utilize the resources on the more powerful processor.
This design is useful for devices that are less sensitive to power constraints. For example, the host processor on a video camera is always on to process video.
OpenThread Border Router supports an RCP design. For more information, refer to OpenThread Border Router.
To build an RCP, refer to the following Codelabs:
BUILD A THREAD NETWORK WITH NRF52840 THREAD BORDER ROUTER
The standard NCP design has Thread features on the SoC and runs the application layer on a host processor, which is typically more capable (but has greater power demands) than the OpenThread device.
Communication between the NCP and the host processor is managed by wpantund through a serial interface, typically using SPI or UART, over the Spinel protocol.
The benefit of this design is that the higher-power host can sleep while the lower-power OpenThread device remains active to maintain its place in the Thread network. And since the SoC is not tied to the application layer, development and testing of applications is independent of the OpenThread build.
This design is useful for gateway devices or devices that have other processing demands like IP cameras and speakers.
Spinel is a general management protocol for enabling a host device to communicate with and manage a co-processor. Initially designed to support Thread-based NCPs, Spinel has been designed with a layered approach that allows it to be easily adapted to other network technologies in the future. It is used with both the RCP and NCP designs.
This protocol is included with OpenThread at /src/lib/spinel. A Python CLI tool called Pyspinel is available for testing purposes.
For more information, see the Internet-Draft for the Spinel Host-Controller Protocol.
Please consider also offering OpenThread NCP (Network Co-Processor) builds as an optional alternative to OpenThread RCP.
https://openthread.io/platforms/co-processor
PS: OpenThread NCP firmware will not work with the "OpenThread Border Router Add-on" for Home Assistant (which contains the OpenThread Daemon) as that currently looks to require OpenThread RCP firmware but as long as it has Spinel+hdlc+uart serial interface it should still be possible to make it work with Thread based integrations as well as for other Thread implementations such as wpantund:
Reference:
https://openthread.io/platforms/co-processor/wpantund
https://github.com/home-assistant/addons/tree/master/openthread_border_router
https://www.home-assistant.io/integrations/thread/
https://www.home-assistant.io/integrations/otbr/
https://www.home-assistant.io/integrations/matter/
https://github.com/home-assistant/addons-development/issues/38