[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

[airix1]

I am experiencing the same issue with both of my ZW4SF Fan controllers. Wondering if there is any update on this issue, or anything I can do to help?

[apella12]

The vast majority of these have been resolved. (This thread is over a year old and probably should have been closed). There is still an issue or two that pop up, usually in the forum because they get more attention there. My guess this is parameter 7?

Edit: if you can live with setting to 0 the problem will go away for now

Edit2: I guess no one bothered to fix the ZW DB. I made a change that should resolve

[airix1]

Thanks for making the change! I'll follow up once it test it.

Yes, selecting 0 for option 7 worked, but sometimes I would have to reselect if after a reboot, or the "handler error" would remain and the device wouldn't come online by itself. Also this now allows textual configs to work for the device, since parameters cannot be configured.