constants.DEFAULT_DIMMING_DURATION, which was defined in the 45.x libraries as an integer type and with a value of 1 sec, has been changed in the 46.x libraries to a “string” type and a “default” value.
libraries 45.x
--- @class st.zwave.constants
--- @alias constants st.zwave.constants
--- @field public TEMPERATURE_SCALE string
--- @field public DEFAULT_DIMMING_DURATION number
--- @field public DEFAULT_POST_DIMMING_DELAY number
--- @field public MIN_DIMMING_GET_STATUS_DELAY number
--- @field public DEFAULT_GET_STATUS_DELAY number
local constants = {}
constants.TEMPERATURE_SCALE = "_temperature_scale"
constants.DEFAULT_DIMMING_DURATION = 1 --seconds
constants.DEFAULT_POST_DIMMING_DELAY = 2 --seconds
constants.MIN_DIMMING_GET_STATUS_DELAY = 5 --seconds
constants.DEFAULT_GET_STATUS_DELAY = 1 --seconds
Libraries 46.x
--- @class st.zwave.constants
--- @alias constants st.zwave.constants
--- @field public TEMPERATURE_SCALE string
--- @field public DEFAULT_DIMMING_DURATION string
--- @field public DEFAULT_POST_DIMMING_DELAY number
--- @field public MIN_DIMMING_GET_STATUS_DELAY number
--- @field public DEFAULT_GET_STATUS_DELAY number
local constants = {}
constants.TEMPERATURE_SCALE = "_temperature_scale"
-- The string "default" has special interpretation by the following command classes when passed as a duration argument:
-- - SceneControllerConf
-- - SwitchBinary
-- - SwitchMultilevel
-- - SceneActuatorConf
-- - WindowCovering
-- - SceneActivation
-- - SwitchColor
constants.DEFAULT_DIMMING_DURATION = "default"
constants.DEFAULT_POST_DIMMING_DELAY = 2 --seconds
constants.MIN_DIMMING_GET_STATUS_DELAY = 5 --seconds
constants.DEFAULT_GET_STATUS_DELAY = 1 --seconds
The drivers that use the defualt handlers to handle switchLevel, colorControl and colorTemperature have been updated to this change
The idiots that we have made drivers with custom handlers based on the defaults of libraries prior to 46.x is causing errors when doing arithmetic calculations with a string.
2023-02-02T19:46:11.618091261+00:00 INFO Z-Wave Bulb Mc <ZwaveDevice: xxxxxxxxx [BF] (Study Credenza LEDs)> sending Z-Wave command: {args={color_components={{color_component_id=“WARM_WHITE”, value=255}}}, cmd_class=“SWITCH_COLOR”, cmd_id=“SET”, dst_channels={}, encap=“AUTO”, payload=“\x01\x00\xFF”, src_channel=0, version=1}
2023-02-02T19:46:11.619322636+00:00 ERROR Z-Wave Bulb Mc Study Credenza LEDs thread encountered error: [string “st/dispatcher.lua”]:233: Error encountered while processing event for <ZwaveDevice: xxxxxxxx [BF] (Study Credenza LEDs)>:
arg1: table: 0x1674140
[string “st/dispatcher.lua”]:233: Error encountered while processing event for <ZwaveDevice: xxxxxxxxxx [BF] (Study Credenza LEDs)>:
arg1: table: 0x1674140
[string “fibaro-rgbw-controller/init.lua”]:134: attempt to perform arithmetic on a string value (field ‘DEFAULT_DIMMING_DURATION’)
In case it helps anyone, if they are bored and want to review their drivers in the switchLevel, colorControl and colorTemperature custom handlers.
I think smartthing will also have to review some of its stock drivers
Hi, @Mariano_Colmenarejo
This was already reported by another developer and I shared it with the team.
I’ll include your comment as well. Thank you for sharing your experience.
Hi, @Mariano_Colmenarejo.
Following up, this change was made due to this report from another developer asking us to avoid setting a default value as devices can have a built-in configuration for the dimming duration.
So, in the default library for switchLevel, when it’s detected that the dimmingDuration value is not a number, it will cast it to the reserved value of the device.
If you need a constant variable duration you can use DEFAULT_GET_STATUS_DELAY or DEFAULT_POST_DIMMING_DELAY
I understand this change wasn’t included explicitly in the firmware update announcement, I’ll share this with the team.
In fact, these constants were used in some stock drivers to calculate the delay to GET the established value after sending a SET command and when a string was found, it gave an error.
The stock drivers were corrected when modifying the libraries, but the custom drivers that used copies of the default ones from the previous libraries began to give errors because they were not informed of the change.
It would be good if they announced these changes since there are many users using custom drivers for devices that the stock drivers do not support
Yes, that’s why I mentioned this before, I’ll share this situation with the team to make them aware that this wasn’t included in the announcement’s notes for future cases and see if we can include this in the one where it changed.
I would suggest that you check with the team to see if this API change was actually intended or of it’s a mistake. Changing acceptable values for a defined API input or response is extraordinarily bad as it guarantees breaking already written code. Better to add a new attribute with new acceptable values and then eventually deprecate the old one, only deleting it after several years and consistent messaging to the developer community about the deletion date.
This is basic API design stuff and shouldn’t need stating but apparently it does!
Hi all, thanks for the feedback. We have updated the 46.08 release post with the recent changes to the Lua libraries for clarity. Going forward we will ensure if there are any library changes as part of a hub firmware release they are called out in the release notes.