Skip to content

Conversation

@hcarter-775
Copy link
Contributor

@hcarter-775 hcarter-775 commented Dec 29, 2025

Description of Change

Update all profiles to support statelessStep capabilities as needed. Include handlers for these step capabilities using the Matter-provided step commands.

This breaks apart the work found in #2669 so that the stateless capability support can be reviewed as an isolated unit.

Summary of Completed Tests

Unit tests added. Tested on-device.

@github-actions
Copy link

Duplicate profile check: Warning - duplicate profiles detected.
light-color-level-2200K-6500K.yml == light-color-level.yml
light-level-colorTemperature-2200K-6500K.yml == light-level-colorTemperature.yml

@github-actions
Copy link

@github-actions
Copy link

github-actions bot commented Dec 29, 2025

Test Results

   71 files  ±0    481 suites  +1   0s ⏱️ ±0s
2 490 tests +2  2 330 ✅  - 158  0 💤 ±0  0 ❌ ±0  160 🔥 +160 
4 274 runs  +3  4 028 ✅  - 243  0 💤 ±0  0 ❌ ±0  246 🔥 +246 

For more details on these errors, see this check.

Results for commit a76a265. ± Comparison against base commit 2192441.

♻️ This comment has been updated with latest results.

@github-actions
Copy link

github-actions bot commented Dec 29, 2025

File Coverage
All files 36%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/init.lua 68%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_handlers/attribute_handlers.lua 13%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_handlers/capability_handlers.lua 20%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_handlers/event_handlers.lua 24%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_utils/color_utils.lua 9%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_utils/device_configuration.lua 17%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_utils/embedded_cluster_utils.lua 32%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_utils/utils.lua 16%

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against a76a265

@hcarter-775 hcarter-775 force-pushed the feature/statelessStep branch from 80a5c0a to 00f1bf4 Compare January 7, 2026 19:16
Copy link
Contributor

@nickolas-deboom nickolas-deboom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I approved earlier but noticed there are some print statements from debugging I assume

@hcarter-775
Copy link
Contributor Author

@nickolas-deboom thanks for the catch, got those removed

Copy link
Contributor

@nickolas-deboom nickolas-deboom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Looks like there is are test failures but I ran the tests locally and they pass, so they might need to be re-run in CI

local endpoint_id = device:component_to_endpoint(cmd.component)
local step_mode = step_size > 0 and clusters.LevelControl.types.StepMode.UP or clusters.LevelControl.types.StepMode.DOWN
print("level:", step_size)
device:send(clusters.LevelControl.server.commands.Step(device, endpoint_id, step_mode, math.abs(step_size), fields.TRANSITION_TIME, fields.OPTIONS_MASK, fields.OPTIONS_OVERRIDE))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tpmanley @hcarter-775 What about using StepWithOnOff to turn on the light while it's off state?
Do we plan to support the level change during the 'off' state?

and Does transition(0) is best choice for the smooth transition? I wonder this is the best value from the test with real devices.
Now, all have '0' value.
lua_libs\st\matter\defaults\colorControl.lua
local TRANSITION_TIME = 0 --1/10ths of a second
lua_libs\st\matter\defaults\colorTemperature.lua
local TRANSITION_TIME = 0 --1/10ths of a second

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It really depends on the scenario, using the normal Step and a transition time of 0 is the most sensible default.

I have been playing with all those parameters for months with my custom driver for Matter lights and multiple buttons (including the new BILRESA scroll) so I will share the experience in case it is useful.

StepWithOnOff is great for dimmers that do not have on/off dedicated buttons since otherwise you would have no way to control the on/off state. It has two main drawbacks though:

  • Cannot set the lights to the minimum brightness level. Most of the time you end up with the light turned off because it's virtually impossible to stop at the minimum. Or just impossible if the minimum is 1% and the steps are, let's say, 10%, it will go from 10% to off with the final step.
  • If you are controlling multiple lights at the same time, they will all turn on or off. As a user, most of the time I do not want that behaviour and expect to control the brightness of the lights that are on, not turn on everything.

Transition time is a great feature of Matter that should have more presence in the capabilities. setLevel of switchLevel has it but not the commands to set colours or colour temperature. It is something requested time ago and the main reason for me to use a custom driver.

When it comes to stepping the brightness level, using transitions is tricky:

  • Some lights flood the hub with brightness level reports while stepping, especially before Matter 1.4 made quiet reporting mandatory. That makes the hub sluggish for a moment and the user would feel the dimming is not responsive. With some lights a transition time of 1 (tenth of a second) the experience is fine, with others it's better to leave it at 0 since they already apply some default transition anyway.
  • If two step commands are sent too close in time and the first one did not end the transition yet, the first step is essentially killed. That's easy to experience with a BILRESA scroll since the steps can happen too fast as you scroll.

For added flexibility, the capability should have optional second and third command arguments for the transition time and the withOnOff behaviour. That would make the default 0 and normal Step if not provided. Maybe it is not late to add them being a proposed capability not yet used elsewhere.

While unrelated to the steps, adding the transition time argument to the commands to set colour and temperature would be great too, like in setLevel of switchLevel capability. It should not break anything since the default is 0 anyway.

Copy link
Contributor

@inasail inasail Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hcarter-775 Thank you for your detailed explanation.
It could be linked to the below conversion, so we need decide more beneficial UX for the user.

  1. 'turning on' before changing the level
  2. keep 'off' state and just change level silently.
  3. doing nothing while 'off' state.

and Regarding the 'transition time', what about adding the preference setting in edge driver for this?
We can't expect same result for different models, so we can give an option to the user. (default:'0')
Definitely, we need to support multi-language for the new setting menu.
cc: @tpmanley

Copy link

@mocelet mocelet Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hcarter-775 Thank you for your detailed explanation

That was my comment actually, I hope I didn't create any confusion! I'm the developer of the Matter Playground custom driver and thought it was useful to share my feedback.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mocelet Oh, sorry my mistake. Thank you for sharing your thought and experience.

Copy link
Contributor Author

@hcarter-775 hcarter-775 Jan 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@inasail, after some internal discussion, I have updated the implementation to ignore step updates if the device is turned off, but without turning the device "on" if it is off, or vice versa. This decision was made in part from the idea that multiple lights may be connected to the knob, though brightening some should not necessarily turn them all on, if they were previously off. However, in this same vein, I also do not think the off devices should be affected while they are off.

Let me know if you disagree with this implementation.

Also, since this conversation is very similar to the one below, I am going to resolve that conversation for the moment. Feel free to re-open as needed.

@hcarter-775 hcarter-775 force-pushed the feature/statelessStep branch from 23eecf0 to 9b7146c Compare January 20, 2026 21:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants