Issue with PAT02-A Z-Wave flood sensor parameter 7 configuration


after upgrading to OH 3.3 I encountered the typical issue with zwave config parameters and their type validation.

The problematic paraameter seemed to be Parameter 7 (customer function)

Auditing changes in jsondb, I can see the parameter 7 is now different – something I do not wish to have

-        "config_10_1": 12.0,
-        "config_13_1": 12.0,
-        "config_14_1": 12.0,
-        "config_15_1": 12.0,
-        "config_1_1": 0.0,
-        "config_20_1": 30.0,
-        "config_21_1": 1.0,
-        "config_23_1": 5.0,
-        "config_2_1": -1.0,
-        "config_5_1": 0.0,
-        "config_6_1": 0.0,
-        "config_7_1": 0.0,  <--- OH 3.2 setting
+        "config_10_1": 12,
+        "config_13_1": 12,
+        "config_14_1": 12,
+        "config_15_1": 12,
+        "config_1_1": 0,
+        "config_20_1": 30,
+        "config_21_1": 1,
+        "config_23_1": 5,
+        "config_2_1": -1,
+        "config_5_1": 0,
+        "config_6_1": 0,
+        "config_7_1": 16, <-- OH 3.3 setting after checking parameter 7 in UI, note the difference

In order to have the thing ONLINE, I had no choice but to check the checkbox. Then I tried to clear the checkbox, having the following error in logs

2022-07-15 09:05:10.479 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] [org.openhab.binding.zwave] - NODE 20: Configuration update set config_7_1 to null (null)
2022-07-15 09:05:10.480 [ERROR] [st.core.internal.thing.ThingResource] [] - Exception during HTTP PUT request for update config at 'things/zwave:device:zwave:node20/config'
        at 2022-07-15T09:01:50+03:00 lerbacka-raspi karaf[520]: java.lang.NullPointerException: null
2022-07-15T09:01:50+03:00 lerbacka-raspi karaf[520]: #011at org.openhab.binding.zwave.handler.ZWaveThingHandler.handleConfigurationUpdate( ~[?:?]
2022-07-15T09:01:50+03:00 lerbacka-raspi karaf[520]: #011at org.openhab.core.thing.internal.ThingRegistryImpl.updateConfiguration( ~[?:?]
2022-07-15T09:01:50+03:00 lerbacka-raspi karaf[520]: #011at ~[?:?]

The device manual (hopefully I found the correct one), seems to indicate that parameter 7 is actually 4 boolean settings:

  1. disable/enable “send out BASIC OFF after flood event cleared”
  2. use notification report OR use sensor binary report
  3. enable/disable multi CC in auto report
  4. disable/enable battery state reporting in device triggered

tl; dr, I think there are several issues

  1. migration from OH 3.2 to 3.3 was not smooth. Not sure if we can improve this?
  2. null pointer exception when clearing parameter 7 with this device. In other words, cannot have paramater 7 value 0x00 (zero byte)
  3. parameter 7 configuration UI does not seem to match manual? should be 4 settings instead?

How to go about fixing these?

Sadly it is not possible to reverse time to change 3.3, so we can’t really help here.

I’ve changed the database so that it is not limited to the single option. According to the manual this is a bitfield, so there are not 4 options, but up to 16 with these 4 bits. I think therefore it’s best to just allow users to define the value based on the bits they need to set.

Amazingly fast response, thanks! Should I see the updated binding with updated database here openHAB-ZWave [Jenkins]?

I understand. I was perhaps thinking that if there would be a “migration fix” now, it would end up in potential 3.3 hot fix, and some users would benefit from this.

But perhaps there is no general fix and we have to sort these out one by one?

Yes, but I’ve not actually pushed this out yet - I will probably do it tomorrow morning (New Zealand time - so Friday night in EU).

Yes, if there’s an error in the database configuration, as is the situation here, then it needs to be fixed for each device.

1 Like