cdjackson
commented
9 months ago I don't really think this is applicable to this library. It would require us to use the Zilabs host stack, which is written in C, and therefore moves away from the Java based library that is the main reason for this library to provide portability.
Is your feature request related to a problem? Please describe.
This is a feature request that may be a bit early but posting as an enhancement feature request for consideration and for tracking:
Suggest that you consider adding dependencies for Silicon Labs CPC daemon (CPCd) and Zigbeed (Zigbee service daemon for EmberZNet Zigbee stack) for the EZSP (EmberZNet Serial Protocol) to be able to use Silabs Multi-PAN RPC firmware for Silabs based multiprotocol adapters in RCP mode now that Silicon Labs EZSP based adapter such as Home Assistant SkyConnect USB adapter, Home Assistant Yellow SBC appliance (which has an embedded EFR32MG21 radio module), and other Zigbee Coordinator adapters based on Silicon Labs EFR32 Zigbee NCP SoC from EFR32MG21/MGM210 and EFR32MG12/MGM12 series has experimental Multi-PAN RPC (Radio Co-Processor) firmware so that they can use Zigbee and Thread (OpenThread) networks on the same radio at the same time.
Please read more about it here:
https://github.com/zigpy/zigpy/discussions/894
https://www.silabs.com/documents/public/application-notes/an1333-concurrent-protocols-with-802-15-4-rcp.pdf
"The host applications connect to the CPC daemon, which in turn connects to the EFR via a SPI or UART link, respectively."
https://hub.docker.com/r/siliconlabsinc/multiprotocol
https://github.com/SiliconLabs/cpc-daemon
or
https://github.com/home-assistant/addons/tree/master/silabs-multiprotocol
and
As well as hardware already supporting this with the mentioned experimental firmware images:
While not mentioning Zigbee specifically the OpenThread page does at least a good job at describing the different architectural design differences between Radio Co-Processor (RCP) and Network Co-Processor (NCP) designs:
https://openthread.io/platforms/co-processor
Describe the solution you'd like
Considering looking into maybe adding Silicon Labs CPC daemon (CPCd) and Zigbeeb (Zigbee service deamon for EmberZNet Zigbee stack) Docker images as a dependency in com.zsmartsystems.zigbee in order to support Silabs Multi-PAN RPC firmware for multiprotocol adapters in com.zsmartsystems.zigbee based Zigbee gateway/hub application implementations like OpenHAB:
https://docs.silabs.com/gecko-platform/4.1/service/cpc/overview
https://www.silabs.com/documents/public/application-notes/an1351-using-co-processor-communication_daemon.pdf
https://docs.silabs.com/gecko-platform/4.1/service/api/group-cpc
https://github.com/SiliconLabs/cpc-daemon
Also check out documentation for Home Assistant’s Silabs multiprotocol add-on which describes its architecture here:
https://github.com/home-assistant/addons/blob/master/silabs-multiprotocol/DOCS.md#architecture
As I understand it; when you enable multi-protocol support in the add-on inside Home Assistant it automatically flashes a Multi-PAN RCP (Radio Co-Processor) firmware to the dongle as well as enables multi-protocol support with a Silicon Labs CPC daemon (CPCd) and accompanying Zigbee service deamon (Zigbeed) and OpenThread Daemon (OT Daemon) that runs the Silabs EmberZNet Zigbee networking stack and OpenThread network stack respectivly on the host in order to allow multi-protocol support, so in essence that new firmware is what adds a requirement of at least an additional Silicon Labs CPC daemon (CPCd) and accompanying Zigbee deamon (Zigbeed) which is currently only automatically installed and available/supported if using Home Assistant OS or Home Assistant Container.
The ZHA integration then connects to that Silicon Labs CPC daemon (CPCd) over TCP/IP using a socket as that in turn has taken over the serial port connection to the Home Assistant Skyconnect USB stick, and that Silicon Labs CPC daemon (CPCd) handles the accompanying Zigbee deamon (Zigbeed) and OpenThread Daemon (OT Daemon).
As a workaround and for testing to connect remotely over TPC/IP on a local network you can install Home Assistant Skyconnect USB stick on another computer with Home Assistant OS (or Home Assistant Container) with enabled multiprotocol so it has flashed Multi-PAN RCP (Radio Co-Processor) firmware and you only use it for Thread protocol and not for the ZHA integration inside Home Assistant, then com.zsmartsystems.zigbee should be able to connect remotely to that Silicon Labs Zigbee deamon (Zigbeed) over TCP/IP using a socket to create a tunnel for EZSP communication as long as there is no firewall rules or container stuff blocking the TPC/IP socket traffic (and the ZHA integration in Home Assistant is not connected to that socket).
As the com.zsmartsystems.zigbee does today not install a Silicon Labs CPC daemon (CPCd) and accompanying Zigbee deamon (Zigbeed) so as such you can not simply access the Home Assistant Skyconnect USB stick if it has Multi-PAN RCP (Radio Co-Processor) firmware. What is missing for the com.zsmartsystems.zigbee to be able work with Home Assistant Skyconnect USB stick when it has Multi-PAN RCP (Radio Co-Processor) firmware is its own installation of Silicon Labs CPC daemon (CPCd) and accompanying Zigbee deamon (Zigbeed).
At least in theory.
Describe alternatives you've considered
The alternative is to keep only supporting Silicon Labs NCP firmware for EmberZNet Zigbee and not supporting Silabs CPC daemon.
PS: This feature is also indirectly related to Thread (OpenThread) and Matter support via EFR32MG1x and EFR32MG21x Silicon Labs IEEE_802.15.4-based radio adapters as well as users will be able to use one single radio adapter that supports Multi-PAN RCP (Radio Co-Processor) firmware run simulations run a Zigbee stack and a Thread (OpenThread) network stack concurrently at the same time as long as it is in MultiPAN RCP mode for multiprotocol support.