What is the right mechanism for fixed attributes? (CON-1103)

[jonsmirl]

Some comments from Boris makes me question how fixed attributes are handled in esp-matter.

Right now they are put into the attribute partition using mfg tool. But then what about OTA? Say you OTA in a different image supporting new locales. OTA can't update the attribute partition.

That leads me to conclude we are using the wrong mechanism to store fixed attributes. An alternative scheme could work like this....

1. User app defines the fixed attributes as an array of constants.
2. When the cluster is created, pass the array into esp-matter
3. esp-matter internally uses attribute overrides to turn the constants into fixed attributes.
   Now the attributes update with OTA.

You'll still use mfg_tool for the certificates, it is just the fixed strings which would move into the code.

This brings up some interesting problems with rebranding. Is there a generic OTA image for all brands? or does each branch need an OTA image? I'd probably lean to each brand needing an image (the OEM vendor would produce an OTA image for each licensed brand).

The "Device instance information options" should use the existing mechanism.
The "Device instance options" need to use code constants. (this also solves the problem of how to internationalize Fixed Labels)

Device instance information options:
  -v VENDOR_ID, --vendor-id VENDOR_ID             Vendor id
  --vendor-name VENDOR_NAME                       Vendor name
  -p PRODUCT_ID, --product-id PRODUCT_ID          Product id
  --product-name PRODUCT_NAME                     Product name
  --hw-ver HW_VER                                 Hardware version
  --hw-ver-str HW_VER_STR                         Hardware version string
  --mfg-date MFG_DATE                             Manufacturing date in format YYYY-MM-DD
  --serial-num SERIAL_NUM                         Serial number
  --enable-rotating-device-id                     Enable Rotating device id in the generated binaries
  --rd-id-uid RD_ID_UID                           128-bit unique identifier for generating rotating
                                                  device identifier, provide 32-byte hex string, e.g.
                                                  "1234567890abcdef1234567890abcdef"

Device instance options:
  --calendar-types CALENDAR_TYPES [CALENDAR_TYPES ...]
                                                  List of supported calendar types. Supported Calendar
                                                  Types: Buddhist, Chinese, Coptic, Ethiopian,
                                                  Gregorian, Hebrew, Indian, Islamic, Japanese, Korean,
                                                  Persian, Taiwanese
  --locales LOCALES [LOCALES ...]                 List of supported locales, Language Tag as defined by
                                                  BCP47, eg. en-US en-GB
  --fixed-labels FIXED_LABELS [FIXED_LABELS ...]  List of fixed labels, eg: "0/orientation/up"
                                                  "1/orientation/down" "2/orientation/down"
  --supported-modes SUPPORTED_MODES [SUPPORTED_MODES ...]
                                                  List of supported modes, eg:
                                                  mode1/label1/ep/"tagValue1\mfgCode, tagValue2\mfgCode"
                                                  mode2/label2/ep/"tagValue1\mfgCode, tagValue2\mfgCode"
                                                  mode3/label3/ep/"tagValue1\mfgCode, tagValue2\mfgCode"

[shubhamdp]

@jonsmirl Agreed on the fixed attributes part, they has to be the part of code and OTA-able. Will see how this can be sorted.

[shubhamdp]

I have raised a PR https://github.com/project-chip/connectedhomeip/pull/32893/files which adds few APIs to set that fixed data.
In esp-matter, we'll hide the one level complexity through cluster::create() and take these strings as input and then the cluster create will call the appropriate APIs.

[shubhamdp]

Hi @jonsmirl, here's how we can update the fixed type attributes in device info provider, https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/esp32/providers.md#example.

I'm checking how this can be handled/consumed when creating the esp-matter data model.