WiFi and Thread network diagnostics clusters were unconditionally
created on the root node when their Kconfig flags were enabled,
regardless of the actual transport. A Thread-only device would
incorrectly include the WiFi Network Diagnostics cluster.
Gate cluster creation on transport-level defines so that WiFi
diagnostics are only added when WiFi is enabled, and Thread
diagnostics only when Thread is enabled.
Fixes https://github.com/espressif/esp-matter/issues/1649
Skip the Network Commissioning cluster on the root node when
CONFIG_CUSTOM_NETWORK_CONFIG is enabled, per Matter spec condition
(!CustomNetworkConfig). This allows devices with out-of-band network
configuration (rich UI, manufacturer-specific means) to omit the
cluster as the spec permits.
- Add CONFIG_CUSTOM_NETWORK_CONFIG Kconfig option
- Conditionally skip network_commissioning in root_node config/add
- Exclude integration.cpp from build when custom config enabled
- Add weak stubs for Plugin callbacks as fallback
- Also guarded secondary network device type and all the
attributes and commands that are part of network commissioning
cluster
emberAfSetDynamicEndpoint does not auto-detect device types to set
the isFlatComposition flag, unlike static endpoints in emberAfInit.
This causes Aggregator and Bridged Node endpoints registered dynamically
to use kTree composition instead of kFullFamily, resulting in PartsList
only listing direct children instead of all descendants.
After registering a dynamic endpoint, check if its device type is
Root Node, Aggregator, or Bridged Node and call
SetFlatCompositionForEndpoint to match the static endpoint behavior.
Closes https://github.com/espressif/esp-matter/issues/1741
cluster::destroy() freed the cluster memory and its children (attributes,
commands, events) but never removed the cluster from the parent endpoint's
linked list, leaving a dangling pointer. This caused use-after-free crashes
when creating a new cluster on the same endpoint after destroying one.
Fix: look up the parent endpoint via the endpoint_id stored in the cluster
struct and unlink before freeing, consistent with how attribute::destroy,
command::destroy and event::destroy handle their parent lists.
attribute::report() was ignoring the return value from set_val() and
always returning ESP_OK. This hid errors like ESP_ERR_NOT_SUPPORTED
for internally managed attributes (e.g., BooleanState::StateValue).
This fix:
- Propagates the error from set_val() back to the caller
- Checks return value of get_val() in report()
- Adds void cast to intentionally unchecked get_data_from_attr_val()
call in update()
Related: https://github.com/espressif/esp-matter/issues/1724
Backport of !1441 (main)
- Use the correct ESP32SecureCertDataProvider.h
- update the readme to list v1.4.2
- ci: bump idf-component-manager to v2.2 for external platform builds
- idf.py build complaining about older v2.1.2 of idf-component-manager so
bumping it.
- components/esp_matter: run the generate_zap_common_files.py, and
commit delta
compatibility adjustments
Added global variable for temperature unit for deferred
setting when enabling endpoint. Compatibility functions to
handle temperature unit attribute reads and writes,
ensuring seamless integration with previous versions.
Also, added a function to retrieve the cluster id and endpoint id for
internally managed attribues.
Storage of this attribute was moved from esp-matter to
connectedhomeip during the v1.4.2 release by implementing the AAI in
connectedhomeip. For most clusters, AAI registration occurs in the
cluster-init callback, but for this Air Quality cluster, it is
delegated to the application layer. So, in the esp-matter's workflow,
no one registers the AAI. And, as this attribute is of primitive type,
we can discard the ATTRIBUTE_FLAG_MANAGED_INTERNALLY flag and storage
can be managed by esp-matter.
Shu Chen
chendejin
Hrishikesh Dhayagude
Shubham Patil
shripad621git
Rohit
WanqQixiang
mahesh