Matter Cluster 57 — Bridged Device Basic Information Cluster

Cluster Identity

Revision history

Shadow Path Format

Cluster 57 values in the device shadow use this format:

endpoint_id / 57 / attribute_id

Example:

{
  "1/57/17": true
}

Cluster 57 Features

The FeatureMap attribute (1/57/65532) is a bitmap. Each bit set means the device implements that feature and the attributes and commands that depend on it.

Example: FeatureMap = 0 means no optional feature is enabled; 1048576 means every feature listed above is enabled.

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 57 Attributes

Cluster 57 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:

1/57/0

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

Example:

{
  "1/57/0": 1
}

Attribute 1 / 0x0001 — VendorName

Path example:

1/57/1

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

Example:

{
  "1/57/1": "example"
}

Attribute 2 / 0x0002 — VendorID

Path example:

1/57/2

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

Example:

{
  "1/57/2": 1
}

Attribute 3 / 0x0003 — ProductName

Path example:

1/57/3

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

Example:

{
  "1/57/3": "example"
}

Attribute 4 / 0x0004 — ProductID

Path example:

1/57/4

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

Example:

{
  "1/57/4": 1
}

Attribute 5 / 0x0005 — NodeLabel

Path example:

1/57/5

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

Example:

{
  "1/57/5": "example"
}

Attribute 6 / 0x0006 — Location

Path example:

1/57/6

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

Example:

{
  "1/57/6": "example"
}

Attribute 7 / 0x0007 — HardwareVersion

Path example:

1/57/7

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

Example:

{
  "1/57/7": 1
}

Attribute 8 / 0x0008 — HardwareVersionString

Path example:

1/57/8

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

Example:

{
  "1/57/8": "example"
}

Attribute 9 / 0x0009 — SoftwareVersion

Path example:

1/57/9

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

Example:

{
  "1/57/9": 1
}

Attribute 10 / 0x000A — SoftwareVersionString

Path example:

1/57/10

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

Example:

{
  "1/57/10": "example"
}

Attribute 11 / 0x000B — ManufacturingDate

Path example:

1/57/11

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

Example:

{
  "1/57/11": "example"
}

Attribute 12 / 0x000C — PartNumber

Path example:

1/57/12

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

Example:

{
  "1/57/12": "example"
}

Attribute 13 / 0x000D — ProductURL

Path example:

1/57/13

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

Example:

{
  "1/57/13": "example"
}

Attribute 14 / 0x000E — ProductLabel

Path example:

1/57/14

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

Example:

{
  "1/57/14": "example"
}

Attribute 15 / 0x000F — SerialNumber

Path example:

1/57/15

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

Example:

{
  "1/57/15": "example"
}

Attribute 16 / 0x0010 — LocalConfigDisabled

Path example:

1/57/16

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

Example:

{
  "1/57/16": true
}

Attribute 17 / 0x0011 — Reachable

Path example:

1/57/17

This attribute is used to indicate whether the bridged device is reachable by the bridge, so a Matter Node which wants to communicate with a bridged device can get an indication that this might fail (when the attribute is False). Determination of reachability might not be perfect (e.g. depending on technology employed), so the Matter Node should be aware of the risk of false positives and negatives on reachability determination. For example, a bridged device may be marked as unreachable while it could actually be reached, and vice-versa.

Example:

{
  "1/57/17": true
}

Attribute 18 / 0x0012 — UniqueID

Path example:

1/57/18

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

Example:

{
  "1/57/18": "example"
}

Attribute 19 / 0x0013 — CapabilityMinima

Path example:

1/57/19

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

Value is a CapabilityMinimaStruct struct (see Data Types).

Example:

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

Attribute 20 / 0x0014 — ProductAppearance

Path example:

1/57/20

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

Value is a ProductAppearanceStruct struct (see Data Types).

Example:

{
  "1/57/20": {
    "finish": 0,
    "primaryColor": 0
  }
}

Attribute 21 / 0x0015 — SpecificationVersion

Path example:

1/57/21

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

Example:

{
  "1/57/21": 1
}

Attribute 22 / 0x0016 — MaxPathsPerInvoke

Path example:

1/57/22

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

Example:

{
  "1/57/22": 1
}

Attribute 24 / 0x0018 — ConfigurationVersion

Path example:

1/57/24

This attribute contains the current version number for the configuration of the bridged device. A larger value of ConfigurationVersion indicates a newer configuration than a lower value. If the bridge detects a change on a bridged device, which it deems as a change in the configuration of the bridged device, it must increase this attribute (and the corresponding attribute on the bridge itself). The ability and the method used to detect such a change on a bridged device is manufacturer specific.

Example:

{
  "1/57/24": 1
}

Cluster 57 Commands

Cluster 57 has 1 client-to-server command and 0 responses.

AcceptedCommandList

The AcceptedCommandList attribute lists the command IDs the endpoint actually implements:

endpoint_id / 57 / 65529

{
  "1/57/65529": [
    128
  ]
}

Bridge Command Payload Format

The bridge accepts Matter commands in this structure:

{
  "message_id": "1",
  "command": "device_command",
  "args": {
    "endpoint_id": 1,
    "cluster_id": 57,
    "command_name": "KeepActive",
    "payload": {},
    "timed_request_timeout_ms": 1000
  }
}

For Cluster 57, always use "cluster_id": 57. Payload keys are the command field names in lowerCamelCase. Octet-string fields are base64-encoded. timed_request_timeout_ms is required for timed commands and ignored otherwise.

Command: KeepActive

Purpose

On receipt, the server must attempt to keep the bridged device active for the duration specified by the command, when the device is next active. The implementation of this is best-effort since it may interact with non-native protocols. However, several specific protocol requirements are: - If the bridged device is a Matter Intermittently Connected Device, then the server must send a StayActiveRequest command with the StayActiveDuration field set to value of the StayActiveDuration field in the received command to the bridged device when the bridged device next sends a checks-in message or subscription report. See Intermittently Connected Devices Behavior for details on ICD state management.

Command Identity

Payload Fields

Bridge Command Example

{
  "message_id": "1",
  "command": "device_command",
  "args": {
    "endpoint_id": 1,
    "cluster_id": 57,
    "command_name": "KeepActive",
    "payload": {
      "stayActiveDuration": 1,
      "timeoutMs": 30000
    }
  }
}

Cluster 57 Events

Event 0 — StartUp

Event 1 — ShutDown

This event has no fields.

Event 2 — Leave

The Leave event should be generated by the bridge when it detects that the associated device has left the non-Matter network. The FabricIndex field has the X conformance, indicating it must NOT be present. This event, in the context of Bridged Device Basic Information cluster, has no usable fields, but the original Basic Information cluster's field definition is kept for completeness.

Event 3 — ReachableChanged

This event is generated when there is a change in the Reachable attribute. Its purpose is to provide an indication towards interested parties that the reachability of a bridged device has changed over its native connectivity technology, so they may take appropriate action. After (re)start of a bridge this event may be generated.

Event 128 — ActiveChanged

This event (when supported) is generated the next time a bridged device becomes active after a KeepActive command is received. See KeepActive for more details.

SmartphoneKey Notes

• Bridged Device Basic Information appears on child endpoints of a bridge (for example a Zigbee gateway). Reachable (attribute 17) reflects the bridge's own view of the child, not the hub's presence pipeline.
• Shadow paths follow endpoint/57/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.