In this post, I’m going to explain another type of cluster and attribute configuration enabled by the ZigBee 3.0 specification. This configuration determines the different operating modes or options that the manufacturer has defined for their device. For example, what you want the device to do in the event of a power loss, the desired sensitivity for a motion sensor, or how to select specific functions on a thermostat, etc.
The Zigbee 3.0 specification categorizes these attribute options as:
- Mandatory (M): All manufacturers must include this attribute configuration in their devices. This ensures a minimum level of standardization.
- Optional (O): Manufacturers may or may not include this attribute in their device to improve its performance and allow it to be customized by the user.
- Allows the use of manufacturer-specific clusters and attributes: This allows manufacturers to add special features and configurations that differentiate them from other products and make them more attractive in the market. This requires using the manufacturer’s code to modify that cluster or attribute.
These custom configurations are made by sending the WriteAttribute command with the values that the manufacturer has defined as options for that attribute.
This command is handled very well using the Hub libraries, but I’ve incorporated them as a module in my MC drivers, making them even easier for me to manage. They’re just a few lines of code that barely consume any Hub resources.
Ideally, these settings would be available in the device preferences in the app, but most of these settings are only made once, to define how I want my device to work, and are rarely touched again.
in smartthings drivers, which manage many different devices, zigbee switch, motion sensor, etc… it would make the drivers excessively complex and large, which would consume much more memory from the Hub and would cause us more problems than benefits.
Therefore, we must find a compromise and include only the most common and useful ones in the drive.
For the remaining configurable optional attributes, I developed a tool, a “Zigbee Device Config Mc” driver, that allows you to modify any cluster and attribute that the manufacturer has included in the device. All we need is:
- Install the Zigbee Device Config Mc driver on our Hub
- Make a temporary driver change to configure our device
- We need to know all the values needed for the WriteAttribute command by searching in the manual or on the internet.
- If it is a battery-powered device, it must be awake when the writeAttribute command is sent.
- Once the device is configured, we will switch back to the original working driver and the customized configuration will remain on the device until we perform a factory reset.
This is the link to Zigbee Device Config Mc thread
This conversation shows how to use the Zigbee configuration driver.
Just a thought:
I think the Matter specification for clusters and attributes is based on what already existed and worked: Zigbee.
Therefore, mandatory, optional, and manufacturer-specific clusters and attributes continue to exist; no manufacturer is going to give up on differentiating themselves from others in their own apps and platforms.
SmartThings platform could also customize devices, but since drivers are constantly evolving and there are already a monster of drivers, let’s see who dares to create community drivers and keep them updated. 
I will continue editing the post to finish it