SDK and Framework Introduction#
SDK 7.1x Overview#
Z-Wave and Z-Wave Long Range 700/800 are designed to meet the demands of the future smart home, where increasing needs for more sensors and battery-operated devices require both long range and low power. Context-aware environments are the next evolution in the smart home market, and they require technologies that have been optimized specifically for these applications.
The hardware is now based on the Silicon Labs Gecko family, a 32-bit Microcontroller based on the powerful ARM® Cortex®core. This change has resulted in power consumption being reduced by 80%, the point-to-point range has been increased to over 100 meters, and the mesh range increased to over 400 meters. With fast wake-up and back-to-sleep mode, battery-powered sensors can now last for ten years using a single coin cell.
To leverage off the powerful hardware, the software has been redesigned. The software now uses a Real-Time Operating System to divide the Z-Wave protocol and the application into independent tasks, an event driving architecture to ensure no direct function calls between protocol and application, and a power manager to automatic power down to lowest possible power mode. While everything has been redesigned, existing customers will find the Z-Wave Framework has been kept, thereby ensuring easy development.
Specifications have been updated to the Z-Wave Plus v2 to ensure interoperability between all Z-Wave products and vendors, and backward compatibility with all existing products. Z-Wave 700/800 devices work seamlessly with the world’s largest ecosystem of interoperable smart products.
Z-Wave Plus v2 Specification#
Each product must follow the Z-Wave Plus v2 specification to be able to pass the certification program and ensure interoperability in the ecosystem of existing products.The primary focus is the ease of use for consumers, which can be summarized into the following:
Shopping does not require intensive knowledge about which products work with which other products.
Installation is as simple as possible and intuitive.
Operating the products does not require any technical knowledge.
No tricky maintenance procedures, such as exclude/include, are needed.
To accomplish this vision, several new requirements are added to the original Z-Wave Plus specification. These additions include:
Both Security-2 (S2) and SmartStart are now mandatory to increase security while keeping the inclusion process simple.
Each product must support Identify functionality, i.e., must feature a visible LED for identification purposes, making it easy to identify a product.
All actuators must support the Basic command class, guaranteeing that any controller can control any actuator.
Any state change must now be reported, making sure the controller always knows the true status of a device.
OTA Firmware update is mandatory to support for all nodes, and dynamic capabilities are now allowed as a controller must have an option to re-interview a node to detect any new/changed capabilities.
For more information about the specifications, refer to [7] and [8].
Z-Wave Plus v2 Framework#
The purpose of the Z-Wave Plus v2 Framework is to facilitate the implementation of robust Z-Wave Plus v2 Compliant products.
The framework is described in full detail in [9]. It is strongly recommended that you read this document before developing your own Z-Wave Application. You can read a short outline here to give you an overview.
The ZAF consists of three blocks:
Transport Layer: This layer handles all communication with the protocol, which includes single cast, multicast, Multi-Channel encapsulation, delivery of bundled commands, etc.
Command Class Handlers: These handlers parse and compose Command Class frames.
Utilities (Utils): Utilities are composed of different modules. Among them, there are modules for handling I/O communication specific for the hardware bundled with the SDK. Other modules are battery monitoring and firmware updating, etc.
The figure below outlines the Z-Wave Plus Framework modules.
Libraries#
This section introduces the different libraries available in the SDK 7.1x. See [6] and [9] for more information. Overall the SDK has 2 libraries: controller library and end device library. The controller library is used for controllers running the Z/IP Gateway and will not be used by end devices. The end device library is used by all the Z-Wave certified applications for end devices.
The end device library can be configured for always on (mains powered) devices or for battery devices.
Always on End device (AOS): End devices that are main powered. They are always listening and act as repeaters in the network. Example usages are on/off switches.
Reporting Sleeping End device (RSS): Battery-operated devices that remain in sleep mode until they are triggered; example usages are door/windows sensors and motion sensors.
Listening Sleeping End device (LSS): Also known as a Frequently Listening Routing End device (FLiRS). A special variant of battery-operated devices, which provide a mechanism to wake up the device within one second, with the battery drain very close to that of a fully asleep device. The FLiRS device alternates between sleep mode and a partially awake mode in which it is listening for a special wakeup beam signal at the rate of once per second. When the FLiRS device receives this beam, it immediately fully wakes up. If the device does not hear a beam, it goes back to full sleep for another period until it partially awakes again and listens for a beam. It is this partially awake mode combined with the special beam that provides for battery lives on par with fully sleeping devices while providing communications latencies of around one second. Example uses are door locks.
Association Groups and Endpoints#
An association is the creation of a logical connection between nodes. It provides the ability to instruct a end device to control other end device(s) upon activation directly. A device must support at least one association group (group 1), which is designated for “Lifeline Reporting" (as defined by the Z-Wave Plus v2 Device Type, see [8]). Each group is responsible for controlling and/or reporting specific commands, e.g., a temperature measurement. One group can hold multiple commands if needed.
Association Group Information (AGI) enables Machine-to-Machine interfacing as well as human user interpretation of available association groups, thus eliminating the need for paper-based documentation.
All device-centric events are mapped to the Lifeline group; this includes events such as Battery Low, Tamper Alarm, and Device Reset Locally. The Lifeline concept allows a gateway to set up just one association from a device to get all it needs.
In the example of a motion sensor, the sensor reading is mapped to the Lifeline group. In contrast, another association group targets local application functionality, such as turning on a lamp based on movement.
Endpoints are the ability for a device to support multiple controllable endpoints within one device. Each endpoint specifies device and command classes supported and can be controlled individually.
Z-Wave Long Range do not support a mesh network resulting in an easier configuration of associations. A Z-Wave Long Range node must only support the Lifeline group and it is only allowed to define one node ID, typically configured to the gateway destination. All the home application logic is situated on the gateway in a typically Z-Wave Long Range network.
Security#
Security 0 was the first version of security. This command class provides a framework for establishing encrypted communications within a Z-Wave network. However, the key exchange at inclusion is vulnerable to interception.
Security 2 is the latest Security Command Class and is required for all Z-Wave devices. S2 defines three types of security layers:
S2 Access Control
S2 Authenticated
S2 Unauthenticated
S2 security operates with the concept of a network key. All nodes may use this key to communicate with each other. S2 divides the logical Z-Wave network into three dedicated security classes, with each one having a unique network key. A given S2 security class not only identifies the network key to use but also dictates the rules applying to authentication of a new node during inclusion. The “S2 Access Control” class is the most trusted class, intended for access control devices like door locks and garage doors. The “S2 Authenticated” class is used for all normal household devices such as sensors and light dimmers. The “S2 Unauthenticated” class is the least trusted class. It is only intended for the most constrained controllers that, due to a limited user interface, are not capable of authenticating a node joining the network.
In a wireless environment, there is a real risk that a foreign node is included accidentally or due to malicious intent. The S2 authentication process allows an including controller to verify that a joining node is indeed the physical device that it claims to be. Depending on the UI, an including controller may allow the user to enter a Device-Specific Key (DSK) string of decimal digits that can be read visually or scanned as a QR code.
Giving that SmartStart is mandatory for Z-Wave devices, all Z-Wave based devices must request either S2 Access Control or S2 Authenticated. If requesting S2 Authenticated, a node must also request S2 Unauthenticated for backward compatibility. All Z-Wave Long Range devices only support SmartStart as inclusion method and S2 Authenticated is the lowest class key allowed.