Matter fabric removal

When a Matter device is commissioned by the Matter controller, it then belongs to a specific Matter fabric. To ensure the interoperability of multiple applications and ecosystems, the device can join the Matter fabrics created by multiple ecosystems using the multi-fabric feature. As a result, the device can belong to multiple fabrics and can be managed by multiple Matter controllers.

To remove the device from a fabric, a Matter controller sends the leave request to it and then removes all information collected from the device. The device receives the leave request and removes all information about the fabric it is leaving.

Reaction to the last Matter fabric removal

When a device leaves the last Matter fabric it has joined, the network credentials and saved data are no longer usable. You can define a reaction to the last fabric removal and decide whether the device should use one of the predefined behaviors, or you can implement custom scenarios.

Predefined last fabric removal behaviors

There are four predefined reactions to the last fabric removal available in the Matter samples. All behaviors are implemented as a delegation for the Fabric Table module, and the chosen reaction is run as a callback on each fabric removal.

To enable the predefined behavior in your specific sample based on the Matter samples in the nRF Connect SDK, complete the following steps:

  1. Include the fabric_table_delegate.h header file in the app_task.cpp project file:

    #include "fabric_table_delegate.h"

  2. Call the AppFabricTableDelegate::Init method after the chip::Server::GetInstance().Init(initParams) invocation within the AppTask::Init method in the app_task.cpp project file:

    AppFabricTableDelegate::Init();

For more information, see the fabric_table_delegate.h header file which is located in the Matter samples common directory.

You can choose one of the following reactions to the last fabric removal and instruct the device to:

  • Not react to the last fabric removal and keep the current state of the device.

  • Remove the network credentials, and keep application-specific non-volatile data.

  • Remove the network credentials, keep application-specific non-volatile data, and then reboot.

  • Remove all stored non-volatile data (both network credentials and application-specific data) and reboot.

  • Remove the network credentials, keep application-specific non-volatile data, and start advertising Bluetooth LE Matter service.

To read more about the reactions to the last fabric and learn how to set the related Kconfigs, see the Advanced Matter Kconfig options page.

Custom last fabric removal delegate

In some cases, the predefined reactions to the last fabric removal are not enough. For example, only one of the predefined scenarios includes removing application-specific non-volatile data, but it also requires rebooting the device. If the predefined reactions do not meet your requirements, you can define a custom reaction to the last fabric removal.

To implement a custom reaction you need to define a new delegation for the Fabric Table module. The Fabric Table module is defined in the Matter stack and is responsible for managing the Matter fabrics to which the device belongs. The module stores a list of the delegations and each registered one will be called when the device leaves a Matter fabric. You can define multiple delegations, but you need to disable the predefined one.

Disabling the predefined reaction

To disable the predefined reaction to the last fabric removal, set the CONFIG_CHIP_LAST_FABRIC_REMOVED_NONE Kconfig option to y.

Implementing the custom Fabric Table delegation

To implement the custom Fabric Table delegation, complete the following points:

  • Include the app/util/attribute-storage.h file from the Matter stack core.

    #include <app/util/attribute-storage.h>

  • Implement a class that inherits chip::FabricTable::Delegate and contains an overridden OnFabricRemoved method from the base class.

    class AppFabricTableDelegate : public chip::FabricTable::Delegate {

   private:

      void OnFabricRemoved(const chip::FabricTable &fabricTable, chip::FabricIndex fabricIndex) {}

};

  • Implement a reaction on the last fabric removal within the body of the OnFabricRemoved method.

  • Call the chip::Server::GetInstance().GetFabricTable().AddFabricDelegate method of the Fabric Table module in the AppTask.Init method, and provide the newly created class of delegation as an argument. The new delegation will be added to the delegation table and allows you to call the overridden OnFabricRemoved method when the last fabric is going to be removed.

Note

Not all actions implemented in the OnFabricRemoved can be called directly from the method body, and should be delegated to be done in Zephyr thread of Matter. This is because the device needs to confirm the removal of the fabric and send the acknowledgment to the Matter controller. To postpone running the chosen action, delegate its invocation to the Zephyr thread of Matter using the chip::DeviceLayer::PlatformMgr().ScheduleWork method. If the device doesn’t complete all activities that need to be done before clearing non-volatile storage, use a timer to delay the action execution.

To see an example implementation of the Fabric Table delegation, see the fabric_table_delegate.h file which is located in the Matter samples common directory.