SiliconLabsSoftware · silabs-vm · Aug 17, 2026 · Jul 27, 2026 · Jul 29, 2026 · Aug 3, 2026
@@ -4,37 +4,39 @@ This page provides links to pre-built software image "artifacts" that can be use
 
 Images for the items listed below are available under the "Assets" section at the bottom of this page:
 
-https://github.com/SiliconLabs/matter_extension/releases/tag/v2.9.0
+https://github.com/SiliconLabs/matter_extension/releases/tag/v2.9.1
 
 ## Matter Hub Raspberry Pi Image
 
 The Matter Hub image is intended to be flashed onto an SD card for a Raspberry Pi. The Matter Hub image provides both an Open Thread Border Router and the Matter chip-tool. Note the image is ~7GB in size so depending on your internet connection this download may take some time. Start the Matter Hub Raspberry Pi image download here:
 
 https://www.silabs.com/documents/public/software/SilabsMatterPi_2.9.0-1.6-extension.zip
 
+> **Note:** This release uses the same MatterHub image as the 2.9.0 release.
+
 ## Radio Co-Processor (RCP) Images
 
 The Radio Co-Processor firmware is used to turn an EFR into an RCP that can be used with a Raspberry Pi to allow the Raspberry Pi's Open Thread Border Router to access the Thread network. Radio Co-Processor (RCP) images are available in the Assets section of this page:
 
-https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.0/ot-rcp-binaries-2.9.0-1.6.zip
+https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.1/ot-rcp-binaries-2.9.1-1.6.zip
 
 ## Matter Accessory Device Images
 
 The Matter Accessory Device Images are used to turn an EFR into a Matter device. These are pre-built binary images for the Matter Demo. Matter Accessory Device Images are located in the Assets section of this page:
 
-https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.0/matter-accessory-device-images_2.9.0-1.6.zip
+https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.1/matter-accessory-device-images_2.9.1-1.6.zip
 
 ## Matter Bootloader Binaries
 
 All Silicon Labs board supporting Matter require that a bootloader binary is flashed to the device along with the application image. Bootloader binaries for all of the Matter supported devices are available here:
 
-https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.0/bootloader_binaries_matter_extension_v2.9.0-1.6.zip
+https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.1/bootloader_binaries_matter_extension_v2.9.1-1.6.zip
 
 ## SiWx917 Firmware for SiWN917 NCP and SiWG917 SOC
 
 The SiWx917 firmware(SiWx917_firmware_files.zip) is used to update the SiWN917 NCP and SiWG917 SOC which can be found in the Assets section of this page:
 
-https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.0/SiWx917_firmware_files_2.9.0-1.6.zip
+https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.1/SiWx917_firmware_files_2.9.1-1.6.zip
 
 **Note**:
 
@@ -52,12 +54,12 @@ https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.0/SiWx917
 
 The SiWx917 RCP folder (siwx917_rcp_files.zip) contains the Matter Linux all-cluster-app, which can be run on a Raspberry Pi, and the wfx-sdio-overlay.dts file, a Device Tree Source file used to configure the SDIO interface on the Raspberry Pi to detect and communicate with the SiWx917 RCP.
 
-https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.0/siwx917_rcp_files.zip
+https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.1/siwx917_rcp_files.zip
 
 ## SiWx917 SoC Configuration Files For JLink RTT Logging
 
 To check device logs on JLink RTT for the Matter Application on the SiWx917 SoC, the **JLink RTT** must be configured for the SiWx917 SoC device by following the instructions on the [JLink RTT SOC Support](/matter/{build-docspace-version}/matter-wifi-enabling-features/jlink-soc-setup) for SiWx917 SoC.
 
-The [JLinkDevices.xml](https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.0/JLinkDevices.xml.zip) and [RS9117_SF_4MB_42bsp.elf](https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.0/RS9117_SF_4MB_42bsp.elf.zip) files referenced in the instructions may be found in the Assets section of this page.
+The [JLinkDevices.xml](https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.1/JLinkDevices.xml.zip) and [RS9117_SF_4MB_42bsp.elf](https://github.com/SiliconLabs/matter_extension/releases/download/v2.9.1/RS9117_SF_4MB_42bsp.elf.zip) files referenced in the instructions may be found in the Assets section of this page.
 
 >**Note**: For EFR32MG2x devices, JLink RTT Logging support is already enabled.
@@ -7,30 +7,130 @@ Build a customizable lighting app using the Matter protocol.
 This guide covers the basics of building a customizable lighting application
 using Matter.
 
-## Application Customization Models
+## Extending Base App Implementation
 
-Matter Extension 2.9.0 migrates a subset of sample apps to the Curiously Recurring Template Pattern (CRTP) based architecture, which removes app manager and DataModelCallbacks files. All other sample apps keep the previous architecture until the patch release.
+### CustomerAppTask
 
-Check your project in Project Explorer:
+To customize app behavior, override any Silicon Labs implemented API in `CustomerAppTask`. This example provides `CustomerAppTask.h` and `CustomerAppTask.cpp` for that purpose. The build system generates the base implementation and the complete set of overridable `*Impl()` APIs in `autogen/AppTask.cpp` and `autogen/AppTaskImpl.h`. Any `*Impl()` methods that you do not override use the Silicon Labs default implementation.
+### How to Override APIs
 
-| If you see… | Architecture | Where to add custom logic |
-|---|---|---|
-| `src/CustomerAppTask.cpp` and `autogen/AppTask.cpp` | **New** | Override `*Impl()` hooks in `CustomerAppTask`, do not edit `autogen/AppTask.cpp` |
-| `src/DataModelCallbacks.cpp` and editable `src/AppTask.cpp` | **Legacy** | Callbacks in `DataModelCallbacks.cpp`, init and app logic in `src/AppTask.cpp` |
+`CustomerAppTask` extends the base `AppTask` by using the Curiously Recurring Template Pattern (CRTP). The base class declares one `*Impl()` method for each overridable API. Override only the `*Impl()` methods that you need. To override a `*Impl()` method:
 
-**Sample apps on the new architecture in 2.9.0:**
+1. Find the method to override in the base API. For more information, see [Override API reference](#override-api-reference).
+2. Declare the same method signature in `CustomerAppTask.h` under the `private:` section. Match the base `*Impl()` signature exactly.
+   > **NOTE:**
+   > `*Impl()` overrides are non-static instance methods, even when the corresponding public dispatcher (for example, `ButtonEventHandler`) is static.
+3. Implement the method in `CustomerAppTask.cpp`.
+4. Build the project. If you implement the corresponding `*Impl()` method in `CustomerAppTask`, your implementation is used. Otherwise, the Silicon Labs default implementation is used. You only need to implement the methods that you want to customize. All other methods automatically use the default implementation.
 
-- Lighting 
-- Zigbee Matter Light
-- On/Off Plug
-- Thermostat
-- Lock
-- Light Switch
-- Rangehood
-- Platform Template
-- Air Quality Sensor
+### DataModelCallbacks and CustomerAppTask
 
-All other Silicon Labs Matter sample apps in this release use the legacy model. Related guides label steps as **New architecture** or **Legacy architecture** where they differ.
+What used to live in `DataModelCallbacks.cpp` before Matter Extension 2.9.1 now lives in `AppTask.cpp`. The
+Matter SDK's `MatterPostAttributeChangeCallback` is implemented in
+`examples/platform/silabs/BaseApplication.cpp` and forwards to
+`AppTask::DMPostAttributeChangeCallback` (defined in `AppTask.cpp`), which you
+can customize via `DMPostAttributeChangeCallbackImpl()` in `CustomerAppTask`.
+
+Forwarding into `AppTask` still goes through CRTP as in
+[How to Override APIs](#how-to-override-apis).
+
+-   **Methods that already exist in the AppTask** — Customize them by overriding
+    the matching `*Impl()` method in `CustomerAppTask`. Do not edit the
+    `AppTask.cpp` for app-specific behavior.
+
+-   **New custom data model methods** — Add them in `CustomerAppTask` directly.
+    Do not add new application logic in autogenerated sources; those edits will
+    not survive regeneration or project upgrades.
+
+### Sample Implementation
+
+The following shows a minimal example `CustomerAppTask` that overrides `AppInitImpl()` and `ButtonEventHandlerImpl()` from 
+the lighting app implementation. 
+
+**CustomerAppTask.h**
+
+```cpp
+#pragma once
+#include "AppTaskImpl.h"
+
+/**
+ * Minimal AppTaskImpl-derived class. Override only the *Impl() methods you need;
+ * add AppInitImpl(), GetAppTask(), and sAppTask as required by the CRTP base.
+ */
+class CustomerAppTask : public AppTaskImpl<CustomerAppTask>
+{
+public:
+    static CustomerAppTask & GetAppTask() { return sAppTask; }
+
+private:
+    friend class AppTaskImpl<CustomerAppTask>;
+    CHIP_ERROR AppInitImpl();
+    void ButtonEventHandlerImpl(uint8_t button, uint8_t btnAction);
+    static CustomerAppTask sAppTask;
+};
+```
+
+**CustomerAppTask.cpp**
+
+```cpp
+#include "CustomerAppTask.h"
+#include "AppTask.h"
+#include "AppConfig.h"
+#include "AppEvent.h"
+#include <platform/CHIPDeviceLayer.h>
+#include <platform/silabs/platformAbstraction/SilabsPlatform.h>
+
+using namespace ::chip::DeviceLayer::Silabs;
+
+#define APP_FUNCTION_BUTTON 0
+#define APP_LIGHT_SWITCH     1
+
+CustomerAppTask CustomerAppTask::sAppTask;
+
+AppTask & AppTask::GetAppTask()
+{
+    return CustomerAppTask::GetAppTask();
+}
+
+CHIP_ERROR CustomerAppTask::AppInitImpl()
+{
+    SILABS_LOG("CustomerAppTask: custom implementation (AppInitImpl)");
+    CHIP_ERROR err = this->AppTask::AppInit();
+    if (err == CHIP_NO_ERROR)
+    {
+        // Override the SDK default button handler registered in AppTask::AppInit().
+        chip::DeviceLayer::Silabs::GetPlatform().SetButtonsCb(CustomerAppTask::ButtonEventHandler);
+    }
+    return err;
+}
+
+void CustomerAppTask::ButtonEventHandlerImpl(uint8_t button, uint8_t btnAction)
+{
+    SILABS_LOG("CustomerAppTask: custom implementation (ButtonEventHandlerImpl)");
+    AppEvent button_event           = {};
+    button_event.Type               = AppEvent::kEventType_Button;
+    button_event.ButtonEvent.Action = btnAction;
+    if (button == APP_LIGHT_SWITCH && btnAction == static_cast<uint8_t>(SilabsPlatform::ButtonAction::ButtonPressed))
+    {
+        button_event.Handler = LightActionEventHandler;
+        AppTask::GetAppTask().PostEvent(&button_event);
+    }
+    else if (button == APP_FUNCTION_BUTTON)
+    {
+        button_event.Handler = BaseApplication::ButtonHandler;
+        AppTask::GetAppTask().PostEvent(&button_event);
+    }
+}
+```
+
+### Override API Reference
+
+The base API and implementation are generated into the `autogen/` directory. These files are regenerated whenever you upgrade the project and match the installed SDK version. Use them as a reference for overridable methods and app configuration.
+
+| File | Purpose |
+|------|--------|
+| `autogen/AppTaskImpl.h` | Declarations of every overridable `*Impl()` method. Copy the signatures you need from here into `CustomerAppTask.h`. |
+| `autogen/AppTask.cpp` | Silicon Labs provides the default `AppTask` implementation. Any `*Impl()` methods that you don't override use this implementation. Use it as a reference when customizing app behavior. |
 
 ## Using Matter with Clusters
 
@@ -86,7 +186,7 @@ through this function. The command can then be dissected using conditional logic
 to call the proper application functions based on the most recent command
 received.
 
-Depending on your sample application, edit the files as described in [Application Customization Models](#application-customization-models). New architecture apps route attribute changes through `CustomerAppTask` and `DMPostAttributeChangeCallbackImpl()`. Legacy architecture apps implement `MatterPostAttributeChangeCallback()` directly in `src/DataModelCallbacks.cpp`.
+Attribute changes route through `CustomerAppTask` and `DMPostAttributeChangeCallbackImpl()`. For more information, see [Extending Base App Implementation](#extending-base-app-implementation).
 
 ## Adding a Cluster to a ZAP Configuration
 
@@ -108,8 +208,6 @@ the current zap configuration, and run the generate.py script above.
 
 ## React to Level Control Cluster Commands
 
-### New Architecture
-
 In a custom implementation of `DMPostAttributeChangeCallbackImpl()` in `src/CustomerAppTask.cpp`, add the following or similar code. This enables the application to react to the MoveToLevel commands.
 
    ```cpp
@@ -125,27 +223,6 @@ In a custom implementation of `DMPostAttributeChangeCallbackImpl()` in `src/Cust
     }
    ```
 
-### Legacy Architecture
-
-In the MatterPostAttributeCallback function in ZclCallbacks, add the following
-line of code or a similar line. This will give the application the ability to react to
-MoveToLevel commands. You can define platform-specific behavior for a
-MoveToLevel action.
-   ```cpp
-    else if (clusterId == LevelControl::Id)
-    {
-       ChipLogProgress(Zcl, "Level Control attribute ID: " ChipLogFormatMEI " Type: %u Value: %u, length %u",
-                        ChipLogValueMEI(attributeId), type, *value, size);
-
-       if (attributeId == LevelControl::Attributes::CurrentLevel::Id)
-       {
-          action_type = LightingManager::MOVE_TO_LEVEL;
-       }
-
-       LightMgr().InitiateActionLight(AppEvent::kEventType_Light, action_type, endpoint, *value);
-    }
-   ```
-
 ## Send a MoveToLevel Command and Read the CurrentLevel Attribute
 
 Rebuild the application and load the new executable on your EFR32 device. Send
@@ -178,7 +255,7 @@ In order to use a custom cluster in an application, follow these steps:
       "value": "true"
     }   
  ```
-For an example, see [Sample ZAP file](https://github.com/SiliconLabsSoftware/matter_extension/blob/v2.9.0/slc/apps/performance_test_app/thread/performance-test-app.zap)
+For an example, see [Sample ZAP file](https://github.com/SiliconLabsSoftware/matter_extension/blob/v2.9.1/slc/apps/performance_test_app/thread/performance-test-app.zap)
 - Install the **Custom ZAP generation** component under **Silicon Labs Matter -> Stack** in the project's Component Editor. 
 
 
@@ -205,5 +205,5 @@ In order to use a custom cluster in an application, follow these steps:
       "value": "true"
     }   
  ```
-For an example, see [Sample ZAP file](https://github.com/SiliconLabsSoftware/matter_extension/blob/v2.9.0/slc/apps/performance_test_app/thread/performance-test-app.zap)
+For an example, see [Sample ZAP file](https://github.com/SiliconLabsSoftware/matter_extension/blob/v2.9.1/slc/apps/performance_test_app/thread/performance-test-app.zap)
 - Install the **Custom ZAP generation** component under **Silicon Labs Matter -> Stack** in the project's Component Editor.
@@ -74,4 +74,5 @@ Update digits based on the following criteria:
 |  v2.7.0-1.4  |  25-Sep-25     | 2025.6.2                       | v3.5.2   | 1.4 | Maintained |
 |  v2.8.0-1.5  |  12-Jan-25     | 2025.12.0                      | v4.0.0   | 1.5 | Maintained |
 |  v2.8.1-1.5  |  23-Mar-25     | 2025.12.2                      | v4.0.1   | 1.5 | Maintained |
-|  v2.9.0-1.6  |  24-Jun-26     | 2026.6.0                       | v4.1.0   | 1.6 | Active     |
+|  v2.9.0-1.6  |  24-Jun-26     | 2026.6.0                       | v4.1.0   | 1.6 | Maintained |
+|  v2.9.1-1.6  |  30-Jul-26     | 2026.6.1                       | v4.1.1   | 1.6 | Active     |
@@ -8,7 +8,7 @@ To get started with Matter over Wi-Fi, download the latest version of Simplicity
 
 ## Setting up the Matter over Wi-Fi Development Environment
 
-Refer to the [Release Notes](https://github.com/SiliconLabs/matter_extension/releases/tag/v2.9.0) to know more about the latest releases from Silicon Labs.
+For more information about the latest Silicon Labs releases, see the [Release Notes](https://github.com/SiliconLabs/matter_extension/releases/tag/v2.9.1).
 
 To control the Matter Accessory Device, a controller is required which is termed as **chip-tool**. The chip-tool can be set up in two ways:
 

@@ -4,12 +4,10 @@ Attributes represent the current state of a device. For instance if the device i
 
 ## Attribute Changes
 
-Depending on your sample app, instructions apply. For more information, refer to [Application customization models](/matter/{build-docspace-version}/matter-references/custom-matter-device/#application-customization-models).
-
-### New Architecture
-
 When a ZCL attribute is updated in the data model, the framework invokes the post-attribute-change path. The Silicon Labs Matter stack routes this as follows: `MatterPostAttributeChangeCallback` in `BaseApplication.cpp` → `AppTask::DMPostAttributeChangeCallback` in `autogen/AppTask.cpp` → your optional `DMPostAttributeChangeCallbackImpl()` override in `CustomerAppTask`.
 
+For more information, see [Extending Base App Implementation](/matter/{build-docspace-version}/matter-references/custom-matter-device/#extending-base-app-implementation).
+
 If this callback is implemented by the device, it is informed of the attribute change. The device may react to the attribute change. For example, in `DMPostAttributeChangeCallback` function the in `AppTask.cpp` file ([onoff-plug-app/src](https://github.com/SiliconLabsSoftware/matter_sdk/blob/main/examples/onoff-plug-app/silabs/src/AppTask.cpp)), if you want to add a custom handler code to control an RGB LED when on/off attribute in the `On-Off` Cluster changes, implement the following in `DMPostAttributeChangeCallbackImpl` in `src/CustomerAppTask.cpp`:
 
 ```cpp
@@ -39,36 +37,6 @@ void DMPostAttributeChangeCallbackImpl(const chip::app::ConcreteAttributePath &
 }
 ```
 
-### Legacy Architecture
-
-When a ZCL attribute is updated in the data model, the framework calls `MatterPostAttributeChangeCallback()` in `src/DataModelCallbacks.cpp`. If this callback is implemented by the device it will be informed of the attribute change. For example, to control an RGB LED when the On/Off attribute changes:
-
-```cpp
-void MatterPostAttributeChangeCallback(const chip::app::ConcreteAttributePath & attributePath,
-                                        uint8_t type,
-                                        uint16_t size,
-                                        uint8_t * value)
-{
-    ClusterId clusterId     = attributePath.mClusterId;
-    AttributeId attributeId = attributePath.mAttributeId;
-    ChipLogProgress(Zcl, "Cluster callback: " ChipLogFormatMEI, ChipLogValueMEI(clusterId));
-
-    if (clusterId == OnOff::Id && attributeId == OnOff::Attributes::OnOff::Id)
-    {
-        if (*value)
-        { // turn on LED
-            sl_led_turn_on((sl_led_t *)&sl_simple_rgb_pwm_led_rgb_led0);
-        }
-        else
-        {// turn off LED
-            sl_led_turn_off((sl_led_t *)&sl_simple_rgb_pwm_led_rgb_led0);
-        }
-    }
-
-    //...
-}
-```
-
 ## Header File
 
 This file contains the high level namespaces and constant definitions for Attributes. In Simplicity Studio, this will be generated in the autogen/zap-generated/ folder of the matter project.

@@ -4,7 +4,7 @@ Events are records of past state transitions such as a light device's on-off att
 
 The autogenerated file [```include/AppEvent.h```](https://github.com/SiliconLabs/matter_extension/blob/main/third_party/matter_sdk/examples/template/silabs/include/AppEvent.h) contains the definition of the event object used by the application. It includes the event types, the structures for each event, and event handler.
 
-**New architecture:** Custom event posting and handlers are overridden in the `CustomerAppTask` file, not in `autogen/AppTask.cpp`.
+Custom event posting and handlers are overridden in the `CustomerAppTask` file, not in `autogen/AppTask.cpp`.
 
 ## Header File