-
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] LevelControl cluster is not working with dynamic endpoints #25401
Comments
It sounds like you are not calling |
See also #24645 which is a similar issue for dynamic-bridge. If that's what you're using, this is a duplicate of that issue. If you're doing something else and defining the clusters yourself, then those definitions need to be fixed accordingly... And yes, we need a better setup for this. |
Thank you for your prompt reply! I've just checked the linked issue and it looks similar. I used the "bridge-app" as the basis, not the "dynamic-bridge", but I think the end result is the same. I simply use the mentioned DECLARE_DYNAMIC_CLUSTER macro. |
Skipping init callbacks will in fact lead to incorrect behavior for OnOff (will not handle StartupOnOff attribute correctly), ModeSelect (will not handle StartUpMode correctly). The other clusters you list don't have any init logic, so not calling that non-existent logic is not a problem. |
@bzbarsky-apple Is this a local function in /app/clusters/level-control/level-control.cpp? |
You wouldn't. You would include the function pointer in your cluster definition on the endpoint, and then initializing the endpoint will call it. The function is declared in |
Thank you for your reply. But could you provide me some detail or sample code please. I define the cluster by marco:
|
Yes, that macro doesn't work right for clusters that need an init function. You'd need to look at what it expands to, do that instead of using the macro, and add the init function to the cluster definition. Or fix the macro to allow defining an init function. |
Sorry, I'm still not clear about what you mentioned. |
I managed to solve it by adding emberAfLevelControlClusterServerInitCallback(id); into emberAfSetDynamicEndpoint() function Thank you |
It's not. One of the fields in that struct is a list of various functions that can be called in various cases.... |
As far as sample code, |
Reproduction steps
I am working on a bridge device and have just tried the LevelControl cluster with a dynamic endpoint. The minLevel and maxLevel attributes are not read from the Application layer and are always zero. Therefore, the move-to-level command's Level value is irrelevant, since the range check changes the value always to zero.
The attributes are always read from the Application layer in other cluster server implementation with the ::Get call, but in the LevelControl cluster the minLevel and maxLevel attributes are not read.
I've made a little change in the moveToLevelHandler function of level-control.cpp and now it works. I don't know if this is the best solution, I've not digged so deep in this cluster server, but it works for me. :) It would be better to do this attribute read at initialization, since it won't change during runtime.
I've put these lines before the range check in moveToLevelHandler function:
// Get minLevel and maxLevel values status = Attributes::MinLevel::Get(endpoint, &state->minLevel); if (status != EMBER_ZCL_STATUS_SUCCESS) { emberAfLevelControlClusterPrintln("ERR: reading minimum level %x", status); return status; } status = Attributes::MaxLevel::Get(endpoint, &state->maxLevel); if (status != EMBER_ZCL_STATUS_SUCCESS) { emberAfLevelControlClusterPrintln("ERR: reading maximum level %x", status); return status; }
Bug prevalence
Whenever I try to change the level.
GitHub hash of the SDK that was being used
4088a77
Platform
core
Platform Version(s)
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: