讀取交易
與節點互動時，其中一個最先遇到的用途是從另一個節點讀取屬性，例如感應器中的溫度值。在這種互動中，必須執行的第一個動作是「讀取要求動作」。Matter
讀取要求動作
方向：發起者 -> 目標
在這個動作中，發起者會查詢目標，並提供下列資訊：
- 屬性要求：零或多個目標屬性的清單。這份清單由零或多個路徑組成，指向目標要求的屬性。
- 事件要求：零或多個路徑清單，指向目標要求的事件。
目標收到「讀取要求動作」後，會組裝內含所要求資訊的「報表資料動作」。
報表資料動作
方向：目標 -> 啟動器
在此動作中，目標會回應：
- 屬性報表：零或多個所回報的屬性清單，這些屬性是在讀取動作要求中要求。
- 事件報表：零或多個回報事件的清單。
- 抑制回應：這個旗標會決定是否要抑制對這項動作的狀態回應。
- 訂閱 ID：如果這份報表是訂閱交易的一部分，則必須包含用於識別訂閱交易的整數。
狀態回應動作
方向：目標 -> 啟動器或啟動器 -> 目標
發起者收到要求的資料後，預設必須產生狀態回應動作。這項動作會從發起者傳送，確認已收到回報的資料。如果設定了「Suppress Status Response」旗標，發起者就不得傳送狀態回應動作。
發起者傳送「狀態回應動作」，或發起者收到「報表資料動作」且已啟用「禁止回應」旗標後，讀取/報表查詢就會完成。
狀態回應動作只包含 status 欄位，用於確認作業成功或顯示失敗代碼。
讀取限制
「讀取要求動作」和「報表資料動作」為Unicast專用，而且這些要求的路徑可能無法指定節點群組。
狀態回覆動作為 Unicast-only，無法做為群播的回覆產生。
訂閱交易
訂閱要求動作
方向：發起者 -> 目標
除了單一的讀取要求動作，發起者也可以訂閱屬性或事件的定期更新。因此，在訂閱交易之後，定期資料更新可能會產生相同的報表資料動作。
訂閱互動會在兩個節點之間建立關係，其中目標會定期產生報表資料動作，傳送給發起者。發起者是「訂閱者」，目標則是「發布者」。
訂閱要求動作包含：
- 間隔下限：報表間隔下限。
- 間隔時間上限：報表間隔時間上限。
- 屬性報表：零或多個在讀取動作要求中要求的已回報屬性清單。
- 事件報表：零或多個回報事件的清單。
在「訂閱要求」之後，目標會以「報告資料動作」回應發起者，其中包含第一批回報資料：已準備發布的資料。
發起者接著會傳送「狀態回應動作」給目標，確認「報表資料動作」。目標收到「狀態回應動作」後，如果回報沒有錯誤，就會傳送「訂閱回應動作」。
目標隨後會以協商間隔定期傳送「報表資料動作」，而發起者會回應這些動作，直到訂閱項目遺失或取消為止。
訂閱回覆動作
方向：目標 -> 啟動器
這是訂閱交易的最後一個動作，並結束程序。It includes:
- 訂閱 ID：用於識別訂閱項目的整數。
- 最短間隔：報告間隔的最終決定下限。
- 時間間隔上限：報表間的最終決定時間間隔上限。
訂閱限制
- 「訂閱要求動作」和「訂閱回應動作」是 Unicast 專用動作。
- 訂閱互動中的所有報表資料動作都必須具有相同的訂閱 ID。
- 如果訂閱者在動作之間的最大協商間隔內未收到 Report Data Action，訂閱就會終止。
- 根據先前的規則，發布商只要停止傳送定期報表資料動作，即可終止訂閱互動。
- 訂閱者可以透過
INACTIVE_SUBSCRIPTION狀態碼回應「Report Data Action」，終止訂閱互動。