Z-wave + Aeotec ZW116 Nano Switch

Add-ons Bindings
1

Hi,
Sorry if this has already been asked, but I haven’t been able to find any threads about it.

I have a couple og Aeotec Nano Switch with power metering (ZW116) that I have been using for some time as just switches.
Now I need to get energy reporting from them.

Which reports to send is supposed to be configure in parameters 101, 102 and 103. In the UI these are single select options. ut according to Aeotec support, these should be a 4-byte value, with legal values between 0 and 15 (same as for the Nano Dimmer ZW111)

If I change this to 15 (which is the value I want) in the code tab, I get an error stating it is not a valid value. (incidentally, this is also the error given when the thing is included, since the value 0 (zero) is the default value)

The code that gives the error is “config_101_4: 15” in the below segment.
Is there any way to override the binding and force it to send 15 as the value for the parameter (I expect not…)

Thanks

Hans-Christian

UID: zwave:device:ad0798efeb:node22
label: swVarmeKjokken
thingTypeUID: zwave:aeon_zw116_02_001
configuration:
  config_100_1_wo: 0
  config_91_2: 25
  config_92_1: 5
  config_90_1: 0
  group_4: []
  group_1:
    - controller
  group_3: []
  group_2: []
  switchall_mode: 255
  config_112_4: 30
  config_113_4: 30
  config_111_4: 30
  config_20_1: 0
  config_84_4: 301991936
  config_83_1: 0
  config_252_1: 0
  config_82_1: 1
  config_81_1: 1
  config_255_4: 0
  config_80_1: 2
  config_110_1_wo: 0
  config_247_1_0000000F: 0
  config_122_1: 3
  config_120_1: 0
  config_121_1: 0
  config_101_4: 15
  config_102_4: 1
  config_9_1: 30
  config_247_1_000000F0: 0
  config_3_1: 1
  config_4_1: 0
  config_103_4: 1
  config_87_4: 8327680
  config_86_4: 8327680
  node_id: 22
bridgeUID: zwave:serial_zstick:ad0798efeb
2

I believe this was fixed in the latest zwave snapshot (DB Update 1800). The .jar for that is here Build 178.

Assuming you are on the OH3.3 release; Uninstall the zwave binding from the UI, in the openhab-cli console add feature:install openhab-transport-serial then drop build 178 in the addons folder. OR if you already have a zwave jar in the addons, just delete that one and drop in the new one.

Bob

Edit: ZW111 looks like it could have problems with the OH core validation, but Zw116 is fine (IMO)

3

Thanks for the quick reply, I’ll try to get time to do this tomorrow.

But won’t removing the binding mess up all the z-wave things I already have?
I guess they will loose all the links to the items at least. Or am I just being pessimistic? :joy:

4

It will look bad momentarily (if you look), but the new binding will start and nothing should be lost/unlinked/changed. Just wait about 30 seconds before looking to keep your blood pressure low. Worst case is that you might have to delete (do not exclude) the ZW116’s and then go right to the inbox–zwave–scan to pick them up with the new properties and the old links.

5

Thanks,

I got the newer version of the jar file installed, and that did indeed allow me to set the parameters correctly.
However, I can no longer add new z-wave devices from the UI (haven’t looked at other ways to add yet).
So I guess I have to remove that jar file and install the zwave binding again.
Or is there another way to fix that issue?

thanks

Hans-Christian

6

There does seem to be an issue (see this).

Did you just upgrade the zwave jar or did you upgrade OH to the latest snapshot? There is nothing that I can see with the latest zwave binding that would cause this problem, but the snapshot OH could have other changes that might be the cause.

7

Just uninstalled the binding, added the serial feature and dropped the jar file into addons folder as you suggested.

Seems like existing z-wave things are working, but no option to discover new ones. Maybe not so strange since there is no a-wave binding atm.

8

What version of OH3 are you on? From the other thread they are both on a snapshot.

If the zwave devices are there the binding is there. You can check all this in the console.

zwave check
zwave check741×328 12.5 KB

9

Yes, the bundle is there, but on version 3.4, the rest of the system is 3.3. I have just dropped the new jar file for zwave into the addons.
Z-Wave binding does not show up as an option to choose when I try to add a new device.

[22:37:02] root@openhab3:~# openhab-cli console

Logging in as openhab
Password:

                       _   _     _     ____

___ ___ ___ ___ | | | | / \ | __ )
/ _ \ / _ \ / _ \ / _ \ | || | / _ \ | _
| () | () | __/| | | || _ | / ___ \ | |) )
___/| / _/|| |||| ||// _|__/
|| 3.3.0 - Release Build

Use ‘’ for a list of available commands
and ‘[cmd] --help’ for help on a specific command.
To exit, use ‘’ or ‘logout’.

openhab> bundle:list | grep ZWave
260 │ Active │ 80 │ 3.4.0.202209010348 │ openHAB Add-ons :: Bundles :: ZWave Binding

10

Just an addition.

I removed the new (3.4) z-wave jar, and installed the binding from the UI agin. Now things are as “normal”, and the option to add new z-wave things is visible again.

Seems like there is some mismatch between the new (3.4.x) version of the binding and the 3.3 version of the core openhab system. (Maybe not so surprising?)

Of course, now the ZW116 does not work again :slight_smile:

11

I’m afraid I don’t know why the UI does not show the add thing for the zwave binding and the Zwave developer/maintainer is on holiday without internet access.

There is way to add an updated XML file to an existing .jar using the jar -uf command. There are some tracks on how to do this in this post

What version of the Zw116 do you have? There is a <2 and >2.1 version in the DB?

12

Thanks for the tip, I’ll have a look at that link. (have to find the jar file for 3.3 though)

The ZW116’s are >2.1 and running firmware 3.0 which according to the supportsite is the latest.

13

The other thread had a workaround for the add problem. This will be a lot easier than adding an xml to an earlier binding

14

FWIW, I had the same problem - had an Aeotec ZW116 that worked just fine. Then started showing an initialization error. Installing the SNAPSHOT .jar fixed the problem.