Is it by design that `attribute::create()` triggers `attribute_callback`?

[cyberxnomad]

Describe the question/query that you have
Is it by design that attribute::create() triggers attribute_callback?

Additional context
...

[shubhamdp]

@cyberxnomad What exactly is your question, please elaborate. attribute::create() just allocates the memory for storing the attribute, and adds it to the cluster's storage.

Where did you find that attribute::create() triggers attribute_callback.

[cyberxnomad]

Hi, @shubhamdp .

When I call esp_matter::endpoint::color_temperature_light::add(ep, &config);, the attribute_callback for chip::app::Clusters::LevelControl::CurrentLevel gets triggered.

I intend to prevent LevelControl when OnOff is Off (by returning an error during the PRE_UPDATE phase of the attribute). But when adding the device, the attribute_callback is triggered and returns an error, causing further Level control operations to no longer trigger attribute_callback.

[cyberxnomad]

Hi, @shubhamdp .

When I call esp_matter::endpoint::color_temperature_light::add(ep, &config);, the attribute_callback for chip::app::Clusters::LevelControl::CurrentLevel gets triggered.

I intend to prevent LevelControl when OnOff is Off (by returning an error during the PRE_UPDATE phase of the attribute). But when adding the device, the attribute_callback is triggered and returns an error, causing further Level control operations to no longer trigger attribute_callback.

Changing the default config before calling esp_matter::endpoint::xxx::add() may trigger attribute_callback.
One such case found:

    dimmable_light::config_t config;
    config.on_off_lighting.start_up_on_off = static_cast<uint16_t>(OnOff::StartUpOnOffEnum::kOn);

    dimmable_light::add(endpoint, &config);

[shubhamdp]

@cyberxnomad thanks for the context.

Yes, this is by design. It's not attribute::create() itself that triggers the callback — it's the Matter SDK cluster initialization that runs when the endpoint is enabled.

During initializeEndpoint(), the Matter SDK calls each cluster's ServerInitCallback, which goes through emberAfWriteAttribute() → MatterPreAttributeChangeCallback() → your attribute_callback.

Returning an error from PRE_UPDATE during initialization can leave the cluster in an inconsistent state. Instead of blocking LevelControl writes in PRE_UPDATE based on the OnOff state, consider checking the OnOff state in the POST_UPDATE callback and adjusting the actual hardware behavior there. The attribute value should be allowed to update (the Matter SDK expects this to succeed during init), but you can choose not to apply the change to hardware when OnOff is Off.

[cyberxnomad]

Hi, @shubhamdp .

Many thanks for your kind assistance.