Alternative EmberZNet Zigbee "Multi-PAN" firmware for EFR32 Series 1 and/or EFR32 Series 2?

[Hedda]

Home Assistant developer agners has begun working on an add-on for Silabs Multiprotocol stack requiring Multi-PAN firmware. See:

https://github.com/zigpy/zigpy/discussions/894

For the Add-on to be useful, you need the Multi-PAN firmware on a Silicon Labs radio: The example firmware is called rcp-uart-802154 in SimplictyStudio. I did compile it for the MGM210P(A32JIA) module we are using, and I use this firmware with testing.

and

https://github.com/home-assistant/addons-development/tree/master/silabs-multiprotocol

NOTE: Requires Silicon Labs based radio with RCP Multi-PAN firmware flashed!

Maybe help with Zigbee coordinator RPC firmware with EmberZNet 6.8 RCP and NCP applications with Multi-PAN Library plugin?

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.8.0.2.pdf

https://community.silabs.com/s/article/building-rpc?language=en_US

This project does require that firmware include Multi-PAN Library plugin. That new Multi-PAN Library plugin is new since EmberZNet SDK 6.8.0.2 and new multi-PAN feature can create a host/NCP application that can support up to two coordinator networks:

https://www.silabs.com/documents/public/application-notes/an724-multi-network.pdf

Very early so would not advise any users use "Multi-PAN" firmware testing unless interested in testing and/or contributing to that project. See:

Concept could in the future even allow running both Zigbee 3.0 and Thread/Matter (OpenThread) stacks applications on a single radio.

It also changes architecture from NCP (Network Co-Processor) based to "DMP RPC" (Dynamic Multiprotocol Radio Co-Processor) based which if I understand correctly offload the network part to the the Zigbee integration application running on system CPU and the adapter becomes slightly more of a "dumb" Zigbee radio (still using EZSP) which for Zigbee removes some limitations on routing tables etc. (meaning that can probably have almost unlimited of devices connected even on radio adapter that has an MCU with limited RAM-memory.

PS: agners is Nabu Casa lead engineer working on Home Assistant Yellow and its EFR32MG21 (MGM210P SiP module) based radio:

https://www.home-assistant.io/blog/2021/09/13/home-assistant-yellow/

https://www.crowdsupply.com/nabu-casa/home-assistant-yellow

https://www.nabucasa.com/about/

[Hedda]

Silicon Labs recently released EmberZNet 6.8 (6.8.0.1) SDK with a new feature to concurrent support of multiple PANs (multi-PAN).

Prior to EmberZNet PRO 6.8.0, the multi-network implementation limited the number of always-on roles that a device could serve on the participating networks. Starting with EmberZNet PRO 6.8.0, the multi-network feature and a new multi-PAN feature allow the device to operate as a coordinator on both Zigbee networks in a host-NCP configuration.

Silicon Labs AN724 application note discusses the design considerations involved in integrating a feature that allows a node with one Zigbee radio to operate on multiple Zigbee networks.

https://www.silabs.com/documents/public/application-notes/an724-multi-network.pdf

"Multi-network and multi-PAN features allow a device to operate on two Zigbee networks using the same radio. These Zigbee networks may have different security settings or network parameters, such as short ID, PAN ID, extended PAN ID, or radio power. The only parameter that stays the same on all networks is the node's EUI64. While the multi-network feature allows the two networks to be on different radio channels, the multi-PAN feature requires that this setting matches."

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.8.0.2.pdf

1 New Items

Added in release 6.8.0.2

The feature to concurrently support multiple PANs (multi-PAN) is added in the 6.8.0.1 release. The multi-PAN feature builds upon the existing multi-network feature, however, the multi-network feature limits the number of always-on networks to one, the multi-PAN feature allows for two always-on networks, both of which must be coordinators. The two networks use the same radio to send and receive packets on their own distinctive PAN IDs.

For additional documentation refer to AN724: Designing for Multiple Networks on a Single Zigbee Chip.

1.1 New Plugins

Added in release 6.8.0.2

Multi-PAN Library

The new plugin is used by the multi-PAN feature to create a host/NCP application that can support up to two coordinator networks.

Added in release 6.8.0.2

Multirail-demo

A new mutirail-demo plugin has been added. This plugin provides sample code to initialize and interact with a second RAIL handle and is used in the new multi-rail GP sample application.

1.2 New APIs

Added in release 6.8.0.2

Stack Profile and Security Level

Introduced emberSetStackProfile() together with the following enums: EMBER_STACK_PROFILE_NONE, EMBER_STACK_PROFILE_ZIGBEE_PRO, EMBER_SECURITY_LEVEL_NONE, EMBER_SECURITY_LEVEL_Z3.

In addition to the new API, the Zigbee stack now initializes the stack profile and security level based on the security profile of each network so that multi-PAN devices are able to form networks with different stack profiles and security levels. For additional documentation refer to the Zigbee Framework API Reference Guide.

1.3 New Sample Applications

Added in release 6.8.0.2**

Multi-PAN

A new set of Host (MpZ3TcCustomTcHost) and NCP (mp-ncp-spi or mp-ncp-uart) sample applications is added. These sets demonstrate the multi-PAN feature. The host application is a Zigbee 3.0 coordinator on the first network and a coordinator with no security on the second network and is meant to connect to an NCP running one of the multi-PAN NCP applications.

ZigbeeMinimalHost

The EmberZNet ZigbeeMinimalHost sample application provides a minimal functional subset to serve as a starting point for users wishing to build their own ZigBee Host applications. The application is configured to operate as a ZigBee Coordinator / Router. No ZigBee Cluster Library (ZCL) application-layer functionality is preconfigured. In the Studio New Project workflow Select Application dialog, it is recommended to select this sample application, rather than the "Start with a blank application" checkbox, to begin development of a new Zigbee Host application.

Z3GatewayGpComboHost and ncp-uart-hw-gp-multi-rail

A new set of Host (Z3GatewayGpComboHost) and NCP (ncp-uart-hw-gp-multi-rail) sample applications is added. This set demonstrates the use of the additional rail handle to send application-specific bidirectional GPDF from Combo to GPD.

[NilsBohr]

@Hedda

slightly more of a "dumb" Zigbee radio (still using EZSP)

That's not really correct. The adapter only communicates using new protocol CPC.

We are working to release a firmware update for our products to support this mode.

[Hedda]

slightly more of a "dumb" Zigbee radio (still using EZSP)

That's not really correct. The adapter only communicates using new protocol CPC.

Is it still possible to include support NCP and EZSP in the same firmware image to that the same images can also be compatible with existing implementations that currently relies on the EZSP interface? So no need to maintain different firmware images?

We are working to release a firmware update for our products to support this mode.

Nice! suggest you/Elelabs maybe reach out to @agners and Nabu Casa (Home Assistant founders) about possible collaboration?

I think it would for example be great if could help create an open document for the community on how to build a firmware image that contains both EmberZNet Zigbee stack and OpenThread stack with Spinel (OpenThread Serial Protocol) in one firmware image?

Recommend publish simple documentation with patch(es) and how to compile similar to the community do for Z-Stack-firmware:

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0

https://community.silabs.com/s/article/building-rpc?language=en_US

[NilsBohr]

@Hedda No, not really. The EZSP and NCP are moved to zigbeed software on Linux by Silabs. I don't see any feasible way to merge current CPC and older NCP-EZSP firmwares together. I would say the best way for community yo move forward is to create an open source alternative for zigbeed which can communicate directly using CPC, but that's a MONUMENTAL task.

[agners]

I don't see any feasible way to merge current CPC and older NCP-EZSP firmwares together.

In theory, you could have a custom command to switch protocol in each of these protocol, and have the underlying firmware switch protcol completely, don't you think? That said, I'd rather prefer not to support that, as it might be complex: Whenever the radio resets/restarts, the host side needs to probe using NCP protocol again to switch back to CPC etc. etc. So it feels a bit brittle.

Anyways, that hole multiprotocol is endeavor is still new, and I'd rather prefer SiLabs makes the CPC protocol stable first (currently it seems that cpcd on host side and firmware need to have the exactly same version :see_no_evil: ).

I would say the best way for community yo move forward is to create an open source alternative for zigbeed which can communicate directly using CPC, but that's a MONUMENTAL task.

Uh, I'd love that :heart_eyes: . Altough, with Matter coming hopefully soon, probably better to focus on that.

[NilsBohr]

Whenever the radio resets/restarts, the host side needs to probe using NCP protocol again to switch back to CPC etc. etc. So it feels a bit brittle.

It's not only about switching between 2 different applications. It's about low level Radio configuration. both NCP and CPC firmwares from Silabs are very closed off. I'm not sure, what will happen when EZSP configured radio boots up in CPC and vice versa. At least I'm not interested to try it out. Moving forward we will provide 3 firmwares: EZSP -Zigbee, Spinel-Thread, CPC - multiprotocol. But that will require to completely rewrite the entire firmware each time you are switching firmware, not just a simple command.

(currently it seems that cpcd on host side and firmware need to have the exactly same version see_no_evil ).

Same situation is with Openthread border router and Spinel sadly... That might actualy stay with us...

Uh, I'd love that heart_eyes . Altough, with Matter coming hopefully soon, probably better to focus on that.

agree

[agners]

Moving forward we will provide 3 firmwares: EZSP -Zigbee, Spinel-Thread, CPC - multiprotocol. But that will require to completely rewrite the entire firmware each time you are switching firmware, not just a simple command.

Wrt CPC - multiprotocol, there are two made available by SiLabs, rcp-uart-802154 and rcp-uart-802154-blehci are you planning to go for the Bluetooth enabled one? So far I've only tested the non-Bluetooth one. I hope they are compatible.. :cold_sweat:

[NilsBohr]

Ideally the bluetooth one, but for now having issues with just 802154 ))

They should be compatible from my understanding. Just an additional Endpoint and additional cpc-hci-bridge similar to zigbeed but for bluetooth communication

[Hedda]

https://github.com/zigpy/zigpy/discussions/894

For the Add-on to be useful, you need the Multi-PAN firmware on a Silicon Labs radio: The example firmware is called rcp-uart-802154 in SimplictyStudio. I did compile it for the MGM210P(A32JIA) module we are using, and I use this firmware with testing.

FYI, grobasoz (Gary Robas) have now published EmberZNet 7.0.1 MultiPan NCP ("MP NCP") firmware for EFR32 Series 2 devices:

https://github.com/grobasoz/zigbee-firmware/tree/master/EFR32%20Series%202/EFR32MG21A020F1024

https://github.com/grobasoz/zigbee-firmware/blob/master/EFR32%20Series%202/EFR32MG21A020F1024/README.md

Note! Multi-Pan NCP, not RCP, and based on EmberZNet 7.0 so it also supports EmberZNet Serial Protocol Version 9 (EZSP V9)!

[agners]

NCP and RCP are just architecture styles. From what I can tell, this particular firmware uses the regular EZSP ASH protocol over UART. It seems to me that this is not to meant to run other protocols, but to form multiple Zigbee networks using a single radio. But I could be wrong on that.

From the readme of that firmware:

This application provides support to form two personal area networks on same channel on sigle radio. Multiple PANs are achieved by configuring a single radio to filter packets on configured networks (two in this case). The both networks must be on the same channel. The networks can operate using different security settings, different network parameters such as short ID, PAN ID, extended PAN ID and so on. The parameters that stay the same on all networks are the channel and EUI64 of the node. The multi PAN node can only act as coordinator.

The MpZ3TcCustomTcHost application can be used with this NCP application. This network coprocessor (NCP) application supports communication with a host application over a UART interface with hardware flow control. This NCP application can be built as configured, or optionally can be augmented with customizations for target hardware, initialization, main loop processing, event definition/handling, and messaging with the host.

Refer to the Silicon Labs zigbee documentation for more information about NCP customization.