ZWave status under OH2

Add-ons Bindings
1

I thought I’d add a status of the OH2 zwave situation here…

Currently, the zwave binding for OH1 is working fine under OH2, so this is currently the recommended path.

In the coming days (or so!) I hope to have a first version of the OH2 zwave binding ready for testing. There are still a few changes to be discussed that need to be merged into the ESH core that I’m waiting to get approved, but once this is done I should be able to release a test binding… This is related to the ability of the binding to provide binding defined options (rather than static options that are defined in the configuration file) - this is needed to provide association updates since the options are dependant on the device… We’re still discussing how to implement this, so this is the current blocker for zwave on OH2…

However, when available, the OH2 binding, in keeping with OH2 concepts, will have automatic binding of channels/items to zwave devices which should make the binding a LOT easier to use - especially for beginners. There will be no need to add complex binding strings - these will automatically be configured with the database - we’ve spent a some time over the past months adding functionality to ESH to support the features zwave needs. This means that the database needs updating - it’s a completely new format to the OH1 database, although I do have a converter to hopefully ease the job. Since the new database needs more information, it’s not a simple case of just converting all the files - I will make the converted files available, and when someone wants a device added they can use it as a starting point, but it will need some work and review…

There are still a few features that I need to implement. Most of this is related to the automatic configuration of the device that I added recently in the OH1 binding, and this makes use of the database. Since this is different in OH2, there’s always the chance that the database format might need to change a little, so I’d like to get a few people using it before we spend too much time adding loads of devices (there are currently 196 devices in the database!). There is some information on the new database format here.

Other things missing at the moment are the nightly heal, and polling (which again needs to be done differently than OH1).

There have also been a few changes in the code - not to the core of the zwave processing, but I have changed the converter concept. This needed to change in ESH due to us now dealing with channels and not items, but I’ve taken the opportunity to simplify this a little. This does mean that I’ve probably introduced some bugs in converters - they ought to be easy to fix, but again this adds to the desire to introduce the binding to a small number of users first…

I’ve also added some new command classes - namely the COLOR command class to support color bulbs.

Any questions etc, just ask :smile:

Cheers
Chris

11 Likes
2

Count me in for testing

3

I also will test. Have about 30 devices in my house, including one of those Zipato RGB bulbs-so COLOR command class especially interesting to test.

4

Good stuff Chris. As always, ready to test and play.

Jim

5

I am also in Chris. Moving into a new Place in September - Perfect for a fresh setup;-)

6

I’m up for testing as well as helping with the device database updates. I come in contact with a range of different Z-wave devices, many of them fresh out of the factory. So once I get the Z-wave binding set up for my OpenHAB2, I’ll get cracking with the devices.

7

Hi Chris, great post. May I ask why OpenHAB left OpenZwave and setup a whole new zwave config. To me it looks like that the opensource Z-Wave vision is in line with OpenHAB.

Beside OpenZwave my Razberry uses the pepper1.net DB, can’t OpenHAB use the same?

It’s just for my personal understanding. I would like to spend more time on the Z-Wave topic and help where possible.

8

I’m not sure if OZW was ever used in OH - certainly it hasn’t been used since I’ve been involved in OH, which is over 2 years - maybe there was an earlier version, but I’m not aware of it… I think the decision was made to write a java version since OH is a java project and JNI wasn’t desirable.

When I started working on the ZWave binding, one of the first things I added was the configuration information. I looked at using existing databases (pepper1, and the OZW format) but these are not compatible with the OH open source license, so I devised our own. The OH1 database format is actually very similar to the OZW format. We quickly rejected pepper due to the licensing, but also because relying on a third party as a fundamental input to run the system didn’t seem like a good idea. Also, we didn’t have any control over it, so if we wanted to add information (which is needed to work around bugs/peculiarities in some devices) then we couldn’t do it…

So, OH requires and uses its own database - it gives us the control over our own destiny…

In OH2, we will actually use a different format which will be inline with the ESH format which is common for all bindings. I’ve written a converter to convert the existing files over to the ESH format, but we will add more information to allow us to eliminate the binding strings (which makes setup a LOT easier).

I hope that makes sense? :smile:

Cheers
Chris

9

Thanks for the detailed explanation. I thought that OZW was used by OH, that’s my mistake (misinterpreted). I had to google JNI, but I get the point. Different language.

It’s silly that it is upto the gateway if devices are properly supported. Z-Wave is promoted as interoperable.

I expect OH Z-Wave binding is based on reverse engineering as well, similar as OZW. When I find some time I will setup OH2 and will try to setup the Z-Wave config.

10

Yes, and no… ZWave devices will interoperate quite well without the database - it is definitely one of zwaves strengths. This will work fine with devices that aren’t in the database (at least for OH1!), however, where the database comes into play is -:

  1. To add configuration - the devices don’t self describe the meaning of their configuration parameters, so we add this information to the database so that we can have a nice interface rather than having to resort to low level commands.
  2. To work around bugs. Some devices don’t stick quite to the standard, or have some sort of bug, and we need to add a workaround. These workarounds are coded into the binding, and then enabled or configured in the database.

Absolutely. In fact I’ve used OZW as a reference in many cases :slight_smile:

Chris

11

Hi, guy’s

Where can i check for the first alpha release, I am eager to try it.

Best regards, Haris

12

Currently I haven’t made this available as it’s not possible to configure associations at the moment. This requires a change to the ESH core - there was some discussion about it on the ESH forum, but it’s not yet decided how to handle this.

13

Hi,
Is there any news about this new version ?

14

Sorry - I needed to do some work in the ZigBee binding over the past week or so.

The problem at the moment is that if I release this you won’t be able to configure associations as some needed functionality is missing is ESH. If I can find some time in a week or so to add this then we can get it available.

Chris

15

Hi,
Still no news about the missing functionality in ESH ?
Regards,
Enric

2 Likes
16

Hey Chris!

I’d like to give the topic a little “push” - any news yet?

17

No - there’s some discussion about the solution in ESH, but it’s not implemented yet.

18

Chris, FYI, running the ZWave 1.8 binding under OH2 creates some problems when exiting the ESH runtime, as if a serial port is not closed properly or alike. At least, on my Mac OS X here, the Aeon Labs z-Stick S2 (connected via USB over ethernet) 's driver is bugging the system. Looking forward to the 2.0 version of the binding :wink: :wink:

19

@chris
What are the missing parts in ESH?
Could you point me to the relevant entries in the Eclipse Bugzilla and Forum?

20

I need to be able to update options in parameters. I’m not sure that there’s a bug, but the discussion is pretty much at the top of the ESH forum - I think it’s called dynamic configuration information. I’m on my phone at the moment so can’t easily check but you should be able to find it easily…