Z-wave HANDLER_CONFIGURATION_PENDING value does not match allowed parameter options

Hi all,

for a few weeks now (probably since the last upate to openhab 3.3.0) one of my z-wave devices stayed in HANDLER_CONFIGURATION_PENDING state. It is just a sensor (SHBW10000 ABUS Z-Wave 4in1 Sensor) so it wasn’t that big of a deal. But now I’ve tried for two days to get it working again without much luck. I’ve also looked into other reports of this error online, but couldn’t find a clear solution.

The good news: The device is “online” when I set the values as the error messages dictate, but then it is also disabled. For example:

{config_101_4=The value 300 does not match allowed parameter options. Allowed options are: [ParameterOption [value=“0”, label=“Disabled”]]}

This parameter controls the time between reports of the temperature measured and 0 disables it.
The documentation clearly states acceptable values are 0 - 2678400 (Hexadecimal: 0x00 – 0x28DE80).

So it seems the problem here is that openhab does not know which values are actually acceptable and which are not. Where does openhab get the info of the allowed values from? Is there a file on disk that one can edit? Or is there a way to disable this check (globally or just for one device)?

Thanks for any help!


This information is maintained in a database that’s managed by @chris and maintained by the community.

From what I can tell, the information in the database looks correct for parameter 101. So, I’m not sure what might be wrong. Perhaps someone else can spot an issue?

I had also found the reference to this website in another case, but dismissed it: I cannot find any info on allowed values in the parameter section, it just lists the Parameter numbers, labels and description. Maybe my firefox and chrome aren’t displaying the page properly!?

I’d be happy to update these entries, if this is the source of the problem.

@rolandp @mhilbush The db is indeed the problem, but it seems already fixed on 9/7:

So if you try the latest snapshot, the issue is most likely gone.

1 Like

You can see all the data for a parameter by clicking on the parameter, but only if you’re logged in.

The patch looks indeed exactly like it fixes my problem. Thanks for the info!

I’m just a bit hesitant to switch to an unstable snapshot version, I’d like to stay on stable as to not invite other problems. I can wait a few weeks for updates - or will this take longer?!

If I’m correct, the release schedule for stable releases is once in 6 months, unless there are important reasons for an intermediate release. I don’t think database updates qualify as important enough…

However, the zwave binding’s current snapshot has had minimal changes since the last stable release, just a few database updates if I’m correct. So chance of undesired impact should be minimal.

I’ve updated to the snapshot, the sensor is working again.
Thanks for the help!


Hi, this did NOT fix a similar problem for me.

Upon upgrading from 3.2 to 3.3, my “YRD446 Yale Real Living Key Free Touchscreen Assure Lock with Z-Wave and Bluetooth” responds with


{config_15_1=The value 0 does not match allowed parameter options. Allowed options are: [ParameterOption [value=“1”, label=“Factory Reset”]]}

This appears as a radiobutton (item 15) “Reset To Factory Defaults”. Not sure what it looked like in OH3.2. This was working fine through all previous OH versions.

Updating to the snapshot from JFrog
does not fix the problem. I removed the Thing and let it rediscover.

When I look at its database entry, OpenSmartHouse Z-Wave Device Database, Param 15 has little red thing on the right which I don’t know what that means.

Let me know if I should try something else. Thanks.

The “fix” is by device, so your problem is not going to be solved with this thread.

I tried to put a general description in the OH3.3 release, but is buried in a long chain. openHAB 3.3 Release discussion - Setup, Configuration and Use / News & Important Changes - openHAB Community

Since it was clear you do not have DB access, I was going to change it for you, but I see @chris already changed it last night. Keep an eye out for number 174 here for the corrected snapshot.

Thank so much. Yeah I just looked at the breaking changes when I did apt install and didn’t recall seeing it - maybe I missed. Will try the workaround.
— Bill