Hello,
I’m currently doing a little bit of research into the zwave protocol and want to try building something myself.
As I have plenty of time with the corona and quarantine.
I found plenty of ZWave APIs but some are very outdated or doesn’t get updated anymore.
My question is which API that openhab is using or if they just reversed engineered the communication?
Thanks in advance
I guess your question is “what library” is being used rather than what “API”? The API is just the standard ZWave protocol definition - but there is no external library being used.
The binding is here.
Chris has written it specifically for openHAB.
OpenHAB has a REST API, if that is what you want. Install restdocs to try it out in a web browser.
Ah ok like that, because I found multiple C++ APIs but nothing that I was wanting to use.
So the serial communiation with a ZWave controller is for all the controllers the same?
For example I have an aeotec z stick, there is a standard to communicate with it?
Can you maybe point me somewhere, because I don’t find a lot about this.
Currently I don’t have acces to my openhab server, but I do have my zwave stick with me to play arround with it.
OpenHAB is written in Java - not C/C++.
Not completely - there are 2 APIs, but only 1 is documented. This is all about to change in the coming months anyway as Silabs are opening this up so there will likely be other companies chipping in.
You can find the ZWave documentation on the Silabs site.
Yes I know that openhab is written in java, but other people wrote (outside openhab) APIs for zwave.
ah it’s from Silabs, I already downloaded their tool, will check more their website, SDK and other stuff I found from them.
I know in the past (few months back) they didn’t published anything, even not their tool.
I hope they bring more documentation about it.
Thanks for some clarification, I lost my track through all the trees.
Sure, but this is the openHAB forum, right? You asked about openHAB API, and then start talking about C++ so it was unclear that you understood this.
Not really months - years now (2 I think).
What exactly are you missing that still needs to be released?
openzwave is one but I have found this one written by Chris as superior. He uses Silabs documentation, not their libraries.
I already checked a little bit of their documentation but didn’t really saw in details the communication bytes.
Can be me that I didn’t found it yet.
Guess I will need a few hours/days to read stuff 
I will check out the one of Chris and see if I can use it in my own project.
Download the latest version of Z/IP and ZWARE. It is free and finally in the latest release (other than a 160 endpoint limit) very good.
The early versions were slow and buggy but it is coming of age. Possibly slightly late in the day as it is very unloved as Chris will prove in a few minutes after I post.
All you need is a 700 series bridge controller from Mouser or other and enjoy the advances of the 700 chipset which are significant.
Out of the box you get S2 security and smartstart. Add to that network health check in a basic form it is a good place to start your journey.
It out performs the serial interface that is currently in most implementations due to the better design pattern used and since the latest reprogram of the code around the bridge serial interface in Z/IP is very hard to break.
The architecture has many layers from the Z/IP interface to the zware sample portals and api so there are downsides in the pure complexity but some of the advance features that are wrapped are reasonably complex and not available in most solutions.
If you are interested I can provide more info.
That software is unrelated to the openHAB binding though.
Just a minor point - I don’t think this is right - it’s fundamentally the same. Certainly the API is exactly the same, although it is true that it has been rewritten for the ARM.
The Serial API is not a great system - 300/500 or 700. ZWave doesn’t use sequence numbers, so tying up transactions is difficult, and this means that there are significant limitations. This is the same in Z/IP as well unfortunately.
Otherwise I don’t disagree that Z/IP could be a good place to start a home brew system. I am however assuming for now that it will not be supported for much longer, although I might be wrong and SiLabs may choose to continue to support it for their chipsets.
In the medium term I will likely release a standalone library in a similar way to what I’ve done with ZigBee - this is currently in discussion with the guys at Sigma.
The question was about zwave API not about the zwave binding
Incorrect. See the quote below.
They were asking about the implementation in openHAB which is the binding. API was just their guess.
yes and no
The latest version has a couple of subtle implementation changes that improve how it behaves.
It changes it from dreadful to slightly better than most if not all current serial implementations.
I have tested and you can get more traffic through Z/IP than you can through the openHab zwave binding.
You could off course copy the strategies and it would even out the performance. Possibly in the new version you already have made these improvements.
Not sure when you last tried a version but worth a retest.
It certainly has a lot of layers but it wraps a lot of complexity so as you say a valid place to start a home grown implementation. Hard to see how it would fit with general openHAB strategy though as linux only.
Possibly the latest improvement is too little too late and it is definitely an understatement to say it is not universal loved.
Ok, maybe - the source looked the same to me though.
Probably, but that’s more to do with the way the binding works than the way the serial API works. The binding will only release a single transaction at once, and it has a broader definition of what constitutes a transaction.
@chris
Could you give a little insight on your „roadmap“.
Also considering that sigma announced to be more open and release former somehow closed information will this mean that the binding will be refactored or something?
I have like 100 Zwave devices and with such a high number there is always 2-3 of them that drive you crazy and do never seen stuff. Recently I see nodes that all of a sudden Report messages with a different node id that was never assigned to them or even never assigned in the network at All and the binding discards it (correctly of course). Many devices that work unreliable with bad reporting of battery values dropping from 100 to empty just as an example. Constantly new issues with devices and hick-ups that I in general I learnt to mistrust Zwave and especially battery devices. But with so many devices that is somehow a lock in.
Best
I know Chris is working on doing that. He is also working in migrating the database and I have assisted in migration work on some of the scripts.
I believe the current binding was primarily built by reverse engineering the device behavior.
What has been announced at the end of last year is that silabs will release all the lower layers of ZWave. This doesn’t directly change anything, but what it means is that other chip manufacturers (other than Silabs) will be able to produce ZWave hardware.
All the higher layers remain the same, so it doesn’t really impact users. In the middle are the current certification requirements to use Z/IP which I would expect to be dropped - IMHO if other chip manufacturers are able to offer products, I expect that cannot come with a requirement to use a Silabs product (ie Z/IP). This is just my guess based on the fact that other manufacturers will be able to play in this domain, but details are still to be released and this is probably still at least a few months off (I think the original press release stated late summer, and I could guess that with the world situation, that could well slip).
My expectation is to take some version of an openHAB type binding through certification - probably next year now, but let’s see how the world situation develops. Given that I’m unsure that openHAB is willing to make the changes in the core needed to support this, I’m unsure at the moment if this will be the exact binding that users here use.
I hope that helps.