microwave_oven endpoint have two instance of operational_state and mode_base (CON-1752)

[ehsanziyaee]

Describe the bug
As we know, in the esp_matter_delegate_callbacks namespace, there has been an attempt to connect the CHIP clusters delegate class to the ESP-Matter clusters. In MicrowaveOvenControlDelegateInitCB, two instances—one for ModeBase and one for OperationalState—have been created again, even though their corresponding instance classes were already initialized in OperationalStateDelegateInitCB and InitModeDelegate.

This duplication of instance creation leads to a mismatch in behavior: some commands issued by ChipTool operate on one instance (e.g., reading the OperationalState attribute), while others operate on a different instance (e.g., handling the start or stop commands).

Specifically, the read command retrieves data from the instance created in OperationalStateDelegateInitCB, while state change commands are handled by the instance created in MicrowaveOvenControlDelegateInitCB.

This issue was confirmed by inspecting the operational-state-server.cpp implementation in CHIP and printing the memory addresses of both the instance and delegate. We observed that different commands accessed different instance pointers, proving the existence of this inconsistency.

Environment

• ESP-Matter Commit Id: (main branch v1.4)

• ESP-IDF Commit Id: (v5.4.2)

• SoC (eg: ESP32 or ESP32-C3): (ESP-S3)

• Device Logs (Please attach the log file):

• Host Machine OS: Ubuntu 24.04

• Host Machine Python version: 3.12.3

• Commissioner app and versions if present:

• Home hub app and versions if present:

• Commissioner's logs if present:

Any additional details
...

[jadhavrohit924]

Thanks for the report, we will fix it.

[ImerHamidovic]

@jadhavrohit924 Any news regarding this issue?

[ehsanziyaee]

I am also waiting for a suggestion. I think the structure and architecture of the esp-meteer are separating us from the instance classes in the chip without providing an alternative solution. The esp-matter system attribute also has its own access to the attributes and is separate from the CHIP. This double instance problem in the endpoints has also increased the problem. @jadhavrohit924 @ImerHamidovic

[ImerHamidovic]

@ehsanziyaee But did you at least manage to register your OperationalState delegate class, and are you able to handle the relevant commands? Because I am not able to do that.

[ehsanziyaee]

Look at this Issue: #1487 , u should add them manually if you want to use them directly. @ImerHamidovic

[ImerHamidovic]

Thanks a lot @ehsanziyaee for the hint! Can I please ask you for one more hint on which API to use to register the relevant commands for handling?

[ehsanziyaee]

@ImerHamidovic welcome. Go to the esp-matter-command namespace and search for your cluster's command, for this case (cluster::operational_state::command::create_start(your clusterId) )

[ImerHamidovic]

Thanks, and sorry for 'polluting' your discussion. I will check it out now, and I hope I will not have any questions for you afterwards.

[jadhavrohit924]

@ImerHamidovic @ehsanziyaee It is in internal review and will be out soon.