Design Article
How to develop Z-Wave devices
Christian Pätz, Z-Wave Alliance
10/9/2012 12:12 AM EDT
3. Design interoperable products
The communication part of the device control code needs to comply with the Z-Wave specification. The Z-Wave specification defines different roles of a device and the developer must choose one of these role types.
• Role in the network: controller can built own networks, additionally differentiating between mobile controllers (e.g. remote controls) or static controllers (e.g. gateways)
• Power supply model: battery powered with regular wakeup, mains powered, battery powered that can be waken u using a wakeup beam.
• Function of the device: switch, dimmer, motor control device, thermostats etc.
The role models of Z-Wave are described in so called Device Classes. The manufacturer needs to choose one device class the products shall fit in. This already defines certain functions and services this device must support. The wireless functions and services of a device are described in so called Command Classes. Command classes are groups of wireless commands that are used to control certain aspects of a device or to deliver data in relation to this aspect.
Command classes are e.g. called Binary switch, Battery, or Motor Control, and combine all functions to deal with a binary on/off switch, the batteries status reporting or the control of a motor device. The command classes that are required by choosing a device class are called mandatory command classes. More than 20 Device classes and 100 Command Classes are described in the Z-Wave Standard.
The manufacturer can - and typically does - add additional voluntary command classes. There are no restrictions on what other voluntary command classes are implemented but in case a certain command shall be supported by the device this command class needs to be:
• announced in a so called Node Information Frame during the inclusion process
• implemented completely and according to the Z-Wave Command Class specification.
The API description of the libraries, the definition of the device classes and the definition of the command classes are therefore the core documents Z-Wave developers need to work with.
The communication part of the device control code needs to comply with the Z-Wave specification. The Z-Wave specification defines different roles of a device and the developer must choose one of these role types.
• Role in the network: controller can built own networks, additionally differentiating between mobile controllers (e.g. remote controls) or static controllers (e.g. gateways)
• Power supply model: battery powered with regular wakeup, mains powered, battery powered that can be waken u using a wakeup beam.
• Function of the device: switch, dimmer, motor control device, thermostats etc.
The role models of Z-Wave are described in so called Device Classes. The manufacturer needs to choose one device class the products shall fit in. This already defines certain functions and services this device must support. The wireless functions and services of a device are described in so called Command Classes. Command classes are groups of wireless commands that are used to control certain aspects of a device or to deliver data in relation to this aspect.
Command classes are e.g. called Binary switch, Battery, or Motor Control, and combine all functions to deal with a binary on/off switch, the batteries status reporting or the control of a motor device. The command classes that are required by choosing a device class are called mandatory command classes. More than 20 Device classes and 100 Command Classes are described in the Z-Wave Standard.
The manufacturer can - and typically does - add additional voluntary command classes. There are no restrictions on what other voluntary command classes are implemented but in case a certain command shall be supported by the device this command class needs to be:
• announced in a so called Node Information Frame during the inclusion process
• implemented completely and according to the Z-Wave Command Class specification.
The API description of the libraries, the definition of the device classes and the definition of the command classes are therefore the core documents Z-Wave developers need to work with.
|
|
|
|
|
Navigate to related information
Tim Miner
10/10/2012 11:59 AM EDT
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:
7. Conclusion
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.
Sign in to Reply
ssfrr
10/11/2012 11:21 AM EDT
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.
Sign in to Reply
joyhaa
10/12/2012 6:05 PM EDT
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
http://code.google.com/p/6lowpan/
Sign in to Reply
joyhaa
4/20/2013 12:01 PM EDT
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.
Sign in to Reply