Sigma have just released the ZWave specification to the public domain. This is a massive help to ZWave binding development, and means that we don’t now need to use old specifications, which will in turn help us ensure we have implemented the protocols correctly (which in general is the case as we already work to specs which are mostly still applicable).
This is definitely great news, and I believe openHAB and ESH has played a big part in this decision. The work being done in ESH especially has meant that Sigma have needed to think about this, and both myself and Kai have been discussing with Sigma how we can open source the specs.
Over the coming weeks and months I’ll work through the binding to make sure that we have correctly implemented everything based on the updated docs.
For anyone wanting to look at the public specs, see below.
Silly question - does the publication include Z-Wave Plus, and in particular, the secure mode extensions which I know you and several others have been working hard to understand enough to implement in OH2 bindings?
Knowing how standards work in other areas, I bet there are still manufacturer specific ‘implementation issues’ to fight with (Fibaro, I’m looking at you and the FGD-212’s in my walls!) but this is indeed fantastic news.
I keep putting off factory resetting my 30 Z-Wave devices to re-pair with security disabled, and might just put the task off for a while longer!
Huge thanks go to you and Kai, and no doubt others for negotiating access to the specs.
Yes - it includes the secure classes. As I said though, I already have an old definition, this so it’s nothing new here. The security classes are quite old, so the definition I currently use already has this specified. The documentation doesn’t mean an instant implementation ;).
I’ve not checked about Z-Wave plus, but I’m certain it will include this. We already have this implemented in the OH2 binding, so the docs will help confirm things are implemented correctly.
Yes, but again, only in the newer command classes. Documentation for most of the standard classes have been available in the public domain for many years. We have only been reverse engineering new command classes…
The big problem is that not all devices conform to the standards (despite the approval program!). This means that we still need to reverse engineer data to work out problems.
When I was in discussion with Sigma a few months back, this is what they were pushing. They really wanted to make this the open standard, but it doesn’t really work for projects like OH. It’s not open source, and it’s not necessarily portable to all platforms which is one of Javas big positives.
On balance, other Z-Wave controller vendors must have signed the NDA’s and gained access to all documentation, but their forums still contain ‘this device doesn’t work, code a workaround’ discussions!
(added attempt at explanation mine)
That’s interesting - I can see the thought process that you don’t need access to the full protocol, just the abstracted Z/IP + Z-Ware for Portal SDK or Z-Wave for CE SDK plus Sigma’s protocol implementation and develop against the API abstraction layer.
As you say, less useful for OH where many of us are looking for on-site multi-protocol middle-ware to reduce external dependencies, or a choice of a platform other than Sigma’s supported dev kit options.
When the ZIPR came out I priced it at about £40 which is pretty much the same price as the Razberry or Aeon G5 Z-Stick in common use today.