ZWave binding updates

I have now merged the development version of the ZWave binding into master, so it will be available in the 2.4 snapshot version. If you are using the ZWave binding, please read this post as the binding contains some breaking changes so you will need to manually update your configuration.

Firstly though - the major enhancements (there are tons more smaller updates) -:

  • Security has been added using the S0 security class. This should allow all devices supporting security to be included into the binding securely.
  • Transaction code has been rewritten to hopefully improve the way transactions are managed.
  • The way associations work has been updated. This is a very messy area in ZWave as there are 2 overlapping command classes, each with multiple versions that all work very differently. This fluidity in the specification means that there are many devices that don’t work exactly as expected - hopefully this will improve the situation for most devices at least (see more information below on this).
  • The notification (alarm) command class has been improved to reduce reliance on the database to define all supported events.
  • Color command class has been improved.
  • UoM (Units of Measure) has been added to some reports - eg temperature units are now handled automatically depending on your unit/location preferences.
  • Nightly heal is added

This binding will require that existing things are deleted, and re-added so that the binding picks up the latest thing definitions . You don’t need to exclude and re-include the devices from the network, and in most cases the devices should look the same to the user so channels should be the same (the database is the same for all versions).

Note that there is now an automatic dongle discovery in the binding. This can be ignored, however if you have auto approve enabled, then it’s possible that this new controller will automatically be enabled and you probably will be best to use it.

The Recommended update process is as follows -:

  1. Backup - always a good idea when upgrading your system :sunglasses:.

  2. If on the release or testing version of OH and on an apt/yum based install, change to the snapshot release repo as the source.

  3. If you are not already running 2.4 snapshots, then upgrade OH using the procedure for your platform.

  4. Ensure that your default region is set so that temperates etc are properly configured. Note that thermostats will not work if this is not set.

  5. Remove all Zwave Things except for the thing representing the Controller. If the controller is accidentally deleted, it should be recreated with the same ThingID, so that the channels do not change. This can be found in the channel info of an items file, or in a backup Thing.json file. If Things are manually configured in .thing files, they can be moved to another directory and then moved back to pull in the updated Thing definitions.

  6. Uninstall the Zwave binding though PaperUI or the Karaf console. How to do this depends on how it is currently installed. If manually installed, delete jar, then uninstall through Karaf, if it is still shows up with list -s | grep zwave . If installed through a UI or the console (a jar was never dropped into addons), uninstall though a UI or the console.

  7. Install the Zwave binding through PaperUI or the Karaf console.

  8. Go to the Inbox and scan for Zwave devices.

  9. Accept the nodes as they appear.

  10. If necessary, perform whatever wake up steps that are needed for battery powered devices so the binding can figure out what it is.

The last point above is generally optional, however it is worth noting that all devices will initially be unknown as the XML files that the binding uses to persist information about the device will be recreated. Mains devices should reappear pretty quickly, but battery devices will take time - the exact duration will depend on the wakeup interval configured for the device (normally, this is in the region of a few hours). You can speed this up by manually waking up the devices (check the manual for each device to learn how to do this). Note that there are a few devices that may not wake up at all by themselves (eg Minimote and Wallmote) and these must be woken manually for them to be discovered.

Note that if you delete the controller thing, and you have previously been using the secure binding, you will need to exclude and re-include secure devices unless you make note of the security key.

One further point to note is that this binding significantly changes the way associations are configured. This area is really very messy in ZWave as there are 2 association command classes, and each one of these has a number of different versions that are all significantly different. On top of this, due to the fluid nature of the spec, many manufacturers have implementations that are non-compliant to any version - in all, this makes working out how to configure associations a bit of a nightmare! If you find associations are not working, then it is recommended to exclude the device, and add it back again so that it is reset and reconfigured with the new binding. If this doesn’t work, then we can look at what is happening in the debug logs.

For those wanting some background or reference material, feel free to read the following thread (it’s not really recommended unless you can’t sleep at night :slight_smile: ).

Thanks to all those who have been testing this - hopefully it will ensure that the pain of the upgrade is minimal :wink: .

40 Likes

Hi Chris,

i made the upgrade and it works very good.
I dont know whats different but my z-weather is working again. It was not unknown … it was simple there.
The last year with many updates and with a fresh installation the z-weather never worked and now i have all values.

Thank you,
Joerg

1 Like

Many thanks for all your work on this - it is hugely appreciated. Even those who don’t use zwave security will (in my experience) find the new binding significantly faster and more reliable.

Dan

1 Like

Just to be sure, this is should also work together with 2.3 stable and not just 2.4?

Yes. Maybe :sunglasses:

1 Like

Worked for me with a little glitch. After scanning for new devices i found a new controller, while the old one was still online. I have only six devices so removing the old controller and setting up an enw one was no problem.

1 Like

I got that one too a while ago (have been running the dev version), I just ignored it and continued using the old controller Thing. So for anyone else reading, you don’t really need to switch controller Thing :wink:

2 Likes

This is correct - the new controller will likely appear on Linux systems as there is an auto detection of USB devices available under Linux now. When upgrading, it’s probably best to ignore this to avoid issues with names of channels etc.

2 Likes

People on 2.3 and the latest binding have reported 500 errors when configuring zwave devices.

Ah, okay, thx. I saw those posts but did not catch the root cause behind it.

Me either… I spent some time searching and couldn’t locate a definitive cause, but the solution seemed to always be an upgrade to an OH snaphot build.

1 Like

Now that dev is merged into master, I wanted to revisit how I upgrade to the latest version of the zwave binding without updating the rest of openHAB.

Simply using bundle:update org.openhab.binding.zwave from the karaf console is not working for me.

The only thing I found to work is to explicitly provide the exact location of the jar in the bundle:update command. Like this.

openhab> list -s | grep zwave
227 │ Active   │  80 │ 2.x.0.old-date     │ org.openhab.binding.zwave

openhab> bundle:update org.openhab.binding.zwave https://ci.openhab.org/job/openHAB2-Bundles/lastSuccessfulBuild/artifact/bindings/org.openhab.binding.zwave/target/org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar     

openhab> list -s | grep zwave
227 │ Active   │  80 │ 2.5.0.new-date     │ org.openhab.binding.zwave
1 Like

TMK, bundle:update should pull down the latest. Do you get the latest if you uninstall and reinstall? I’d test, but I’m still using manual installs.

I tried that earlier today and it didn’t work either.

@sihui I see this issue you opened a while back is still open. To your knowledge, is using uninstall/install to update the version of a binding still broken?

I tested again and realized a whole mess:

Let’s start with the current state:

openhab> bundle:list|grep -i zwave
256 │ Active   │  80 │ 2.4.0.201809091339     │ ZWave Binding

Then I executed

openhab> bundle:update org.openhab.binding.zwave

and got

openhab> bundle:list|grep -i zwave
256 │ Active   │  80 │ 2.4.0.201809091339     │ ZWave Binding

So this did not work.

Then I tried

bundle:update "ZWave Binding"

and got the same version again.

openhab> bundle:uninstall org.openhab.binding.zwave

gives an empty karaf screen, but the binding is still showing as installed in PaperUI. Although it does not work anymore :sunglasses:

I did not try to restart openHAB, maybe that solves the PaperUI problem.

Next try:

openhab> bundle:install org.openhab.binding.zwave
Bundle IDs:
Error executing command: Error installing bundles:
        Unable to install bundle org.openhab.binding.zwave: org.osgi.framework.BundleException: Error reading bundle content.

No luck.

So I hit the uninstall button again in PaperUI and the blue mark is gone. Then I installed the zwave binding through PaperUI and it shows:

openhab> bundle:list|grep -i zwave
264 │ Active   │  80 │ 2.4.0.201809091339     │ ZWave Binding

So actually NOTHING works :rofl:

Nothing at all in the logs, btw.

Edit: ahh, damn, it looks like there is no newer zwave snapshot than 2.4.0.201809091339

But isn’t this the most current version? I just updated to build 1357 about an hour ago, and that’s the zwave version I got with that build.

Oops. Nm. I just saw your edit.

1 Like

Just done the update, but no longer see any neighbors in the individual things, and don’t see the network map in Habmin. Is this expected?

No.

Did you

To the letter!