Matter Cluster 40 — Basic Information Cluster

Cluster Identity

Revision history

Shadow Path Format

Cluster 40 values in the device shadow use this format:

endpoint_id / 40 / attribute_id

Example:

{
  "0/40/0": 1
}

Data Types

ColorEnum

The data type of ColorEnum is derived from enum8.

ProductFinishEnum

The data type of ProductFinishEnum is derived from enum8.

CapabilityMinimaStruct (struct)

This structure provides constant values related to overall global capabilities of this Node, that are not cluster-specific.

ProductAppearanceStruct (struct)

This structure provides a description of the product's appearance.

Cluster 40 Attributes

Cluster 40 defines 24 attributes plus the global attributes. Conformance: M mandatory, O optional, a feature code means "mandatory when that feature is present", square brackets mean "optional when …".

Global attributes

Attribute Details

Attribute 0 / 0x0000 — DataModelRevision

Path example:

0/40/0

This attribute is set to the revision number of the Data Model against which the Node is certified.

Example:

{
  "0/40/0": 1
}

Attribute 1 / 0x0001 — VendorName

Path example:

0/40/1

This attribute specifies a human readable (displayable) name of the vendor for the Node.

Example:

{
  "0/40/1": "example"
}

Attribute 2 / 0x0002 — VendorID

Path example:

0/40/2

No condensed specification text is available for VendorID; use the type, conformance and constraint below together with the cluster description above.

Example:

{
  "0/40/2": 1
}

Attribute 3 / 0x0003 — ProductName

Path example:

0/40/3

This attribute specifies a human readable (displayable) name of the model for the Node such as the model number (or other identifier) assigned by the vendor.

Example:

{
  "0/40/3": "example"
}

Attribute 4 / 0x0004 — ProductID

Path example:

0/40/4

No condensed specification text is available for ProductID; use the type, conformance and constraint below together with the cluster description above.

Example:

{
  "0/40/4": 1
}

Attribute 5 / 0x0005 — NodeLabel

Path example:

0/40/5

Indicates a user defined name for the Node. This attribute should be set during initial commissioning and may be updated by further reconfigurations.

Example:

{
  "0/40/5": "example"
}

Attribute 6 / 0x0006 — Location

Path example:

0/40/6

This attribute is an ISO 3166-1 alpha-2 code to represent the country, dependent territory, or special area of geographic interest in which the Node is located at the time of the attribute being set. This attribute is set during initial commissioning (unless already set) and may be updated by further reconfigurations. This attribute may affect some regulatory aspects of the Node's operation, such as radio transmission power levels in given spectrum allocation bands if technologies where this is applicable are used. The Location's region code is interpreted in a case-insensitive manner.

Example:

{
  "0/40/6": "example"
}

Attribute 7 / 0x0007 — HardwareVersion

Path example:

0/40/7

This attribute specifies the version number of the hardware of the Node. The meaning of its value, and the versioning scheme, are vendor defined.

Example:

{
  "0/40/7": 1
}

Attribute 8 / 0x0008 — HardwareVersionString

Path example:

0/40/8

This attribute specifies the version number of the hardware of the Node. The meaning of its value, and the versioning scheme, are vendor defined. The HardwareVersionString attribute is used to provide a more user-friendly value than that represented by the HardwareVersion attribute.

Example:

{
  "0/40/8": "example"
}

Attribute 9 / 0x0009 — SoftwareVersion

Path example:

0/40/9

This attribute contains the current version number for the software running on this Node. A larger value of SoftwareVersion is newer than a lower value, from the perspective of software updates. Nodes may query this field to determine the currently running version of software on another given Node.

Example:

{
  "0/40/9": 1
}

Attribute 10 / 0x000A — SoftwareVersionString

Path example:

0/40/10

This attribute contains a current human-readable representation for the software running on the Node. This version information may be conveyed to users. The maximum length of the SoftwareVersionString attribute is 64 bytes of UTF-8 characters. The contents should only use simple 7-bit ASCII alphanumeric and punctuation characters, so as to simplify the conveyance of the value to a variety of cultures.

Example:

{
  "0/40/10": "example"
}

Attribute 11 / 0x000B — ManufacturingDate

Path example:

0/40/11

This attribute specifies the date that the Node was manufactured. The first 8 characters specifies the date of manufacture of the Node in international date notation according to ISO 8601, i.e., YYYYMMDD, e.g., 20060814. The final 8 characters may include country, factory, line, shift or other related information at the option of the vendor. The format of this information is vendor defined.

Example:

{
  "0/40/11": "example"
}

Attribute 12 / 0x000C — PartNumber

Path example:

0/40/12

This attribute specifies a human-readable (displayable) vendor assigned part number for the Node whose meaning and numbering scheme is vendor defined. Multiple products (and hence PartNumbers) can share a ProductID. For instance, there may be different packaging (with different PartNumbers) for different regions; also different colors of a product might share the ProductID but may have a different PartNumber.

Example:

{
  "0/40/12": "example"
}

Attribute 13 / 0x000D — ProductURL

Path example:

0/40/13

No condensed specification text is available for ProductURL; use the type, conformance and constraint below together with the cluster description above.

Example:

{
  "0/40/13": "example"
}

Attribute 14 / 0x000E — ProductLabel

Path example:

0/40/14

This attribute specifies a vendor specific human readable (displayable) product label. The ProductLabel attribute may be used to provide a more user-friendly value than that represented by the ProductName attribute. The ProductLabel attribute should NOT include the name of the vendor as defined within the VendorName attribute.

Example:

{
  "0/40/14": "example"
}

Attribute 15 / 0x000F — SerialNumber

Path example:

0/40/15

This attribute specifies a human readable (displayable) serial number.

Example:

{
  "0/40/15": "example"
}

Attribute 16 / 0x0010 — LocalConfigDisabled

Path example:

0/40/16

This attribute must allow a local Node configuration to be disabled. When this attribute is set to True the Node must disable the ability to configure the Node through an on-Node user interface. The value of the LocalConfigDisabled attribute must NOT in any way modify, disable, or otherwise affect the user's ability to trigger a factory reset on the Node.

Example:

{
  "0/40/16": true
}

Attribute 17 / 0x0011 — Reachable

Path example:

0/40/17

This attribute (when used) indicates whether the Node can be reached. For a native Node this is implicitly True (and its use is optional). Its main use case is in the derived Bridged Device Basic Information cluster where it is used to indicate whether the bridged device is reachable by the bridge over the non-native network.

Example:

{
  "0/40/17": true
}

Attribute 18 / 0x0012 — UniqueID

Path example:

0/40/18

No condensed specification text is available for UniqueID; use the type, conformance and constraint below together with the cluster description above.

Example:

{
  "0/40/18": "example"
}

Attribute 19 / 0x0013 — CapabilityMinima

Path example:

0/40/19

This attribute provides the minimum guaranteed value for some system-wide resource capabilities that are not otherwise cluster-specific and do not appear elsewhere. This attribute may be used by clients to optimize communication with Nodes by allowing them to use more than the strict minimum values required by this specification, wherever available. The values supported by the server in reality may be larger than the values provided in this attribute, such as if a server is not resource-constrained at all. However, clients should only rely on the amounts provided in this attribute.

Value is a CapabilityMinimaStruct struct (see Data Types).

Example:

{
  "0/40/19": {
    "caseSessionsPerFabric": 3,
    "subscriptionsPerFabric": 3,
    "simultaneousInvocationsSupported": 1,
    "simultaneousWritesSupported": 1
  }
}

Attribute 20 / 0x0014 — ProductAppearance

Path example:

0/40/20

This attribute provides information about the appearance of the product, which could be useful to a user trying to locate or identify the node.

Value is a ProductAppearanceStruct struct (see Data Types).

Example:

{
  "0/40/20": {
    "finish": 0,
    "primaryColor": 0
  }
}

Attribute 21 / 0x0015 — SpecificationVersion

Path example:

0/40/21

This attribute contains the current version number for the specification version this Node was certified against. A larger value of SpecificationVersion is newer than a lower value. Nodes may query this field to determine the currently supported version of the specification on another given Node. The format of this number is segmented as its four component bytes.

Example:

{
  "0/40/21": 1
}

Attribute 22 / 0x0016 — MaxPathsPerInvoke

Path example:

0/40/22

Indicates the maximum number of elements in a single InvokeRequests list that the Node is able to process. Note that since this attribute may change over time, both increasing and decreasing, as software versions change for a given Node, clients should take care not to assume forever unchanging values and should NOT cache this value permanently at Commissioning time. If the MaxPathsPerInvoke attribute is absent or zero, such as in Basic Information cluster revisions prior to Revision 3, clients must assume a value of 1.

Example:

{
  "0/40/22": 1
}

Attribute 24 / 0x0018 — ConfigurationVersion

Path example:

0/40/24

This attribute contains the current version number for the configuration of the Node. A larger value of ConfigurationVersion indicates a newer configuration than a lower value.

Example:

{
  "0/40/24": 1
}

Cluster 40 Commands

Cluster 40 defines no commands. It is read (and, for writable attributes, written) through attribute access only.

Cluster 40 Events

Event 0 — StartUp

The StartUp event is generated by a Node as soon as reasonable after completing a boot or reboot process. The StartUp event should be the first Data Model event recorded by the Node after it completes a boot or reboot process.

Event 1 — ShutDown

The ShutDown event should be generated by a Node prior to any orderly shutdown sequence on a best-effort basis. When a ShutDown event is generated, it should be the last Data Model event recorded by the Node. This event should be delivered urgently to current subscribers on a best-effort basis.

This event has no fields.

Event 2 — Leave

The Leave event should be generated by a Node prior to permanently leaving a given Fabric, such as when the RemoveFabric command is invoked for a given fabric, or triggered by factory reset or some other manufacturer specific action to disable or reset the operational data in the Node. When a Leave event is generated, it should be assumed that the fabric recorded in the event is no longer usable, and subsequent interactions targeting that fabric will most likely fail.

Event 3 — ReachableChanged

This event (when supported) is generated when there is a change in the Reachable attribute. Its main use case is in the derived Bridged Device Basic Information cluster.

SmartphoneKey Notes

• Basic Information on endpoint 0 is written to the device-info part of the shadow (vendor, product, serial, software version, UniqueID).
• Shadow paths follow endpoint/40/attribute; attribute values that the device reports as unreadable are written as n/a.
• Attribute IDs, command IDs and enum values on this page come from the CSA Matter 1.6.1 data model; descriptions are condensed from the specification text.