페이지 선택
Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
Search in pages

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,

 

  • 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
  • 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
  • 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

 

  • Report Transaction Empty

 

Action Action Flow Description
Report Data Initiator ⇐ Target report with no data or events with SuppressResponse set to TRUE

 

 

 

8.7.   Write Interactyion

  • Write Interaction

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 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.

 

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

 

  • Attribute Information Blocks

 

  • 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.

 

 

 

 

 

 

Adsense

 

 WiFi IoT Module

 

www.mxchip.com

 

 

 Bluetooth Module

www.feasycom.com

 

 

 5G/LTE/CAT-M1/NB-IoT

 

www.simcom.com

 

Viewed Page List