Chapter 8. Interaction Model Specification
8.1. Practical Information
8.1.1. Revision History
Revision | Description |
1-9 | Released as versions of the Zigbee Cluster Library chapter 2 which combined the interac tion model with encoding |
10 | Initial Release of this specification |
8.1.2. Scope & Purpose
This is part of a package of Data Model specifications that are agnostic to underlying layers (encod ing, message, network, transport, etc.). Each specification below may be independently maintained. This package, as a whole, shall be independently maintained as agnostic and decoupled from lower layers. This package may be referenced by inclusion in vertical protocol stack specifications.
Data Model Defines first order elements and namespace for endpoints, clusters, attributes, data types, etc.
Interaction Model Defines interactions, transactions and actions between nodes.
System Model Defines relationships that are managed between endpoints and clusters.
Cluster Library Reference library of cluster specifications.
Device Library Reference library of devices type definitions.
8.1.3. Origin Story
The original baseline for this section comes from the Zigbee Cluster Library [ZCL] Chapter 2 relat ing to ZCL commands and interactions. This specification addresses these gaps determined by the Data Model Tiger Team:
- Multi-Element Message support
- Synchronized Reporting
- Reduce message types (commands & actions)
- Complex data type support in all messages
- Events
- Interception attack
8.1.4. Purpose
The purpose is to define a layer that abstracts interactions from other layers, including security, transport, message format & encoding. The intent is that this document will align with current clus ter specifications in the ZCL (revision 8 at this time), and still support cluster evolution over time.
8.1.5. Glossary
Term | Short | Spec Details | Description |
Wildcardable | A | this spec | able to indicate all cur rent instances of the data |
Optional | O | Data Model | only required for some action behavior |
Quality | Qual, Q | Data Model | quality of information in an information block |
Action Flow | this spec | direction flow of actions | |
Path | this spec | a path to an element (see Path) | |
Group Path | this spec | a path with a group ID instead of node ID and endpoint number (see Group Path) | |
Wildcard Path | this spec | a path with one or more elements that are wildcards (see Wild card Path) | |
Attribute Path | this spec | a path to an attribute data field path for attribute data (see Attribute Path) | |
Request Path | this spec | a path that may be a group or wildcard path (see Request Path) | |
Concrete Path | this spec | a path that is not a group or wildcard path (see Concrete Path) | |
Existent Path | this spec | a concrete path that exists on a server clus ter (see Existent Path) |
Term | Short | Spec Details | Description |
Supported | Data Model | the indicated element is supported by the imple mented instance | |
Unsupported | Data Model | the indicated element is not supported by the implemented instance |
8.1.6. Conventions & Conformance
Please see the Data Model specification.
8.2. Concepts
Relationships between devices are established using data model elements and interactions defined here. Please see the System Model specification for more information.
An interaction is a sequence of transactions. A transaction is a sequence of actions.
An action is a single logical communication from a source node to one or more destination nodes. An action is conveyed by one or more messages.
The actual construction and encoding of messages is left to the message layer, which is the layer below this layer.
- The protocol layers below this layer MAY have constraints that only support a subset of the functionality described
Examples:
• A client may choose Read interactions instead of Subscribe interactions. • A client may choose to not Write or Invoke commands. |
8.2.1. Path
A path is used to indicate one or more element instances in the data model. The path has the form as described in Augmented Backus–Naur:
<path> ::= <target> <cluster> <cluster element> <target> ::= <group target> | <endpoint target> <group target> ::= <group ID> <endpoint target> ::= <node> <endpoint> <endpoint> ::= <wildcard endpoint> | <concrete endpoint> <cluster> ::= <wildcard cluster> | <concrete cluster> <cluster element> ::= <attribute> | <event> | <command> |
An Attribute Path is a path indicating an <attribute>. A Command Path is a path indicating a <command>.
An Event Path is a path indicating an <event>.
8.2.1.1. Concrete Path
- A concrete path SHALL NOT have group IDs or
- A concrete path SHALL indicate a single element instance that is either:
- an event with the path ending in an event ID
- a command with the path ending in a command ID
- an attribute with the path ending in an attribute ID
- a struct field with the path ending in a field ID
- a list entry with the path ending in a list entry
8.2.1.2. Existent Path
- An existent path is a concrete path that indicates a single existing instance on the node indi cated in the
8.2.1.3. Group Path
A group path is a path that targets endpoints that are members of a group, using group ID, instead of indicating a node and endpoint.
- A group path SHALL resolve into zero or more
- A group path SHALL include a group ID that indicates zero or more endpoints that are members of the
- A group path MAY include a wildcard cluster indication and therefore also be a Wildcard Path.
8.2.1.4. Wildcard Path
A wildcard path is a path with a wildcard endpoint indication and/or wildcard cluster indication.
- A wildcard path SHALL resolve into zero or more
- A wildcard path SHALL indicate zero or more element
- A wildcard path MAY include a group ID and therefore also be a Group Path.
8.2.1.5. Request Path
A request path is used in actions that request data model elements.
- A request path SHALL be either a concrete path, a group path or a wildcard
8.2.1.6. Request Path Expansion
Many actions specify this process step to expand a request path into a list of existent paths. This process does not check access qualities, such as read or write access, privileges, or fabric qualities.
- If the path is a Group Path, it SHALL be replaced with a list of paths, one for each endpoint that is a member of the group on the target
- Else the list SHALL be the
- Each path in the list that is a Wildcard Path SHALL be replaced with a complete list of existent paths, which are the permutations from substituting the wildcarded elements with existent ele ments.
This process produces zero or more existent paths.
8.2.1.7. Attribute Path
An attribute path is used to indicate all or part of a cluster attribute. An attribute path may indicate deeper parts of collection type data.
Associated Information Block: AttributePathIB
If the attribute data type is a collection data type, such as a struct or list, then the path may indicate deeper nested parts of the data.
The nesting of collection data is conceptually unlimited, but the actual structure of the data is well- defined in the cluster specification. Attribute data structures are similar to data structures sup ported in a programming language (see Data Types in the Data Model specification). An attribute path is conceptually similar to the path or dot notation used to reference programming language data structures.
A field ID for structure data or an entry index for list data are currently the only options in an attribute path, after the attribute ID itself.
- The <attribute> component of an attribute path SHALL have the following form:
* <nesting level> occurs zero or more times as defined in a cluster specification.
The endpoint component is subject to wildcard expansion, as constrained in particular actions and contexts.
8.2.1.8. Command Path
A command path is used to indicate a cluster command. Associated Information Block: CommandPathIB
- The <command> component of a command path SHALL have the following form:
- The endpoint field is wildcardable, though this may be disallowed in the various uses of the Command Path in different actions and
8.2.1.9. Event Path
A event path is used to indicate a cluster event. Associated Information Block: EventPathIB
- The <event> component of an event path SHALL have the following form:
Please see Event for a description of a cluster event and event data fields.
The endpoint, cluster and event ID fields are wildcardable. These are further constrained in the various uses of the Event Path in different actions and contexts.
- An event path SHALL NOT be a group
8.2.2. Interaction
An interaction is a sequence of one or more transactions between nodes, that occurs in the context of an accessing fabric, or no fabric.
How a fabric, or no fabric, context is established for an interaction, is not defined here.
The first transaction (of an interaction) starts with the first action from the node called the initia tor. The first action destination is called the target, which is either a node or group. For the remain der of the interaction, the initiator remains the same.
An interaction may be a single transaction (e.g. Read). An interaction may be an unbounded num ber of transactions (e.g. Subscribe).
Interaction | Transactions | Description |
Read Interaction | Read | This interaction is a request for cluster attributes and/or event data. |
Subscribe Interaction | Subscribe, Report | This interaction subscribes to cluster attributes and/or event data. |
Write Interaction | Write | This interaction modifies clus ter attributes. |
Interaction | Transactions | Description |
Invoke Interaction | Invoke | This interaction invokes cluster commands. |
8.2.3. Transaction
A transaction is either the whole, or part of an interaction. A transaction is a sequence of one or more actions. Actions in a transaction are defined as first or following, to better describe dependen cies in this specification.
- The first action of a transaction SHALL be initiated by a single
- An action in a transaction SHALL have a target destination that is either a single node, called a unicast action or a group of nodes, called groupcast
8.2.3.1. Transaction ID
The transaction ID is a field present in all actions (see Common Action Information) that indicates the logical grouping of those actions.
- All following actions in a transaction SHALL have the same transaction ID as the first
- A groupcast action SHALL end a transaction and any subsequent action in the interaction SHALL NOT use the same transaction
The table below lists all transactions.
Transaction | Description |
Read Transaction | This transaction is a request for cluster attribute and/or event data. |
Subscribe Transaction | This transaction creates a subscription to cluster attributes and/or events. |
Report Transaction | This transaction maintains a subscription for the Subscribe interaction. |
Write Transaction | This transaction modifies cluster attributes. |
Invoke Transaction | This transaction invokes cluster commands. |
8.2.4. Action
The table below lists all actions.
Action | Description | Outgoing Message |
Status Response Action | This action is a success or error response. | Unicast |
Read Request Action | This action is a request for clus ter attribute data and/or events. | Unicast |
Action | Description | Outgoing Message |
Report Data Action | This action responds to a Read Request Action or Subscribe Request Action. | Unicast |
Subscribe Request Action | This action is a request for a subscription to cluster attribute data and/or events. | Unicast |
Subscribe Response Action | This action is a response to a Subscribe Request Action. | Unicast |
Write Request Action | This action is a request to mod ify cluster attribute data. | Unicast | Groupcast |
Write Response Action | This action responds to a Write Request Action. | Unicast |
Invoke Request Action | This action executes a cluster command. | Unicast | Groupcast |
Invoke Response Action | This action is used to respond to an Invoke Request Action with cluster defined responses. | Unicast |
Timed Request Action | This action indicates that another action will take place within a Timed interval. | Unicast |
8.2.5. Common Action Behavior
The message layer below this interaction layer encodes an action into one or more messages and delivers the messages to a destination. This interaction layer delivers action information to the mes sage layer by passing action information, through some interface (not defined here). The message layer delivers action information, from an incoming message, to this interaction layer.
In all action descriptions in this specification, action information (or information blocks), refers to the information that is transferred to and from the message layer.
There is no designation of mandatory or optional for such information because the implementation is undefined. However, some information fields may be omitted, meaning the information may not be needed for all actions.
8.2.5.1. Common Action Information
Action Field | Type | Conformance | Description |
InteractionModelRevi sion | uint8 | M | the revision number of the implemented Inter action Model specifica tion under which the sending node was certi fied |
Action | action-id | M | the action |
TransactionID | trans-id | M | the transaction ID |
FabricIndex | fabric-idx | M | the accessing fabric index, based on the ses sion used to deliver the action |
SourceNode | node-id | M | the node ID of the node that generates the action |
DestinationNode | node-id | O.a | the node ID of the desti nation where the action is sent |
DestinationGroup | group-id | O.a | the group ID of the des tination where the action is sent |
action specific | variable | M | specific action informa tion described in each action section |
- Outgoing Action
- Each generated action SHALL provide the action information above to the message
- If the action is the first action of a transaction, the TransactionID SHALL be a value that uniquely identifies the transaction on the source of the
- If the action is a following action, the TransactionID SHALL be the same as the TransactionID in the first action of the
- If the action is a unicast following action the DestinationNode SHALL be the SourceNode of the previous action in the
- The generated action information SHALL be submitted to the message
- Upon receipt of this action information, the message layer SHALL construct and convey one or more messages for this action to the
- If the message layer encounters an error that prevents the complete construction, encoding and/or conveyance of the action, then the message layer SHALL inform this layer of the error.
- If the action is not completely conveyed, the action, with the associated transaction and
interaction, SHALL terminate.
- If the failed action is NOT a Status Response action, this layer SHOULD, if possible, sub mit a Status Response action to the message layer, with a status code of FAILURE and the same
8.2.5.3. Incoming Action
- If the message layer receives a valid message for an action, it SHALL be delivered to this layer with the action information
- If this layer receives a message for an action that is not expected semantically, has invalid action information, or has an error not described in this specification, a Status Response action with an INVALID_ACTION Status Code SHALL be generated as defined in Status Response Action, and the associated transaction and interaction SHALL
- If during the receipt and decoding of messages for an action by the message layer, an error occurs that prevents a complete receipt of a valid action, then the message layer SHALL inform this layer of the
- When informed of an error from a message layer, the action, with the associated transaction and interaction, SHALL
- If the action is not able to be executed due to insufficient resources, a Status Response SHALL be sent to the initiator with a status code of either:
- PATHS_EXHAUSTED if there are not enough resources to support the number of paths in the action information,
- and the number of paths in the action exceeds the number of paths that is guaranteed to be supported for the action (see Interaction Model Limits),
- BUSY in all other recoverable resource exhausted situations (e.g. if too many Read interac tions are already in progress),
- or RESOURCE_EXHAUSTED for any other resource insufficiency,
- and the interaction SHALL be
It is implementation specific whether the message layer submits logical parts of an action to this layer as it receives and processes each message. The only requirement above is that all the informa tion, or an error, be submitted to this layer.
Global common interaction Status Codes are defined in this document in Status Codes. Cluster spe cific Status Codes are defined in each cluster specification.
8.3. Status and Interaction
There is no Status interaction, but an error status may be generated as part of any interaction.
8.3.1. Status Response Action
This action is defined as a following action for some actions, or is generated when there is an unspecified transaction or interaction error. This action conveys status to this layer or conveys sta
tus from this layer to another node. The status indicates success or an error as part of a transaction or interaction.
Please see Common Action Behavior for behavior common to all actions. The specific action infor mation for this action is shown below.
8.3.1.1. Status Response Information
Action Field | Type | Conformance | Description |
Status | status | M | a status code (see Status Codes) |
- Outgoing Status Response Action
- This action SHALL be
- This action SHALL NOT be generated in response to a
- This action SHALL be generated as specified in interactions defined
- If this action is generated with an error Status, the current transaction and interaction SHALL be
- This action SHALL only be generated with an error Status when an error occurs as a result of the immediate previous received action in the current
- This action’s DestinationNode field SHALL be the immediate previous received action’s SourceNode.
- This action’s TransactionID field SHALL be the immediate previous received action’s Transac tionID.
- If there is no well-defined Status Code for an error or exception, the Status Code of FAILURE SHALL be
8.3.1.3. Incoming Status Response Action
- Upon receipt of this action with a success Status Code, this layer SHALL consume the status and continue the current transaction and
- Upon receipt of this action with an error Status, this layer SHALL terminate the current transac tion and
- Upon receipt of this action with an error Status, this layer SHALL submit the error to the layer above.
8.4. Read Interaction
This interaction is generated when an initiator wishes to determine the value of one or more attributes or events located on a node.
8.4.1. Read Transaction
Action | Action Flow | Description |
Read Request | Initiator ⇒ Target | data report request |
Report Data | Initiator ⇐ Target | response report with data |
8.4.2. Read Request Action
Read Request action is the first action of a Read transaction (and interaction). Please see Common Action Behavior for behavior common to all actions. The specific action information for this action is shown below.
8.4.2.1. Read Request Action Information
Action Field | Type | Conformance | Description |
AttributeRequests | list[AttributePathIB] | M | a list of zero or more request paths to cluster attribute data |
DataVersionFilters | list[DataVersionFil terIB] | AttributeRequests | a list of zero or more cluster instance data versions |
EventRequests | list[EventPathIB] | M | a list of zero or more request paths to cluster events |
EventFilters | list[EventFilterIB] | EventRequests | a list of zero or more minimum event num bers per specific node |
FabricFiltered | bool | M | limits the data read within fabric-scoped lists to the accessing fabric |
- Outgoing Read Request Action
- This action SHALL be
- This action SHALL be generated as the first action in a Read
- A valid AttributePathIB for attribute data SHALL be one in the table Valid Read Attribute Paths.
- A valid EventPathIB for an event SHALL be one in the table Valid Event Paths.
- A path indicated in AttributeRequests or EventRequests SHALL NOT target a
8.4.2.3. Incoming Read Request Action
- Upon receipt of this action, this layer SHALL generate a Report Data action to the subscriber, as defined in Incoming Read Request and Subscribe Request Action Processing.
- If the Report Data was generated successfully, it SHALL be submitted to the message
8.4.3. Report Data Action
This action is either a first action in a Report transaction (as part of a Subscribe interaction), or a following action to a Read Request action or Subscribe Request action.
Please see Common Action Behavior for behavior common to all actions. The specific action infor mation for this action is shown below.
8.4.3.1. Report Data Action Information
Action Field | Type | Conformance | Description |
SuppressResponse | bool | M | do not send a response to this action |
SubscriptionId | uint32 | O | a SubscriptionId only used in a Subscribe interaction |
AttributeReports | list[AttributeReportIB] | O | a list of zero or more attribute data reports |
EventReports | list[EventReportIB] | O | a list of zero or more event reports |
- Incoming Read Request and Subscribe Request Action Processing
- Each path indicated by the Report Data action SHALL be a Concrete Path.
- Upon receipt of a Read Request action or Subscribe Request action, this process SHALL be fol lowed:
- Each request path in the AttributeRequests field SHALL be processed as follows:
- If the path does not conform to Valid Read Attribute Paths then:
- a Status Response with the INVALID_ACTION Status Code SHALL be generated as defined in Status Response Action,
- a Report Data action SHALL NOT be generated,
- and this interaction and process SHALL
- Else if the path is a concrete path:
- If the path indicates a node that is unsupported, an AttributeStatusIB SHALL be gener ated with the UNSUPPORTED_NODE Status
- Else if the path indicates an endpoint that is unsupported, an AttributeStatusIB SHALL be generated with the UNSUPPORTED_ENDPOINT Status
- Else if the path indicates a cluster that is unsupported, an AttributeStatusIB SHALL be generated with the UNSUPPORTED_CLUSTER Status
- Else if the path indicates an attribute or attribute data field that is unsupported, an AttributeStatusIB SHALL be generated with the UNSUPPORTED_ATTRIBUTE Status Code
with the Path field indicating the first unsupported data field (not the entire attribute data path).
- Else if the path indicates attribute data that is not readable, an AttributeStatusIB SHALL be generated with the UNSUPPORTED_READ Status
- Else if reading from the attribute in the path requires a privilege that is not granted to access the cluster in the path, an AttributeStatusIB SHALL be generated with the UNSUP PORTED_ACCESS Status
- If an AttributeStatusIB was generated, the path SHALL be
- Else perform Request Path Expansion and process each expanded existent path as follows:
- If the path indicates attribute data that is not readable, then the path SHALL be dis
- Else if reading from the attribute in the path requires a privilege that is not granted to access the cluster in the path, then the path SHALL be
- If no error free existent paths remain, then AttributeRequests are considered
- Else each remaining error free existent path is processed as follows:
- If the DataVersionFilters field indicates DataVersionFilterIB entries with a Path field that matches the path, where all matching entries have a DataVersion field that matches the data version of the cluster instance in the path, then the path SHALL be ignored
- Else If the attribute in the path is a fabric-scoped list:
- If the FabricFiltered parameter is true, an AttributeDataIB SHALL be generated with the Data as a fabric-filtered list of entries, and the Path SHALL be the path being
- Else if the FabricFiltered parameter is false, an AttributeDataIB SHALL be generated with the Data as a list of entries, with each entry indicated as a fabric-sensitive struct, and the Path SHALL be the path being
- Else an AttributeDataIB SHALL be generated with the Data and Path as indicated by the path being
- Each AttributeDataIB or AttributeStatusIB generated from processing AttributeRequests SHALL be added to the AttributeReports action field in the Report Data
- Each request path in the EventRequests field SHALL be processed as follows:
- If the path is a concrete path:
- If the path indicates a cluster event that is not supported, an EventStatusIB SHALL be generated with the UNSUPPORTED_EVENT Status
- Else if reading the event in the path requires a privilege that is not granted to access the cluster in the path, an EventStatusIB SHALL be generated with the UNSUPPORTED_AC CESS Status
- If an EventStatusIB was generated, the path SHALL be
- Else if the path does not conform to Valid Event Paths then:
- a Status Response with the INVALID_ACTION Status Code SHALL be generated as defined in Status Response Action,
- If the path is a concrete path:
- a Report Data action SHALL NOT be generated,
- and this interaction and process SHALL
- Else perform Request Path Expansion and process each expanded existent path as follows:
- If reading the event in the path requires a privilege that is not granted to access the clus ter in the path, then the path SHALL be
- If no error free existent paths remain, then EventRequests are considered
- Else for each unique node indicated in the remaining existent paths:
- Each event record currently queued in the node, in order from lowest to highest event num ber, SHALL generate an EventDataIB except for any of the following:
- If the node indicated matches the Node information field of an EventFilterIB from Event Filters, and the event number is less than the EventMin field in the EventFilterIB.
- If the event record path does not match a path in the remaining existent event
- If the event record path is fabric-sensitive, and the associated fabric does not match the accessing fabric.
- Each information block generated from processing EventRequests SHALL be added to the EventReports action field in the Report Data
- Each event record currently queued in the node, in order from lowest to highest event num ber, SHALL generate an EventDataIB except for any of the following:
- If this action is in response to a Subscribe Request action,
- If both AttributeRequests and EventRequests are empty
- a Status Response Action with the INVALID_ACTION Status Code SHALL be sent to the initiator,
- a Report Data action SHALL NOT be generated,
- and the interaction and process SHALL
- Else a SubscriptionId which uniquely identifies this subscription on the publisher SHALL be indicated in the Report Data action
- If both AttributeRequests and EventRequests are empty
- Else the SubscriptionId SHALL be
8.4.3.3. Outgoing Report Data Action
- This action SHALL be
- This action MAY have an empty list of AttributeReports and/or
- This action SHALL NOT include any nested attribute data field or nested event data field that is defined as fabric-sensitive, if the associated fabric for that field does not match the accessing fabric for the
- SuppressResponse MAY be set to TRUE for a Report Data action that initiates a Report transac tion that conveys an empty list of AttributeReports and EventReports, otherwise:
- SuppressResponse SHALL be set to TRUE for a Report Data action that is part of a Read
- SuppressResponse SHALL be set to FALSE for a Report Data action that is part of a Subscribe
- This action SHALL be generated as either:
- part of a Read transaction in direct response to a Read Request
- part of a Subscribe transaction in direct response to a Subscribe Request
- part of a Subscribe interaction as the first action of each synchronized Report Transaction.
8.4.3.4. Incoming Report Data Action
- Upon receipt of this action, if SuppressResponse is TRUE, a response SHALL NOT be generated;
- Otherwise a Status Response Action SHALL be generated with a status code of
- SUCCESS to continue the interaction,
- INVALID_SUBSCRIPTION if the action is part of a Subscribe interaction and the Subscrip tionID is invalid,
- FAILURE to terminate the interaction,
- The Status Response Action SHALL be submitted to the message layer to deliver to the source of this
8.5. Subscribe Interaction
The Subscribe interaction is composed of these transactions:
Transaction | Description |
Subscribe | start and prime a reporting session |
Report | synchronized Report transaction |
more reports | continuous Report transactions for the life of the subscription |
This interaction allows a subscriber to create a subscription with a publisher on another node for the purposes of receiving data reports from that publisher thereafter, for the duration of the sub scription. This allows the subscriber to maintain a coherent snapshot, or twin, of the subscription data as it currently exists on the publisher. The session itself is kept synchronized on both sides through the receipt of timely data reports with the intervals defined by a negotiated maximum interval subscription parameter.
This interaction is started when the initiator (or subscriber), wishes to subscribe to one or more attributes or events located on a target node (the publisher). The attribute data and events requested in the Subscribe transaction are the subscription data.
This interaction starts by creating a subscription with a Subscribe transaction, which primes the subscriber with initial subscription data. The rest of the subscription is a sequence of Report trans actions initiated by the publisher as defined by parameters of the subscription. Each Report trans action in a subscription reports changes to the subscription data.
To keep the subscription alive, a Report transaction is sent from the publisher every maximum interval, or possibly more frequently.
Report transactions from the publisher are rate limited by the minimum interval subscription para meter, as negotiated between the subscriber and publisher.
The Subscribe Request action provides boundary values (floor or ceiling) for the publisher to deter mine the final minimum and maximum interval parameters of the subscription. The time units for these intervals are seconds.
Each Subscribe interaction is a subscription that is identified by a Subscription ID as generated by the publisher.
- The Subscribe interaction SHALL start with one Subscribe transaction followed by a periodic sequence of Report transactions (see Report Transaction).
- A Report transaction SHALL be initiated by a Report Data action as part of an active subscrip tion for a Subscribe
- All Report Data actions in a Subscribe interaction SHALL have the same SubscriptionId parame ter value that uniquely identifies the interaction among all subscriptions on the
- Each Report transaction in a subscription SHALL report the path for each delta change in the subscription data, including the attribute data that has changed and/or the event that has occurred, since the last Report transaction, with the exception of attribute data with the Changes Omitted quality.
- Each Report transaction initiated by the publisher SHALL complete successfully before another Report transaction is initiated by the
- Each Report transaction SHALL NOT be initiated by the publisher until the minimum interval has expired since the last Report transaction in the
- Attribute changes SHALL be delivered as soon as possible, taking into account the minimum interval.
- Events SHALL always be queued and buffered. Each Report containing events SHALL deliver queued events without reordering the queue. Queued events MAY be opportunistically deliv ered whenever some other activity triggers a Report transaction. Absent any such triggers, queued events SHALL be delivered in a Report transaction generated at the maximum
- When the IsUrgent flag is FALSE or absent for a subscription’s event path in the EventPathIB, event queueing does not automatically trigger a Report
- When the IsUrgent flag is TRUE for a subscription’s event path in the EventPathIB, the queueing of such an event SHALL trigger a Report transaction for the subscription, subject to all Report transaction rules. This Report transaction will report the events that have been queued by the time the Report transaction
- If the subscriber does not receive a Report transaction within the maximum interval from the last Report Data, the subscriber SHALL terminate the Subscribe
- If a node receives a Report Data action with an inactive SubscriptionId, a Status Response action SHALL be sent with an INVALID_SUBSCRIPTION Status
- If, in response to a Report Data action, the publisher receives a Status Response action with a status code that is not SUCCESS, the publisher SHALL terminate the Subscribe
- If the publisher does not receive a Status Response action in response to a Report Data action
with SuppressResponse set to FALSE, the publisher MAY terminate the Subscribe interaction or SHALL re-synchronize the subscription in the next Report Data transaction by:
- Including all subscription data to re-prime the subscription, or
- Including all deltas since the last successful Report Data
- The subscriber MAY terminate the subscription and interaction by responding with a Status Response action with an INVALID_SUBSCRIPTION Status
- The publisher MAY terminate the subscription and interaction by not generating a Report trans action within the maximum
- When a Subscribe interaction is terminated on the publisher or subscriber, the subscription, identified by a SubscriptionId, SHALL also be
8.5.1. Subscribe Transaction
Action | Action Flow | Description |
Subscribe Request | Initiator ⇒ Target | list of event and attribute data identifiers supported on a server cluster |
Report Data | Initiator ⇐ Target | primed published data |
Status Response | Initiator ⇒ Target | success, or otherwise an error to terminate the subscription |
Subscribe Response | Initiator ⇐ Target | provides subscription parame ters |
8.5.2. Subscribe Request Action
Subscribe Request action is a first action. Please see Common Action Behavior for behavior com mon to all actions. The specific action information for this action is shown below.
8.5.2.1. Subscribe Request Action Information
Action Field | Type | Conformance | Description |
KeepSubscriptions | bool | M | false to terminate exist ing subscriptions from initiator |
MinIntervalFloor | uint16 | M | the requested mini mum interval bound ary floor in seconds |
MaxIntervalCeiling | uint16 | M | the requested maxi mum interval bound ary ceiling in seconds |
Action Field | Type | Conformance | Description |
AttributeRequests | list[AttributePathIB] | O | a list of zero or more request paths to cluster attribute data |
DataVersionFilters | list[DataVersionFil terIB] | AttributeRequests | a list of zero or more cluster instance data versions |
EventRequests | list[EventPathIB] | O | a list of zero or more request paths to cluster events |
EventFilters | list[EventFilterIB] | EventRequests | a list of zero or more minimum event num bers per specific node |
FabricFiltered | bool | M | limits the data read within fabric-scoped lists to the accessing fabric |
- Outgoing Subscribe Request Action
- This action SHALL initiate a Subscribe
- A Subscribe Request action SHALL be unicast from the subscriber to the
- This action SHALL be generated to initiate a Subscribe interaction (see Subscribe Interaction).
- This action SHALL include a requested ceiling (highest) maximum interval value as MaxInter valCeiling.
- This action SHALL include a requested floor (lowest) minimum interval value as MinInter valFloor.
- At least one attribute or event SHALL be indicated in the
- A valid AttributePathIB SHALL be one in the table Valid Read Attribute Paths.
- A valid EventPathIB SHALL be one in the table Valid Event Paths.
- A path indicated in AttributeRequests or EventRequests SHALL NOT target a
8.5.2.3. Incoming Subscribe Request Action
- If KeepSubscriptions is FALSE, all existing or pending subscriptions on the publisher for this subscriber SHALL be
- This layer SHALL process the Subscribe Request action as defined in Incoming Read Request and Subscribe Request Action Processing.
8.5.3. Subscribe Response Action
Subscribe Response action is the last following action in a Subscribe Transaction. This action acti vates the subscription. Please see Common Action Behavior for behavior common to all actions. The
specific action information for this action is shown below (see Subscribe Interaction).
8.5.3.1. Subscribe Response Action Information
Action Field | Type | Conformance | Description |
SubscriptionId | uint32 | M | identifies the subscrip tion |
MaxInterval | uint16 | M | the final maximum interval for the sub scription in seconds |
- Outgoing Subscribe Response Action
- Upon receipt of a successful Status Response action from the subscriber for the Report Data action that primes the subscription, this action SHALL be generated and submitted to the mes sage layer to send to the
- This action SHALL be
- The SubscriptionId value SHALL be the same as the one used in Report Data generated to prime this
- The publisher SHALL compute an appropriate value for the MaxInterval field in the action. This SHALL respect the following constraint: MinIntervalFloor ≤ MaxInterval ≤ MAX(SUBSCRIPTION_ MAX_INTERVAL_PUBLISHER_LIMIT, MaxIntervalCeiling)
- Upon sending a Subscribe Response action, the subscription, as indicated by the SubscriptionId, SHALL become active on the publisher with a min interval equal to the requested MinInter valFloor and a max interval equal to the MaxInterval field in the
8.5.3.3. Incoming Subscribe Response Action
- Upon receipt of a Subscribe Response action, the subscription, as indicated by the Subscrip tionId, SHALL become active to the
8.5.3.4. Subscription Activation
- The paths to the subscription data SHALL only be error free existent paths generated from processing the Subscribe
The EventFilters and DataVersionFilters fields in the Subscribe Request are one time parameters for the priming of the subscription.
- Subsequent ReportData actions, as part of the subscription, SHALL include the latest:
- EventNo associated with each node generating new
- DataVersion associated with each cluster where there are data
- The FabricFiltered parameter from the Subscribe Request SHALL remain in effect for all data reported during the
- Upon subscription activation, the minimum and maximum interval parameters SHALL take
effect to determine the timing and expectation of subsequent Report transactions.
8.6. Report Transaction
There is no Report interaction. A Report transaction is part of a Subscribe interaction. Please see Subscribe Interaction for details.
The valid Report transactions are:
8.6.1. Report Transaction Non-Empty
Action | Action Flow | Description |
Report Data | Initiator ⇐ Target | report of data and/or events with SuppressResponse set to FALSE |
Status Response | Initiator ⇒ Target | an error ends the interaction |
Action | Action Flow | Description |
Report Data | Initiator ⇐ Target | report with no data or events with SuppressResponse set to TRUE |
8.7. Write Interactyion
This interaction is started when an initiator wishes to modify the values of one or more attributes located on one or more nodes. An optional Timed Request action defines a Timeout interval that starts at the sending of the Status Response action.
8.7.1. Write Transaction
- A Write interaction SHALL consist of one of the transactions shown
8.7.1.1. Timed Write Transaction
Action | Action Flow | Description |
Timed Request | Initiator ⇒ Target | time interval defined to send Write Request action |
Status Response | Initiator ⇐ Target | confirmation |
Write Request | Initiator ⇒ Target | data to modify |
Write Response | Initiator ⇐ Target | with errors or success from Write Request action |
- Untimed Write Transaction
Action | Action Flow | Description |
Write Request | Initiator ⇒ Target | data to modify |
Write Response | Initiator ⇐ Target | with errors or success from Write Request action |
- If there is a preceding successful Timed Request action, the following Write Request action SHALL be received before the end of the Timeout
- If there is a preceding successful Timed Request action, the Timeout interval SHALL start when the Status Response action acknowledging the Timed Request action with a success code is
- If there is a preceding successful Timed Request action, the Write Request action SHALL be uni cast.
- If there is not a preceding successful Timed Request action, the Write Request action MAY be groupcast.
- A client MAY choose to use a Timed Write transaction even if the attribute does not have the Timed Interaction
- The server SHALL support a Timed Write transaction for all writeable
8.7.2. Write Request Action
This action is either the first action of the Write transaction or it follows a successful Timed Request action. Please see Common Action Behavior for behavior common to all actions. The specific action information for this action is shown below.
8.7.2.1. Write Request Action Information
Action Field | Type | Conformance | Description |
SuppressResponse | bool | M | do not send a response to this action |
TimedRequest | bool | M | flag action as part of a timed write transaction |
WriteRequests | list[AttributeDataIB] | M | a list of one or more path and data tuples. |
- Outgoing Write Request Action
- This action SHALL be generated as the first action in a Write transaction, or following a Timed Request action and successful Status Response
- If this action is part of a Timed Write transaction, TimedRequest SHALL be TRUE, else
- If not part of a Timed Write transaction, this action MAY be
- If this action is groupcast, SuppressResponse SHALL be
8.7.2.3. Incoming Write Request Action
- If this action is not able to be executed because the maximum supported number of Write inter actions is already in progress, then a Status Response action with the BUSY Status Code SHALL be submitted to the message layer and this interaction SHALL
- If this action is part of a Timed Write transaction, and the Timeout has expired from the preced ing Timed Request action, then a Status Response action with the TIMEOUT Status Code SHALL be submitted to the message layer and this interaction SHALL
- If this action is part of a Timed Write transaction, and this action has TimedRequest set to FALSE, then a Status Response action with the TIMED_REQUEST_MISMATCH Status Code SHALL be submitted to the message layer and this interaction SHALL
- If this action is marked with TimedRequest as TRUE but this action is not part of a Timed Write transaction (i.e. there was no corresponding Timed Request action prior to it matching the same TransactionID), then a Status Response action with the TIMED_REQUEST_MISMATCH Status Code SHALL be submitted to the message layer and this interaction SHALL
See Outgoing Write Response Action for building a Write Response action and executing the Write Request action.
- If this action was unicast and SuppressResponse is FALSE, a Write Response action SHALL be generated and submitted to the message layer to send to the initiator, otherwise no Write Response SHALL be
8.7.3. Write Response Action
This action is a following action for a Write Request action. Please see Common Action Behavior for behavior common to all actions. The specific action information for this action is shown below.
8.7.3.1. Write Response Action Information
Action Field | Type | Conformance | Description |
WriteResponses | list[AttributeStatusIB] | O | a list of zero or more concrete paths indicat ing errors |
- Outgoing Write Response Action
- This action SHALL be
- Each request path in the WriteRequests field of a Write Request SHALL be processed as follows:
- If the path does not conform to Valid Write Attribute Paths then:
- a Status Response with the INVALID_ACTION Status Code SHALL be generated as defined in Status Response Action,
- a Write Response action SHALL NOT be generated,
- and this interaction and process SHALL
- Else if the path is a concrete path:
- If the path does not conform to Valid Write Attribute Paths then:
- If the path indicates a specific node that is unsupported, an AttributeStatusIB SHALL be generated with the UNSUPPORTED_NODE Status
- Else if the path indicates a specific endpoint that is unsupported, an AttributeStatusIB SHALL be generated with the UNSUPPORTED_ENDPOINT Status
- Else if the path indicates a specific cluster that is unsupported, an AttributeStatusIB SHALL be generated with the UNSUPPORTED_CLUSTER Status
- Else if the path indicates an attribute or attribute data field that is unsupported, an AttributeStatusIB SHALL be generated with the UNSUPPORTED_ATTRIBUTE Status Code with the Path field indicating only the path to the first unsupported data field (not the entire attribute data path).
- Else if the path indicates a specific attribute data that is not writable, an AttributeSta tusIB SHALL be generated with the UNSUPPORTED_WRITE Status
- Else if writing to the attribute in the path requires a privilege that is not granted to access the cluster in the path, an AttributeStatusIB SHALL be generated with the UNSUP PORTED_ACCESS Status
- Else if the path indicates specific attribute data that requires a Timed Write transaction to write and this action is not part of a Timed Write transaction, an AttributeStatusIB SHALL be generated with the NEEDS_TIMED_INTERACTION Status
- Else if the attribute in the path indicates a fabric-scoped list and there is no accessing fabric, an AttributeStatusIB SHALL be generated with the UNSUPPORTED_ACCESS Status Code, with the Path field indicating only the path to the
- Else if the DataVersion field of the AttributeDataIB is present and does not match the data version of the indicated cluster instance, an AttributeStatusIB SHALL be generated with the DATA_VERSION_MISMATCH Status Code.
- If the above processing generated an AttributeStatusIB, the path SHALL be
- Else perform Write Path Data Process
- Else perform Request Path Expansion and process each expanded existent path as follows:
- If the path indicates attribute data that is not writable, then the path SHALL be dis
- If writing to the attribute in the path requires a privilege that is not granted to access the cluster in the path, then the path SHALL be
- Else if the path indicates specific attribute data that requires a Timed Write transaction to write and this action is not part of a Timed Write transaction, then the path SHALL be discarded.
- Else perform Write Path Data Process
8.7.3.3. Write Path Data Process
- If the path indicates a fabric-scoped list or list entry, it SHALL be processed as a fabric-filtered list of fabric-scoped structs.
- Each data field indicated by the path, SHALL be processed in the order conveyed as follows:
- If a data field is not within the constraints defined by the cluster specification, an AttributeS tatusIB SHALL be generated with the CONSTRAINT_ERROR Status Code, with the Path field duplicating the
- Otherwise perform the following:
- The data field SHALL be changed to the data indicated with the
- An AttributeStatusIB SHALL be generated with the SUCCESS Status Code, with the Path field duplicating the
8.7.3.4. Write Response Generation
- Each AttributeStatusIB generated from processing the WriteRequests field of the Write Request action, SHALL be added to the WriteResponses action field of the Write Response
NOTE An empty WriteResponses would occur if all paths were wildcard or group paths that expand to non-accessible data. |
8.7.3.5. Incoming Write Response Action
Upon receipt of this action, the action information SHALL be submitted to the layer above.
8.7.4. Timed Request Action
This action is a first action of a transaction. The specific action information for this action is shown below.
This action informs the receiver that another action will be sent in the same direction, within the same transaction, and within a specified Timeout interval. The Timeout interval SHALL start when the Status Response action acknowledging the Timed Request action with a success code is sent.
8.7.4.1. Timed Request Action Information
Action Field | Type | Conformance | Description |
Timeout | uint16 | M | an interval, in millisec onds, to expect a fol lowing action |
- Outgoing Timed Request Action
- This action SHALL be generated as an optional first action in a Write or Invoke
- This action SHALL be
8.7.4.3. Incoming Timed Request Action
- Upon receipt of this action, this layer SHALL construct and send a Status Response action with SUCCESS to the
- This layer SHALL expect a Write Request or Invoke Request action within Timeout milliseconds of sending the Status Response
8.8. Invoke Interaction
This interaction is generated when a device wishes to invoke one or more cluster specific com mands on one or more nodes. Cluster commands are defined as either client to server or server to client. Invoke Request action SHALL support group paths and SHOULD support wildcard paths. Invoke Response action does not support wildcard paths.
8.8.1. Invoke Transaction
- The Invoke interaction SHALL consist of one of the Invoke transactions shown below
8.8.1.1. Timed Invoke Transaction
Action | Action Flow | Description |
Timed Request | Initiator ⇒ Target | time interval defined to send Invoke Request action |
Status Response | Initiator ⇐ Target | confirmation |
Invoke Request | Initiator ⇒ Target | commands to invoke |
Invoke Response | Initiator ⇐ Target | response(s) defined by the clus ter specification |
… | Initiator ⇐⇒ Target | subsequent response(s) defined by the cluster specification |
- Untimed Invoke Transaction
Action | Action Flow | Description |
Invoke Request | Initiator ⇒ Target | commands to invoke |
Invoke Response | Initiator ⇐ Target | response(s) defined by the clus ter specification |
… | Initiator ⇐⇒ Target | subsequent response(s) defined by the cluster specification |
- A client MAY choose to use a Timed Invoke transaction even if the command does not have the Timed Interaction
- The server SHALL support a Timed Invoke transaction for all
8.8.2. Invoke Request Action
- This action SHALL be generated as the first action in an Invoke transaction, or following a Timed Request action and successful Status Response
- If there is a preceding successful Timed Request action, the following Invoke Request action
SHALL be received before the end of the Timeout interval.
- If there is a preceding successful Timed Request action, the Timeout interval SHALL start when the Status Response action acknowledging the Timed Request action with a success code is
- Each Invoke Request and Invoke Response action in a Timed Invoke transaction SHALL be uni cast.
- If not part of a Timed Invoke transaction, this action MAY be
- If a cluster command is defined to be invoked as the result of a groupcast, the command SHALL be invoked with an Invoke Request action which SHALL start a new
- Each path in an Invoke Request or Invoke Response action SHALL indicate a server
Invoke Request action is either the first action of the Invoke transaction or it follows a successful Timed Request action. Please see Common Action Behavior for behavior common to all actions. The specific action information for this action is shown below.
8.8.2.1. Invoke Request Action Information
Action Field | Type | Constraint | Conformance | Description |
SuppressRe sponse | bool | M | do not send a response to this action | |
TimedRequest | bool | M | flag action as part of a timed invoke transaction | |
InvokeRequests | list[Command DataIB] | max 1 all | M P, M | cluster com mand(s) |
- Outgoing Invoke Request Action
- This action SHALL be generated as the first action in an Invoke transaction, or following a Timed Request action and successful Status Response
- If this action is part of a Timed Invoke transaction, TimedRequest SHALL be TRUE, else
- A valid CommandDataIB SHALL be one in the table Valid Command Paths.
- A path indicated in InvokeRequests MAY target a
NOTE As defined above, more than one command in InvokeRequests is provisional.
8.8.2.3. Incoming Invoke Request Action
- If this action is part of a Timed Invoke transaction, and the Timeout has expired from the pre ceding Timed Request action, then a Status Response action with the TIMEOUT Status Code SHALL be submitted to the message layer and this interaction SHALL
- If this action is part of a Timed Invoke transaction, and this action has TimedRequest set to FALSE, then a Status Response action with the TIMED_REQUEST_MISMATCH Status Code SHALL be submitted to the message layer and this interaction SHALL
- If this action is marked with TimedRequest as TRUE, but this action is not part of a Timed Invoke transaction (i.e. there was no immediately previous Timed Invoke action), then a Status Response action with the TIMED_REQUEST_MISMATCH Status Code SHALL be submitted to the message layer and this interaction SHALL
- Each request path in the InvokeRequests field SHALL be processed as follows:
- If the path does not conform to Valid Command Paths then:
- a Status Response with the INVALID_ACTION Status Code SHALL be generated as defined in Status Response Action,
- an Invoke Response action SHALL NOT be generated,
- and this interaction and process SHALL
- Else if the path is a concrete path:
- If the path indicates a node that is unsupported, a CommandStatusIB SHALL be gener ated with the UNSUPPORTED_NODE Status
- Else if the path indicates an endpoint that is unsupported, a CommandStatusIB SHALL be generated with the UNSUPPORTED_ENDPOINT Status
- Else if the path indicates a cluster that is unsupported, a CommandStatusIB SHALL be generated with the UNSUPPORTED_CLUSTER Status
- Else if the path indicates a command that is unsupported, a CommandStatusIB SHALL be generated with the UNSUPPORTED_COMMAND Status
- Else if invoking the command in the path requires a privilege that is not granted to access the cluster in the path, a CommandStatusIB SHALL be generated with the UNSUP PORTED_ACCESS Status
- Else if the command in the path is fabric-scoped and there is no accessing fabric, a Com mandStatusIB SHALL be generated with the UNSUPPORTED_ACCESS Status
- Else if the command in the path requires a Timed Invoke transaction to invoke and this action is not part of a Timed Invoke transaction, a CommandStatusIB SHALL be gener ated with the NEEDS_TIMED_INTERACTION Status
- Each generated CommandStatusIB CommandPath field SHALL be a duplicate of the con crete path processed, including the command ID of the original concrete
- Else perform Request Path Expansion and process each expanded existent path as follows:
- If invoking the command in the path requires a privilege that is not granted for the clus ter in the path, then the path SHALL be
- Else if the command in the path is fabric-scoped and there is no accessing fabric, then the path SHALL be
- Else if the command in the path requires a Timed Invoke transaction to invoke and this action is not part of a Timed Invoke transaction, then the path SHALL be
- Each command in the remaining and error-free concrete command paths SHALL be executed, as defined in Invoke Execution, in the same order as conveyed and expanded:
Invoke Execution
- The command SHALL be executed as defined in the cluster specification, and the following applies:
- For each data field in CommandFields:
- If a mandatory data field is missing, or incoming data cannot be mapped to the expected data type for a field, a CommandStatusIB SHALL be generated with an error status of INVALID_COMMAND, even if the cluster defines another type of
- If a data field violates expected constraints, a CommandStatusIB SHOULD be generated with an error status of
- If the cluster specification defines a following command in response to the command, a CommandDataIB SHALL be generated for the following command with these fields:
- CommandFields defined for the following command
- ClusterPath field of the CommandPath field that is a duplicate of the command path processed, up to the cluster ID
- Command field of the CommandPath field that is the command ID of the following com mand
- Else if the cluster specification defines a success or error status as a response (sometimes specified as a Default Response), a CommandStatusIB SHALL be generated with these fields:
- CommandPath that is a duplicate of the concrete command path processed
- After all valid commands complete execution, Invoke Response Generation SHALL be per formed.
- For each data field in CommandFields:
8.8.3. Invoke Response Action
Invoke Response action is a following action for an Invoke Request action. Please see Common Action Behavior for behavior common to all actions. The specific action information for this action is shown below.
8.8.3.1. Invoke Response Action Information
Action Field | Type | Conformance | Description |
SuppressResponse | bool | M | do not send a response to this action |
InvokeResponses | list[InvokeResponseIB] | M | command response or status |
- Outgoing Invoke Response Action
- This action SHALL be generated in response to an Invoke Request action or Invoke Response action, after all valid commands are
- A valid InvokeResponseIB SHALL only indicate concrete
Invoke Response Generation
- If the previous action in this transaction action is groupcast, this process and transaction termi nate with no
- Else if SuppressResponse is FALSE, or a CommandDataIB was generated, an Invoke Response action SHALL be generated as follows:
- Each generated CommandStatusIB and CommandDataIB SHALL be included in an InvokeRe sponseIB in the InvokeResponses action
- An Invoke Response action SHALL be submitted to the message layer to send to the source of the previous
8.8.3.3. Incoming Invoke Response Action
- Upon receipt of this action, each entry in InvokeResponses SHALL be processed, in order, as fol lows:
- If the entry is a CommandStatusIB, it SHALL be submitted to the layer
- Else if the response is a CommandDataIB:
- If the ClusterPath field of the CommandPath field does not duplicate or match a wildcard of one of the paths in the previous action of the interaction, the entry SHALL be dis carded.
- Else if the command ID value of the Command field of the CommandPath field is not expected by the cluster instance, the entry SHALL be
- Else the CommandDataIB SHALL be executed in Invoke Execution.
- After all commands complete execution Invoke Response Generation SHALL be
8.9. Common Action Information Blocks and Paths
Shown below are common information blocks used to submit actions to, and receive actions from, the message layer.
8.9.1. Path Information
- Logically for this specification, the Node or Group SHALL be present in all
- When an outgoing path indicates the same Node or Group as the action target, the message layer MAY optimize the path by removing Node or
- When an incoming path does not indicate a Node or Group, the message layer SHALL add the action target (Node or Group) to the
See Path for more information.
8.9.1.1. ClusterPathIB
Path Field | Type | Quality | Conformance |
Group | group-id | !Endpoint |
Path Field | Type | Quality | Conformance |
Node | node-id | !Group | |
Endpoint | endpoint-no | A | !Group |
Cluster | cluster-id | A | M |
- AttributePathIB
An attribute path supports nesting levels deeper than the attribute with the NestedPath field below. The NestedPath indicates zero or more nesting levels to establish the nesting depth of the attribute path.
- An attribute path MAY indicate data at any nesting depth in the attribute
- If the Attribute is indicated as a wildcard then the path SHALL indicate all attributes of the clus ter.
- If the Attribute is indicated as a wildcard, then NestedPath SHALL be
- If the final nesting level in an attribute path indicates a collection data type, then the path SHALL indicate all collection data, plus any deeper nested data as part of the
Path Field | Type | Quality | Conformance |
Cluster | ClusterPathIB | M | |
Attribute | attrib-id | A | M |
NestedPath | list[NestingLevelIB] | Attribute != wildcard |
8.9.2.2. NestingLevelIB
This defines a deeper nesting level of an attribute path to collection data, such as a struct field, or list entry.
Path Field | Type | Quality | Conformance |
FieldID | field-id | A | O.a |
ListIndex | entry-idx | A | O.a |
8.9.2.3. Valid Read Attribute Paths
This table is valid for AttributePathIB for a Read Request action or a Subscribe Request action. See AttributePathIB for more conformance restrictions.
The table defines valid attribute data path with wildcard and non-wildcard combinations.
Node | Endpoint | Cluster | Attribute | Attribute Data Requested |
Specific | Wildcard | Wildcard | Wildcard | all attribute data from all clusters on all endpoints on a specific node |
Specific | Wildcard | Wildcard | Specific |
specific global attribute data or field for all clus ters on all end points on a spe cific node (e.g. ClusterRevision) |
Specific | Wildcard | Specific | Wildcard |
all attribute data from a specific cluster on all end points on a spe cific node (e.g. Descriptor cluster) |
Specific | Wildcard | Specific | Specific | a specific attribute data or field from a specific cluster on all endpoints on a specific node (e.g. Descriptor cluster) |
Specific | Specific | Wildcard | Wildcard | all attribute data from all clusters on a specific end point on a specific node |
Specific | Specific | Wildcard | Specific |
a specific global attribute data or field for all clus ters on a specific endpoint on a spe cific node (e.g. ClusterRevision) |
Specific | Specific | Specific | Wildcard | all attribute data from a specific cluster on a spe cific endpoint a specific node |
Node | Endpoint | Cluster | Attribute | Attribute Data Requested |
Specific | Specific | Specific | Specific | a specific attribute data or field from a specific cluster on a specific end point on a specific node |
8.9.2.4. Valid Write Attribute Paths
This table is valid for Path field of a AttributeDataIB for a Write Request action. See AttributeDataIB and AttributePathIB for more conformance restrictions.
The table defines valid attribute data paths including combinations with wildcards, non-group (node & endpoint), and group paths. A blank entry means the element does not exist in the path.
Node | Endpoint | Group | Cluster | Attribute | Attribute Data Provided |
Specific | Wildcard | Specific | Specific | a specific attribute data or field from a specific cluster on all end points on a spe cific node | |
Specific | Specific | Specific | Specific | a specific attribute data or field from a specific cluster on a specific endpoint on a specific node | |
Specific | Specific | Specific | a specific attribute data or field from a specific cluster on a specific group of zero or more end points on each node |
8.9.2.5. AttributeDataIB
This is used in Write Request and Report Data actions.
Info Field | Type | Quality | Conformance |
DataVersion | data-ver | desc | |
Change | enum8 | desc | |
Path | AttributePathIB | M | |
Data | desc | M |
DataVersion
- This field SHALL NOT be present for a group or wildcard
- This field MAY be present for a path in a Write Request
- This field SHALL be present for a path in a Report Data
Change
This field indicates a change to a list for a write interaction, or as reported for a read or subscribe interaction.
- This field SHALL only be present if the data type is a list entry index or list data type.
- The list change SHALL be in the context of a fabric-filtered list, if fabric-filtering is enabled or required.
- This field SHALL be one of the values defined in the table
Name | Description |
REPLACE | This indicates the entire list changing to another list. |
ADD | This adds one or more entries without imposing a specific order. |
DELETE | This deletes a particular entry. |
MODIFY | This modifies a particular entry. |
REPLACE
- This Change value SHALL indicate replacing the entire
- This Change value SHALL only be used when the last nesting level of the Path field indicates a list (Attribute or FieldID).
- The data type of the AttributeDataIB Data field SHALL be list.
- The Data field MAY be an empty list which effectively deletes all entries from the
ADD
- This Change value SHALL indicate adding one or more entries to the list, in an order deter mined by the
- This Change value SHALL only be used when the last nesting level of the Path field indicates a
list (Attribute or FieldID).
- The data type of the AttributeDataIB Data field SHALL be list.
DELETE
- This Change value SHALL indicate deleting one particular
- This Change value SHALL only be used when the last nesting level of the Path field indicates a list entry index (ListIndex).
- The data type of the AttributeDataIB Data field SHALL be the data type of the list
MODIFY
- This Change value SHALL indicate modifying one particular
- This Change value SHALL only be used when the last nesting level of the Path field indicates a list entry index (ListIndex).
- The data type of the AttributeDataIB Data field SHALL be the data type of the list
Path
See AttributePathIB.
Data
- The data type of this field SHALL be the data type of the data indicated by the Path
- If the final nesting level indicated by the Path is an list entry index, the data type SHALL be the data type of the
8.9.2.6. AttributeReportIB
Info Field | Type | Quality | Conformance |
AttributeStatus | AttributeStatusIB | O.a | |
AttributeData | AttributeDataIB | O.a |
- Only one of the above two fields SHALL be
8.9.2.7. DataVersionFilterIB
Info Field | Type | Quality | Conformance |
Path | ClusterPathIB | M | |
DataVersion | data-ver | M |
- The Path field SHALL indicate a concrete
8.9.3. Event Information Blocks and Paths
8.9.3.1. EventFilterIB
Info Field | Type | Quality | Conformance |
Node | node-id | M | |
EventMin | event-no | M |
- EventPathIB
Path Field | Type | Quality | Conformance |
Path | ClusterPathIB | M | |
Event | event-id | O | |
IsUrgent | bool | O |
- Valid Event Paths
This table is valid for EventPathIB. The table defines valid event paths including combinations with wildcards, but not group paths.
Node | Endpoint | Cluster | Event | Event(s) Requested |
Specific | Wildcard | Wildcard | Wildcard | all events from all clusters on all end points on a spe cific node |
Specific | Wildcard | Specific | Wildcard | all events from a specific cluster on all endpoints on a specific node (e.g. Descriptor cluster) |
Specific | Wildcard | Specific | Specific |
a specific event from a specific cluster on all end points on a spe cific node (e.g. Descriptor cluster) |
Specific | Specific | Wildcard | Wildcard | all events from all clusters on a spe cific endpoint on a specific node |
Specific | Specific | Specific | Wildcard | all events from a specific cluster on a specific endpoint on a specific node |
Node | Endpoint | Cluster | Event | Event(s) Requested |
Specific | Specific | Specific | Specific | a specific event from a specific cluster on a spe cific endpoint on a specific node |
8.9.3.4. EventDataIB
Info Field | Type | Quality | Conformance |
Path | EventPathIB | M | |
EventNumber | event-no | M | |
Priority | priority | M | |
EpochTimeStamp | posix-ms | O.a | |
SystemTimeStamp | systime-ms | O.a | |
Data | variable | O |
- The Path field SHALL indicate an existent
- The Path field SHALL NOT have an IsUrgent field
8.9.3.5. EventReportIB
Info Field | Type | Quality | Conformance |
EventStatus | EventStatusIB | O.a | |
EventData | EventDataIB | O.a |
- Only one of the above fields SHALL be
8.9.4. Command Information Blocks and Paths
8.9.4.1. CommandPathIB
Path Field | Type | Quality | Conformance |
ClusterPath | ClusterPathIB | M | |
Command | command-id | M |
- Valid Command Paths
This table is valid for CommandPathIB. The table defines valid command paths including combina tions with wildcards, non-group (node & endpoint), and group paths. A blank entry means the ele ment does not exist in the path.
Node | Endpoint | Group | Cluster | Command | Description | Confor mance |
Specific | Wildcard | Specific | Specific | a specific cluster com mand to all endpoints of a node | P, M | |
Specific | Specific | Specific | Specific | a specific cluster com mand to a specific end point on a node | M | |
Specific | Specific | Specific | a specific cluster com mand to a group of endpoints | M |
NOTE Support for commands paths involving wildcards is provisional.
8.9.4.3. CommandDataIB
Info Field | Type | Quality | Conformance |
CommandPath | CommandPathIB | M | |
CommandFields | variable | M |
- InvokeResponseIB
This is used in response to an invoked command.
Info Field | Type | Quality | Conformance |
Command | CommandDataIB | O.a | |
Status | CommandStatusIB | O.a |
- Only one of the above fields SHALL be
- The Path field in CommandDataIB and CommandStatusIB SHALL indicate a concrete
8.9.5. Status Information Blocks and Paths
8.9.5.1. CommandStatusIB
This is used to indicate an invalid command, or an error accessing the command.
Info Field | Type | Quality | Conformance |
CommandPath | CommandPathIB | M | |
Status | StatusIB | M |
- The Path field SHALL indicate a concrete
8.9.5.2. EventStatusIB
This is used to indicate an invalid event, or an error accessing the event.
Info Field | Type | Quality | Conformance |
Path | EventPathIB | M | |
Status | StatusIB | M |
- The Path field SHALL indicate a concrete
8.9.5.3. AttributeStatusIB
This is used to indicate an invalid attribute data request path, or an error accessing the data.
Info Field | Type | Quality | Conformance |
Path | AttributePathIB | M | |
Status | StatusIB | M |
- The Path field SHALL indicate a concrete
8.9.5.4. StatusIB
This is used to respond with errors or success to actions. A success Status field is valid for every layer. A non-success Status field is either defined in this layer, or generated and recognized by another layer. ClusterStatus is defined in a cluster specification.
Please see Status Codes for valid values for Status.
Info Field | Type | Quality | Conformance |
Status | status | M | |
ClusterStatus | status | O |
Status Field
This is the one of the common status code values defined in Status Code Table.
ClusterStatus Field
ClusterStatus values are defined in a cluster specification.
8.10. Status Codes
The table below lists global status codes for the Interaction Model. These MAY be used by interac tion model processing of actions and as common status codes for cluster specifications. All values not defined here SHALL be reserved (per general conventions). Cluster specifications that wish to communicate a status not defined in this table MAY use a cluster-specific status code as described in Status Codes.
8.10.1. Status Code Table
Status Code | Value | Summary |
0x00 | SUCCESS | Operation was successful. |
0x01 | FAILURE | Operation was not successful. |
0x7D | INVALID_SUBSCRIPTION | Subscription ID is not active. |
0x7E |
UNSUPPORTED_ACCESS
NOT_AUTHORIZED |
The sender of the action or command does not have autho rization or access. NOT_AUTHORIZED is an obso lete name of this error code. |
0x7F | UNSUPPORTED_ENDPOINT | The endpoint indicated is unsupported on the node. |
0x80 | INVALID_ACTION | The action is malformed, has missing fields, or fields with invalid values. Action not car ried out. |
0x81 |
UNSUPPORTED_COMMAND
UNSUP_COMMAND |
The indicated command ID is not supported on the cluster instance. Command not carried out. UNSUP_COMMAND is an obso lete name for this error code. |
0x82 | reserved | Deprecated: use UNSUPPORT ED_COMMAND |
0x83 | reserved | Deprecated: use UNSUPPORT ED_COMMAND |
0x84 | reserved | Deprecated: use UNSUPPORT ED_COMMAND |
0x85 |
INVALID_COMMAND
INVALID_FIELD |
The cluster command is mal formed, has missing fields, or fields with invalid values. Com mand not carried out. INVALID_FIELD is an obsolete name for this error code. |
Status Code | Value | Summary |
0x86 | UNSUPPORTED_ATTRIBUTE | The indicated attribute ID, field ID or list entry does not exist for an attribute path. |
0x87 |
CONSTRAINT_ERROR
INVALID_VALUE |
Out of range error or set to a reserved value. Attribute keeps its old value. Note that an attribute value may be out of range if an attribute is related to another, e.g. with minimum and maximum attributes. See the individual attribute descrip tions for specific details. INVALID_VALUE is an obsolete name for this error code. |
0x88 |
UNSUPPORTED_WRITE
READ_ONLY |
Attempt to write a read-only attribute. READ_ONLY is an obsolete name for this error code. |
0x89 |
RESOURCE_EXHAUSTED
INSUFFICIENT_SPACE |
An action or operation failed due to insufficient available resources. INSUFFICIENT_SPACE is an obsolete name for this error code. |
0x8A | reserved | Legacy cluster specification error status code: use SUCCESS |
0x8B | NOT_FOUND | The indicated data field or entry could not be found. |
0x8C | UNREPORTABLE_ATTRIBUTE | Reports cannot be issued for this attribute. |
0x8D | INVALID_DATA_TYPE | The data type indicated is unde fined or invalid for the indi cated data field. Command or action not carried out. |
0x8E | reserved | Legacy cluster specification error status code: use UNSUP PORTED_ATTRIBUTE. |
0x8F | UNSUPPORTED_READ | Attempt to read a write-only attribute. |
0x90 | reserved | Deprecated: use FAILURE |
0x91 | reserved | Deprecated: use FAILURE |
Status Code | Value | Summary |
0x92 | DATA_VERSION_MISMATCH | Cluster instance data version did not match request path |
0x93 | reserved | Legacy cluster specification error status code: use FAILURE |
0x94 | TIMEOUT | The transaction was aborted due to time being exceeded. |
0x95 | reserved | ZCL OTA Upgrade cluster spe cific error status code |
0x96 | reserved | ZCL OTA Upgrade cluster spe cific error status code. |
0x97 | reserved | ZCL OTA Upgrade cluster spe cific error status code. |
0x98 | reserved | ZCL OTA Upgrade cluster spe cific error status code. |
0x99 | reserved | ZCL OTA Upgrade cluster spe cific error status code. |
0x9A | reserved | ZCL OTA Upgrade cluster spe cific error status code. |
0x9B | UNSUPPORTED_NODE | The node ID indicated is not supported on the node. |
0x9C | BUSY | The receiver is busy processing another action that prevents the execution of the incoming action. |
0xC0 | reserved | Deprecated: use FAILURE |
0xC1 | reserved | Deprecated: use FAILURE |
0xC2 | reserved | Deprecated: use FAILURE |
0xC3 | UNSUPPORTED_CLUSTER | The cluster indicated is not sup ported on the endpoint. |
0xC4 | reserved | Deprecated: use SUCCESS |
0xC5 | NO_UPSTREAM_SUBSCRIP TION | Used by proxies to convey to clients the lack of an upstream subscription to a source. |
0xC6 | NEEDS_TIMED_INTERACTION | A Untimed Write or Untimed Invoke interaction was used for an attribute or command that requires a Timed Write or Timed Invoke. |
Status Code | Value | Summary |
0xC7 | UNSUPPORTED_EVENT | The indicated event ID is not supported on the cluster instance. |
0xC8 | PATHS_EXHAUSTED | The receiver has insufficient resources to support the speci fied number of paths in the request |
0xC9 | TIMED_REQUEST_MISMATCH | A request with TimedRequest field set to TRUE was issued out side a Timed transaction or a request with TimedRequest set to FALSE was issued inside a Timed transaction. |
0xCA | FAILSAFE_REQUIRED | A request requiring a Fail-safe context was invoked without the Fail-Safe context. |