-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Control state objects in LevelControl cluster for dynamic endpoints are never initialized #24645
Comments
@raven-worx Reading the issue my first thought was that the I don't have a sample app with dynamic endpoint creation to this out. Did you debug the calls of |
@jmartinez-silabs Yes i also debugged It should get called when i call For now as a workaround i added the few lines of |
Do you say that in your endpoint config for the dynamic endpoint? I am guessing not, because |
Ideally, we would auto-infer the init method somehow.... |
i am using the dynamic-bridge-app as a base |
Then that's possibly a bug in dynamic-bridge-app, depending on how it's setting up its clusters. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Reproduction steps
I am implementing a dynamic-bridge Matter device. Some of the dynamic endpoints have a LevelControl cluster added.
The problem now is that the LevelControl cluster doesn't work when the value is about to be changed via a command.
After debugging the LevelControl cluster implementation i found that the retrieved state pointer (eg. inside
moveToLevelHandler()
method) is not initialized properly.This is only the case for dynamically added endpoints. The dummy endpoint's (the endpoint to include all clusters in ZAP tool) state object gets initialized in
emberAfLevelControlClusterServerInitCallback()
. Especially themaxLevel
/minLevel
members remain 0 and thus the command never executes correctly.The attributes are set properly, see my endpoint dump attached.
Bug prevalence
always
GitHub hash of the SDK that was being used
43dd327
Platform
other
Platform Version(s)
1.0.0.2
Anything else?
repl_dump.txt
The text was updated successfully, but these errors were encountered: