Z-wave switchLevel handler overrides dimming duration configured on device

The function below is from st.zwave.defaults.switchLevel:

--- Issue a level-set command to the specified device.
---
--- @param driver st.zwave.Driver
--- @param device st.zwave.Device
--- @param command table ST level capability command
function capability_handlers.switch_level_set(driver, device, command)
  local set
  local get
  local delay = constants.MIN_DIMMING_GET_STATUS_DELAY -- delay in seconds
  local level = utils.round(command.args.level)
  level = utils.clamp_value(level, 1, 99)

  if device:is_cc_supported(cc.SWITCH_MULTILEVEL) then
    local dimmingDuration = command.args.rate or constants.DEFAULT_DIMMING_DURATION -- dimming duration in seconds
    -- delay shall be at least 5 sec.
    delay = math.max(dimmingDuration + constants.DEFAULT_POST_DIMMING_DELAY, delay) -- delay in seconds
    get = SwitchMultilevel:Get({})
    set = SwitchMultilevel:Set({ value=level, duration=dimmingDuration })
  elseif device:is_cc_supported(cc.BASIC) then
    get = Basic:Get({})
    set = Basic:Set({ value=level})
  end
  device:send_to_component(set, command.component)
  local query_level = function()
    device:send_to_component(get, command.component)
  end
  device.thread:call_with_delay(delay, query_level)
end

The line below sets dimming duration to either the rate passed by the switchLevel capability or a default of 1 second. However, many dimmers have default dimming rates built in. Those device-specific default dimming rates would be prefereable to defaulting to a 1-second duration since they may be user configurable. Having the handler for switchLevel send a 1-second duration overrides those dimming settings programmed on the device.

local dimmingDuration = command.args.rate or constants.DEFAULT_DIMMING_DURATION -- dimming duration in seconds

To compound matters, there is currently no way for a user to specify that the device’s default dimming duration should be used. The setLevel capability allows a second argument (rate, a non-negative integer) to be passed. However, the ST app currently provides no way through device controls, routines, or scenes to specify what that rate should be.

Even if the rate argument could be passed, the duration parameter for z-wave commands (see here as an example) is set up to expect the string “default” to be passed in order for the device to use its default rate settings. Since setLevel’s rate argument is an integer, there is no way for the user to send “default”.

@nayelyz Could the default handler be changed to use “default” as the dimming duration, instead of 1 second, when rate is not specified in the setLevel command? If a user desired a 1 second dimming duration, they would still be able to specify that using the rate argument (assuming the app is modified to allow that argument to be used).

4 Likes

Hi, @philh30.

Thank you for sharing this, I’ll create a report for the team to look at. In the meantime, are you using a custom handler?

Hi, @philh30!

Just following up on this issue, the team mentioned the fix is included in the v46 of the firmware which was recently released for the Beta group. Are you part of it? If so, can you help us check if it’s solved, please?

@nayelyz I do have the v46 firmware. Unfortunately that firmware seems to have further constrained the amount of memory available to Edge drivers (or perhaps it added to the amount of memory used by each driver?). I’ve found I can only run 11 drivers before the proactive driver reboots kick in. I’m sorry but I simply don’t have room on my hub to spin up a driver to test the new default handler. I’ve had to drop several integrations and get creative with combining others just to keep my hub stable and running what I need in my house.

I hope the team is also looking at the hub memory issues and developing some tools to help users view and manage their hubs better. I’ve certainly noticed an uptick in the number of forum users running into (or blowing past) the memory caps.

I’ve created reports about that for users that have memory issues active because that’s where the team can get data from. Unfortunately, I don’t have more information but thanks for letting us know about your experience, I’ll add this as a note to the report on this issue.

The z-wave specs shows that value 0xFF is a valid duration value for the Switch Multilevel Set command so why does the platform change it to 240?

I was hoping that might be a workaround to the original issues…

Hi, @krlaframboise
Are you using the libraries from v46? The constant used for the dimming duration was modified and also the default libraries were modified accordingly.

I’m using the latest version available and I’m aware of those other changes because they broke some of my tests, but this is something different.

If you look at those screenshots you’ll see that the test is written to expect a duration of 0xFF/255, but the platform is altering the test and expecting 240 instead. It’s not just the test because if you send a duration of 255 to a device it also gets changed to 240 before it’s sent.

I was just pointing out that 255/0xFF is a valid duration value according to the command class specs and wondering why the platform is changing it…