-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[Scenes] Level control handler bugfix #29076
[Scenes] Level control handler bugfix #29076
Conversation
…ssary typing and added doc on on-off and level control handlers interactions
PR #29076: Size comparison from 14cbb32 to 63bd2cb Increases (12 builds for bl702, bl702l, esp32, linux, psoc6, telink)
Decreases (11 builds for cc32xx, efr32, esp32, nrfconnect, psoc6, telink)
Full report (67 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lpbeliveau-silabs could we update the summary to contain things a bit clearer on what to expect in the PR?
Title says "bugfix" but it never says what bug... so the summary links to an issue and if opening the issue, that links to a PR review.
That is a lot of steps for reviewers and when this log becomes part of the git history it will likely not be useful either.
Could we explain what the bug was and what the fix is?
Co-authored-by: Junior Martinez <[email protected]>
Summary updated. |
PR #29076: Size comparison from 14cbb32 to e32c08f Increases (15 builds for bl702, bl702l, efr32, esp32, linux, nrfconnect, psoc6, telink)
Decreases (12 builds for cc32xx, efr32, esp32, nrfconnect, psoc6, telink)
Full report (67 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
} | ||
else | ||
{ | ||
chip::app::NumericAttributeTraits<uint32_t>::SetNull(pairs[0].attributeValue); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But ApplyScene was not fixed, so this is broken.... How was this tested?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, If null value (255) for a uint8_t is stored, this will cause the ApplyScene to fail as we are asking to move to a value outside of the boundaries.
This will return failure to the Apply Scene. Is the expected behavior here to silently fail instead of explicitly letting the user know the scene wasn't applied?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would think the expected behavior is to move to the values that were stored in the scene, including a null level if that's what was stored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, so we do not want that recall scene to end up in a failure.
How do we expect the level to behave to a null level? Value capped at maximum or lowest possible value, remaining at current level?
So basically, we either ignore the level command silently, ignore the whole scene returning an error (current implementation), or move to an unexpected level.
Say we explicitly add a scene with a null value, we could say this behaves as expected, but what if null is added from a save scene. This means the user just saved the current scene while the level value was null. This probably means the user was not expecting the level to have an impact when restoring the scene.
By that reasoning, should we decide that silently ignoring the move to null seems like the expected behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we expect the level to behave to a null level?
Well, how was it behaving when the scene was saved?
The questions you are asking are spec questions, not implementation questions, no? If the spec does not define this, it needs to...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The MoveToLevel Command states that the command SHALL have the Level data field, constrained between 0 to 254. We do not respect that, therefore this should result in an error.
However the RecallScene states that the status of RecallScene at step 3 (applying EFS) SHALL be SUCCESS, so my initial interpretation seems wrong, silent failure seems to be the way here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does the spec say that recalling a scene involves a MoveToLevel command? Seems like if that's the intent the spec needs to say it...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
set the attributes and corresponding state of the cluster accordingly.
The "corresponding state of the cluster" bits.
Either way, setting the attributes to null without taking an action on the actual level would mean read level won't reflect the actual state of the cluster if no action is taken.
Now does it have to be the actual moveToLevel command, the spec doesn't precise it. So we could technically create a separate function that allows us to move the level to "null" but that is still not defined right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lpbeliveau-silabs Indeed.
* Used NumericAttributesTraits for storage null values, removed un-necessary typing and added doc on on-off and level control handlers interactions * Update src/app/clusters/on-off-server/on-off-server.cpp Co-authored-by: Junior Martinez <[email protected]> --------- Co-authored-by: Junior Martinez <[email protected]>
* Used NumericAttributesTraits for storage null values, removed un-necessary typing and added doc on on-off and level control handlers interactions * Update src/app/clusters/on-off-server/on-off-server.cpp Co-authored-by: Junior Martinez <[email protected]> --------- Co-authored-by: Junior Martinez <[email protected]>
Addresses : #29033
Solves broken null value storage by adding proper null handling for storing the current level.
Also removes un-necessary explicit typing and documents the behavior of the on-off handler when the level-control handler is registered.