[SmartThings Edge] Issue with default function to send Z-Wave configuration parameters

@nayelyz,
The function that is used by default in Z-Wave drivers to send configuration values to the different parameters of the devices gives an error:

--- Handle preference changes
---
--- @param driver st.zwave.Driver
--- @param device st.zwave.Device
--- @param event table
--- @param args
local function info_changed(driver, device, event, args)
  local preferences = preferencesMap.get_device_parameters(device)
  for id, value in pairs(device.preferences) do
    if args.old_st_store.preferences[id] ~= value and preferences and preferences[id] then
      local new_parameter_value = preferencesMap.to_numeric_value(device.preferences[id])
      device:send(Configuration:Set({parameter_number = preferences[id].parameter_number, size = preferences[id].size, configuration_value = new_parameter_value}))
    end
  end
end
  • when trying to send a parameter value greater than 32767 (0x7FFF)
device:send(Configuration:Set({parameter_number = preferences[id].parameter_number, size = preferences[id].size, configuration_value = new_parameter_value}))
  • The error is in the st/utils.lua module, line 188: bad argument #2 to ‘pack’ (integer overflow)
--- Serialize an integer into a bytestring.
---
--- @param value number value to write
--- @param width number integer width in bytes
--- @param signed boolean true if signed, false if unsigned
--- @param little_endian boolean true if little endian, false if big endian
--- @return string serialized integer as byte string
function utils.serialize_int(value, width, signed, little_endian)
  local pattern = ">"
  if little_endian then
    pattern = "<"
  end
  if signed then
    pattern = pattern .. "i"
  else
    pattern = pattern .. "I"
  end
  pattern = pattern .. width
  return string.pack(pattern, value)
end

In some Fibaro devices it is necessary to send values up to 65535 (0xFFFF), to configure energy and power reports in seconds.

I would swear that with the previous 41.x libraries it worked fine, but I’m not sure and I don’t see any changes in that function for the 42.x libraries.

These are the logs of sending a correct configuration value 32767 (0x7FFF)

2022-04-23T15:51:34.592156003+00:00 INFO Z-Wave Switch MIO  <ZwaveDevice: bd5c15c7-76f5-4430-b95d-c8ea349e9f61 [1E] (Luz Entrada)> received lifecycle event: infoChanged
2022-04-23T15:51:34.667414003+00:00 TRACE Z-Wave Switch MIO  Found DeviceLifecycleDispatcher handler in zwave_switch
2022-04-23T15:51:34.675446003+00:00 PRINT Z-Wave Switch MIO  Preference Changed >>>     ch1TimeParameter        Old Value >>>>>>>>>     33000.0 Value >>        32767.0
2022-04-23T15:51:34.683953669+00:00 INFO Z-Wave Switch MIO  <ZwaveDevice: bd5c15c7-76f5-4430-b95d-c8ea349e9f61 [1E] (Luz Entrada)> sending Z-Wave command: {args={configuration_value=32767, default=false, parameter_number=12, size=2}, cmd_class="CONFIGURATION", cmd_id="SET", dst_channels={}, encap="AUTO", payload="\x0C\x02\x7F\xFF", src_channel=0, version=1}
2022-04-23T15:51:34.694848336+00:00 TRACE Z-Wave Switch MIO  Z-Wave command(002ad834) queued for radio transmission: CC:Configuration, CID:0x04
2022-04-23T15:51:34.700183003+00:00 PRINT Z-Wave Switch MIO  Memory >>>>>>>     1720.921875      Kbytes
2022-04-23T15:51:34.705995003+00:00 DEBUG Z-Wave Switch MIO  Luz Entrada device thread event handled
2022-04-23T15:51:34.909335336+00:00 TRACE Z-Wave Switch MIO  Z-Wave command(002ad834) transmit status: TRANSMIT_COMPLETE_OK

And these are the ones with a value of 32768 (0x8000), which gives the error

2022-04-23T15:51:43.278250670+00:00 TRACE Z-Wave Switch MIO  Received event with handler device_lifecycle
2022-04-23T15:51:43.309074337+00:00 INFO Z-Wave Switch MIO  <ZwaveDevice: bd5c15c7-76f5-4430-b95d-c8ea349e9f61 [1E] (Luz Entrada)> received lifecycle event: infoChanged
2022-04-23T15:51:43.396378670+00:00 TRACE Z-Wave Switch MIO  Found DeviceLifecycleDispatcher handler in zwave_switch
2022-04-23T15:51:43.405161337+00:00 PRINT Z-Wave Switch MIO  Preference Changed >>>     ch1TimeParameter        Old Value >>>>>>>>>     32767.0 Value >>        32768.0
2022-04-23T15:51:43.411998670+00:00 ERROR Z-Wave Switch MIO  Luz Entrada thread encountered error: [string "st/dispatcher.lua"]:229: Error encountered while processing event for 
<ZwaveDevice: bd5c15c7-76f5-4430-b95d-c8ea349e9f61 [1E] (Luz Entrada)>:
    arg1: infoChanged
    arg2: table: 0xc09678
[string "st/utils.lua"]:188: bad argument #2 to 'pack' (integer overflow)

It also occurs in the parameter values of size= 1 Byte (0 to 255) 0x00 to 0xFF

2022-04-23T07:46:04.599561484+00:00 TRACE Z-Wave Switch Mc Received event with handler device_lifecycle
2022-04-23T07:46:04.609753984+00:00 INFO Z-Wave Switch Mc <ZwaveDevice: 7026948e-c577-4118-9340-a219524d1e4e [65] (Zzz Store Plug)> received lifecycle event: infoChanged
2022-04-23T07:46:04.628990859+00:00 TRACE Z-Wave Switch Mc Found DeviceLifecycleDispatcher handler in zwave_switch
2022-04-23T07:46:04.632657859+00:00 PRINT Z-Wave Switch Mc Preference Changed >>> powerReportFrequency Old Value >>>>>>>>> 255.0 Value >> 254.0
2022-04-23T07:46:04.637461234+00:00 ERROR Z-Wave Switch Mc Zzz Store Plug thread encountered error: [string “st/dispatcher.lua”]:229: Error encountered while processing event for <ZwaveDevice: 7026948e-c577-4118-9340-a219524d1e4e [65] (Zzz Store Plug)>:
arg1: infoChanged
arg2: table: 0x1940050
[string “st/utils.lua”]:188: bad argument #2 to ‘pack’ (integer overflow)
2 Likes

Not really my thing but I see in the logs …

{configuration_value=32767, default=false, parameter_number=12, size=2}

I believe the size is the parameter size in bytes? So are you saying somewhere the ST Library is assuming a signed integer when it should unsigned, hence the overflow?

1 Like

Yes it is correct size is the size in Bytes
In this case the parameter needs 2 Bytes (0xFFFF) unsigned.

Indeed Function seems that it packs value as a 2-Byte signed integer.

  • Positives from 0x0000 to 0x7FFF (0 a 32767)
  • Negative from 0x8000 to 0xFFFF (-1 a -32768)
--- Serialize an integer into a bytestring.
---
--- @param value number value to write
--- @param width number integer width in bytes
--- @param signed boolean true if signed, false if unsigned
--- @param little_endian boolean true if little endian, false if big endian
--- @return string serialized integer as byte string
function utils.serialize_int(value, width, signed, little_endian)
  local pattern = ">"
  if little_endian then
    pattern = "<"
  end
  if signed then
    pattern = pattern .. "i"
  else
    pattern = pattern .. "I"
  end
  pattern = pattern .. width
  return string.pack(pattern, value)
end

This function try returns and get error:

string.pack(">i2", 32768)

It should pack it as a 2-byte unsigned integer. from 0x0000 to 0xFFFF (0 a 65535)

string.pack(">I2", 32768)

In the logs can see:

  • if you send from 32767 to -32768 pack it well
2022-04-23T15:51:34.675446003+00:00 PRINT Z-Wave Switch MIO  Preference Changed >>>     ch1TimeParameter        Old Value >>>>>>>>>     33000.0 Value >>        32767.0
2022-04-23T15:51:34.683953669+00:00 INFO Z-Wave Switch MIO  <ZwaveDevice: bd5c15c7-76f5-4430-b95d-c8ea349e9f61 [1E] (Luz Entrada)> sending Z-Wave command: {args={configuration_value=32767, default=false, parameter_number=12, size=2}, cmd_class="CONFIGURATION", cmd_id="SET", dst_channels={}, encap="AUTO", payload="\x0C\x02\x7F\xFF", src_channel=0, version=1}
2022-04-23T15:51:34.694848336+00:00 TRACE Z-Wave Switch MIO  Z-Wave command(002ad834) queued for radio transmission: CC:Configuration, CID:0x04
2022-04-23T15:51:34.700183003+00:00 PRINT Z-Wave Switch MIO  Memory >>>>>>>     1720.921875      Kbytes
2022-04-23T15:51:34.705995003+00:00 DEBUG Z-Wave Switch MIO  Luz Entrada device thread event handled
2022-04-23T15:51:34.909335336+00:00 TRACE Z-Wave Switch MIO  Z-Wave command(002ad834) transmit status: TRANSMIT_COMPLETE_OK
022-04-24T09:51:07.764813545+00:00 PRINT Z-Wave Switch MIO  Preference Changed >>>     ch1TimeParameter        Old Value >>>>>>>>>     -32769  Value >>        -32767
2022-04-24T09:51:07.785159878+00:00 INFO Z-Wave Switch MIO  <ZwaveDevice: bd5c15c7-76f5-4430-b95d-c8ea349e9f61 [1E] (Luz Entrada)> sending Z-Wave command: {args={configuration_value=-32767, default=false, parameter_number=12, size=2}, cmd_class="CONFIGURATION", cmd_id="SET", dst_channels={}, encap="AUTO", payload="\x0C\x02\x80\x01", src_channel=0, version=1}
2022-04-24T09:51:07.803672878+00:00 TRACE Z-Wave Switch MIO  Z-Wave command(f4d003ff) queued for radio transmission: CC:Configuration, CID:0x04
2022-04-24T09:51:07.819017878+00:00 PRINT Z-Wave Switch MIO  Memory >>>>>>>     1995.7607421875  Kbytes
2022-04-24T09:51:07.833181545+00:00 DEBUG Z-Wave Switch MIO  Luz Entrada device thread event handled   
2022-04-24T09:51:07.999419878+00:00 TRACE Z-Wave Switch MIO  Z-Wave command(f4d003ff) transmit status: TRANSMIT_COMPLETE_OK
  • if you send > 32767 or < -32768 it packs it wrong
2022-04-23T15:51:43.309074337+00:00 INFO Z-Wave Switch MIO  <ZwaveDevice: bd5c15c7-76f5-4430-b95d-c8ea349e9f61 [1E] (Luz Entrada)> received lifecycle event: infoChanged
2022-04-23T15:51:43.396378670+00:00 TRACE Z-Wave Switch MIO  Found DeviceLifecycleDispatcher handler in zwave_switch
2022-04-23T15:51:43.405161337+00:00 PRINT Z-Wave Switch MIO  Preference Changed >>>     ch1TimeParameter        Old Value >>>>>>>>>     32767.0 Value >>        32768.0
2022-04-23T15:51:43.411998670+00:00 ERROR Z-Wave Switch MIO  Luz Entrada thread encountered error: [string "st/dispatcher.lua"]:229: Error encountered while processing event for 
<ZwaveDevice: bd5c15c7-76f5-4430-b95d-c8ea349e9f61 [1E] (Luz Entrada)>:
    arg1: infoChanged
    arg2: table: 0xc09678
[string "st/utils.lua"]:188: bad argument #2 to 'pack' (integer overflow)

2022-04-24T09:47:15.608246761+00:00 TRACE Z-Wave Switch MIO  Received event with handler device_lifecycle
2022-04-24T09:47:15.642659761+00:00 INFO Z-Wave Switch MIO  <ZwaveDevice: bd5c15c7-76f5-4430-b95d-c8ea349e9f61 [1E] (Luz Entrada)> received lifecycle event: infoChanged
2022-04-24T09:47:15.717676428+00:00 TRACE Z-Wave Switch MIO  Found DeviceLifecycleDispatcher handler in zwave_switch
2022-04-24T09:47:15.727153428+00:00 PRINT Z-Wave Switch MIO  Preference Changed >>>     ch1TimeParameter        Old Value >>>>>>>>>     32768   Value >>        -32769
2022-04-24T09:47:15.734159428+00:00 ERROR Z-Wave Switch MIO  Luz Entrada thread encountered error: [string "st/dispatcher.lua"]:229: Error encountered while processing event for <ZwaveDevice: bd5c15c7-76f5-4430-b95d-c8ea349e9f61 [1E] (Luz Entrada)>:
    arg1: infoChanged
    arg2: table: 0xd1abb8
[string "st/utils.lua"]:188: bad argument #2 to 'pack' (integer overflow)

OK I am well out of my comfort zone here. I know there is something about unsigned integers being introduced in a later ‘version’ of Z-Wave but I’ve no idea what the significance of a ‘version’ is in practice and whether it is something you need to take control of yourself. I shall now defer to those who actually know what they are talking about and can take things forward.

I’m not an expert on this.
The driver uses the configuration, version 4, but I tried with versions 1, 2 and 3 giving the same error.

I would swear that when I added the fibaro plug model 0x0600 and fibaro RGBW controller to the stock driver in February, it didn’t give this error in the parameters that use values up to 65535, but I can’t find any log to verify it.

Therefore something would have changed in the edge libraries, but I am not able to find what changed

@nayelyz

I found a way to avoid this error and be able to send the configuration values.

setting the size to twice the value needed for the maximum value.
By sending size 4 I can send the value 65535 without error.

2022-04-25T13:40:11.619892268+00:00 DEBUG Z-Wave Switch v5  Luz Entrada device thread event handled
2022-04-25T13:40:26.558091603+00:00 TRACE Z-Wave Switch v5  Received event with handler device_lifecycle
2022-04-25T13:40:26.659534270+00:00 INFO Z-Wave Switch v5  <ZwaveDevice: bd5c15c7-76f5-4430-b95d-c8ea349e9f61 [1E] (Luz Entrada)> received lifecycle event: infoChanged
2022-04-25T13:40:26.696590937+00:00 TRACE Z-Wave Switch v5  Found DeviceLifecycleDispatcher handler in zwave_switch
2022-04-25T13:40:26.702877603+00:00 PRINT Z-Wave Switch v5  Preference Changed >>>      ch1TimeParameter        Old Value >>>>>>>>>     50      Value >>        65535
2022-04-25T13:40:26.708742937+00:00 PRINT Z-Wave Switch v5  >>>>> parameter_number:     12      size:   4       configuration_value:    65535
2022-04-25T13:40:26.722731937+00:00 INFO Z-Wave Switch v5  <ZwaveDevice: bd5c15c7-76f5-4430-b95d-c8ea349e9f61 [1E] (Luz Entrada)> sending Z-Wave command: {args={configuration_value=65535, default=false, parameter_number=12, size=4}, cmd_class="CONFIGURATION", cmd_id="SET", dst_channels={}, encap="AUTO", payload="\x0C\x04\x00\x00\xFF\xFF", src_channel=0, version=1}
2022-04-25T13:40:26.812635937+00:00 TRACE Z-Wave Switch v5  Z-Wave command(5c871778) queued for radio transmission: CC:Configuration, CID:0x04
2022-04-25T13:40:26.818576270+00:00 DEBUG Z-Wave Switch v5  Luz Entrada device thread event handled
2022-04-25T13:40:27.058338937+00:00 TRACE Z-Wave Switch v5  Z-Wave command(5c871778) transmit status: TRANSMIT_COMPLETE_OK

or with size 2 I can send values 255 without error.

I will check if the devices work correctly since the manufacturer says what sizes are necessary for each parameter

  1. Time period between reports on power load and energy
    consumption.
    Parameter defines time period between reports sent when changes
    in power load have not been recorded. By default, if power load
    changes have not been recorded, reports are sent every hour.
    Default setting: 3 600 (s),
    Available settings: 1 - 65534 (s)
    Value of 65535 - no periodic reports. Reports will be sent only in
    case of power load / energy consumption changes (parameters 40,
    42, 43,45) or in case of polling.
    Parameter: 2[byte]

  2. Power reporting frequency.
    This parameter defines how frequently standard power reports
    (parameter 42) will be sent. By default Wall Plug sends up to 5
    reports each 30 seconds, provided the power load changes by 15%.
    Default seting: 30 (s)
    Available settings: 1 - 254 (s)
    Value of 255 - Reports will be sent only as a result of parameter 47
    settings or in case of polling.
    Parameter: 1[byte]

@Mariano_Colmenarejo, can you share the device’s fingerprint and which parameters have this issue, please?

I’d like to check its technical sheet on the Catalog of Certified Z-Wave Products

This happens with any parameter that needs to send the maximum value corresponding to the size in bytes.
If size = 1 value 255
if size = 2 value 65535

There are several old fibaro models that use it like this, i put three of them:

  FIBARO_WALL_PLUG_OLD_EU = {
    MATCHING_MATRIX = {
      mfrs = 0x010F,
      product_types = 0x0600,
      product_ids = 0x1000
    },
    PARAMETERS = {
      alwaysActive = {parameter_number = 1, size = 1}, 
      restoreState = {parameter_number = 16, size = 1},
      overloadSafety = {parameter_number = 70, size = 2}, ----> need size = 4
      inmediatePowerReport = {parameter_number = 40, size = 1},
      standardPowerReports = {parameter_number = 42, size = 1},
      powerReportFrequency = {parameter_number = 43, size = 1},  ----> need size = 2
      energyReportingThreshold = {parameter_number = 45, size = 1},  ----> need size = 2
      periodicReports = {parameter_number = 47, size = 2},  ----> need size = 4
      ringColorOn = {parameter_number = 61, size = 1},
      ringColorOff = {parameter_number = 62, size = 1}
    }
  },
  FIBARO_RELAY_SINGLE = {
    MATCHING_MATRIX = {
      mfrs = 0x010F,
      product_types = 0x0402,
      product_ids = {0x1002}
    },
    PARAMETERS = {
      restoreState = {parameter_number = 16, size = 1},
      autoOffRelay = {parameter_number = 3, size = 1},
      autoOffTime = {parameter_number = 4, size = 2}, -----> need size = 4
      bistableKeyStatus = {parameter_number = 13, size = 1},
      switchType = {parameter_number = 14, size = 1}, 
      dimmerRollerShutter = {parameter_number = 15, size = 1},
    }
  },
  FIBARO_RELAY_DUAL = {
    MATCHING_MATRIX = {
      mfrs = 0x010F,
      product_types = 0x0202,
      product_ids = {0x1002}
    },
    PARAMETERS = {
      restoreState = {parameter_number = 16, size = 1},
      autoOffRelay = {parameter_number = 3, size = 1},
      autoOffTime1 = {parameter_number = 4, size = 2},-----> need size = 4
      autoOffTime2 = {parameter_number = 5, size = 2},-----> need size = 4
      bistableKeyStatus = {parameter_number = 13, size = 1},
      switchType = {parameter_number = 14, size = 1},
      dimmerRollerShutter = {parameter_number = 15, size = 1},
    }
  },

I’ve also seen that newer plug model, for a value of 255, say to use size =2, which fixes the problem.

  FIBARO_WALL_PLUG_EU = {
    MATCHING_MATRIX = {
      mfrs = 0x010F,
      product_types = 0x0602,
      product_ids = {0x1003, 0x1001}
    },

Parameter 24. SWITCH ON value - „On/Off” association groups
The value of BASIC SET command frame sent to the devices associated in „On/Off” association groups (2, 3).
„On/Off (Button)” association group - in accordance with parameter 20.
„On/Off (Power)” association group - in accordance with parameter 23.
Available settings: 0-99 or 255
Default setting: 255 Parameter size: 2 [bytes]

I’ve also been looking at the different zwave profiles of their stock drivers and there are a few more that would need to be resized or corrected, but I haven’t made a note of them.

I have also seen that no profile has parameters with negative values, although if it is necessary to have that possibility, it would be necessary to be able to send the data type so that it could be chosen.

Thanks

I haven’t been following this whole conversation because I use a voice reader and it just gets really confusing.

But as far as negative value parameters, that’s common in temperature ranges and also in temperature offsets.

However, almost all Z wave device manufacturers use a twos complement format to handle negative values in parameters.

So for example the Z wave Fibaro multi sensor allows you to set a negative offset value in parameter 66, but you do so by using the twos complement. So to set the parameter to a negative offset of -2°C, you would use the value of 65516.

And Aeotec uses the same method for their zwave multi sensor 6, but for one byte, so a -2.0 Celsius offset is 236 in decimal in parameter 201.

Tagging @garrett.kranz

1 Like

The particular issue seems to be that initially the Configuration Command Class exclusively used the signed integer format for parameters, regardless of byte length. However from version 3 (?) you could also used unsigned integers and a couple of others.

The need is to set a two byte parameter that accepts values that would imply it has to be an unsigned integer.

Setting a command class version is a known, but it seems an extra step is still needed to change the parameter format.

It may well be possible to workaround the problem by using an appropriate negative number, but it doesn’t seem like it should be necessary and that there is probably a more elegant solution.

1 Like

The default cc.configuration libraries support up to version 4.
In the cody, since version 1, values ​​of type parameters signrd, unsignef, boolean are allowed.
Now I can’t use my pc to show the 42.x libraries example.

The problem is that it seems that by default the “signed” variable is always passed to the function as the value is signed and the user has no control to tell it what integer type they want to use in that parameter.

User can control what version of configuration want to use in the driver.
I have tried with the 1,2,3,4 versions, with the same result

I have seen in the profiles of stock zwave drivers, that almost all of them use maximum values ​​of the positive half of the range.
Let me explain, if size=2 signed bytes has a range from -32767 to 32767, the profiles use parameters with a maximum value of 32767 so that no overflow error occurs.

But there are profiles in stock drivers that do not take this into account and will give an error when the maximum of the positive range is exceeded.

I have also seen that the most modern Fibaro devices, in their manual, use the necessary size to use the maximum value of the parameter in the part of the positive range and have doubled the size to be used.
This is the solution I have tried and on older fibaro devices it seems to work fine.

Manufacturers may have reached an agreement to only use signed configuration values, this is pure speculation!

@Mariano_Colmenarejo It is true that all configuration values are signed values in Z-Wave. This is in the spec for version 1 of the Configuration command class, and subsequent versions maintain backwards compatibility. I do not see any comment in subsequent Configuration CC versions saying otherwise. (Note here is a link to download a zip of the zwave specs from the z-wavealliance). Devices should be respecting the 2s complement ranges for signed integers, but as you see some do not, and actually are interpreting the bytes as an unsigned value.

The workaround, as others have mentioned, is to take the 2’s complement value of the unsigned value in order to set the bytes correctly. So in the example of a config parameter that has size of 1 byte, but still uses the value 255 (0xFFFF) as a valid parameter, you would set it to -1 with size of 1 byte since that is the valid signed value which 0xFFFF represents in 2s complement.

Here’s another example where your config value is 2 bytes (range -32768 to 32767), but you need to specify a value greater than 32767. Lets say we are trying to specify 40,000, which the device says is valid, even though the spec doesn’t allow it:

  • 40,000 as an unsigned 2 byte value is 0x9C40
  • 0x9C40 as a 2 byte 2s complement value is -25,536
  • set the configuration with the signed value and the correct byte size: device:send(Configuration:Set({parameter_number = 47, size = 2, configuration_value =-25536}))

Hopefully this helps you workaround the configurations where device manufacturers did not respect the ranges of config values.

1 Like

Apologies to all if I have caused any confusion. I was being guided by Adding A Configuration Parameter and the corresponding configuration format types that appear in the ST Lua libraries. I guess they don’t mean what I assumed they mean?

2 Likes

Page 177 of the Z-Wave Application Command Class Specification, under section 4.32.1 - Compatability considerations.

2 Likes

Thans for the reply

I understand what you mean, I have to trick the default libraries so that they send the value FFFF (65535), sending the value -1 to the default library function.
I would have to make a code change before sending the value to the defualt function for these specific manufacturers.

I do not want to doubt what you say, since I am not an expert in this and I am sure I am wrong and I do not want you to misunderstand me either, I just want to collaborate

As seen in the link @orangebucket sent, zwave-alliance says that you can use values ​​with signed and unsigned format
There is even an example with size = 2 bytes and the value range from 0 to 65535.

On the other hand, also in the edge libraries it is clear that these formats can be used in the configuration, not only the signed one.

--- @class st.zwave.CommandClass.Configuration.format
--- @alias format st.zwave.CommandClass.Configuration.format
--- @field public SIGNED_INTEGER number 0x00
--- @field public UNSIGNED_INTEGER number 0x01
--- @field public ENUMERATED number 0x02
--- @field public BIT_FIELD number 0x03
local format = {
  SIGNED_INTEGER = 0x00,
  UNSIGNED_INTEGER = 0x01,
  ENUMERATED = 0x02,
  BIT_FIELD = 0x03
}
Configuration.format = format
Configuration._reflect_format = zw._reflection_builder(Configuration.format)

Also If this is going to stay like this, you will have to correct the code to send the AEON_NANO_SHUTTER configuration parameter 35, “openCloseTiming”, profile “stateless-curtain-power-button” to be able to send the values 128 to 255, with size = 1 Byte. with default libraries.
It will give oveflow integer error.

Apart from this, the profile needs in the preference the - name: "openCloseTiming" before the title field to make it work.

name: stateless-curtain-power-button
components:
- id: main
  capabilities:
  - id: statelessCurtainPowerButton
    version: 1
  - id: refresh
    version: 1
  categories:
  - name: Blind
preference:
  - preferenceId: reverse
    explicit: true
  - title: "Open close timing"
    description: "Set the motor's open/close time"
    required: false
    preferenceType: interger
    definition:
      minimum: 5
      maximum: 255
      default: 10
  AEON_NANO_SHUTTER = {
    MATCHING_MATRIX = {
      mfrs = {0x0086, 0x0371},
      product_types = {0x0003, 0x0103},
      product_ids = 0x008D
    },
    PARAMETERS = {
      openCloseTiming = {parameter_number = 35, size = 1}
    }
  }

Thanks agains

1 Like

Actually I may be causing the confusion because I missed this in the spec relating to Configuration V3 and V4:

A device supporting the Configuration Command Class v3 MUST respond to a Configuration Properties Get command. If a Configuration Properties Report command is not returned in response to a Configuration Properties Get command, a controlling device MUST treat the parameter value as a signed integer.

This indicates to me that v3 and v4 do support other types besides signed integers. However, it does appear that we are always serializing a signed value for the configuration parameters regardless of the format (the Configuration format in the ST Lua libs is only used in the Configuration Properties commands)

The workaround provided seems necessary for these situations for the time being, but I will work internally to get the configuration format to be respected when we are sending v3 and v4 Configuration Set commands.

2 Likes

Thanks for bringing this to our attention.

1 Like

@nayelyz, @carter.swedal

Enlarging the size of the parameter value prevents the sending from generating an overflow error in the driver, but it does not work well since the value is interpreted in the device in an erroneous way.

Sending the value with 2’s complement and the correct size does work well to send the value and to configure the device correctly.

For now I will leave it like this in my driver for specific fibaro devices subdrivers.

--- Handle preference changes
---
--- @param driver st.zwave.Driver
--- @param device st.zwave.Device
--- @param event table
--- @param args
local function info_changed(driver, device, event, args)
  local preferences = preferencesMap.get_device_parameters(device)
  for id, value in pairs(device.preferences) do
    if args.old_st_store.preferences[id] ~= value and preferences and preferences[id] then
      local new_parameter_value = preferencesMap.to_numeric_value(device.preferences[id])
      --2's complement value if needed
      if preferences[id].size == 2 and new_parameter_value > 32767 then
        new_parameter_value = new_parameter_value - 65536
      elseif preferences[id].size == 1 and new_parameter_value > 127 then
        new_parameter_value = new_parameter_value - 256
      end
      device:send(Configuration:Set({parameter_number = preferences[id].parameter_number, size = preferences[id].size, configuration_value = new_parameter_value}))
    end
  end
end

Maybe if it is implemented in the main init.lua (info_changed function), sending the value with complement 2 for all values that exceed the corresponding positive range of size 1, 2, 4 would be valid for all cases

Thanks

2 Likes

Hi @carter.swedal

Doing the driver of the Z-Wave parameter configurator I have seen that smartthings default libraries to allow the sending of negative values.
This means that if the parameter is:

  • 1 Byte (0xFF): positive from 0 to 127 and negative from -1 to 128
  • 2 Byte (0xFFFF): positive from 0 to 32767 and negative from -1 to 32768

So far everything perfect, but still disallow sending unsigned values

Some devices like old fibaro, fibaro relay, I do not know if there will be more cases in more manufacturers or models, need send these values:

  • Parameter: 4
  • value : 0 to 65535
  • Size: 2 Bytes

Others like Aeotec Nano Shuter in their driver zwave-window-treatment:

  • parameter: 35
  • value : 5 to 255
  • Size: 1 Byte

As I mentioned in above post, I solved it in my modified drivers by sending the complement to 2 for values ​​> 127 (with 1 Byte) 0 > 32767 (with 2 Byte)
The fibaro devices continues to work fine althoughthe value shown in the CLI when reading is -32768 instead of 65535, because it sends the value in hexadecimal and the device interprets it well, but the CLI and libraries default does not decode fine these values to shown It when received with configuration parameter Get function. Always interprets it as signed values.

In the drivers that do not have this modification like some yours stock, when they send values ​​> 127 (1Byte) or > 32767 (2 Byte) it will give this fatal error and the device will not be configured:

2022-08-13T09:41:26.362964862+00:00 ERROR Z-Wave Device Config Mc Fibaro Single Relay thread encountered error: [string "st/dispatcher.lua"]:233: Error encountered while processing event for <ZwaveDevice: e062ff99 -4cfc-47c2-be7f-91881fdc3a8c [1F] (Fibaro Single Relay)>:
    arg1: table: 0xa56778
[string "st/utils.lua"]:188: bad argument #2 to 'pack' (integer overflow)

The most modern devices I have seen that for values ​​0 to 255, they have a size of 2 bytes and for values ​​0 to 65535 they have a size of 4 bytes

2 Likes

@Mariano_Colmenarejo, thank you for your persistence. I appreciate you helping identify issues with the stock drivers. This is still on my radar, but due to some bandwidth issues it has yet to be fixed.

2 Likes