Hedda
commented
4 years ago Also see the duplicate request for zigpy https://github.com/zigpy/zigpy/issues/486
Closed Hedda closed 3 years ago
Hedda
commented
4 years ago Also see the duplicate request for zigpy https://github.com/zigpy/zigpy/issues/486
Adminiuga
commented
4 years ago What are the benefits of supporting multiple PAN IDs?
Hedda
commented
4 years ago In the first place there the reasons that were listed by Silicon Labs as to why they implemented support for this in EmberZNet 6.8 :
"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."
"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."
"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."
Then I guess there are many similar benefits to that of multi-adapter support but without the benefit of running different stacks/firmware, (in that way the benefit of multiple PANs on one coordinator is that do not need to maintain another coordinator).
Personally I would want to test and keep unstable devices on their own mesh network until issues with them can be resolved.
So for starters I would have one "test" network and one "production" network at home to keep ones partner happy when testing.
Also, ZHA does not yet have support for "IAS ACE" (Intruder Alarm System + Alarm Control Panel) but if and when it does perhaps you want to separate your IAS and ACE devices from other Zigbee devices by keeping them on their own network (if not possible to keep on own adapter) due to risk of the Zigbee network getting hacked. You might also want to have higher security settings for your IAS and ACE devices.
https://github.com/dmulcahey/home-assistant/tree/dm/zha-ias-ace-support
As noted in Silicon Labs features, the multi-PAN feature allows for two always-on networks that can have different security settings.
Are perhaps also the direct children limited per PAN? Or is direct children limited per Zigbee coordinator even if multi-PANs? And the same question with routes; powerful chips like EFR32 MG2 could maybe have more children limited and maybe more total devices?
Hedda
commented
4 years ago @NilsBohr from Elelabs said they will release 6.8 firmware for their products later this year -> https://github.com/Elelabs/elelabs-zigbee-ezsp-utility/issues/3
Adminiuga
commented
4 years ago well, if anyone is really interested in multi-pan support, the PRs are welcome.
Also, ZHA does not yet have support for "IAS ACE" (Intruder Alarm System + Alarm Control Panel) but if and when it does perhaps you want to separate your IAS and ACE devices from other Zigbee devices by keeping them on their own network (if not possible to keep on own adapter) due to risk of the Zigbee network getting hacked.
Are perhaps also the direct children limited per PAN? NO. never were. direct children is a limitation of the hardware and firmware settings. having many direct children means you don't have a strong mesh network. i.e. you are approaching the problem wrong way Same applies to having multiple meshes. instead of one strong mesh, are you keeping two different weak meshes. why?
MattWestb
commented
4 years ago The problem is then running as dual coordinator the first network (0) can having any security level but the second one (1) must running in unsecure mode. Its good putting some Xiaomi sensors on the network 1 and having all real ZB3 on the network 0. I finding it better buying some new real ZB3 sensors or putting one CC2531 or one billy for the the low security devices so can keeping the security for the real ZB3 devices. I finding more interesting making one software multi coordinator that supporting multiple different / same radiolibs in ZHA, its open some very interesting solutions. By the way someone have already ported 6.8.0.1 for ELU013, ELR023 and EByte-E180-Z120B for nearly one month ago and im very sure all have being tested with the current master release of bellows ;-)))
Hedda
commented
4 years ago IAS ACE and IAS Zone devices were designed to operate on the same zigbee network.
Yes, so that could mean that you want to build an alarm-system for anti-burglar purposes with dedicated components like; an alarm panel, window/door sensors, motion sensors, and sirens, but maybe keep that network separate from your lighting devices.
I finding more interesting making one software multi coordinator that supporting multiple different / same radiolibs in ZHA, its open some very interesting solutions.
Honestly, I would much prefer if applications like Home Assistant's ZHA component would itself support multiple coordinators.
See request -> https://github.com/zigpy/zigpy/issues/308
Off-topic but it would be great if one ZHA instance could be capable of separate loading several copies of zigpy + a radio library.
You could, for example, run a dedicated "home alarm network" for your IAS ACE devices on an Elelabs Zigbee USB Adapter, a separate "home production network" for lighting devices on a HUSBZB-1 USB Adapter, and a "test and lab network" for testing automation on an ITEAD Sonoff ZBBridge flashed with Tasmota configured as serial-server (pass-through) to socket for HA's ZHA.
Supporting multiple coordinators adds the benefit of giving you the option to run or test different adapters and radio libraries.
As such you could for have an Elelabs Zigbee USB Adapter for IAS ACE devices and a CC2562 adapter for your lighting devices.
By the way someone have already ported 6.8.0.1 for ELU013, ELR023 and EByte-E180-Z120B for nearly one month ago
Where? Do you have links to firmware downloads and more information?
MattWestb
commented
4 years ago @Hedda Some one have putting them little of side but not hiding them at one well known location ;-)))
MattWestb
commented
4 years ago If I was building one IAS then it must being in real ZB3 with enough security for the purposes and then most of the devices is sleeping end devices its need more routers for getting one stable robust mesh therefore lights its ideal as "backbone" for the IAS. If not i building it with in traditional way with cables and using analog random multiplexing addressed devices (military / bank classed security) as i have done most of my professional life.
The current implantation with one unsecured network its not interested for my but i finding the possibility having multi instance of NCPs in ZHA tha letting one NCP working in high security mode with ZB3 lights and IAS devices and one "reduced" security network for devices like Xiaomi weather sensors and perhaps some old LL lights as routers for extending the mesh.
For getting the light system autonom and flexible for custom steering i have finding the ZigBee Lighting & Occupancy Device Specification 25 "Control bridge" with CLI being joined in the ZB3 light network and connected to tasmota that is sending custom commands to the lights without decreasing the security and autonomy of the lights. Tasmota have very nice system with roules that can being triggered from internal or external data and can working without all the wifi network / internet is up and running.
This opening for one "tasmota Zigbee Commander". One application is then going to the WC the lights is going on and then going from it the light is going of after one minute and the ventilation is running for 4 minutes after as long the lights it not going on, if the light is going on again then the ventilation is going off. The second application is going in the shower and the lights is going on from the motion but its going off after one minute. Then pressing one button and the tasmota is sending one "on with off 60 secund" every 55 seconds until long pressing the same button tasmota is sending one "on with off 15 seconds". The ventilation in the shower can esely being controlled with humidity sensors and manual with button pressing for manual override or "baying time" (triple press and ventilation runs for 30 minutes) or by simple timers (15 min every 3 hour). Its one very flexible solution without compromising the ZB3 security and have only one small device (ESP82xx with one NCP) that is not depending on always having internet and the compleet wifi network being online and its not being killed of one SD-card that is failing and is working autonome. Its connecting the secure ZB3 network and the flexibility from tasmotas echo system in one very nice way if being good implanted.
Hedda
commented
4 years ago FYI, EmberZNet SDK 6.8.2.0 GA (General Availability) was released on October 14th of 2020 as a bug-fix release to 6.8.0.1 / 6.8.0.2
https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.8.2.0.pdf
I can see that see zigpy / bellows developers have already firmware version to test with Elelabs ELU013 and ELR023 adapters:
https://github.com/zha-ng/EZSP-Firmware/tree/master/Elelabs-ELU013
Added slx_zigbee_routing_set_route_record_policy() to select the conditions under which a node will send a route record to the concentrator. Note that only the default policy of ROUTE_RECORD_POLICY_ACK_BY_SOURCE_ROUTED_MESSAGE is Zigbee-compliant.
ID # + Description
Adminiuga
commented
3 years ago No plans to support multiple pan-ids.
Hedda
commented
2 years ago FYI, Home Assistant developer agners begun working on an add-on for Silabs Multiprotocol stack requiring "Multi-PAN" firmware:
https://github.com/zigpy/zigpy/discussions/894
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/release-notes/emberznet-release-notes-6.8.0.2.pdf
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/
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.
@dmulcahey I think this might be a nice feature to have if it could be added to the Home Assistant ZHA implementation?
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."
@mtx512 @grobasoz @NilsBohr Maybe help with updated Zigbee coordinator HW firmware with EmberZNet 6.8 NCP application?
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.