[SUGGESTION] Increase default configuration parameters in firmware ITead Zigbee 3.0 USB Dongle

[Hedda]

Suggest increasing some of the default configuration parameters in firmware for ITead Zigbee 3.0 USB Dongle and SM-011.

Configuration Parameter	Value
Address Table Size	32
Child Table Size	32
Source Routes	200

That in firmware would make ITead Zigbee 3.0 USB Dongle and SM-011 be classified as a "pro" device as per zigpy/bellows#397

I do not think that changing those should cause any regressions as max can be set in the application or inherit from the NCP.

EFR32MG21 MCU used in ITead Zigbee 3.0 USB Dongle and SM-011 is certainly powerful/sized enough to support it.

Note that while this is supported by zigpy/bellows zigpy/bellows#397 but cannot yet be utilized in downstream HA's ZHA.

PS: This has been tested by tube0013 with his EFR32 based gateway/bridge

See example of used in real life

https://github.com/tube0013/tube_gateways

https://github.com/tube0013/tube_gateways/blob/main/tube_zb_gw_efr32/README.md

Specific Configuration for the Tube EFR32 Gateways

Because the EFR32 gateways uses some firrmware settings different than the bellows defaults it is recommended set them in the configuration.yaml so bellows will utilize them.

For EFR32 Series 2 Gateways with Firmware based on the 6.9.2 SDK or later please use the following config

Add these lines to your configuration.yaml file:

zha:
  zigpy_config:
    source_routing: true
    ezsp_config:
      CONFIG_APS_UNICAST_MESSAGE_COUNT: 64
      CONFIG_MAX_END_DEVICE_CHILDREN: 32
      CONFIG_SOURCE_ROUTE_TABLE_SIZE: 200
      CONFIG_ROUTE_TABLE_SIZE: 16
      CONFIG_ADDRESS_TABLE_SIZE: 32
      CONFIG_PACKET_BUFFER_COUNT: 250
      CONFIG_BINDING_TABLE_SIZE: 32
      CONFIG_NEIGHBOR_TABLE_SIZE: 26

https://github.com/tube0013/tube_gateways/blob/main/tube_zb_gw_efr32/README.md

you can do bellows -d /dev/ttyUSBx config --all it would print the current default, out of the box settings

this is with children set to 32 in fw.

NOTE: Configuration changes do not persist across resets
CONFIG_PACKET_BUFFER_COUNT=254
CONFIG_NEIGHBOR_TABLE_SIZE=26
CONFIG_APS_UNICAST_MESSAGE_COUNT=30
CONFIG_BINDING_TABLE_SIZE=32
CONFIG_ADDRESS_TABLE_SIZE=32
CONFIG_MULTICAST_TABLE_SIZE=8
CONFIG_ROUTE_TABLE_SIZE=16
CONFIG_DISCOVERY_TABLE_SIZE=8
CONFIG_STACK_PROFILE=0
CONFIG_SECURITY_LEVEL=5
CONFIG_MAX_HOPS=30
CONFIG_MAX_END_DEVICE_CHILDREN=32
CONFIG_INDIRECT_TRANSMISSION_TIMEOUT=3000
CONFIG_END_DEVICE_POLL_TIMEOUT=8
CONFIG_TX_POWER_MODE=0
CONFIG_DISABLE_RELAY=0
CONFIG_TRUST_CENTER_ADDRESS_CACHE_SIZE=0
CONFIG_SOURCE_ROUTE_TABLE_SIZE=200
CONFIG_FRAGMENT_WINDOW_SIZE=1
CONFIG_FRAGMENT_DELAY_MS=0
CONFIG_KEY_TABLE_SIZE=12
CONFIG_APS_ACK_TIMEOUT=1600
CONFIG_ACTIVE_SCAN_DURATION=3
CONFIG_END_DEVICE_BIND_TIMEOUT=60
CONFIG_PAN_ID_CONFLICT_REPORT_THRESHOLD=2
CONFIG_REQUEST_KEY_TIMEOUT=0
CONFIG_CERTIFICATE_TABLE_SIZE=0
CONFIG_APPLICATION_ZDO_FLAGS=0
CONFIG_BROADCAST_TABLE_SIZE=15
CONFIG_MAC_FILTER_TABLE_SIZE=0
CONFIG_SUPPORTED_NETWORKS=1
CONFIG_SEND_MULTICASTS_TO_SLEEPY_ADDRESS=0
CONFIG_ZLL_GROUP_ADDRESSES=1
CONFIG_ZLL_RSSI_THRESHOLD=128
CONFIG_MTORR_FLOW_CONTROL=1
CONFIG_RETRY_QUEUE_SIZE=16
CONFIG_NEW_BROADCAST_ENTRY_THRESHOLD=9
CONFIG_TRANSIENT_KEY_TIMEOUT_S=300
CONFIG_BROADCAST_MIN_ACKS_NEEDED=255
CONFIG_TC_REJOINS_USING_WELL_KNOWN_KEY_TIMEOUT_S=300
CONFIG_CTUNE_VALUE=282
CONFIG_ASSUME_TC_CONCENTRATOR_TYPE=1```

[Hedda]

@xsp1989 Again I am not a firmware developer but maybe also increase "Address Table Size" to 32 and "Source Routes" to 200?

Configuration Parameter	Value
Address Table Size	32
Child Table Size	32
Source Routes	200

At least that is what I understand in zigpy/bellows#397 that tube0013 has configurated his EFR32MG21 based gateway to use?

https://github.com/tube0013/tube_gateways/blob/main/tube_zb_gw_efr32/README.md

Because the EFR32 gateways uses some higher firmware settings it is recommended set them in the configuration.yaml so bellows will utilize them.

Add these lines to your configuration.yaml file:

zha:
  zigpy_config:
    source_routing: true
    ezsp_config:
      CONFIG_APS_UNICAST_MESSAGE_COUNT: 30
      CONFIG_MAX_END_DEVICE_CHILDREN: 32
      CONFIG_SOURCE_ROUTE_TABLE_SIZE: 200
      CONFIG_ROUTE_TABLE_SIZE: 16
      CONFIG_ADDRESS_TABLE_SIZE: 32
      CONFIG_PACKET_BUFFER_COUNT: 254
      CONFIG_BINDING_TABLE_SIZE: 32
      CONFIG_NEIGHBOR_TABLE_SIZE: 26

[Hedda]

Looks like Elelabs which uses older and slower EFR32G13 (and EFR32MG12) MCUs is using similar increased values as well:

https://github.com/zha-ng/EZSP-Firmware/blob/master/Elelabs-ELU013/README.md

Configuration Parameter	Value
Address Table Size	16
Child Table Size	32
Source Routes	200

So might be a good idea to set higher values for "Address Table Size", "Child Table Size", and "Source Routes" for EFRM32G21?

@xsp1989 What do you think about a new firmware these suggested higher values below?

Configuration Parameter	Value
Address Table Size	32
Child Table Size	32
Source Routes	200

...and what about increasing "NEIGHBOR TABLE SIZE" maximum to 26? Should any other values be increased for "pro" devices?

zigpy/bellows#397

  CONFIG_APS_UNICAST_MESSAGE_COUNT: 30
  CONFIG_MAX_END_DEVICE_CHILDREN: 32
  CONFIG_SOURCE_ROUTE_TABLE_SIZE: 200
  CONFIG_ROUTE_TABLE_SIZE: 16
  CONFIG_ADDRESS_TABLE_SIZE: 32
  CONFIG_PACKET_BUFFER_COUNT: 254
  CONFIG_BINDING_TABLE_SIZE: 32
  CONFIG_NEIGHBOR_TABLE_SIZE: 26

@tube0013 Would you maybe mind sharing your insight and experience with these higher values for EFR32MG21 MCUs?

https://github.com/tube0013/tube_gateways/blob/main/tube_zb_gw_efr32/README.md

Specific Configuration for the Tube EFR32 Gateways

Because the EFR32 gateways uses some higher firmware settings it is recommended set them in the configuration.yaml so bellows will utilize them.

Add these lines to your configuration.yaml file:

zha:
  zigpy_config:
    source_routing: true
    ezsp_config:
      CONFIG_APS_UNICAST_MESSAGE_COUNT: 30
      CONFIG_MAX_END_DEVICE_CHILDREN: 32
      CONFIG_SOURCE_ROUTE_TABLE_SIZE: 200
      CONFIG_ROUTE_TABLE_SIZE: 16
      CONFIG_ADDRESS_TABLE_SIZE: 32
      CONFIG_PACKET_BUFFER_COUNT: 254
      CONFIG_BINDING_TABLE_SIZE: 32
      CONFIG_NEIGHBOR_TABLE_SIZE: 26

[Hedda]

@xsp1989 What is your thoughts on this #13 ?

[Hedda]

@silabs-RaoulvB What are your opinions on these EmberZNet config parameters for EFR32MG21 for Zigbee Coordinator purpose?

And is it also a good idea to change some other default values for a powerful Zigbee Coordinator based on EFR32MG21?

To give you an example of what SiLabs own example Z3GatewayHost application does at startup:

$ ./build/exe/Z3GatewayHost.exe -p COM14 -f x
Reset info: 11 (SOFTWARE)
ezsp ver 0x08 stack type 0x02 stack ver. [6.9.2 GA build 256]
Ezsp Config: set address table size to 0x0002:Success: set
Ezsp Config: set TC addr cache to 0x0002:Success: set
Ezsp Config: set MAC indirect TX timeout to 0x1E00:Success: set
Ezsp Config: set max hops to 0x001E:Success: set
Ezsp Config: set tx power mode to 0x8000:Success: set
Ezsp Config: set supported networks to 0x0001:Success: set
Ezsp Config: set stack profile to 0x0002:Success: set
Ezsp Config: set security level to 0x0005:Success: set
Ezsp Value : set end device keep alive support mode to 0x00000003:Success: set
Ezsp Policy: set binding modify to "allow for valid endpoints & clusters only":Success: set
Ezsp Policy: set message content in msgSent to "return":Success: set
Ezsp Value : set maximum incoming transfer size to 0x00000052:Success: set
Ezsp Value : set maximum outgoing transfer size to 0x00000052:Success: set
Ezsp Config: set binding table size to 0x0010:Success: set
Ezsp Config: set key table size to 0x0004:Success: set
Ezsp Config: set max end device children to 0x0020:Success: set
Ezsp Config: set aps unicast message count to 0x000A:Success: set
Ezsp Config: set broadcast table size to 0x000F:Success: set
Ezsp Config: set neighbor table size to 0x0010:Success: set
NCP supports maxing out packet buffers
Ezsp Config: set packet buffers to 253
Ezsp Config: set end device poll timeout to 0x0008:Success: set
Ezsp Config: set zll group addresses to 0x0000:Success: set
Ezsp Config: set zll rssi threshold to 0xFFD8:Success: set
Ezsp Config: set transient key timeout to 0x00B4:Success: set
Ezsp Endpoint 1 added, profile 0x0104, in clusters: 8, out clusters 19
Ezsp Endpoint 242 added, profile 0xA1E0, in clusters: 0, out clusters 1

[silabs-RaoulvB]

@Hedda the config parameters are Zigbee stack parameters and are not depending on the HW (e.g. MG12 versus MG21) and mostly have influence on your network capabilities, so whatever was done for MG12/13 can (and should) also be done on MG21, but not for the reason of the soc used, but for your network functionality. The advantage of the MG21 versus MG12/13 is mainly in faster speed, lower power consumption and improved radio performance, but please keep in mind that a Zigbee network is a system composed of many components and in the end there will be a "weakest" link somewhere.
As a very crude example: if your gateway (maybe based on an MG21) in your setup has only reach to a single router as next hop and this router has slow performance or e.g. small routing/neighbour/address table, some of these parameters are completely irrelevant as that weakest link will limit your system capability. And if this next hop router is a commercial device, the configuration of that device is leading, and you have no influence.
Please also remember that a Zigbee Coordinator is in operating mode exactly the same a a router. It management features are there to manage the network in terms of setting up the network, allowing new members in etc, but has no special function in normal operation.
Good reading for understanding how Zigbee works: https://www.silabs.com/documents/public/user-guides/ug103-02-fundamentals-zigbee.pdf

[Hedda]

The suggestion here of increasing default configuration parameters in a standard firmware image for ITead Zigbee 3.0 USB Dongle is based on the assumption that it will primarily be used as a Zigbee Coordinator in DIY home automation hubs/gateways/bridges.

Since it is relatively inexpensive you could probably also assume that it will be bought by a lot of users who are new to Zigbee so it is therefore very important that the default firmware for it will be pre-configured with the optimized parameters out-of-the-box.

I think that the concept to aim for should be as much "plug-and-play" as possible for all users who is new to Zigbee who might just buy this Zigbee 3.0 USB Dongle and a bunch of battery-operated sensors as their first purchase of Zigbee devices. Yes I know that do you need Zigbee Router devices to cover a large and get a good network mesh but it would be great if it also works great with a couple of mains-powered Zigbee Router devices and loads of battery-operated sensors Zigbee end devices.

Again, ITead marketing should maybe make it more clear that the target audience for this relatively inexpensive Zigbee 3.0 USB Dongle product is primarily users of the most popular DIY home automation software applications such as Home Assistant, OpenHAB, Zigbee2MQTT, IoBroker, Jeedom, etc. ...and the reason for that target audience is clearly for ITead to sell more of their mostly battery-operated Sonoff branded Zigbee devices to that DIY home automation market (following the attach rate business concept).

With users of DIY home automation software applications so clearly being the target audience for this Zigbee 3.0 USB Dongle product the default firmware for it should really come fully pre-configured with optimized parameters tuned for that purpose out-of-the-box, e.g. optimized for plugging it into Raspberry Pi type single-board-computers then connecting and controlling anything from a few to a few of hundreds (maybe ~ 20-200) Zigbee devices that are similar to the relatively inexpensive Sonoff branded Zigbee devices (whether they are powered by mains-power or battery-operated).

[Hedda]

Closed without comment?