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

Add-ons Bindings
1

Hi

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)

image
image960×540 42.2 KB

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] [org.openhab.core.io.rest.core] - 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(ZWaveThingHandler.java:654) ~[?:?]
2022-07-15T09:01:50+03:00 lerbacka-raspi karaf[520]: #011at org.openhab.core.thing.internal.ThingRegistryImpl.updateConfiguration(ThingRegistryImpl.java:94) ~[?:?]
2022-07-15T09:01:50+03:00 lerbacka-raspi karaf[520]: #011at org.openhab.core.io.rest.core.internal.thing.ThingResource.updateConfiguration(ThingResource.java:498) ~[?:?]
...

The device manual (hopefully I found the correct one), http://manuals-backend.z-wave.info/make.php?lang=en&sku=PHIEPAT02-A 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

image
image1234×330 37 KB

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?

2

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.

3

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?

4

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
5

Dear all

Sorry to re-open this thread. I have the same issues with the PAT02-A Z-Wave sensors as described in the first post here. I tried setting parameter 7 multiple times in the GUI and also rebooted my Raspi multiple times. I am running version 3.3.0 and have all the newest updates installed. If I read this correctly here, you changed something in the database to allow more settings for parameter 7. However, the GUI still only shows one possible setting

Param7
Param71130×156 11.9 KB

Selecting this setting for parameter 7 does not stick. Once clicked and saved, it is again unchecked. The PAT02-A devices cannot initialize. Network heal and reinitialize do not help, either.

Can you give me a hint on how to fix this without having to be an expert debugger?

Thanks

6

I’m not quite sure what this means? If you are running 3.3, then unless you have manually installed the SNAPSHOT version of the binding, it will not include this change. Maybe that’s what you mean by “all the newest updates”?

1 Like
7

Sorry, yes- I was not clear enough. I am in the “main” branch and don’t have any Snapshot versions of bindings installed. I read a bit about updating to the snapshot version of the Z-Wave binding, but I am not yet convinced to take the risk, that my many other Z-Wave devices will stop working when I go to a snapshot version. Will the database change be included in the next release version of OpenHAB?

8

Yes, when 3.4 is released in December 2022, it will be there.

I could argue that the current testing release (OH 3.4 Milestone 1) is a better option. The releases tend to be crunch time for developers and can have problems just like anything else. However, the first milestone after a release is mostly just the fixes and minimal new. If I was only going to update every 6 months, I would skip the release and use the first milestone after the release. However, that is just my opinion.