|
|
|
|
|
Z-Wave Basics
Z-Wave is a protocol designed for wireless communication with and within a network of smart home automation devices. It specifically targets remote control applications in residential and light commercial environments. The technology uses a low-power RF radio embedded or retrofitted into home electronics devices and systems, such as lighting, home access control, entertainment systems and household appliances. The Z-Wave wireless protocol is optimized for reliable, low-latency communication of small data packets, unlike Wi-Fi and other IEEE 802.11-based wireless LAN systems that are designed primarily for high-bandwidth data flow. Z-Wave operates in the sub-gigahertz frequency range, around 900 MHz. This band competes with some cordless telephones (DECT) and other consumer electronics devices, but avoids interference with Wi-Fi and other systems that operate on the 2.4 GHz band. Z-Wave is designed to be easily embedded in consumer electronics products, including battery operated devices such as remote controls, smoke alarms and security sensors. Z-Wave was developed by a Danish startup called Zen-Sys, which was acquired by Sigma Designs in 2008. Z-Wave is currently supported by over 160 manufacturers worldwide and appears in a broad range of consumer products in the U.S., Europe and Asia. The standard itself is not open and is available only to Sigma-Designs customers under non-disclosure agreement. All these products share the Z-Wave transceiver chip that is supplied by Sigma Designs and Mitsumi. Z-Wave home automation technology comprises of three layers:
Z-Wave is one of the most reliable wireless technologies. Every command sent is acknowledged (ACK) by the receiver, which sends a return receipt to the sender. This does not guarantee that the message is delivered correctly, however, the sender receives an indication that the situation has changed, or an error has occurred. If a message transmission is unsuccessful the sender node will try to retransmit it up to three times or 65 seconds depending on hardware and firmware versions.
In later versions of Z-Wave the so-called "explorer frames" are introduced. They can be used to heal broken routes caused by moved or removed devices .Explorer frames are supposed to reach the target device, even without any topology knowledge by the transmitter. Explorer frames are used as a last option by the sending node when all other routing attempts have failed.
Z-Wave Device Types
In Z-Wave terminology controlling devices are called controllers, reporting devices are called sensors and controlled devices are called actuators. Nearly all of the Z-Wave devices available on the market can be categorized into one of these functional groups:
Controllers are factory programmed with a Home ID, which usually changes after every reset. Slaves do not have a preprogrammed Home ID as they take the Home ID assigned to them by a network controller.
There are two types of controllers: primary and secondary. The primary controller in a Z-Wave network can include further nodes into the network, whereas, in networks without an activated SUC or SUC/SIS (refer to the Static Controller section below), a secondary controller cannot. In all other respects, a primary and a secondary controller operate the same way. Each Z-Wave network should have one primary controller, which is normally used for network setup.
Sensors and Actuators are known under the common name Slaves. These are devices which, controlled by other Z-Wave devices, deliver reports and/or perform a set of actions.
There are also two types of slaves: standard (normal) slaves and routing slaves. Standard (normal) slaves usually cannot send unsolicited messages to other nodes. They can only send messages to another node as a response to a message from it. An exception is them sending unsolicited messages on wake up. Routing slaves, in contrast, can send unsolicited messages to other nodes, which allows them to retransmit a message from a sender to a recipient. Usually mains powered devices are chosen for routing slaves, because they do not have the limitations a battery imposes. In Z-Wave Plus all devices are required to be routing slaves, even the battery powered ones. Furthermore non Z-Wave plus sleeping devices can be routing slaves if they support associations.
Network Setup, Topology and Operation
Z-Wave utilizes a mesh network topology and consists of at least two nodes a controller and a controllable device. Additional nodes (devices, as well as controllers) can be added at any time.
To be able to communicate with each other the nodes need to have access to a common media. Each node in the network also needs to have a unique identification to distinguish it from the other nodes in the same network. The Z-Wave protocol defines two types of identification for the organization of the network.
Two nodes can communicate with each other only if they are part of the same network (i.e. they have the same Home ID). In this case they cannot have identical Node IDs because it would not be possible to distinguish between them. This means that each node in a single network can be individually addressed, giving you complete control over your own home automation system. Nodes from different networks (i.e. with different Home IDs) cannot communicate with each other and they may have the same Node ID, because their home networks are isolated from one another.
To be controlled via Z-Wave a device must be "included" to the Z-Wave network. This process is called Inclusion (also known as "pairing" and "adding"), and is usually achieved by pressing a (sequence of) button(s) on the controller and the device being added to the network. An Inclusion procedure only needs to be performed once, after which the device is always recognised by the controller. During such a pairing the primary controller provides the node being included with Home ID (the ID of the network managed by this controller), as well as Node ID (the identifier of the node within this network). The length of the Node ID limits the number of nodes that can be included in a network to 256. However, some of these nodes are allocated by the network for internal communication and special functions, so the Z-Wave network can have a maximum of 232 devices. If a node is not any more needed as part of a Z-Wave network, it can also be removed from this network. The process of removing (excluding) a device from a Z-Wave network is called Exclusion. During an Exclusion the Home ID and the Node ID are deleted from the device. The device is reset to the factory default state (controllers have their own Home ID and slaves have no Home ID). Devices can be removed from the Z-Wave network through a process of button strokes, similar to the one used for their inclusion.
One basic challenge for the inclusion/exclusion of a node to/from an existing network is the distance between this node and the primary controller. There are two approaches to overcome this challenge:
The former is achieved through enabling the controller adding mode option High Power and the latter - through enabling the controller adding mode option Network-Wide Inclusion. See Z-Wave Events for more detail on these options. According to the last Z-Wave specification it is recommended to always enable these options. Network-Wide Inclusion is only available when including nodes and depends on the capabilities of the controller firmware and the capabilities of all nodes in the path between the controller and included node.
A node (called sender) can send a message to another node in the same network (called recipient) in two ways:
A Z-Wave device always tries first to transmit a message directly to its destination. If not possible, the device tries with the last working route to the destination. If this fails, the device uses the explorer frames mechanism if supported. Explorer frames is a mechanism in which the controller broadcasts a message and the nodes that receive it do the same until the message reaches its destination node. If the controller does not support the explorer frames mechanism (older controllers), it tries all available routes in its routing table for up to 65 seconds.
Since all Z-Wave networks use the same frequency, they compete for it. Before sending a message the device first ensures that there is no wireless transmission ongoing in its frequency, and if there is - it waits for a pseudo-random amount of time before it checks again and then sends it's own message. This means that having multiple Z-Wave networks in the same physical location may reduce the overall performance of all these networks, even though they have different Home IDs.
Having a large number of networks/devices in the same room degrades the performance!
Associations
Z-Wave allows to create associations between devices. This allows devices to communicate directly without the assistance of the network controller. A typical example is the association between a door binary sensor and an alarm (being activated when a signal for opening a door is sent by the door binary sensor). To use Association the sending node must know a valid route to the destination. Only routing slaves and controllers can use association. To set up an association the sending node must know the Node ID and Receiving Node ID of all devices that are to be associated.
Battery-Powered Devices
Battery-powered devices are also typically sleeping devices, which means they spend most of their time with their RF module turned off and are therefore unable to receive unsolicited messages unless they wake up. Such devices periodically wake up and send a wake up notification to a pre-configured node, and wait for a certain amount of time before they go back to sleeping mode. The node target of the wake up message must send back at the end of the communication a Wake up no more info message. During wake up period the device can receive Z-Wave messages, can be inspected and configured. This implies that the communication with sleeping devices is mostly asynchronously.
A special type of battery-powered device is a FLiRS (Frequently Listening Routing Slave) device, which has its RF module powered off most of the time but is turned on shortly every few hundred milliseconds (250, 750 or 1000) to check if there is a beam signal active. All standard messages are ignored until the beam is detected, after which the device receives and analyses the incoming message, checks the Home ID and destination Node ID to verify whether the device itself is the recipient, and if so - processes the message. FLiRS devices are therefore a kind of semi-sleeping devices with which unsolicited communication can be carried out at any time. However, a certain price is paid for this advantage. Firstly, due to the beaming process the communication with these devices is significantly slower. Secondly, the more messages are sent to the device the more its battery gets drained. In fact, even if a FLiRS message is not designated for a particular device it must still receive and process the message in the first place, in order to discard it. To avoid fast battery exhaustion the application should take into account whether a device is a FLiRS or not.
Network Security
All traffic in a Z-Wave network is transmitted unsecured and unencrypted, unless both the end device and the controller support Z-Wave Security. Secure communication begins with secure inclusion (which is an extension to the normal inclusion) during which a special handshaking procedure is executed after which all traffic between the two devices is AES-encrypted. The traffic is encrypted using a single network key for all devices, so that two secure end devices can also communicate directly. If the controller loses the network key for some reason, then it will fail to communicate securely with the secure end devices, which implies that these devices must be removed and added (securely) to the network again. If two devices are part of a secure network they can choose not to use encryption and communicate by using plain text. All Z-Wave plus certified devices support security.
Command Classes
The functionality of the devices within a Z-Wave network is organized into Command Classes. Command Classes are groups of commands and responses related to a certain function of a device. Each type of device will support different command classes - switches, dimmers, thermostats, etc.
To ensure Z-Wave devices can communicate with each other even when they do not know the specific function of the other device, there is a special command class called Basic.The basic command class is the lowest common denominator of all Z-Wave devices. Every Z-Wave device supports the Basic command class.
The Basic command class consists of two commands and one response:
The unique feature of the Basic command class is that every device interprets the Basic commands depending on the specific functionality of this device.
For example:
Device Classes
To allow interoperability between different Z-Wave devices from different manufacturers, each device must include certain well-defined functions above and beyond the Basic command class.
These requirements are called Device Classes. Device classes are organized into a three-layer hierarchy:
Z-Wave Plus introduces Device Types as a replacement for the Specific Device Classes. Device Types are used to better describe the device requirements. Generic and Specific Device Classes are still supported for backward comparability.
Basic Device Class
The Basic device class simply defines a device as a Controller, Static Controller, Slave or Routing Slave.
Generic Device Classes
The Generic device class defines the basic functionality that a device will support as a controller or slave. Current Generic device classes are:
Specific Device Class
Assigning a Specific device class to a Z-Wave device allows to further specify its functionality. Each Generic device class refers to a number of specific device classes.
In case a Z-Wave device is assigned to a Specific device class, it is required to support a set of command classes as functions of this Specific device class.
These required command classes are called Mandatory Command Classes and are individual to particular generic and specific device classes.
Above and beyond the mandatory command classes, Z-Wave devices can support further optional command classes.
A Z-Wave manufacturer is allowed to implement an unlimited number of optional device classes. However, if these device classes are implemented, the Z-Wave standard defines how these commands and functions are to be supported.
Device Types
Z-Wave Plus Device Types extend the Z-Wave device class specification in order to improve interoperability and preserve backward comparability. They specify additional Command Classes and a new network behavior during installation and runtime. The Z-Wave Plus InfoCommand Class is used to identify if a product adheres to Z-Wave Plus requirements and to identify which Role Type the Z-Wave Plus device supports.
The Z-Wave Plus Device Type is communicated through the Node Information Frame (NIF) and is the two byte concatenation of the Z-Wave Generic and Specific Device Classes. The Z-Wave Plus Info Command Class is used to differentiate between legacy and Z-Wave Plus devices.
Z-Wave Plus specifies the following Device Types:
Rules for Device Classes
The Basic, Generic and, if available, Specific device classes and Device Types are announced by the device during its Inclusion, using a Node Information Frame (NIF).
Like the device classes, the Node Information Frame also announces all optional command classes of the included device. With this announcement, a controller can use and control an included Z-Wave device according to its functionality.
A Z-Wave device works according to the Z-Wave standard if:
Z-Wave defines a broad variety of command classes covering almost every aspect of home automation and control. Nevertheless, manufacturers may wish to implement further functionality not already defined in a command class specification.
The command class Proprietary Function is defined to cover these needs. A Proprietary Function would allow a manufacturer to implement specific functions that can then be used only by other devices supporting these proprietary functions.
The use of a Proprietary Function is subject to approval by the Z-Wave alliance certification authority and requires extensive documentation. So far very few devices make use of this function. Typically, new requirements result sooner or later in an amendment to the existing standard, which makes this function part of the official standard and any proprietary extensions become obsolete.
Types of Controllers
Controllers are able to store and calculate routes in the network. They can acts as network topology storage and remote controls.
Static Controller
A mains-powered controller with fixed location is called static controller. It keeps up-to-date the routing table of the network and provides it on request to other controllers.
A static controller can be SUC or SUC/SIS capable, in which case it can not act as a repeater.
SUC
The Static Update Controller (SUC) is a special function of a static controller. It was introduced to allow all controllers in a network to have an updated routing table. Most static controllers can perform as a SUC, however, there could be only one SUC in a network, and normally this functionality needs to be activated (in most cases by the primary controller in the network). The SUC receives the updated routing table from the primary controller and provides this routing table to all other controllers in the network. Because the SUC is a static controller and therefore always active, and it always has the last version of the network topology, any other controller can regularly request an up-to-date routing table from the SUC. To make sure that all other nodes, particularly other controllers, are aware of the presence of a SUC in the network, the Node ID of an activated SUC is periodically communicated within the network. A SUC is useful in a network where the Primary Controller supports sleeping mode (like most portable battery powered controllers). If the original portable primary controller is lost or damaged, the SUC can assign the primary privilege to a new mobile controller, protecting the user from re-establishing the whole network with a brand new primary controller, and having a different Home ID. A SUC only stores the network topology and no associations are kept in it, so a SUC is not a general backup service.
SIS
SIS = SUC ID Server is a function introduced to enhance the SUC functionality to overcome the limitation that only one controller - the primary controller is allowed to include new devices.
The SIS acts as a depot for new Node IDs that can be assigned by controllers. Having a SIS in the network allows every controller in the network to include devices. A controller will just request a new Node ID from the SIS and assign this new Node ID to the device being included. The SIS ensures that Node IDs are only assigned to one node - avoiding conflicts. The only requirement for the respective controller is to have a network connection to the SIS server in order to request a Node ID.
A SIS capable static controller becomes a SIS (SUC ID Server) only on request from the primary controller. If there is no SIS in the network, when a new controller is included (different from installation or bridge controller) the primary will try to assign it the SIS role. After activation of the SIS functionality the SIS becomes the new primary controller if it was not primary before. All the other (slave) controllers are called inclusion controllers. There could be only one SIS in the network.
Portable Controller
This type of controller has the ability to discover its position in the network, when it needs to communicate with other nodes. All remote units are portable controllers. Portable controllers are typically battery powered and hence support sleeping mode. They are very useful in the inclusion/exclusion process.
A portable controller can not act as a SUC/SIS or a repeater.
Installation Controller
The installation controller is essentially a portable controller which incorporates extra functionality that can be used to implement professional installer tools which need extended network diagnostics. Like most portable controllers, the installation controllers are typically also battery powered.
Bridge Controller
The Bridge Controller is a static controller, which has the additional capability to represent up to 128 virtual slave devices. This is used to bridge Z-Wave to/from other network types like X10 or TCP/IP. The virtual slave devices represent the bridged devices communicating over other protocols. Note that the bridge controller needs to be primary or inclusion controller in order to include a virtual slave device.
A bridge controller can not act as a SUC/SIS or a repeater.
Selection of Devices - Controllers
The selection of devices is always based on the desired functionality of the network. A Z-Wave network always has a central control unit - either a portable remote control or a static (fixed location) controller built in or plugged to a gateway, for instance an IP gateway or a PC with the required software installed on it.
It is recommended to use a static controller for a reliable Z-Wave network installation.
Using a remote (mobile) control as the only controller for a Z-Wave network is not recommended unless:
Selection of Devices - Slaves
Portable dimmers and switches, also called smart plugs or wall outlet plugs are easy to choose. You just need to check that the device’s maximum switching capacity (load) is suitable for your appliance. Choosing wall switches is usually based on the aesthetic design, so that it complements existing switches or decor. Most switches have the same industry-standard design as other wall outlets, wall switches, antennas, phone jacks and Ethernet outlets.
When selecting dimmers and switches, it is highly recommended to consider the ones supporting a Z-Wave HAIL Command Class. This functionality allows the end device to send unsolicited change reports to the controller, e.g. whenever the user has pressed the switch physically on the device itself. Without this command class no such reports are sent and thus the end user UI will ultimately not reflect the correct state of the device.
Our Z-Wave module does implement a periodic polling mechanism to read and update the device states automatically, which as with any polling mechanism may take quite some time (a minimum of 40 seconds, or considerably longer, depending on the number of mains-powered devices).
Radio specifications