Daniel Kneip

Unsure, when we run everything manually, we are able to do ./chip-tool levelcontrol read max-level 1 4 on the endpoint and get back [1662752589.533495][146309:146314] CHIP:TOO: MaxLevel: 254 as expected, which...

@bzbarsky-apple The following patch seems to resolve this issue for us: ``` diff --git a/src/app/clusters/level-control/level-control.cpp b/src/app/clusters/level-control/level-control.cpp index bcf52cd16..2ba741f40 100644 --- a/src/app/clusters/level-control/level-control.cpp +++ b/src/app/clusters/level-control/level-control.cpp @@ -875,6 +875,9 @@ static void stepHandler(EndpointId...

@bzbarsky-apple Can you review and let me know if you think that is a reasonable patch?

@jmartinez-silabs Our DUT is a Bridge, so this is a Bridged Device. We've been manually running this test case for debugging purposes. From our debugging, state->maxLevel is correct after emberAfLevelControlClusterServerInitCallback()...

@jmartinez-silabs We just found that the emberAfLevelControlClusterServerInitCallback() is receiving endpoint 2 when it should be endpoint 4. The moveTo command correctly uses endpoint 4, which is why the patch was...

@jmartinez-silabs It seems that `emberAfLevelControlClusterServerInitCallback` is only called at startup. Endpoint 2 is a dummy endpoint defined in the ZAP file that includes all the cluster definitions needed for our...

@jmartinez-silabs Please find attached a patch that fixes our issue and addresses some earlier concerns. Can you have a look? [level-control.cpp.patch.zip](https://github.com/project-chip/connectedhomeip/files/9601776/level-control.cpp.patch.zip)