For the software development, a System Development Kit (SDK) is needed. Different versions of SDKs are offered by Sigma Designs, Mitsumi or DigiKey with price points between $1500 and $3500. They differ in the selection of hardware provided. The more expensive SDK-versions not only contain EEPROM programmer hardware but also different test hardware for sensors, actors and for different frequencies. All SDKs contain the software and documentation package. In order to access the set of documentations, software codes and tools, a NDA with Sigma Designs needs to be signed. By signing the NDA the manufacturer agrees to keep all information provided in the SDK as confidential.
As shown in Figure 4 the communication stack of Z-Wave consists of three parts. The PHY and MAC layer is specified as ITU-T recommendation G.9959 [ITU2012]. The network layer is Sigma Designs proprietary code and protected by several patents. The application layer is defined by the product manufacturer but needs to comply with the protocol to ensure interpretability and product certification.
The SDK contains all needed documentation and code to build a firmware that covers all three parts of the communication stack. The NET, PHY and MAC layer are well-defined and shall not be altered by the developers. They are therefore not available as source code but as precompiled libraries only. The libraries are complemented by plenty of sample codes to show the usage of the libraries and to document the implementation of a Z-Wave compatible code.
The closed source of the libraries has its pros and cons: • Con:
In case there are bugs in this library, the turnaround cycle is much longer and for developers debugging is harder. • Pro:
Nobody can change the lower part of the protocols. This makes sure that at least for this part all Z-Wave products interoperate without problems, since they all rely on the same well-managed code base.
In order to compile a firmware for the Z-Wave modules using the Sigma Designs SDK a KEIL C compiler is needed [KEIL]. Although KEIL is a good and professional tool developers would certainly prefer to use the GNU tool chain as well. The precompiled libraries for the PHY and NET layer however force the usage of certain versions of the KEIL compiler and its environment. The SDK contains the following parts:?precompiled libraries for different applications, sample code,?source code for certain tools and the complete documentation of the Z-Wave protocol.
Z-Wave distinguishes different functions in the network, referred to as controllers or slaves. These different roles in the network use different functions in the protocol in Z-Wave. As a result, the SDK offers different library versions for different device roles in the network. The main reason for this is memory footprint since the implementation of all functions in one library would exceed the available EEPROM space to store operation code. ?Most of the functions of the library, particularly the versions dealing with the network organization but also the initialization of the chip and the handling of the input and output queue of the transceiver are hidden from the developer. The main functions the developer uses are:
• sending and receiving application commands?
• including / excluding devices?
• some network management functions?
• access to the peripherals such as watchdogs, TRIAC control etc.
The SDK also contains a skeleton to simplify the design of new applications. Various sample codes for different functions of Z-Wave simplify the use of the skeleton and help in developing applications. Unfortunately developers have almost no debugging mechanism for writing Z-Wave firmware. There is neither a JTAG in circuit debugger interface available or any emulator or simulator for the chip. The memory constrains for the 300 series add another layer of complexity and can make the development of firmware a frustrating experience. However, the Z-Wave ecosystem contains several service providers that provide help and professional development services. [Z-Wave.Me] [Seluxit].
Z-wave rules for HA(home automation), Zigbee is still _trying_ for SE(smart energy) after so many years, I worked on zigbee for a long while and hated that, it's too complicated for simply sensors, the protocol/profile design is terrible(i.e. no two profiles can co-exist on the same node), the only thing good about zigbee is that it has a fancy name, its spec is made by marketing folks instead of engineers.
the problem is that: it's nearly a single vendor thing, unlike zigbee.
z-wave is easier to implement while zigbee is not, however zigbee seems more open, also i don't think zwave support 6lowpan
Overall a well-researched article by someone obviously familiar with Z-Wave. Nice overview.
The link to the BuLogics website is giving me trouble because of the trailing slash.
Full Disclosure: I work for BuLogics.
I found the article to be packed with great information. However, the final edit semed to leave several run-on sentences that promoted confusion.
Look at this example taken from the last portion of the article:
The integration of Z-Wave hardware in own projects is quite...
To my eye, the word "your" was probably intended to go between "in" and "own" but is missing. This kind of omission is sprinkled througout the article.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.