[CSA-CP] Rename CLUSTER_MASK_ and ATTIBUTE_MASK defines to differentiate with …

examples/air-quality-sensor-app/linux/AirQualitySensorAppAttrUpdateDelegate.cpp

@@ -23,7 +23,6 @@
 #include <app/clusters/software-diagnostics-server/software-diagnostics-server.h>
 #include <app/clusters/switch-server/switch-server.h>
 #include <app/server/Server.h>
-#include <app/util/att-storage.h>
 #include <platform/PlatformManager.h>
 
 #include <air-quality-sensor-manager.h>

examples/all-clusters-app/linux/AllClustersCommandDelegate.cpp

@@ -26,7 +26,6 @@
 #include <app/clusters/software-diagnostics-server/software-diagnostics-server.h>
 #include <app/clusters/switch-server/switch-server.h>
 #include <app/server/Server.h>
-#include <app/util/att-storage.h>
 #include <app/util/attribute-storage.h>
 #include <platform/PlatformManager.h>
 

examples/all-clusters-app/linux/main-common.cpp

@@ -53,7 +53,6 @@
 #include <app/clusters/time-synchronization-server/time-synchronization-server.h>
 #include <app/clusters/valve-configuration-and-control-server/valve-configuration-and-control-server.h>
 #include <app/server/Server.h>
-#include <app/util/att-storage.h>
 #include <app/util/attribute-storage.h>
 #include <lib/support/CHIPMem.h>
 #include <platform/DeviceInstanceInfoProvider.h>

examples/all-clusters-minimal-app/linux/main-common.cpp

@@ -21,7 +21,6 @@
 #include <app/CommandHandler.h>
 #include <app/clusters/identify-server/identify-server.h>
 #include <app/server/Server.h>
-#include <app/util/att-storage.h>
 #include <lib/support/CHIPMem.h>
 #include <new>
 #include <platform/PlatformManager.h>

examples/bridge-app/esp32/README.md

@@ -54,10 +54,10 @@ defined:
     definition.
 
 -   All attributes defined with these macros will be configured as
-    `ATTRIBUTE_MASK_EXTERNAL_STORAGE` in the ZCL database and therefore will
-    rely on the application to maintain storage for the attribute. Consequently,
-    reads or writes to these attributes must be handled within the application
-    by the `emberAfExternalAttributeWriteCallback` and
+    `MATTER_ATTRIBUTE_FLAG_EXTERNAL_STORAGE` in the ZCL database and therefore
+    will rely on the application to maintain storage for the attribute.
+    Consequently, reads or writes to these attributes must be handled within the
+    application by the `emberAfExternalAttributeWriteCallback` and
     `emberAfExternalAttributeReadCallback` functions. See the bridge
     application's `main.cpp` for an example of this implementation.
 

examples/bridge-app/linux/README.md

@@ -45,10 +45,10 @@ defined:
     definition.
 
 -   All attributes defined with these macros will be configured as
-    `ATTRIBUTE_MASK_EXTERNAL_STORAGE` in the ZCL database and therefore will
-    rely on the application to maintain storage for the attribute. Consequently,
-    reads or writes to these attributes must be handled within the application
-    by the `emberAfExternalAttributeWriteCallback` and
+    `MATTER_ATTRIBUTE_FLAG_EXTERNAL_STORAGE` in the ZCL database and therefore
+    will rely on the application to maintain storage for the attribute.
+    Consequently, reads or writes to these attributes must be handled within the
+    application by the `emberAfExternalAttributeWriteCallback` and
     `emberAfExternalAttributeReadCallback` functions. See the bridge
     application's `main.cpp` for an example of this implementation.
 

examples/bridge-app/telink/README.md

@@ -56,10 +56,10 @@ defined:
     definition.
 
 -   All attributes defined with these macros will be configured as
-    `ATTRIBUTE_MASK_EXTERNAL_STORAGE` in the ZCL database and therefore will
-    rely on the application to maintain storage for the attribute. Consequently,
-    reads or writes to these attributes must be handled within the application
-    by the `emberAfExternalAttributeWriteCallback` and
+    `MATTER_ATTRIBUTE_FLAG_EXTERNAL_STORAGE` in the ZCL database and therefore
+    will rely on the application to maintain storage for the attribute.
+    Consequently, reads or writes to these attributes must be handled within the
+    application by the `emberAfExternalAttributeWriteCallback` and
     `emberAfExternalAttributeReadCallback` functions. See the bridge
     application's `main.cpp` for an example of this implementation.
 

examples/chef/common/clusters/switch/SwitchEventHandler.cpp

@@ -20,7 +20,6 @@
 #ifdef MATTER_DM_PLUGIN_SWITCH_SERVER
 #include <app/clusters/switch-server/switch-server.h>
 #include <app/server/Server.h>
-#include <app/util/att-storage.h>
 #include <platform/PlatformManager.h>
 
 #include "SwitchEventHandler.h"

examples/chef/common/clusters/switch/SwitchManager.cpp

@@ -21,7 +21,6 @@
 #include <app-common/zap-generated/attributes/Accessors.h>
 #include <app/clusters/switch-server/switch-server.h>
 #include <app/server/Server.h>
-#include <app/util/att-storage.h>
 #include <app/util/attribute-storage.h>
 #include <platform/PlatformManager.h>
 

examples/chef/esp32/main/main.cpp

@@ -41,7 +41,6 @@
 #include <app-common/zap-generated/callback.h>
 #include <app-common/zap-generated/cluster-objects.h>
 #include <app/server/Dnssd.h>
-#include <app/util/att-storage.h>
 #include <setup_payload/QRCodeSetupPayloadGenerator.h>
 
 #include "Display.h"

examples/fabric-bridge-app/linux/README.md

@@ -51,10 +51,10 @@ defined:
     definition.
 
 -   All attributes defined with these macros will be configured as
-    `ATTRIBUTE_MASK_EXTERNAL_STORAGE` in the ZCL database and therefore will
-    rely on the application to maintain storage for the attribute. Consequently,
-    reads or writes to these attributes must be handled within the application
-    by the `emberAfExternalAttributeWriteCallback` and
+    `MATTER_ATTRIBUTE_FLAG_EXTERNAL_STORAGE` in the ZCL database and therefore
+    will rely on the application to maintain storage for the attribute.
+    Consequently, reads or writes to these attributes must be handled within the
+    application by the `emberAfExternalAttributeWriteCallback` and
     `emberAfExternalAttributeReadCallback` functions. See the bridge
     application's `main.cpp` for an example of this implementation.
 

examples/fabric-sync/README.md

@@ -0,0 +1,185 @@
+# Matter Linux Fabric Sync Example
+
+An example application to implement the Fabric Synchronization feature and
+demonstrates the end-to-end Fabric Synchronization feature using dynamic
+endpoints.
+
+Fabric Synchronization feature will facilitate the commissioning of end devices
+from one fabric to another without requiring user intervention for every end
+device. It defines mechanisms that can be used by multiple
+ecosystems/controllers to communicate with one another to simplify the
+experience for users.
+
+This doc is tested on **Ubuntu 22.04 LTS (aarch64)**
+
+<hr>
+
+-   [Matter Linux Fabric Sync Example](#matter-linux-fabric-sync-example)
+    -   [Theory of Operation](#theory-of-operation)
+    -   [Building](#building)
+    -   [Running the Complete Example on Ubuntu](#running-the-complete-example-on-ubuntu)
+
+<hr>
+
+## Theory of Operation
+
+### Dynamic Endpoints
+
+The Fabric-Sync Example makes use of Dynamic Endpoints. Current SDK support is
+limited for dynamic endpoints, since endpoints are typically defined (along with
+the clusters and attributes they contain) in a .zap file which then generates
+code and static structures to define the endpoints.
+
+To support endpoints that are not statically defined, the ZCL attribute storage
+mechanisms will hold additional endpoint information for `NUM_DYNAMIC_ENDPOINTS`
+additional endpoints. These additional endpoint structures must be defined by
+the application and can change at runtime.
+
+To facilitate the creation of these endpoint structures, several macros are
+defined:
+
+`DECLARE_DYNAMIC_ATTRIBUTE_LIST_BEGIN(attrListName)`
+`DECLARE_DYNAMIC_ATTRIBUTE(attId, attType, attSizeBytes, attrMask)`
+`DECLARE_DYNAMIC_ATTRIBUTE_LIST_END(clusterRevision)`
+
+-   These three macros are used to declare a list of attributes for use within a
+    cluster. The declaration must begin with the
+    `DECLARE_DYNAMIC_ATTRIBUTE_LIST_BEGIN` macro which will define the name of
+    the allocated attribute structure. Each attribute is then added by the
+    `DECLARE_DYNAMIC_ATTRIBUTE` macro. Finally,
+    `DECLARE_DYNAMIC_ATTRIBUTE_LIST_END` macro should be used to close the
+    definition.
+
+-   All attributes defined with these macros will be configured as
+    `MATTER_ATTRIBUTE_FLAG_EXTERNAL_STORAGE` in the ZCL database and therefore
+    will rely on the application to maintain storage for the attribute.
+    Consequently, reads or writes to these attributes must be handled within the
+    application by the `emberAfExternalAttributeWriteCallback` and
+    `emberAfExternalAttributeReadCallback` functions. See the bridge
+    application's `main.cpp` for an example of this implementation.
+
+`DECLARE_DYNAMIC_CLUSTER_LIST_BEGIN(clusterListName)`
+`DECLARE_DYNAMIC_CLUSTER(clusterId, clusterAttrs, role, incomingCommands, outgoingCommands)`
+`DECLARE_DYNAMIC_CLUSTER_LIST_END`
+
+-   These three macros are used to declare a list of clusters for use within a
+    endpoint. The declaration must begin with the
+    `DECLARE_DYNAMIC_CLUSTER_LIST_BEGIN` macro which will define the name of the
+    allocated cluster structure. Each cluster is then added by the
+    `DECLARE_DYNAMIC_CLUSTER` macro referencing attribute list previously
+    defined by the `DECLARE_DYNAMIC_ATTRIBUTE...` macros and the lists of
+    incoming/outgoing commands terminated by kInvalidCommandId (or nullptr if
+    there aren't any commands in the list). Finally,
+    `DECLARE_DYNAMIC_CLUSTER_LIST_END` macro should be used to close the
+    definition.
+
+`DECLARE_DYNAMIC_ENDPOINT(endpointName, clusterList)`
+
+-   This macro is used to declare an endpoint and its associated cluster list,
+    which must be previously defined by the `DECLARE_DYNAMIC_CLUSTER...` macros.
+
+## Building
+
+-   For Linux host example:
+
+    ```sh
+    source scripts/activate.sh
+    ./scripts/build/build_examples.py --target linux-x64-fabric-sync-no-ble build
+    ```
+
+-   For Raspberry Pi 4 example:
+
+    Pull Docker Images
+
+    ```sh
+    docker pull ghcr.io/project-chip/chip-build-crosscompile:112
+    ```
+
+    Run docker
+
+    ```sh
+    docker run -it -v ~/connectedhomeip:/var/connectedhomeip ghcr.io/project-chip/chip-build-crosscompile:112 /bin/bash
+    ```
+
+    Build
+
+    ```sh
+    cd /var/connectedhomeip
+
+    git config --global --add safe.directory /var/connectedhomeip
+
+    ./scripts/run_in_build_env.sh \
+     "./scripts/build/build_examples.py \
+        --target linux-arm64-fabric-sync-no-ble-clang \
+        build"
+    ```
+
+    Transfer the fabric-bridge-app binary to a Raspberry Pi
+
+    ```sh
+    scp ./fabric-sync ubuntu@xxx.xxx.xxx.xxx:/home/ubuntu
+    ```
+
+## Running the Complete Example on Ubuntu
+
+-   Building
+
+    Follow [Building](#building) section of this document.
+
+-   Run Linux Fabric Sync Example App on two Linux machine E1 and E2
+
+    ```sh
+    sudo rm -rf /tmp/chip_*
+    cd ~/connectedhomeip/
+    out/debug/fabric-sync
+    ```
+
+-   Initiate the FS Setup Process from E1 to E2
+
+    ```sh
+    > app add-bridge 1 20202021 192.168.86.246 5540
+    Done
+    > New device with Node ID: 0000000000000001 has been successfully added.
+    A new device has been added on Endpoint: 2.
+    ```
+
+-   Verify Reverse Commissioning of the Fabric-Bridge from E1 on E2
+
+    ```sh
+    > New device with Node ID: 0000000000000002 has been successfully added.
+    ```
+
+-   Pair Light Example to E2
+
+    Since Fabric-Bridge also functions as a Matter server, running it alongside
+    the Light Example app on the same machine would cause conflicts. Therefore,
+    you need to run the Matter Light Example app on a separate physical machine
+    from the one hosting Fabric-Sync.
+
+    ```sh
+    > app add-device 3 <setup-pin-code> <device-remote-ip> <device-remote-port>
+    ```
+
+    After the device is successfully added, you will observe the following
+    message on E2 with the newly assigned Node ID:
+
+    ```sh
+    > New device with Node ID: 0x3 has been successfully added.
+    ```
+
+    Additionally, you should also get notified when a new device is added to E2
+    from the E1:
+
+    ```sh
+    > A new device is added on Endpoint 3.
+    ```
+
+-   Synchronize Light Example to E1
+
+    After the Light Example is successfully paired in E2, we can start to
+    synchronize the light device to E1 using the new assigned dynamic endpointid
+    on Ecosystem 2.
+
+    ```sh
+    > app sync-device <endpointid>
+    ```

examples/lighting-app-data-mode-no-unique-id/linux/LightingAppCommandDelegate.cpp

@@ -23,7 +23,6 @@
 #include <app/clusters/software-diagnostics-server/software-diagnostics-server.h>
 #include <app/clusters/switch-server/switch-server.h>
 #include <app/server/Server.h>
-#include <app/util/att-storage.h>
 #include <app/util/attribute-storage.h>
 #include <platform/PlatformManager.h>
 

examples/lighting-app/infineon/cyw30739/src/LightingManager.cpp

@@ -19,7 +19,6 @@
 
 #include "LightingManager.h"
 #include <app-common/zap-generated/attributes/Accessors.h>
-#include <app/util/att-storage.h>
 #include <stdio.h>
 
 using namespace chip;

examples/lighting-app/linux/LightingAppCommandDelegate.cpp

@@ -23,7 +23,6 @@
 #include <app/clusters/software-diagnostics-server/software-diagnostics-server.h>
 #include <app/clusters/switch-server/switch-server.h>
 #include <app/server/Server.h>
-#include <app/util/att-storage.h>
 #include <app/util/attribute-storage.h>
 #include <platform/PlatformManager.h>
 

src/app/AttributePathExpandIterator-Ember.cpp

@@ -22,7 +22,6 @@
 #include <app/ConcreteAttributePath.h>
 #include <app/EventManagement.h>
 #include <app/GlobalAttributes.h>
-#include <app/util/att-storage.h>
 #include <app/util/endpoint-config-api.h>
 #include <lib/core/CHIPCore.h>
 #include <lib/core/TLVDebug.h>
@@ -98,7 +97,7 @@ void AttributePathExpandIteratorEmber::PrepareClusterIndexRange(const AttributeP
     }
     else
     {
-        mClusterIndex = emberAfClusterIndex(aEndpointId, aAttributePath.mClusterId, CLUSTER_MASK_SERVER);
+        mClusterIndex = emberAfClusterIndex(aEndpointId, aAttributePath.mClusterId, MATTER_CLUSTER_FLAG_SERVER);
         // If the given cluster id does not exist on the given endpoint, it will return uint8(0xFF), then endClusterIndex
         // will be 0, means we should iterate a null cluster set (skip it).
         mEndClusterIndex = static_cast<uint8_t>(mClusterIndex + 1);

src/app/clusters/group-key-mgmt-server/group-key-mgmt-server.cpp

@@ -22,7 +22,6 @@
 #include <app/CommandHandler.h>
 #include <app/MessageDef/StatusIB.h>
 #include <app/server/Server.h>
-#include <app/util/att-storage.h>
 #include <app/util/attribute-storage.h>
 #include <credentials/GroupDataProvider.h>
 #include <lib/support/CodeUtils.h>

src/app/clusters/groups-server/groups-server.cpp

@@ -22,7 +22,6 @@
 #include <app-common/zap-generated/ids/Clusters.h>
 #include <app/CommandHandler.h>
 #include <app/reporting/reporting.h>
-#include <app/util/att-storage.h>
 #include <app/util/config.h>
 #include <credentials/GroupDataProvider.h>
 #include <inttypes.h>
@@ -339,7 +338,7 @@ bool emberAfGroupsClusterRemoveAllGroupsCallback(app::CommandHandler * commandOb
         }
         iter->Release();
         ScenesManagement::ScenesServer::Instance().GroupWillBeRemoved(fabricIndex, commandPath.mEndpointId,
-                                                                      ZCL_SCENES_GLOBAL_SCENE_GROUP_ID);
+                                                                      ScenesManagement::ScenesServer::kGlobalSceneGroupId);
     }
 #endif
 

src/app/clusters/mode-select-server/mode-select-server.cpp

@@ -24,7 +24,6 @@
 #include <app/CommandHandler.h>
 #include <app/ConcreteCommandPath.h>
 #include <app/clusters/mode-select-server/supported-modes-manager.h>
-#include <app/util/att-storage.h>
 #include <app/util/attribute-storage.h>
 #include <app/util/config.h>
 #include <app/util/odd-sized-integers.h>

src/app/clusters/on-off-server/on-off-server.cpp

@@ -667,8 +667,9 @@ bool OnOffServer::offWithEffectCommand(app::CommandHandler * commandObj, const a
         if (globalSceneControl)
         {
 #ifdef MATTER_DM_PLUGIN_SCENES_MANAGEMENT
-            ScenesManagement::ScenesServer::Instance().StoreCurrentScene(fabric, endpoint, ZCL_SCENES_GLOBAL_SCENE_GROUP_ID,
-                                                                         ZCL_SCENES_GLOBAL_SCENE_SCENE_ID);
+            ScenesManagement::ScenesServer::Instance().StoreCurrentScene(fabric, endpoint,
+                                                                         ScenesManagement::ScenesServer::kGlobalSceneGroupId,
+                                                                         ScenesManagement::ScenesServer::kGlobalSceneId);
 #endif // MATTER_DM_PLUGIN_SCENES_MANAGEMENT
             OnOff::Attributes::GlobalSceneControl::Set(endpoint, false);
         }
@@ -723,8 +724,8 @@ bool OnOffServer::OnWithRecallGlobalSceneCommand(app::CommandHandler * commandOb
     }
 
 #ifdef MATTER_DM_PLUGIN_SCENES_MANAGEMENT
-    ScenesManagement::ScenesServer::Instance().RecallScene(fabric, endpoint, ZCL_SCENES_GLOBAL_SCENE_GROUP_ID,
-                                                           ZCL_SCENES_GLOBAL_SCENE_SCENE_ID);
+    ScenesManagement::ScenesServer::Instance().RecallScene(fabric, endpoint, ScenesManagement::ScenesServer::kGlobalSceneGroupId,
+                                                           ScenesManagement::ScenesServer::kGlobalSceneId);
 #endif // MATTER_DM_PLUGIN_SCENES_MANAGEMENT
 
     OnOff::Attributes::GlobalSceneControl::Set(endpoint, true);