I know there has been talk in non-specific threads, but I wanted to start something just for Z-Wave 700 series controller compatibility. I noticed Silicon Labs is already starting to talk about building their 800 series products.
What is the main reason OpenHab doesn’t support the Z-Wave 700 series controllers yet?
Lack of API documentation? Money for licensing? Time to rewrite the binding? etc?
I believe the problem, if I recall correctly, is that silicon Labs is requiring the use of their proprietary C library and not allowing access through a serial API. Including such a library in an open source project would be problematic. Things may have changed since I read that or I may be misremembering.
What are the problems with that? Would a solution for that be to “press this button to install a third party Z-wave 700 plugin” or whatever? For example VirtualBox has their extension pack that is a separate download and is licensed differently.
But alternatively, what are the hiccups with making the current serial interface work with the 700 series hardware, without Silicon Lab’s official “700 series” stamp of approval?
It’s a massive rewrite of the binding - so sadly it’s a big problem.
In theory it’s possible (and much much easier) to modify the binding to use the existing serial API, but Silabs have changed this and not published the spec (unless it’s come out recently). I’ve personally not had the time recently to look through this to work out what’s changed. I was working on a commercial system a while back and Silabs stated they would release the spec. This didn’t happen, and the commercial customer decided they didn’t want to go with ZWave due to concern over its longevity, and moved to Zigbee instead.
Would the Z-wave spec be inadvertently embedded into the Z/IP source code? If they are translating everything to IP, it seems like it would be in there somewhere.
There are different levels of specification - the command classes are specified, but the low level API isn’t. Yes, you are right though - it’s always possible to decompile software, or look at data on the serial port to find out how something works. This is reverse engineering, and it’s how the binding was effectively written around 10 years ago as the API was not released.
This is however very time consuming, and error prone and as I said above, I’ve not had the time to sit down and try to work out what has changed in the 700 series API.
It’s possible - it just takes a lot of time.
Is OpenHAB using it’s own proprietary binding or is it making use of a third party managed project like OpenZWave or something similar?
The openHAB binding doesn’t make use of any other libraries.
OpenZWave is pretty much unmaintained now for quite a long time.
Is that because of the Z/IP direction the official group is going or another project taking its place?
I don’t think it’s anything to do with Z/IP. It’s just that the maintainers seemed to not have time to continue the project and there has been no significant activity since about 2019. Most projects that used openZWave have now moved to other libraries from what I can see.
Hi
Are there any news regarding Z-Wave 700/800?
Currently I have a “Razberry” (Z-Wave 500). But if this will die in future, maybe there are no old controllers to buy anymore. Already at this time it seem to be harder to get an old one. So I’m a little bit afraid and hope there will be support soon, because I plan to invest even more in Z-Wave devices.
Starting with OH4.1M4 the 700 chip zwave controllers should work.
This wasn’t in the release notes. Is it safe to proceed with testing?
Yes, I tested it yesterday in the milestone.
Also since I had a hand in the PR, I have run with 700 controllers in OH for several months. (There was a late change during the review that wasn’t tested long, but seems okay.) It would be good to get feedback before OH4.1 in case something needs to be fixed.
Dear @apella12
Great to hear and thank you very much for your effort!
I read on GitHub that there might be issues when using both types of chip with one instance of the Binding:
Although unlikely, if using two zsticks of different chips (500 and 700) with one instance of the binding, there could be problems with this jar?
How will this issue look like? Just want to know before trying to migrate.
Any other things you might have feedback on when testing?
FYI:
I’m currently using 2 Sticks (500 and 700) as i started migrating to a 700 Stick some time ago as i was expecting some more performance and stability than my old 500 stick.
I’ve done this using zwaveJS and mqtt. I only did some devices until now as i found it pretty anoying using another tool for z-wave and creating all the mqtt topics in OH.
Currently everything is running on the same VM. I just need to stop zwaveJS and add the 700 stick to OH. I’m using the Aeotec 700 Stick.
That possibility was pointed out in the review by the developer, so I added it to the comment section on my personal github. However, it was addressed (fixed) in the official binding.
I also have since deleted that jar from my github website to avoid confusion.
Thanks for that information.
I tried using the Aeotec Gen7 Stick. The Nodes are already added to the controller. I stopped zwave-js-ui and added the Gen7 Stick to OH. The Stick got online. Yeah.
I then tried to add the Nodes. The nodes showed up in my inbox but didn’t show any further informations. Even the name did not change and all nodes showed up like “Node 7”.
I added some Nodes for testing but they wohn’t get online.
Here are the logs when Scanning on the Z-Wave Network with only the Gen7 Stick enabled:
gen7Debug.txt (13.7 KB)
Maybe you have an idea.
I also tried Including a new device. But it doesn’t even show up when in include mode.
I restarted zwave-js UI right now. And the recently added device using OH now shows up in zwave-js.
Inclusion seemed to work even the device did not show up on OH
