[BUG] Incorrect scene table data for lighting products

[Jim-tech]

Reproduction steps

Brief description:
I was testing the Scenes Management Cluster on Matter SDK 1.3 and was trying to evaluate the NVM space for the scene table. I then observed some abnormals for the scene table entry. The entry size is quite bigger than expected.

Reproducing:

1. Commission the device with chip-tool and set the node ID of the device to 1.

./chip-tool pairing ble-wifi 1 <ssid> <wifi password> <pass-code> <discriminator>

2. Run the following commands. (These commands are from the Matter testplan verification steps)

./chip-tool groupkeymanagement key-set-write '{"groupKeySetID": "0x01a1","groupKeySecurityPolicy": 0, "epochKey0":"a0a1a2a3a4a5a6a7a8a9aaabacadaeaf","epochStartTime0": 1110000,"epochKey1":"b0b1b2b3b4b5b6b7b8b9babbbcbdbebf", "epochStartTime1": 1110001,"epochKey2":"c0c1c2c3c4c5c6c7c8c9cacbcccdcecf", "epochStartTime2": 1110002 }' 1 0

./chip-tool groupkeymanagement key-set-write '{"groupKeySetID": "0x01a2","groupKeySecurityPolicy": 0, "epochKey0":"d0d1d2d3d4d5d6d7d8d9dadbdcdddedf","epochStartTime0": 2220000,"epochKey1":"e0e1e2e3e4e5e6e7e8e9eaebecedeeef", "epochStartTime1": 2220001,"epochKey2":"f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff", "epochStartTime2": 2220002 }' 1 0

./chip-tool groupkeymanagement write group-key-map '[{"groupId": "0x0101", "groupKeySetID": "0x01a1", "fabricIndex": 1}, {"groupId": "0x0102", "groupKeySetID": "0x01a2", "fabricIndex": 1} ]' 1 0

./chip-tool groups add-group 0x0101 Gp1 1 1

./chip-tool groups add-group 0x0102 Gp2 1 1

./chip-tool accesscontrol write acl '[{"privilege": 5, "authMode": 2, "subjects": null, "targets": null}, {"privilege": 4, "authMode": 3, "subjects": null, "targets": null}]' 1 0

./chip-tool scenesmanagement remove-all-scenes 0x0101 1 1

./chip-tool scenesmanagement remove-all-scenes 0x0102 1 1

./chip-tool scenesmanagement get-scene-membership 0x0101 1 1

3. Run the following command to create a scene entry.

./chip-tool scenesmanagement add-scene 0x0101 0x01 1000 "scene name1" '[{"clusterID": "0x0006", "attributeValueList":[{"attributeID": "0x0000", "attributeValue": "0x00"}]}, {"clusterID": "0x0008", "attributeValueList":[{"attributeID": "0x0000", "attributeValue": "0x64"}]}, {"clusterID": "0x0300", "attributeValueList":[{"attributeID": "0x0000", "attributeValue": "0x80"}, {"attributeID": "0x0001", "attributeValue": "0x80"}, {"attributeID": "0x0003", "attributeValue": "0x616B"}, {"attributeID": "0x0004", "attributeValue": "0x607D"}]}]' 1 1

4. After that I checked the scene table entry saved in NVM. the entry size is 215 bytes. This is obviously abnormal. Below is the entry content in NVM.

key: f/1/e/1/sc/1
        value(len:215):
                15 25 04 01 01 24 05 02 25 07 e8 03 36 01 15 24         .%...$..%...6..$
                02 06 30 03 80 00 00 00 00 00 00 00 00 00 00 00         ..0.............
                00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00         ................
                00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00         ................
                00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00         ................
                00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00         ................
                00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00         ................
                00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00         ................
                00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00         ................
                00 00 00 00 00 18 15 24 02 08 30 03 0a 16 15 24         .......$..0....$
                00 00 24 01 64 18 18 18 15 25 02 00 03 30 03 24         ..$.d....%...0.$
                16 15 24 00 00 24 01 80 18 15 24 00 01 24 01 80         ..$..$....$..$..
                18 15 24 00 03 25 01 6b 61 18 15 24 00 04 25 01         ..$..%.ka..$..%.
                7d 60 18 18 18 18 18    }`.....

5. By parsing the entry, we can see, there are 80 bytes to represent the On/Off attribute value.

Expected Result
The expected result should be like below:

key: f/1/e/1/sc/0
        value(len:97):
                15 25 04 01 01 24 05 01 25 07 e8 03 36 01 15 24         .%...$..%...6..$
                02 06 30 03 0a 16 15 24 00 00 24 01 00 18 18 18         ..0....$..$.....
                15 24 02 08 30 03 0a 16 15 24 00 00 24 01 64 18         .$..0....$..$.d.
                18 18 15 25 02 00 03 30 03 24 16 15 24 00 00 24         ...%...0.$..$..$
                01 80 18 15 24 00 01 24 01 80 18 15 24 00 03 25         ....$..$....$..%
                01 6b 61 18 15 24 00 04 25 01 7d 60 18 18 18 18         .ka..$..%.}`....
                18      .	

Root Cause Analysis
I checked the source code and did some trouble-shooting. I think the root cause is in the file src/app/clusters/on-off-server/on-off-server.cpp.

If "StartUpOnOff" attribute of the On/Off cluster is not set to NVM, the default scene handler will not be registered for the On/Off cluster. This is exactly the case on my device.
I think registering the scene handler should be independent on this "StartUpOnOff" attribute.
Could you check? Thanks.

Bug prevalence

Whenever I do this

GitHub hash of the SDK that was being used

5bb5c9e

Platform

esp32

Platform Version(s)

No response

Anything else?

No response

[lpbeliveau-silabs]

Agreed, the handler registration should not be in this ifdef. Will move it shortly.