diff --git a/sld249-matter-prerequisites/matter-artifacts.md b/sld249-matter-prerequisites/matter-artifacts.md index 04abcc5..50c1284 100644 --- a/sld249-matter-prerequisites/matter-artifacts.md +++ b/sld249-matter-prerequisites/matter-artifacts.md @@ -4,7 +4,7 @@ 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 @@ -12,29 +12,31 @@ The Matter Hub image is intended to be flashed onto an SD card for a Raspberry P 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. diff --git a/sld250-matter-references/custom-matter-device.md b/sld250-matter-references/custom-matter-device.md index 1d94cce..e6cc8be 100644 --- a/sld250-matter-references/custom-matter-device.md +++ b/sld250-matter-references/custom-matter-device.md @@ -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 +{ +public: + static CustomerAppTask & GetAppTask() { return sAppTask; } + +private: + friend class AppTaskImpl; + 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 +#include + +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(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. diff --git a/sld250-matter-references/matter-zap.md b/sld250-matter-references/matter-zap.md index 880553c..442d4cc 100644 --- a/sld250-matter-references/matter-zap.md +++ b/sld250-matter-references/matter-zap.md @@ -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. diff --git a/sld250-matter-references/versioning-release-maintenance.md b/sld250-matter-references/versioning-release-maintenance.md index ce9fac9..a034e40 100644 --- a/sld250-matter-references/versioning-release-maintenance.md +++ b/sld250-matter-references/versioning-release-maintenance.md @@ -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 | \ No newline at end of file diff --git a/sld290-matter-wifi-getting-started-example/index.md b/sld290-matter-wifi-getting-started-example/index.md index 3df8272..29984d9 100644 --- a/sld290-matter-wifi-getting-started-example/index.md +++ b/sld290-matter-wifi-getting-started-example/index.md @@ -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: diff --git a/sld295-matter-api-reference/attributes.md b/sld295-matter-api-reference/attributes.md index 5483fb8..8535535 100644 --- a/sld295-matter-api-reference/attributes.md +++ b/sld295-matter-api-reference/attributes.md @@ -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. diff --git a/sld295-matter-api-reference/event.md b/sld295-matter-api-reference/event.md index 6bbcf3a..d2996b9 100644 --- a/sld295-matter-api-reference/event.md +++ b/sld295-matter-api-reference/event.md @@ -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 diff --git a/sld295-matter-api-reference/index.md b/sld295-matter-api-reference/index.md index 960faa9..a3d6fde 100644 --- a/sld295-matter-api-reference/index.md +++ b/sld295-matter-api-reference/index.md @@ -11,13 +11,11 @@ This section covers the various Application Programming Interfaces (APIs) that a ## Application APIs -For guidance on new vs legacy sample app architecture and where to add custom logic, see [Application Customization Models](/matter/{build-docspace-version}/matter-references/custom-matter-device/#application-customization-models). +For information about customizing app behavior with `CustomerAppTask`, see [Extending Base App Implementation](/matter/{build-docspace-version}/matter-references/custom-matter-device/#extending-base-app-implementation). ### Initialization -**New architecture:** Default initialization is included in `autogen/AppTask.cpp`. Override `AppInitImpl()` and other `*Impl()` hooks in `src/CustomerAppTask.cpp` to customize behavior. - -**Legacy architecture:** The application Init sequence is included in `src/AppTask.cpp` and is called at the beginning of the application to ensure that all components are properly initialized and ready to operate. It sets up necessary callbacks, initializes hardware components, and handles any errors that may occur during the process. +Default initialization is included in `autogen/AppTask.cpp`. Override `AppInitImpl()` and other `*Impl()` hooks in `src/CustomerAppTask.cpp` to customize behavior. ```cpp CHIP_ERROR AppTask::Init() diff --git a/sld388-matter-new-features/index.md b/sld388-matter-new-features/index.md index fae0c99..301dc6e 100644 --- a/sld388-matter-new-features/index.md +++ b/sld388-matter-new-features/index.md @@ -1,5 +1,8 @@ # New Features +## New Features for v2.9.1-1.6 +- LLVM compiler support for Matter projects. + ## New Features for v2.9.0-1.6 - Quality-tested Matter 1.6 solution for Thread MG24 / MG26 / MG30, Wi-Fi SiWG917 SoC and SiWN917 NCP mode. - Matter + AWS dual-stack support for 917 NCP boards. diff --git a/sld477-matter-quick-start-demo/01-wifi-quick-start-demo.md b/sld477-matter-quick-start-demo/01-wifi-quick-start-demo.md index 9ce14c2..d0864bb 100644 --- a/sld477-matter-quick-start-demo/01-wifi-quick-start-demo.md +++ b/sld477-matter-quick-start-demo/01-wifi-quick-start-demo.md @@ -4,7 +4,7 @@ This Quick-Start Guide will demo the out-of-box experience for adding an SiWx917 ## Software Requirements -- Simplicity Studio v6 with SiSDK - 2026.6.0 + Silicon Labs Matter - 2.9.0 + WiSeConnect - 4.1.0 +- Simplicity Studio v6 with SiSDK - 2026.6.1 + Silicon Labs Matter - 2.9.1 + WiSeConnect - 4.1.1 - Simplicity Connect mobile App on Smartphone ## Hardware Requirements diff --git a/sld477-matter-quick-start-demo/02-thread-quick-start-demo.md b/sld477-matter-quick-start-demo/02-thread-quick-start-demo.md index 5d86e1a..a422eb5 100644 --- a/sld477-matter-quick-start-demo/02-thread-quick-start-demo.md +++ b/sld477-matter-quick-start-demo/02-thread-quick-start-demo.md @@ -6,7 +6,7 @@ This demo uses the **Matter Thread - SoC Lighting FreeRTOS** example application ## Software Requirements -- Simplicity Studio v6 with SiSDK - 2026.6.0 + Silicon Labs Matter - 2.9.0 +- Simplicity Studio v6 with SiSDK - 2026.6.1 + Silicon Labs Matter - 2.9.1 - Simplicity Connect mobile App on Smartphone ## Hardware Requirements diff --git a/sld57-matter-landing-page/index.md b/sld57-matter-landing-page/index.md index b477446..e1aa768 100644 --- a/sld57-matter-landing-page/index.md +++ b/sld57-matter-landing-page/index.md @@ -31,7 +31,7 @@ Want to get a Matter application up and running quickly? Here's a high-level ove 4. **[Optional] Customize Matter App Behavior and Logic** - Use Project Configurator and other Studio tools to customize your app logic: [Developing with Project Configurator](https://docs.silabs.com/ssv6ug/latest/ssv6-configure-project/) - - Customize app behavior using the model your sample app provides — see [Application Customization Models](/matter/{build-docspace-version}/matter-references/custom-matter-device/#application-customization-models). Refactored apps use `CustomerAppTask` and `autogen/AppTask.cpp`, all other apps use `DataModelCallbacks.cpp` and `src/AppTask.cpp`. + - Customize app behavior in `CustomerAppTask` and `autogen/AppTask.cpp`. For more information, see [Extending Base App Implementation](/matter/{build-docspace-version}/matter-references/custom-matter-device/#extending-base-app-implementation). - Follow documentation to develop a custom matter device with ZAP and corresponding callbacks: [Custom Matter Device Development](/matter/{build-docspace-version}/matter-references/custom-matter-device) 5. **Build and Flash** @@ -48,7 +48,7 @@ Want to get a Matter application up and running quickly? Here's a high-level ove ## Other Resources -**To see release notes** containing a list of features and known issues, go to [Matter Release Notes on Silicon Labs Matter Extension](https://github.com/SiliconLabs/matter_extension/releases/tag/v2.9.0). +**To see release notes** containing a list of features and known issues, go to [Matter Release Notes on Silicon Labs Matter Extension](https://github.com/SiliconLabs/matter_extension/releases/tag/v2.9.1). **If you are new to Matter** or would like more information about Silicon Labs Matter-based products, see the [Matter content on silabs.com](https://www.silabs.com/wireless/matter). diff --git a/sld601-matter-application-development/index.md b/sld601-matter-application-development/index.md index fb44db8..f575d9c 100644 --- a/sld601-matter-application-development/index.md +++ b/sld601-matter-application-development/index.md @@ -1,6 +1,6 @@ # Introduction -This section covers application development topics. Silicon Labs will build out this section over time. For Matter v2.9.0, we provide: +This section covers application development topics. Silicon Labs will build out this section over time. For Matter v2.9.1, we provide: - [Matter Scenes Quick Start Guide](./matter-scenes-quick-start-guide) - [Matter Event and Timer Guide](./matter-event-timer-guide.md) diff --git a/sld601-matter-application-development/matter-application-cluster-logic.md b/sld601-matter-application-development/matter-application-cluster-logic.md index 4417f7b..279c1c6 100644 --- a/sld601-matter-application-development/matter-application-cluster-logic.md +++ b/sld601-matter-application-development/matter-application-cluster-logic.md @@ -55,18 +55,15 @@ Now that the On/Off cluster has been successfully added to the Sample Door Lock - Attributes, commands, and events for the cluster are added to your application’s data model. - Code is generated for attribute storage, command handling, and event notification. -- **New architecture**: implement application-specific behavior in `src/CustomerAppTask.cpp` by overriding `*Impl()` hooks (for example `DMPostAttributeChangeCallbackImpl()`), not by editing `autogen/AppTask.cpp`. -- **Legacy architecture**: Callback stubs are generated for you to implement application-specific behavior. You interact with the cluster by filling in these stubs and using the generated data structures. +- Implement application-specific behavior in `src/CustomerAppTask.cpp` by overriding `*Impl()` hooks, such as `DMPostAttributeChangeCallbackImpl()`, instead of editing `autogen/AppTask.cpp`. Additionally, a corresponding component is automatically added to your project. This occurs because enabling a cluster in ZAP updates your project configuration to include the necessary software components and libraries required to support that cluster’s functionality. For clusters, this functionality is implemented in the `/third_party/matter_sdk/src/app/clusters` directory. For the On/Off cluster, the server command handlers and related logic can be found in the `/on-off-server/on-off-server.cpp` file. ## Step 4: Add Application Logic -This guide uses the Lock sample app, which is on the **new architecture** in 2.9.0. See [Application Customization Models](/matter/{build-docspace-version}/matter-references/custom-matter-device/#application-customization-models) to confirm which model your project uses. +For information about customizing app behavior, see [Extending Base App Implementation](/matter/{build-docspace-version}/matter-references/custom-matter-device/#extending-base-app-implementation). -### New Architecture - -Application logic centers on AppTask, but refactored Matter projects split responsibilities: +Application logic centers on AppTask: - `autogen/AppTask.cpp`: default implementation, regenerated on project upgrade (do not edit for application logic, use as reference only). - `src/CustomerAppTask.cpp` and `include/CustomerAppTask.h`: your custom logic, add custom code and override `*Impl()` hooks here. @@ -131,41 +128,6 @@ Finally, add a call to `OnOffTmrStart()` at the end of your `AppInitImpl()` over In the flowchart above, `OnOffAttributeWriteStartTimer()` calls `OnOffTmrStart()` to restart the timer. -### Legacy Architecture - -Locate your project's src/AppTask.cpp file. This file acts as the central hub for application-specific logic, initialization, and event processing in a Matter application on Silicon Labs platforms. Start by adding two helper functions: a one-shot timer to expire in 10 seconds and the OnOffTmrExpiryHandler handler function. - -Include `app-common/zap-generated/attributes/Accessors.h` in your `AppTask.cpp` file, so that you can access cluster attributes. - -Add the timer start function to `AppTask.cpp` and declare it in `AppTask.h`: - -```C++ -void AppTask::OnOffAttributeWriteStartTimer() -{ - OnOffTmrStart(); -} -``` - -Now, locate the MatterPostAttributeChangeCallback() function in the src/DataModelCallbacks.cpp file. This function is invoked by the application framework after an attribute value has been changed. Because you are modifying the OnOff attribute in the OnOffTmrExpiryHandler() function, use this callback to re-initiate the timer so that the attribute continues to toggle. To achieve this, call AppTask::OnOffAttributeWriteStartTimer(), which is part of the AppTask context. - -```C++ -void MatterPostAttributeChangeCallback(const chip::app::ConcreteAttributePath & attributePath, uint8_t type, uint16_t size, - uint8_t * value) -{ - ClusterId clusterId = attributePath.mClusterId; - AttributeId attributeId = attributePath.mAttributeId; - - if (clusterId == OnOff::Id && attributeId == OnOff::Attributes::OnOff::Id){ - AppTask::GetAppTask().OnOffAttributeWriteStartTimer(); - } - -} -``` - -Make sure to #include "AppTask.h" at the top of the DataModelCallbacks.cpp file to call the AppTask::GetAppTask() function. For more information on the AppTask, refer to AppTask.h. - -Finally, add a call to OnOffTmrStart() at the end of the AppTask::AppInit() function to start the attribute write sequence. - ## Step 5: Interact with the On/Off Cluster After building your project, flash the compiled firmware onto your target board. Once the device is running, you should observe log messages approximately every 10 seconds indicating that the OnOff cluster's OnOff attribute is being written to. This confirms that the cluster is active and functioning as expected. diff --git a/sld601-matter-application-development/matter-event-timer-guide.md b/sld601-matter-application-development/matter-event-timer-guide.md index d1bf386..02ca399 100644 --- a/sld601-matter-application-development/matter-event-timer-guide.md +++ b/sld601-matter-application-development/matter-event-timer-guide.md @@ -5,7 +5,7 @@ The Matter event handler uses the FreeRTOS queue to transport a message from the producer to the consumer area. Events can be used to create asynchronous message processing or inter-task communication. -Depending on your sample app, instructions apply. See [Application Customization Models](/matter/{build-docspace-version}/matter-references/custom-matter-device/#application-customization-models). +For information about customizing app behavior, see [Extending Base App Implementation](/matter/{build-docspace-version}/matter-references/custom-matter-device/#extending-base-app-implementation). Steps to make an event work: @@ -57,8 +57,6 @@ struct AppEvent When creating an event and pushing it to the event queue at minimum, **Handler** and **Type** must be defined in order for the event to work. -### New Architecture - Custom event posting and handlers are overridden in the `CustomerAppTask` file, not in `autogen/AppTask.cpp`. ```C++ @@ -72,21 +70,6 @@ void CreateObserverEvent(void) } ``` -### Legacy Architecture - -Post events from `src/AppTask.cpp`: - -```C++ -void AppTask::CreateObserverEvent(void) -{ - AppEvent active_mode_event = {}; - active_mode_event.Type = AppEvent::kEventType_Observer; - active_mode_event.Handler = SilabsSensors::SendSensorsValues; - - sAppTask.PostEvent(&active_mode_event); -} -``` - ## Callback Observer event callback @@ -102,8 +85,6 @@ void SilabsSensors::SendSensorsValues(AppEvent * aEvent) **AppTaskMain** is dispatching all the events from the event list. -### New Architecture - ```C++ void AppTask::AppTaskMain(void * pvParameter) { @@ -137,41 +118,6 @@ void AppTask::AppTaskMain(void * pvParameter) } ``` -### Legacy Architecture - -```C++ -void AppTask::AppTaskMain(void * pvParameter) -{ - AppEvent event; - QueueHandle_t sAppEventQueue = *(static_cast(pvParameter)); - - CHIP_ERROR err = sAppTask.Init(); - if (err != CHIP_NO_ERROR) - { - SILABS_LOG("AppTask.Init() failed"); - appError(err); - } - -#if !(defined(CHIP_CONFIG_ENABLE_ICD_SERVER) && CHIP_CONFIG_ENABLE_ICD_SERVER) - sAppTask.StartStatusLEDTimer(); -#endif - - sAppTask.RegisterObserver(); - - SILABS_LOG("App Task started"); - - while (true) - { - BaseType_t eventReceived = xQueueReceive(sAppEventQueue, &event, portMAX_DELAY); - while (eventReceived == pdTRUE) - { - sAppTask.DispatchEvent(&event); - eventReceived = xQueueReceive(sAppEventQueue, &event, 0); - } - } -} -``` - ## Matter Timer ### Start @@ -188,8 +134,6 @@ chip::DeviceLayer::PlatformMgr().UnlockChipStack(); ### Callback -### New Architecture - Timer callback. Implement in `src/CustomerAppTask.cpp`. ```C++ @@ -199,15 +143,4 @@ void TestCallback(System::Layer * layer, void * aAppState) } ``` -### Legacy Architecture - -Timer callback. Implement in `src/AppTask.cpp`. - -```C++ -void AppTask::TestCallback(System::Layer * layer, void * aAppState) -{ - // Do something -} -``` - If you need a periodic timer, you can recall `StartTimer()` in the callback. diff --git a/sld601-matter-application-development/matter-scenes-quick-start-guide.md b/sld601-matter-application-development/matter-scenes-quick-start-guide.md index cd97a33..5d719e9 100644 --- a/sld601-matter-application-development/matter-scenes-quick-start-guide.md +++ b/sld601-matter-application-development/matter-scenes-quick-start-guide.md @@ -37,7 +37,7 @@ The following hands-on tutorial walks through the process of storing and recalli ### Requirements -- Simplicity SDK 2026.6.0 + Matter extension 2.9.0 (or newer) +- Simplicity SDK 2026.6.1 + Matter extension 2.9.1 (or newer) - Raspberry Pi 4 + MatterHub Image - 1x Silabs WTSK EFR32xG21 (BRD4108B) in RCP configuration - 2x [EFR32xG24-DK2601B Dev Kit](https://www.silabs.com/development-tools/wireless/efr32xg24-dev-kit?tab=overview) @@ -166,9 +166,7 @@ public: ### Step 3 Implement Callbacks -This guide uses the Lighting sample app, which is on the **new architecture** in 2.9.0. See [Application Customization Models](/matter/{build-docspace-version}/matter-references/custom-matter-device/#application-customization-models) to confirm which model your project uses. - -#### New Architecture +For information about customizing app behavior, see [Extending Base App Implementation](/matter/{build-docspace-version}/matter-references/custom-matter-device/#extending-base-app-implementation). Make the following additions to `src/CustomerAppTask.cpp`: @@ -282,87 +280,6 @@ CHIP_ERROR AppInitImpl() This initializes the LED to be white. -#### Legacy Architecture - -Make the following additions to `src/DataModelCallbacks.cpp`: - -:::collapsed{summary="Click to expand and view the DataModelCallbacks.cpp file"} -```c++ -// Color Transformer -#include "ColorTransformer.h" - -// Customer Application -#include "sl_simple_rgb_pwm_led.h" -#include "sl_simple_rgb_pwm_led_instances.h" -#include "sl_led.h" -. -. -// Initialize color mode x-y -uint16_t cx = 0xFFFF; -uint16_t cy = 0xFFFF; - -// Initialize RGB -uint16_t r = 0xFFFF; -uint16_t g = 0xFFFF; -uint16_t b = 0xFFFF; - -// Initialize xy color mode flag -bool xyFlag = false; -``` -::: - -Inside `MatterPostAttributeChangeCallback` in _src/DataModelCallbacks.cpp_, implement the on/off functionality of the LED: - -```c++ -if (clusterId == OnOff::Id && attributeId == OnOff::Attributes::OnOff::Id) - { -/* code to add */ - 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); - } -/* ----------- */ - -#ifdef DIC_ENABLE - dic_sendmsg("light/state", (const char *) (value ? (*value ? "on" : "off") : "invalid")); -#endif // DIC_ENABLE - LightMgr().InitiateAction(AppEvent::kEventType_Light, *value ? LightingManager::ON_ACTION : LightingManager::OFF_ACTION); - - - } -``` - -Use the same Color Control cluster handling as in the **New architecture** section above. - -Initialize the LED in `src/AppTask.cpp`. Add the same includes, then inside `AppTask::Init()`: - -```c++ -CHIP_ERROR AppTask::Init() -{ - CHIP_ERROR err = CHIP_NO_ERROR; - - sLightLED.Set(LightMgr().IsLightOn()); - -/* code to add */ - // Initialize LED - sl_led_init((sl_led_t *)&sl_simple_rgb_pwm_led_rgb_led0); - - // Set initial color to white and turn off - uint16_t red = 255; // max red - uint16_t green = 255; // no green - uint16_t blue = 255; // max blue - sl_led_set_rgb_color(&sl_simple_rgb_pwm_led_rgb_led0, red, green, blue); - sl_led_turn_off((sl_led_t *)&sl_simple_rgb_pwm_led_rgb_led0); -/* ----------- */ - -// Update the LCD with the Stored value. Show QR Code if not provisioned - return err; -} -``` - -This initializes the LED to be white. - ### Step 4: Build and Flash Build the project and flash the binary to as many Matter devices as you wish to have in your scene. This demo includes two lighting devices. Ensure that the devices have been flashed with a bootloader prior to flashing the application for the first time. diff --git a/sld962-matter-aws-feature/build-matter-aws-dual-stack.md b/sld962-matter-aws-feature/build-matter-aws-dual-stack.md index 92f8984..cd79375 100644 --- a/sld962-matter-aws-feature/build-matter-aws-dual-stack.md +++ b/sld962-matter-aws-feature/build-matter-aws-dual-stack.md @@ -11,7 +11,7 @@ For the standard Matter + AWS build (917 SoC or standard 917 NCP with host LwIP ## Prerequisites - A **917 NCP** Matter project or the reference example `matter_wifi_917_ncp_lock_app_dual_stack_freertos`. -- Matter Extension **2.9.0** or later, and WiseConnect SDK **4.1.0** or later installed in Simplicity Studio. +- Matter Extension **2.9.1** or later, and WiseConnect SDK **4.1.1** or later installed in Simplicity Studio. - AWS cloud configured according to [AWS installation](./aws-configuration-registration.md). - Hardware and software requirements are met as described in [Matter + AWS Prerequisites](./index.md#prerequisites). diff --git a/sld962-matter-aws-feature/matter-aws-dual-stack-overview.md b/sld962-matter-aws-feature/matter-aws-dual-stack-overview.md index 9ffb02d..63d8628 100644 --- a/sld962-matter-aws-feature/matter-aws-dual-stack-overview.md +++ b/sld962-matter-aws-feature/matter-aws-dual-stack-overview.md @@ -73,8 +73,8 @@ Standard Matter + AWS on 917 SoC and standard 917 NCP boards is documented separ ### Software -- Matter Extension **2.9.0** or later -- WiseConnect SDK **4.1.0** or later +- Matter Extension **2.9.1** or later +- WiseConnect SDK **4.1.1** or later - Correct SiWx917 NCP connectivity firmware supporting dual network stack mode ## Reference Example