kirovilya
commented
1 year ago It is strange to require multiprotocol support to zigbee-herdsman. You don't require multiprotocol support to ZHA do you? :) As you already know, Home Assistant has a multiprotocol addon for this, which launches the necessary daemons and displays ports to which both ZHA and Zigbee2MQTT (zigbee-herdsman) are already normally connected. No refinement is required.
On the other hand, if users do not use Home Assistant, then they have difficulties - they need to somehow start the multiprotocol daemons on their own. A docker container similar to the Home Assistant multiprotocol addon would help here. I ran these daemons without a container and everything worked for me with Zigbee2MQTT, but it's easier for the user to start the container. Unfortunately, I have not found such a container yet. With the existing containers from SiliconLabs, I was not able to pull serial ports out of the container to connect Zigbee2MQTT to them. Maybe because I'm a bad docker specialist :)
Therefore, first of all, you need to learn how to run multiprotocol daemons in containers and write instructions for launching. Who will do it? Don't know :)
github-actions[bot]
Hedda
Koenkk
@kirovilya I hope that for tracking it is OK if post this as a separate enhancement feature request consideration for the ezsp adapter:
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) in order to for the ezsp adapter in zigbee-herdsman 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
The need and possible solution?
Please consider looking into maybe adding Silicon Labs CPC daemon (CPCd) and Zigbeeb (Zigbee service daemon for EmberZNet Zigbee stack) Docker images as a dependency in zigbee-herdsman in order to support Silabs Multi-PAN RPC firmware for multiprotocol adapters in zigbee-herdsman based Zigbee gateway/hub application implementations like Zigbee2MQTT and IoBroker :
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 daemon (Zigbeed) and OpenThread Daemon (OT Daemon) that runs the Silabs EmberZNet Zigbee networking stack and OpenThread network stack respectively 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 service daemon (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 zigbee-herdsman should be able to connect remotely to that Silicon Labs Zigbee service 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 zigbee-herdsman does today not install a Silicon Labs CPC daemon (CPCd) and accompanying Zigbee daemon (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 zigbee-herdsman to be able to 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 daemon (Zigbeed).
At least in theory.
Alternatives and workarounds
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.