For a user, who is new to the field of home automation, the world of Z-Wave technology might at first seem intimidating. And it all starts with picking the right Z-Wave hub, a.k.a controller or gateway.
At the time of writing, one can choose between 2748 slave devices and around 336 number of Z-wave hubs. That is a huge amount of devices to choose from, which would require a lot of man-hours to look through. Therefore, more and more people decide to perform their due diligence by looking for recommendations in various groups, whether they are in the form of Facebook groups, subreddits, blogs or even the older IRC channels, where existing users can share their uncensored experience.
Before setting up a home automation system, the user has to make two main decisions, which are: what kind of end devices (slaves) will they be using and what gateway (master) will be used to control and receive various measurements and reports from them.
The purpose of this short article is to present a high-level overview of the differences between the Z-Wave enabled gateway devices, currently found on the market.
What are Z-wave hubs?
Hubs, a..k.a. gateways, a.k.a. controllers are devices, consisting of hardware and a software part, which enable the user to add or remove other Z-Wave enabled devices from a network. Each Z-Wave network is uniquely identified by a 4-byte value (e.g. E2 FA 18 2A), called the HomeId, and can host up to 232 devices. Every device added to the network is a part of a so-called mesh network, which means that it can communicate with its adjacent nodes directly and can also relay messages via routing to devices, which are not in their direct range.
Once added to a network, one can use the Z-Wave hub to perform various functions, such as setup scenes (e.g. dim the lights to 80% at a specific time), calculate the optimal paths for the sent messages, frequently check the health of the network, make additional changes to the configurations of devices (e.g. configure a device, so it sends its power consumption or temperature reports every 10 minutes instead of every 30 minutes), monitor the communication in the network by looking through the log of sent and received packets, control the basic functionality of a device, etc. Some of these features are found in all gateways, whereas some are only available to a user, after purchasing a license.
Z-Wave hub hardware
From the hardware side of things, a device can communicate over Z-Wave if it contains a specific chip, which acts as an interface and enables it to communicate with other Z-Wave devices. This chip can be found in various forms on the market:
- as a part of an USB dongle
- a Raspberry Pi HAT (in some cases, the HAT versions, of a specific key/dongle, can achieve twice the range of their USB variants)
- as a part of a single circuit board, which are nowadays quite popular among the Maker and DIY communities.
The difference between the three options is that while the first two require a host system (such as a PC or a single board computer, for example, Raspberry Pi or Beagle Bone Black) the third one already has everything to run as a standalone gateway. Going with the first two options means that the user will have to install and configure an application, which will enable them to communicate with the Z-Wave chip and therefore perform the network operations mentioned above.
Z-Wave hub software
From the software side, the Z-Wave hubs can be divided into open-source gateways and proprietary gateways.
The first ones make use of open-sourced libraries, such as OpenZWave, which are usually hosted on public code repositories and are developed and maintained by their respective user communities. Once a change is added to the repository, it is subsequently merged with the codebase of other gateways, which use the same library, although this can take a while.
Proprietary gateways are commercial alternatives, usually bundled with other services (lately, prediction algorithms and the use of AI seem to be the rage), which have one important advantage: once a new device is on the market, device manufacturers can send their new devices to the authors for integration to avoid any problems in the future.
Working with open-sourced gateways usually requires the user to have a basic knowledge of Linux commands and computer networks (a large number of Docker images, of popular open source gateways, are also available), so this option is mostly used by the DIY-ers (frequently, some device data, such as configuration parameter and association group description, is specified in device configuration files, usually in the form of an XML file that has to be edited in accordance to some rules).
On the other hand, buying a commercial gateway means you will probably just have to connect the gateway to a power source, register an account on its cloud service and you'll be ready to include your newly bought devices.
When a device is added to a network the gateway usually performs a so-called initial inclusion interview during, which it asks the device for all its supported sensor types and units, metering capabilities, initial measurement values, supported notification states and statuses, configuration values and other meta-data (e.g. manufacturer information, to show a logo of the company or brand name). This enables the gateway to present the device correctly in its entirety.
This interview implementation varies from gateway to gateway with some performing long and thorough interviews and others collecting only some basic device information. In some cases, this interview is also used to whitelist devices, which are integrated into the gateway (for others that are not the interview usually stops once the manufacturer information is received). Usually, the interview process does not provide all the data, which the gateway would need to present the device, so the missing information is obtained from complementary configuration files. These files are created for every device, which is certified, that is why it is important to use devices, which are Z-Wave certified.
Gateway technology - protocols
Another important difference between the gateways, which are currently on the market, is the number of supported technologies and protocols. While some gateways only support Z-Wave technology, others support multiple others, such as Bluetooth, Wifi, ZigBee, LoRa, etc.
As more and more gateways are popping out on the market, the need to support more and more technologies is also rising. It is not uncommon to have a home automation system, which consists of end devices that communicate via various protocols and technologies, such as the ones mentioned above. Two popular gateways, which offer support for various technologies and protocols, are OpenHAB (a vendor and technology agnostic open source automation software, which can be used with a Z-Wave dongle or a Z-Wave Raspberry Pi HAT, and has support for more than 200 different technologies and services) and the commercial Samsung SmartThings, which is a standalone gateway. The image below shows a larger list of known gateways, which support Z-Wave.
|Devolo Home Control Central Unit|
|Fibaro Home Center Lite|
|Home Seer 3 Smart Home|
|Icontrol Networks Piper|
|Indigo Domotics Indigo|
|Mediola AIO Gateway|
|Toon Smart Thermostat|
|Universal Devices Gateway ISY994|
Gateways are usually controlled and offer support for devices via desktop applications, gateway plugins (e.g. stable and beta apps), multiple native mobile applications, or dedicated websites, which act as interfaces to the gateway. One should know that a device will not necessarily work on all available interfaces, even if a device is correctly working when controlled by using one of the supported interfaces. This can be quite frustrating for a user, especially if a few of the devices in his possession are working on one interface and the others are working in the others.
At GOAP, we have recently started to publish our integration test results in the form of extended compatibility tables on our website to show the user how our devices are working on a selected gateway.
Z-wave hub security
A few years ago, no encryption was enforced by the Z-Wave protocol, so anybody with a special sniffer key and the knowledge of the application protocol was able to see the network packets.
However, in the last three years, this has improved considerably, since Z-Wave has introduced the S0 security scheme, which uses the symmetric encryption, at the center of which is a so-called 16-byte network key. The attacker would have to obtain this key in order to decrypt the exchanged packets. The S0 security scheme was replaced by the use of public key cryptography, or asymmetric cryptography (also used in digital certificates), which makes it vastly more secure. Each exchanged packet is encrypted/decrypted using a suitable public/private key pair, unlike before, when a packet wasn't even encrypted or when each packet was encrypted using the same key.
So when buying a new gateway, it is recommended to buy one, which already supports the asymmetric cryptography to provide your network with maximum security. You can easily check if a gateway supports this type of security by inspecting its packaging, leaflet or manual. There will have to be a PIN or a 16-byte device-specific key (DSK) printed on at least one of them and under supported command classes the command class SECURITY_2 will be listed.
You can find the manual of every certified Z-Wave device in the Z-Wave Alliance catalog of certified devices. Make sure you filter the search results by marking »Supports Security 2« and selecting the item »Gateway controller« under the »Category« dropdown control, to list only the suitable gateways, like shown in the picture below.
Recently, one more feature, called SmartStart, was introduced in Z-Wave. The idea behind it is that the user scans (via the mobile application of the gateway) all the QR codes of the devices, which he intends to add to the gateway, and in this way, authenticates it. The QR codes contain, among the plethora of meta-data (e.g. icons, manufacturer information, firmware version, etc.), also the device-specific key, which is placed on a provisioning list of the gateway.
Upon connecting the device to a power source, it will automatically try to join a gateway if its DSK can be found on the provisioning list - without any other user activity (besides scanning the code). This simplifies the installation process since up till now, the user had to perform a special key press or toggle sequence, optionally enter the PIN of the device, and also activate the add/remove procedure on the gateway itself.
When buying a new gateway, try to make sure it also supports this feature, especially since all the newest 700 series Z-Wave devices, which will come to the market in the following months, will have to support it. Currently, there are two gateways, which contain this feature. Descriptions of both can be found in the already mentioned catalog.
Pick your Z-wave hub!
There are some other things, which should be taken into account, when selecting a Z-wave hub, like: i) Usually, gateways can only operate on one frequency, but there are some exceptions (like the ZwaveMe gateway), which makes it possible to change the operating frequency of the gateway. ii) There are some USB dongles, which can act as portable controllers (e.g. the Aeotec GEN5) meaning, the user doesn't have to necessarily use a host to include a device.