-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternative EmberZNet Zigbee "Multi-PAN RCP firmware" for EFR32 Series 1 and/or EFR32 Series 2? #21
Comments
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 ItemsAdded in release 6.8.0.2The 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 PluginsAdded in release 6.8.0.2Multi-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.2Multirail-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 APIsAdded in release 6.8.0.2Stack 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. 1.3 New Sample ApplicationsAdded 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. |
From the release notes: I strongly advise using the most recent SDK if you want to add support for this feature. |
Of course. I only posted for reference since 6.8.0.2 was first to contain support so its documentation contained the information. |
FYI, grobasoz (Gary Robas) have now published EmberZNet 7.0.1 MultiPan NCP ("MP NCP") firmware for EFR32 Series 2 devices: Note! Multi-Pan NCP, not RCP, and based on EmberZNet 7.0 so it also supports EmberZNet Serial Protocol Version 9 (EZSP V9)! |
FYI, looks like Nabu Casa developers are working experimental RCP Multi-PAN firmware image that is not compatible with NCP: https://github.com/NabuCasa/silabs-firmware https://github.com/NabuCasa/silabs-firmware/tree/main/RCPMultiPAN Nabu Casa developers are also working on NCP + RPC beta firmware to make Home Assistant SkyConnect backwards-compatible: https://github.com/NabuCasa/silabs-firmware/tree/main/EmberZNetAndOpenThreadRCP/beta The reason for this is that Home Assistant 2022.12 has now been released with initial multiprotocol support Zigbee and Thread (including Matter over Thread) with "Home Assistant SkyConnect" USB adapter and "Home Assistant Yellow" embedded radio: https://www.home-assistant.io/blog/2022/12/07/release-202212/ Looks like as an experimental feature user can choose RPC Multi-PAN firmware for multiprotocol support is flashed if the user chooses to enable multiprotocol support in the "Home Assistant SkyConnect" and "Home Assistant Yellow" add-ons for Home Assistant, which is listed as an experimental feature. And at this point, moving back to an EmberZNet Zigbee NCP firmware requires manually reflashing the adapter. RPC Multi-PAN firmware requires that the application support connecting to Zigbeed (Silicon Labs Zigbee Daemon) via socket to be able to use for ezsp adapters wih EmberZNet RPC firmware (instead of EmberZNet NCP firmware). |
FYI, @skgsergio look to be working on MultiPAN RCP (Multiprotocol) firmware for ZB-GW04 dongle + ZYZBP008 SM-011 module: https://github.com/skgsergio/silabs-multiprotocol-firmware-zbgw04-usb |
Now RCP has been discussed in another issue, and the firmware is also provided. This discussion is closed first, and you can reopen it if necessary. |
Home Assistant developer agners has begun working on an add-on for Silabs Multiprotocol stack requiring Multi-PAN RCP firmware.
zigpy/zigpy#894
and
https://github.com/home-assistant/addons-development/tree/master/silabs-multiprotocol
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
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.
https://github.com/home-assistant/addons-development/tree/master/silabs-multiprotocol
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/
The text was updated successfully, but these errors were encountered: