Feature: add callback data to the bridge device type callback (CON-989) #811
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
I have added callback data to the bridge device type callback (
esp_matter_bridge::set_device_type
). Correspondingly, callback data has been integrated into theesp_matter_bridge::create_device
andesp_matter_bridge::resume_device
functions.Why
This enhancement allows for the efficient transmission of type-specific configuration data to the device during its creation. This is particularly beneficial in scenarios where passing such information to the
priv_data
parameter might not be ideal. Thepriv_data
parameter, typically passed to endpoint metadata and other callbacks likeattribute_callback
, can now be kept separate from configuration details.Use-case
In my specific use-case, I have implemented an abstraction layer above
esp-matter
. When a device is created, I aim to transmit both application user context (device object with application meta-data) and Matter-specific configuration (e.g., features for a generic switch). By utilizing the callback data, I can achieve a clean separation betweenpriv_data
and configurations within the abstraction layer. This proves to be advantageous as the abstraction layer does not need to be aware of the context structure inpriv_data
, resulting in a more organized and maintainable codebase.I believe that this enhancement aligns with common use-cases where developers desire to keep
priv_data
and configurations distinctly separated.