[zwave] ZW4SF Fan Speed Controller, joins network with invalid default config_7_1

[switzer60]

Expected Behavior

When a zwave thing is added to openhab, that thing has valid defaults for it's configuration parameters.

Current Behavior

When this zwave thing is added to OpenHAB
UID: zwave:device:xxxxxxxxc:nodeyy
label: "Z-Wave Node 0yy: ZW4SF Fan Speed Controller"
thingTypeUID: zwave:leviton_zw4sf_01_008
configuration:
config_7_1: -2
config_3_1: 10
config_4_1: 99
config_5_1: 0
node_id: 85
config_6_1: 3
bridgeUID: zwave:serial_zstick:xxxxxxxx

config_7_1: -2 is an invalid configuration parameter and throws the following error:

2023-01-27 19:04:04.006 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:device:xxxxxxxx:nodeyy' changed from UNINITIALIZED (HANDLER_CONFIGURATION_PENDING): {config_7_1=The value -2 does not match allowed parameter options. Allowed options are: [ParameterOption [value="0", label="LED Off"], ParameterOption [value="254", label="Status Mode"], ParameterOption [value="255", label="Locator Mode"]]} to UNINITIALIZED (HANDLER_MISSING_ERROR)

Possible Solution

Set a reasonable default (my opinion would be for 254 or 255)

Steps to Reproduce (for Bugs)

1. Join zwave thing to controller through NWI
2. Device throws configuration error: config_7_1=The value -2 does not match allowed parameter options. Allowed options are: [ParameterOption [value="0", label="LED Off"], ParameterOption [value="254", label="Status Mode"

Context

Joining thing to OpenHAB

Your Environment

$lshw
$ sudo lshw
description: Space-saving Computer
product: HP ProDesk 400 G2 MINI (M2V15AV)
vendor: HP
serial: MXL7032Y4K
width: 64 bits
capabilities: smbios-2.7 dmi-2.7 smp vsyscall32
configuration: administrator_password=disabled boot=normal chassis=space-saving family=103C_53307F G=D frontpanel_password=disabled keyboard_password=disabled power-on_password=disabled sku=M2V15AV uuid=4E839C63-A6DF-E611-9C43-BC0000D20000
*-core
description: Motherboard
product: 806A
vendor: HP
physical id: 0
version: KBC Version 05.39
serial: PEWPL0E0Z497UH
*-cache:0
description: L1 cache
physical id: 0
slot: L1 Cache
size: 64KiB
capacity: 64KiB
capabilities: synchronous internal write-back data
configuration: level=1
*-cache:1
description: L1 cache
physical id: 1
slot: L1 Cache
size: 64KiB
capacity: 64KiB
capabilities: synchronous internal write-back instruction
configuration: level=1
*-cache:2
description: L2 cache
physical id: 2
slot: L2 Cache
size: 512KiB
capacity: 512KiB
capabilities: synchronous internal write-back unified
configuration: level=2
*-cache:3
description: L3 cache
physical id: 3
slot: L3 Cache
size: 3MiB
capacity: 3MiB
capabilities: synchronous internal write-back unified
configuration: level=3
*-cpu
description: CPU
product: Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz
vendor: Intel Corp.
physical id: 4
bus info: cpu@0
version: Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz
serial: To Be Filled By O.E.M.
slot: U3E1
size: 2986MHz
capacity: 3200MHz
width: 64 bits
clock: 100MHz
capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities cpufreq
configuration: cores=2 enabledcores=2 threads=4
*-memory
description: System Memory
physical id: 5
slot: System board or motherboard
size: 8GiB
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.5 LTS
Release: 20.04
Codename: focal
$ uname -a
Linux openhab05 5.4.0-137-generic openhab/openhab-addons#154-Ubuntu SMP Thu Jan 5 17:03:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
$ apt list
openhab-addons/stable,now 3.4.1-1 all [installed]
openhab/stable,now 3.4.1-1 all [installed]
zulu-repo/now 1.0.0-3 all [installed,local]
zulu11-ca-jre-headless/stable,now 11.0.18-1 amd64 [installed,automatic]
zulu11-jre-headless/stable,now 11.0.18-1 amd64 [installed]

[stefan-hoehn]

first of all, thanks, @switzer60 for your comprehensive description though I don't think it is a bug in the binding as it behaves like expected: the device sends an invalid value and the binding rejects it based on the configuration provided for that devices. It might be a "bug" in the definition of the device (see below)

btw, usually it is better to bring this issue up in the openHAB community forum first because more people are watching this (I only noticed it here by chance) and will jump in helping you.

Before we start applying defaults for unwanted values, I would rather recommend to find out first why we see a -2 here. Either the device is faulty or the configuration is wrong or the interpretation of the value is wrong which is what I am guessing here:

-2 equals 254 if treated as an unsigned byte instead of a byte.

The definition of the device can be found here (you may need to log in to see the param details that were provided):

https://www.opensmarthouse.org/zwavedatabase/1418

I don't know why the byte is interpreted as a signed value instead of an unsigned and before we do anything else I would like to know, though

A solution COULD be that we try to define the status mode as -2 in the definition of the device (likewise the 255 as -1).

@cdjackson what do you think?

[switzer60]

@stefan-hoehn,

Thanks so much for providing some guidance. This is the first bug report I've submitted.

I'm so grateful to the folks that make this software so fantastic, and I felt like, at a minimum, I could contribute a bug report to try and make things better.

In order to provide additional detail, I did purchase 2 of these devices, and both of them exhibited the same behavior.

Switzer

[wborn]

Can you transfer this issue to the zwave repo @kaikreuzer?

[apella12]

Out of curiosity have you tried changing the parameter to 254? That is the default for the device in the binding. The reason it may appear as -2 is explained above. If that doesn't work will need a fix to satisfy both the OH core rigorous validation and not confuse device owners (since the manual clearly states 254, 255, & 0 are the only options). I have an idea on how but will need to run by the Zwave developer. However, the simplest is if setting the parameter as 254 works.

[switzer60]

Yes. You can change the value via the "Code" tab (but no using the "Thing" tab, perhaps a separate bug). However, now I get this error:

2023-03-21 08:42:11.605 [WARN ] [.core.thing.binding.BaseThingHandler] - Attempt to apply invalid configuration 'Configuration[{key=config_7_1; type=BigDecimal; value=-1}, {key=config_3_1;
type=BigDecimal; value=0}, {key=group_1; type=ArrayList; value=[controller]}, {key=config_4_1; type=BigDecimal; value=99}, {key=config_5_1; type=BigDecimal; value=0}, {key=config_6_1; typ
e=BigDecimal; value=3}, {key=node_id; type=BigDecimal; value=85}]' on thing 'zwave:device:04cb25f98c:node85' blocked. This is most likely a bug: {config_7_1=The value -1 does not match all
owed parameter options. Allowed options are: [ParameterOption [value="0", label="LED Off"], ParameterOption [value="254", label="Status Mode"], ParameterOption [value="255", label="Locator
Mode"]]}

This is the Code from the Thing defintion:
UID: zwave:device:04cb25f98c:node85
label: "Z-Wave Node 085: ZW4SF Fan Speed Controller"
thingTypeUID: zwave:leviton_zw4sf_01_008
configuration:
config_7_1: 254
config_3_1: 10
config_4_1: 99
config_5_1: 0
config_6_1: 3
node_id: 85
bridgeUID: zwave:serial_zstick:04cb25f98c

[apella12]

The message indicates you changed to 255? Is that true? Anyway one more test; set the config to "0" and see what happens. I suspect it will work fine until a DB fix can be made.

FYI, IMO - This is technically an issue with the OH core, not the zwave binding. The Zwave specification requires signed bytes. What is probably happening is that when you change the value at 254, 255 or 0, the binding sends a SET message. The binding follows that up with a GET message and then the device sends a REPORT and the device REPORT is translated back to the signed byte value and put on the UI thing. As noted above I think a change can be made to the zwave DB to get this working rather than bounce you back and forth.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/trouble-with-xml-export-for-new-zwave-device/147433/4