[TE5] Global Attribute ClusterRevision looks broken for clusters of bridged devices

[AntonGrey]

ClusterRevision attribute should be greater than 0. Affected clusters of Bridged devices.

• According to spec ClusterRevision attr SHALL be greater 0.
• Actually Cluster revision is 0.
• Steps to reproduce:

1. Start CHIP bridge-app example.
2. Connect to bridge-app with chip-device-ctrl tool
3. Perform zclread BridgedDeviceBasic ClusterRevision 12344321 2 0 command

• Logs:
  Cluster_revision_chip-bridge-app.log
  Cluster_revision_chip-device-ctrl.log

Original issue was found during TE5.
According to spec ClusterRevision attr SHALL be greater 0

Logs:

chip-device-ctrl > zclread OnOff ClusterRevision 12344321 2 0
[1631463550.593479][2265:2273] CHIP:DMG: SendReadRequest: Client[0] [ INIT]
[1631463550.593789][2265:2273] CHIP:IN: Secure message was encrypted: Msg ID 90
[1631463550.593868][2265:2273] CHIP:IN: Encrypted message 0x8444d58 to 0x0000000000BC5C01 of type 2 and protocolId 5 on exchange 39073.
[1631463550.593939][2265:2273] CHIP:IN: Sending msg 0x8444d58 to 0x0000000000BC5C01 at utc time: 3394106 msec
[1631463550.593995][2265:2273] CHIP:IN: Sending secure msg on generic transport
[1631463550.594284][2265:2273] CHIP:IN: Secure msg send status ../../src/inet/IPEndPointBasis.cpp:915: Success
[1631463550.594520][2265:2273] CHIP:DMG: Client[0] moving to [AwaitingResponse]
[1631463550.599870][2265:2273] CHIP:EM: Received message of type 0x05 with vendorId 0x0000 and protocolId 0x0005 on exchange 39073
[1631463550.600022][2265:2273] CHIP:EM: Rxd Ack; Removing MsgId:0000005A from Retrans Table
[1631463550.600081][2265:2273] CHIP:EM: Removed CHIP MsgId:0000005A from RetransTable
[1631463550.600197][2265:2273] CHIP:DMG: ReportData =
[1631463550.600262][2265:2273] CHIP:DMG: {
[1631463550.600308][2265:2273] CHIP:DMG: AttributeDataList =
[1631463550.600370][2265:2273] CHIP:DMG: [
[1631463550.600426][2265:2273] CHIP:DMG: AttributeDataElement =
[1631463550.600498][2265:2273] CHIP:DMG: {
[1631463550.600560][2265:2273] CHIP:DMG: AttributePath =
[1631463550.600641][2265:2273] CHIP:DMG: {
[1631463550.600724][2265:2273] CHIP:DMG: NodeId = 0xbc5c01,
[1631463550.600794][2265:2273] CHIP:DMG: EndpointId = 0x2,
[1631463550.600848][2265:2273] CHIP:DMG: ClusterId = 0x6,
[1631463550.600898][2265:2273] CHIP:DMG: FieldTag = 0xfd,
[1631463550.600944][2265:2273] CHIP:DMG: }
[1631463550.600999][2265:2273] CHIP:DMG:
[1631463550.601047][2265:2273] CHIP:DMG: Data = 0,
[1631463550.601083][2265:2273] CHIP:DMG: DataElementVersion = 0x0,
[1631463550.601127][2265:2273] CHIP:DMG: },
[1631463550.601174][2265:2273] CHIP:DMG:
[1631463550.601210][2265:2273] CHIP:DMG: ],
[1631463550.601253][2265:2273] CHIP:DMG:
[1631463550.601284][2265:2273] CHIP:DMG: }
[1631463550.601755][2265:2273] CHIP:ZCL: ReadAttributesResponse:
[1631463550.601797][2265:2273] CHIP:ZCL: ClusterId: 0x0000_0006
[1631463550.601832][2265:2273] CHIP:ZCL: attributeId: 0x0000_FFFD
[1631463550.601862][2265:2273] CHIP:ZCL: status: Success (0x0000)
[1631463550.601891][2265:2273] CHIP:ZCL: attribute TLV Type: 0x04
[1631463550.601925][2265:2273] CHIP:ZCL: attributeValue: 0
[1631463550.602038][2265:2273] CHIP:DMG: Client[0] moving to [INIT]
[1631463550.602076][2265:2273] CHIP:DMG: Client[0] moving to [UNINIT]
[1631463550.602116][2265:2273] CHIP:EM: Sending Standalone Ack for MsgId:0000002E
AttributeReadResult(path=AttributePath(nodeId=12344321, endpointId=2, clusterId=6, attributeId=65533), status=0, value=0)

[pjzander-signify]

The storage of attributes from dynamic endpoints in memory is not supported. The reason for this is that the memory that is needed to store (fixed endpoint) attributes is generated with ZAP and it can not handle storage of attributes that are added later.

In the bridge app examples (Linux and ESP32) the storage of the revision id's is in memory. This is in contrast with all the other attributes from dynamic endpoints that are stored externally. As a result of this, reading a cluster revision attribute from a dynamic endpoint will return an incorrect value.

[pjzander-signify]

The issue is solved in 44304c5.
Note that cluster revision id must be returned by the bridge application. See also the example of the bridge-app in the SDK.