December 20, 2012 at 23:09A bit about Z-Wave technology
- From the sandbox
- Tutorial
In this article, I would like to highlight some of the insides of the Z-Wave protocol. Considering that the owner of the protocol, Sigma Designs (which absorbed Zensys) asks to sign the NDA before revealing the features of the implementation, and some of them don’t show anyone at all, you won’t find detailed data on the network. I am not going to tell too much here not to violate the signed NDA. I hope this information turns out to be useful and encourages someone to start developing their own glands on this protocol. So, let's begin!
Z-Wave is a common radio data transfer protocol designed for home automation. A characteristic feature of Z-Wave is the standardization from the physical layer to the application layer. Those. The protocol covers all levels of OSI classification, which allows for the compatibility of devices from different manufacturers when creating heterogeneous networks.
The Z-Wave protocol has been developed for apartments and small houses. Typically, such systems contain from 5 to 100 devices. The main feature of Z-Wave is that it belongs to the DIY format, i.e. Installation and configuration of the system, the homeowner can do on their own. The protocol was developed specifically to control devices such as lights, shutters, gates, thermostats and other means of transmitting short commands requiring little power consumption. Typical small tasks solved with the help of Z-Wave are the installation of walk-through switches, moving the switches to a more convenient level, remote control of gates and shutters, turning on the light using motion sensors. All these tasks do not require wire shifting. There are more complex apartment automation projects,
Let's go through all the levels of the OSI model (except for the missing representative one) and describe the main characteristics of Z-Wave.
Data is transmitted at a frequency of 869.0 MHz (Russia) , 868.42 MHz (Europe, CEPT countries, China, Singapore, the United Arab Emirates, South Africa), 908.42 MHz (USA, Mexico), 921.42 MHz (Australia, Brazil, New Zealand), 919.8 MHz ( Hong Kong), 865.2 MHz (India), 868.2 MHz (Malaysia), Japan (951-956 and 922-926 MHz). FSK modulation (frequency shift keying). Transmission speed: 42 kbps, 100 kbps and 9.6 kbps (for compatibility with older devices). Duty rate not more than 1%. Maximum transmit power 1 mW.
Packets with data integrity control (checksum) and addressing of the receiver and sender are used. A multicast address or broadcast can be used as a recipient (in this case, the packet is received by all network participants with the radio module turned on).
The Z-Wave protocol defines a routing algorithm that allows data to be transferred between devices out of direct line of sight. All constantly working network nodes (there are still sleeping and “often listening” nodes) I can participate in forwarding packets between other network participants. Z-Wave uses the Source Routing mechanism, i.e. the route is determined by the sender. Broadcast and multicast packets are not routed. If it is not possible to find the desired node by the routes recorded in memory, there is a mechanism to search for a node throughout the network by sending a special Explorer Frame package (see below) to all network nodes. After the node is successfully found, the new route is recorded by the sender in memory for future use.
At this level, Z-Wave guarantees delivery confirmation and resending if the package was not delivered to the recipient. Each node involved in the forwarding confirms the fact of receiving the message. To reduce the load of ether in the Z-Wave, the mechanism of “silent confirmations” is used: node (A), which transmitted the packet to the next node (B) on the route of the packet, does not wait for confirmation from it, but sees that B sent the packet further to node C and perceives this as a fact of confirmation of a successful packet forwarding from A to B. Upon receiving the packet, the end node sends back the delivery confirmation, which travels back along the same route to the original sender. Thus, the sender always knows whether the packet has reached the destination or not.
It is used only when using encryption, where short sessions with a one-time key are defined.
Z-Wave also defines an interpretation algorithm for commands received at the application level. This level is described by a set of Command Classes. For some Classes, there are several options for interpreting commands, which depend on the Device Class that defines the type of device.
Since 2012, the physical and link layers of the Z-Wave protocol have been included in the ITU-T G.9959 standard (recommendations of the telecommunication standardization sector of the International Telecommunication Union).
The levels from transport to channel are implemented in the Sigma Designs program code and are supplied in precompiled form (included in the SDK). On the one hand, a proprietary code is a minus, but the closeness of this protocol has its advantages: no manufacturer can change the lower levels of the protocol, which makes it easier to ensure compatibility - all devices are based on one well-debugged code.
All teams in Z-Wave are extremely compactly packed. This is necessary to reduce the size of the packet, which positively affects the time taken on the air, as well as to reduce transmission losses. Z-Wave is designed to transmit short commands without opening a session, i.e. not at all suitable for streaming streaming data. The maximum usable size of the transmitted data is 46 bytes (the size of the application layer data without encryption).
Theoretically, the Z-Wave protocol could be implemented on any hardware, but here the manufacturer of the Sigma Designs protocol (previously Zensys, which was part of the Sigma Designs structure) offers its own solution.
All Z-Wave devices are based on the same series of chips from two manufacturers (Sigma Designs and Mitsumi). These microcircuits are available in two versions: the chip itself and the module containing the minimum required set of components for the operation of the radio module. For many devices, you may still need an additional EEPROM non-volatile memory chip, but it is not a required component. Chips of the Z-Wave family are ZW0201, newer and 100% compatible with the previous ZW0301, SD3402. Based on them, modules ZM2102, ZM3102, ZM4101 and ZM4102 are made. All the chips mentioned are based on the Inventra core, compatible with Intel 8051.
The ZW0201 and ZW0301 chips have 2 KB of RAM, 32 KB of ROM, built-in hardware SPI, UART, TRIAC, WUT, GPT, WatchDog, four 12-bit ADCs, PWM (PWM), 2 interrupt inputs, as well as Digital I / O legs.
The fourth generation of SD3402 chips has 16 KB of RAM, 64 KB of ROM, 64 bytes of NVRAM, built-in hardware SPI, UART, TRIAC, WUT, GPT, WatchDog, USB, IR-controller with a learning function, hardware encryption module AES 128 bit, scanner 128 buttons .
Sigma Designs has announced the release of the next 5th generation of chips for the first quarter of 2013.
It is worth noting that each next generation of chips differs not only in an increased set of built-in hardware, but also in lower power consumption. For example, the most popular module ZM3102consumes 36 mA in send mode, 23 mA in receive mode, and only 2.5 μA in sleep mode.
More information on chips and modules can be found on the Sigma Designs website .
Most Z-Wave devices no longer contain any microcontrollers, except for the Sigma Desgins Z-Wave module and EEPROM (optional). This greatly simplifies the development of new devices and reduces their cost.
We have already mentioned the presence of routing in the protocol. Here it is worthwhile to distract and talk about the different types of nodes in Z-Wave.
A device that stores information about the neighbors of all network nodes (network topology) and is able based on this information to find a route to any network node. In addition, this device can move around the network and can reach all nodes of the network from anywhere in the network (of course, provided that the network is simply connected). This type of device cannot be accessed because they do not appear in the routing table (being portable) - they can only answer their request. Possible use: remote control. Such a device requires non-volatile EEPROM memory.
Similar to a portable one, but it should not move in space and should always be available to other network participants. Typical application: PC controller, performer. Such a device requires non-volatile EEPROM memory.
A device capable of only answering a request that came to it, because Does not know the network topology and does not store any routes. Such devices can only be sensors powered by the network and interrogated by other nodes, or performers. They do not know how to initiate sending data on their own (send unsolicited packets - unsolicited packets). Such devices are no longer manufactured, but they still remain on the market.
A device capable of storing up to 4 routes for 5 nodes (the so-called “return routes”). These devices can initiate data sending (send unsolicited packets), and can also be sleeping or “often listening”. Typical application: sensors, performers, fixed control panels (motion sensor, power button on batteries).
Like a child routing device, but storing routes to all network nodes, and not just to 5. This device requires non-volatile EEPROM memory.
As we can see, most nodes know the routes to some nodes through their neighbors. Complete lists of neighbors of all nodes are stored on the controllers, which rely on their reliability in the formation of routes. This means that all devices (except portable controllers) should not be moved in space . However, with the advent of the Explorer Frame function (see below), this condition has become less stringent. After moving network devices, non-working routes are automatically corrected when necessary.
Controllers (both static and portable) can have different roles on the network:
The primary controller is the network coordinator. This is the only node that can include new nodes in the network and exclude existing ones. It also stores the latest information on the network topology and can update the lists of neighbors for all other (secondary) controllers and form routes in all child nodes. The primary controller can be only one on the network. Usually the primary controller is the one from which the construction of the network began. However, in the future, the primary controller can include a new controller in the network, transferring its role to it.
Secondary controllers are all other controllers in the network. For normal operation, they should periodically request information about the network topology (neighbors of each node) from the primary controller.
The Z-Wave network is determined by the unique Home ID parameter (generated when the network is created by a random number generator with noise from the radio as a random number source or Sigma Designs is assigned for old controllers). Several Z-Wave networks with different Home IDs can coexist on the same territory. However, they will not see each other and interact with each other. Due to the mandatory duty cycle requirement (no more than 1% of the time is in the transmission state), these networks will not interfere with each other.
Each node in the network has its own unique Node ID, which is assigned by the primary controller when the device is connected to the network. Also, when connected to the network, the switched on device remembers the Home ID of the primary controller for further communication. A network can contain up to 232 devices.
Switching on takes place by transferring the controller to a special Turn-on mode ( Inclusion mode ; usually with a special button or key combination), and the device to be switched into Learning mode ( Learn mode ; usually by single or triple pressing a button). In this case, the controller and the switched on device must be in direct line of sight. Many modern (protocol versions 4.5x or 6.x) constantly powered (non-sleeping) devices first 3-5 minutes after turning on the power supply switch to a special training mode ( Network Wide Inclusion , NWI) if they are not already connected to the network . Moreover, the condition of being in direct line of sight is no longer required. This allows you to easily connect new devices to the network without running around the house.
The exclusion from the network is similar: the controller is switched to the Exclusion mode , and the child node to the Learning mode. After exclusion, the Node ID and Home ID devices will reset to 0 (for controllers, NodeID will reset to 1, and HomeID to the factory value). Most devices with an exception will reset all other user settings to factory defaults.
It is worth noting that a device already registered in one network will not be included in another network. But any primary controller (even a device not from its network) can be excluded from the network.
Controllers and child devices are included in the network and excluded from it in the same way.
When connected to the network, the primary controller receives information about the type of connected node and its NIF (see below).
A big plus of the Z-Wave protocol is the ability for devices to work on batteries. There are two types of battery powered devices:
Sleeping . Such devices will not participate in network routing as a relay, but they themselves can use other nodes to transmit their packets. Awakening alerts, waking periods, and going to sleep are regulated by the Wakeup Command Class, i.e. at the application level. Having woken up, these devices inform about their awakening, wait for commands from other network devices, and then fall asleep back. The sooner the device falls asleep, the less battery power will be used up. With proper management of such devices, they can live on one set of batteries for a year or more. Portable controllers are also sleeping devices.
Often listening( FLiRS= Frequently Listening Routing Slave) - these are devices that wake up every 0.25 or 1 second for a short time (several milliseconds) in order to check if there is a special wake up beam on the air. Such a packet is sent to them by other devices before starting communication with them. This package lasts 0.25 or 1 second, respectively, takes ether for all this time, and allows the frequently sleeping device, after waking up briefly, to see that there is a package for it. Seeing the “wake up” package, it wakes up fully, receives the data intended for it, processes it, possibly sends a response, and then falls asleep. Such a mechanism allows you to create devices that you should always have access to, but there is no way to carry out a power supply network to their installation site. A typical example of such devices:
All application-level data is transmitted in the form of short packets of the following form:
First comes the Team Class, then a team in this class, then the data specific to this team. Thanks to the strict standard that describes Command Classes, devices from different manufacturers can understand each other without any problems.
We give an example of popular classes and describe the purpose.
Basic is the most popular class, allowing devices of various types to be compatible at a minimum level. For example, a switch can send on / off commands, which the dimmer and relay will interpret as turning on / off the light, a thermostat as a transition between normal / energy-saving modes, and a blind control device as moving / stopping the shutters.
The list of Command Classes supported by the device is contained in the NIF package ( Node Information Frame - device description package). Thanks to it, you can define the Device Class (Device Class, see below) and a list of device capabilities. This package comes to the primary controller when you turn on the device in the network, and also when you press the button one or three times (for most devices, see the documentation for the specific device).
Each device is characterized by its functional type (Device Class, Device Class). Each class defines the required Command Classes supported by the device and how to interpret their commands. For example, commands of the Basic command class can be interpreted completely differently for different classes of devices: for a two-position relay, Basic Set 0 turns off, 1-99 or 255 turn on, while for a thermostat they can be interpreted as temperature in units or 1/10 degrees Celsius , i.e. from 0 to 255 or from 0 to 25.5 degrees, respectively. All other Command Classes are clearly stated down to the interpretation of each command.
Z-Wave - this mesh network ( mesh network A ), where each node knows its surrounding nodes and can guide them through the bags. Using routing allows you to successfully overcome obstacles between nodes that do not allow them to communicate directly. However, rearrangements of furniture and other changes in the situation, as well as failure of one unit, can lead to the appearance of non-working routes. To do this, they need to be updated periodically. The primary controller can do this prophylactically once a week or at the request of the user.
But in the Z-Wave protocol, there is another tool for replacing non-working routes with working ones, which appeared in protocol version 4.5. If the node could not reach the destination, it sends a special Explore Frame packet to all neighbors. Those, in turn, distribute it further on the network until some node says that the desired node was found in its direct line of sight. Thus, the sender will find a new route and remember it in their tables. This method is less economical than centrally updating the routes of the entire network: to bypass a dead node, each node needs to update each route that goes through an idle one by sending Explorer Frame. In addition, using Explorer Frame takes about 0.5-1 seconds, and during this time the network is clogged with these packets.
Up to 4 transmitter nodes may be contained along the route. Given the maximum distance between devices 10-30 meters in direct line of sight (depending on the antennas), we can say that the maximum range of packet delivery is 40-120 meters. Naturally, when passing floors and walls, the signal power drops significantly, which leads to a decrease in the transmission distance. In practice, a 4-storey building with a total area of 500 square meters is the limit of one Z-Wave protocol network with high-quality data transmission.
The conclusion is simple: update the route after the change of the network topology, and permutation of furniture or use only devices based on the protocol versions 4.5x and 6.x .
Naturally, when creating at least some decent automation, the question arises about the connection with software running on a PC. There are several software packages for this purpose:
In addition, there is a cloud service:
Sigma Designs sells not only chips, but also DevKit - a set of boards for prototyping new devices. Those who consider themselves cool can immediately make prototypes on bare ZM3102 modules. In addition, to create Z-Wave devices, you need the SDK (Software Development Kit) from the same Sigma Desgins, which implements the Z-Wave protocol up to and including the transport layer. This greatly simplifies the work of developers who just need to master this API (with documentation on 500 pages) and write all the "user" code that implements the application level and the behavior of the device itself (buttons, screen, LEDs, etc.). The cost of DevKit with the SDK is $ 3,000.
In addition to this, a C51 compiler from Keil (now owned by ARM) is needed. Somewhere else, $ 3,000. And a lot of patience and skills specific to the development of emdedded devices.
Naturally, being a radio protocol, Z-Wave is quite easy to listen to (well, we all know that there are very few capable amateur radio enthusiasts in the whole country :) You can hack into any system - a matter of money and time. Becoming a hardware developer, buying an SDK and gaining a lot of knowledge can do just that! But given that this is a home automation system for light and climate, I don’t think it would occur to anyone to spend a couple hundred thousand rubles hacking your automation. Scrap is much cheaper!
But here is the answer to the paranoid: Z-Wave has full AES encryption with a key length of 128 bits. Naturally, encryption imposes its limitations: it works more slowly, because it is no longer enough just to send a packet - before this you need to exchange one-time keys (nonce). Because encryption is implemented so far only in window systems, door locks and PC controllers.
Talking about wired technology here makes no sense. They have very different characteristics and applications. In finished objects, created without laying wires in all important places of the apartment, you can use only radio automation technology.
Who else is in the wireless world?
The Z-Wave protocol itself, as well as the patents for the solutions used in the protocol, are the property of Sigma Designs. The coordination of manufacturers, the development of the protocol and the conduct of advertising and training events are entrusted to the Z-Wave Aliance , a consortium of Z-Wave equipment manufacturers. Compatibility control is entrusted to certification offices (in the USA BuLogics and PepperoOne in Germany), which certify all devices entering the market, guaranteeing full compatibility between devices from different manufacturers. Only after passing such certification you can draw the Speaks Z-Wave logo on your device and sell it as a device running the Z-Wave protocol.
Sigma Designs and the Z-Wave Alliance are constantly conducting seminars for technicians of various levels, helping to quickly enter the market with high-quality devices.
Until recently, Z-Wave did not develop in Russia due to the lack of a permitted frequency. The European frequency of 868.42 MHz was not allowed by the SCRF, although the Russian government has acceded to some CEPT recommendations applicable to short-range devices. Since February 2012, Sigma Designs has allocated a separate frequency of 869.0 MHz for Russia. This frequency falls under the decision of the State Committee for Emergencies No. 07-20-03-001 of 05/07/2007 (Appendix 11). For the Russian frequency, the same chip is used as for Europe.
A lot of information about the protocol can be obtained from open source projects such as OpenZWave , AZW , Linux MCE , as well as from this wiki site and the following articles: first , second , third
For those who have not yet held Z-Wave equipment in their hands, you can see and feel in the first MGTS salon at Novy Arbat, 2
In this article, descriptions of such concepts of the Z-Wave protocol as SUC / SIS, Zensor and many other outdated and not relevant to the author’s views are completely omitted.
What is Z-Wave?
Z-Wave is a common radio data transfer protocol designed for home automation. A characteristic feature of Z-Wave is the standardization from the physical layer to the application layer. Those. The protocol covers all levels of OSI classification, which allows for the compatibility of devices from different manufacturers when creating heterogeneous networks.
What does Z-Wave technology do?
- Lighting control (relays / dimmers), curtains, roller shutters and gates
- Management of blinds and other motors (10-230 V)
- Turn on / off any loads up to 3.5 kW (module in a socket or built-in relay)
- Remote control with remote control
- Heating control (electric heated floors with overheating protection, electric boilers and radiators, thermostats for radiator water valves)
- Air conditioning control (via IR interface simulating a remote control)
- Detection of alarm events (motion sensors, door / window openings, leaks, dry contacts)
- Status monitoring (temperature, humidity, light sensors)
- Control of A / V equipment (according to the Z-Wave protocol or through an IR interface simulating a remote control)
- Communication with any software via PC controller
- Collection of data from counters
What tasks does Z-Wave best solve?
The Z-Wave protocol has been developed for apartments and small houses. Typically, such systems contain from 5 to 100 devices. The main feature of Z-Wave is that it belongs to the DIY format, i.e. Installation and configuration of the system, the homeowner can do on their own. The protocol was developed specifically to control devices such as lights, shutters, gates, thermostats and other means of transmitting short commands requiring little power consumption. Typical small tasks solved with the help of Z-Wave are the installation of walk-through switches, moving the switches to a more convenient level, remote control of gates and shutters, turning on the light using motion sensors. All these tasks do not require wire shifting. There are more complex apartment automation projects,
Data transfer protocol
Let's go through all the levels of the OSI model (except for the missing representative one) and describe the main characteristics of Z-Wave.
Physical level
Data is transmitted at a frequency of 869.0 MHz (Russia) , 868.42 MHz (Europe, CEPT countries, China, Singapore, the United Arab Emirates, South Africa), 908.42 MHz (USA, Mexico), 921.42 MHz (Australia, Brazil, New Zealand), 919.8 MHz ( Hong Kong), 865.2 MHz (India), 868.2 MHz (Malaysia), Japan (951-956 and 922-926 MHz). FSK modulation (frequency shift keying). Transmission speed: 42 kbps, 100 kbps and 9.6 kbps (for compatibility with older devices). Duty rate not more than 1%. Maximum transmit power 1 mW.
Channel level
Packets with data integrity control (checksum) and addressing of the receiver and sender are used. A multicast address or broadcast can be used as a recipient (in this case, the packet is received by all network participants with the radio module turned on).
Network layer
The Z-Wave protocol defines a routing algorithm that allows data to be transferred between devices out of direct line of sight. All constantly working network nodes (there are still sleeping and “often listening” nodes) I can participate in forwarding packets between other network participants. Z-Wave uses the Source Routing mechanism, i.e. the route is determined by the sender. Broadcast and multicast packets are not routed. If it is not possible to find the desired node by the routes recorded in memory, there is a mechanism to search for a node throughout the network by sending a special Explorer Frame package (see below) to all network nodes. After the node is successfully found, the new route is recorded by the sender in memory for future use.
Transport level
At this level, Z-Wave guarantees delivery confirmation and resending if the package was not delivered to the recipient. Each node involved in the forwarding confirms the fact of receiving the message. To reduce the load of ether in the Z-Wave, the mechanism of “silent confirmations” is used: node (A), which transmitted the packet to the next node (B) on the route of the packet, does not wait for confirmation from it, but sees that B sent the packet further to node C and perceives this as a fact of confirmation of a successful packet forwarding from A to B. Upon receiving the packet, the end node sends back the delivery confirmation, which travels back along the same route to the original sender. Thus, the sender always knows whether the packet has reached the destination or not.
Session level
It is used only when using encryption, where short sessions with a one-time key are defined.
Application level
Z-Wave also defines an interpretation algorithm for commands received at the application level. This level is described by a set of Command Classes. For some Classes, there are several options for interpreting commands, which depend on the Device Class that defines the type of device.
Since 2012, the physical and link layers of the Z-Wave protocol have been included in the ITU-T G.9959 standard (recommendations of the telecommunication standardization sector of the International Telecommunication Union).
The levels from transport to channel are implemented in the Sigma Designs program code and are supplied in precompiled form (included in the SDK). On the one hand, a proprietary code is a minus, but the closeness of this protocol has its advantages: no manufacturer can change the lower levels of the protocol, which makes it easier to ensure compatibility - all devices are based on one well-debugged code.
All teams in Z-Wave are extremely compactly packed. This is necessary to reduce the size of the packet, which positively affects the time taken on the air, as well as to reduce transmission losses. Z-Wave is designed to transmit short commands without opening a session, i.e. not at all suitable for streaming streaming data. The maximum usable size of the transmitted data is 46 bytes (the size of the application layer data without encryption).
Single chip solution
Theoretically, the Z-Wave protocol could be implemented on any hardware, but here the manufacturer of the Sigma Designs protocol (previously Zensys, which was part of the Sigma Designs structure) offers its own solution.
All Z-Wave devices are based on the same series of chips from two manufacturers (Sigma Designs and Mitsumi). These microcircuits are available in two versions: the chip itself and the module containing the minimum required set of components for the operation of the radio module. For many devices, you may still need an additional EEPROM non-volatile memory chip, but it is not a required component. Chips of the Z-Wave family are ZW0201, newer and 100% compatible with the previous ZW0301, SD3402. Based on them, modules ZM2102, ZM3102, ZM4101 and ZM4102 are made. All the chips mentioned are based on the Inventra core, compatible with Intel 8051.The ZW0201 and ZW0301 chips have 2 KB of RAM, 32 KB of ROM, built-in hardware SPI, UART, TRIAC, WUT, GPT, WatchDog, four 12-bit ADCs, PWM (PWM), 2 interrupt inputs, as well as Digital I / O legs.
The fourth generation of SD3402 chips has 16 KB of RAM, 64 KB of ROM, 64 bytes of NVRAM, built-in hardware SPI, UART, TRIAC, WUT, GPT, WatchDog, USB, IR-controller with a learning function, hardware encryption module AES 128 bit, scanner 128 buttons .
Sigma Designs has announced the release of the next 5th generation of chips for the first quarter of 2013.
It is worth noting that each next generation of chips differs not only in an increased set of built-in hardware, but also in lower power consumption. For example, the most popular module ZM3102consumes 36 mA in send mode, 23 mA in receive mode, and only 2.5 μA in sleep mode.
More information on chips and modules can be found on the Sigma Designs website .
Most Z-Wave devices no longer contain any microcontrollers, except for the Sigma Desgins Z-Wave module and EEPROM (optional). This greatly simplifies the development of new devices and reduces their cost.
Types of Nodes
We have already mentioned the presence of routing in the protocol. Here it is worthwhile to distract and talk about the different types of nodes in Z-Wave.
Portable Controller
A device that stores information about the neighbors of all network nodes (network topology) and is able based on this information to find a route to any network node. In addition, this device can move around the network and can reach all nodes of the network from anywhere in the network (of course, provided that the network is simply connected). This type of device cannot be accessed because they do not appear in the routing table (being portable) - they can only answer their request. Possible use: remote control. Such a device requires non-volatile EEPROM memory.
Static Controller
Similar to a portable one, but it should not move in space and should always be available to other network participants. Typical application: PC controller, performer. Such a device requires non-volatile EEPROM memory.
Child device (slave)
A device capable of only answering a request that came to it, because Does not know the network topology and does not store any routes. Such devices can only be sensors powered by the network and interrogated by other nodes, or performers. They do not know how to initiate sending data on their own (send unsolicited packets - unsolicited packets). Such devices are no longer manufactured, but they still remain on the market.
Child Routing Slave
A device capable of storing up to 4 routes for 5 nodes (the so-called “return routes”). These devices can initiate data sending (send unsolicited packets), and can also be sleeping or “often listening”. Typical application: sensors, performers, fixed control panels (motion sensor, power button on batteries).
Advanced child routing device (Routing Enhanced Slave)
Like a child routing device, but storing routes to all network nodes, and not just to 5. This device requires non-volatile EEPROM memory.
As we can see, most nodes know the routes to some nodes through their neighbors. Complete lists of neighbors of all nodes are stored on the controllers, which rely on their reliability in the formation of routes. This means that all devices (except portable controllers) should not be moved in space . However, with the advent of the Explorer Frame function (see below), this condition has become less stringent. After moving network devices, non-working routes are automatically corrected when necessary.
Controllers (both static and portable) can have different roles on the network:
The primary controller is the network coordinator. This is the only node that can include new nodes in the network and exclude existing ones. It also stores the latest information on the network topology and can update the lists of neighbors for all other (secondary) controllers and form routes in all child nodes. The primary controller can be only one on the network. Usually the primary controller is the one from which the construction of the network began. However, in the future, the primary controller can include a new controller in the network, transferring its role to it.
Secondary controllers are all other controllers in the network. For normal operation, they should periodically request information about the network topology (neighbors of each node) from the primary controller.
Networking and the coexistence of multiple networks
The Z-Wave network is determined by the unique Home ID parameter (generated when the network is created by a random number generator with noise from the radio as a random number source or Sigma Designs is assigned for old controllers). Several Z-Wave networks with different Home IDs can coexist on the same territory. However, they will not see each other and interact with each other. Due to the mandatory duty cycle requirement (no more than 1% of the time is in the transmission state), these networks will not interfere with each other.
Each node in the network has its own unique Node ID, which is assigned by the primary controller when the device is connected to the network. Also, when connected to the network, the switched on device remembers the Home ID of the primary controller for further communication. A network can contain up to 232 devices.
Switching on takes place by transferring the controller to a special Turn-on mode ( Inclusion mode ; usually with a special button or key combination), and the device to be switched into Learning mode ( Learn mode ; usually by single or triple pressing a button). In this case, the controller and the switched on device must be in direct line of sight. Many modern (protocol versions 4.5x or 6.x) constantly powered (non-sleeping) devices first 3-5 minutes after turning on the power supply switch to a special training mode ( Network Wide Inclusion , NWI) if they are not already connected to the network . Moreover, the condition of being in direct line of sight is no longer required. This allows you to easily connect new devices to the network without running around the house.
The exclusion from the network is similar: the controller is switched to the Exclusion mode , and the child node to the Learning mode. After exclusion, the Node ID and Home ID devices will reset to 0 (for controllers, NodeID will reset to 1, and HomeID to the factory value). Most devices with an exception will reset all other user settings to factory defaults.
It is worth noting that a device already registered in one network will not be included in another network. But any primary controller (even a device not from its network) can be excluded from the network.
Controllers and child devices are included in the network and excluded from it in the same way.
When connected to the network, the primary controller receives information about the type of connected node and its NIF (see below).
Battery operation
A big plus of the Z-Wave protocol is the ability for devices to work on batteries. There are two types of battery powered devices:
Sleeping . Such devices will not participate in network routing as a relay, but they themselves can use other nodes to transmit their packets. Awakening alerts, waking periods, and going to sleep are regulated by the Wakeup Command Class, i.e. at the application level. Having woken up, these devices inform about their awakening, wait for commands from other network devices, and then fall asleep back. The sooner the device falls asleep, the less battery power will be used up. With proper management of such devices, they can live on one set of batteries for a year or more. Portable controllers are also sleeping devices.
Often listening( FLiRS= Frequently Listening Routing Slave) - these are devices that wake up every 0.25 or 1 second for a short time (several milliseconds) in order to check if there is a special wake up beam on the air. Such a packet is sent to them by other devices before starting communication with them. This package lasts 0.25 or 1 second, respectively, takes ether for all this time, and allows the frequently sleeping device, after waking up briefly, to see that there is a package for it. Seeing the “wake up” package, it wakes up fully, receives the data intended for it, processes it, possibly sends a response, and then falls asleep. Such a mechanism allows you to create devices that you should always have access to, but there is no way to carry out a power supply network to their installation site. A typical example of such devices:
Command Classes
All application-level data is transmitted in the form of short packets of the following form:
| Command Class ID |
| Command id |
| team specific data |
First comes the Team Class, then a team in this class, then the data specific to this team. Thanks to the strict standard that describes Command Classes, devices from different manufacturers can understand each other without any problems.
We give an example of popular classes and describe the purpose.
Basic is the most popular class, allowing devices of various types to be compatible at a minimum level. For example, a switch can send on / off commands, which the dimmer and relay will interpret as turning on / off the light, a thermostat as a transition between normal / energy-saving modes, and a blind control device as moving / stopping the shutters.
- Switch Binary / Switch Multilevel - used to control lighting (relays / dimmers), as well as to control motors (for shutters or gates).
- Sensor Binary / Sensor Multilevel - for a binary sensor (door opening, leakage, smoke, movement) and a multi-position sensor (temperature, light, humidity).
- Meter - used to take readings and reset the accumulated values of counters.
- Association - allows you to establish communications between devices. For example, there are 3 buttons on the device. There are 3 associations groups for the buttons for them. When you click on the button, the Basic Set Enable commands are sent to the corresponding group. The Association class is used to maintain a list of nodes in this group. This approach allows you to easily and efficiently configure direct relationships between network devices.
- Configuration - allows you to change some of the device parameters set by the manufacturer. For example, the speed of dimming light or the sensitivity of a motion sensor.
- Battery - allows you to request the battery power of devices.
- Wakeup - to control the waking parameters of sleeping devices.
- MultiChannel - used to address a specific component of a complex device consisting of several elements. Regular Command Classes (Basic, Switch / Sensor Binary / Multilevel, Meter) are encapsulated in the command of this class with the element number. For example, a device may contain two relays or three sensors (temperature, humidity, and motion).
The list of Command Classes supported by the device is contained in the NIF package ( Node Information Frame - device description package). Thanks to it, you can define the Device Class (Device Class, see below) and a list of device capabilities. This package comes to the primary controller when you turn on the device in the network, and also when you press the button one or three times (for most devices, see the documentation for the specific device).
Device classes
Each device is characterized by its functional type (Device Class, Device Class). Each class defines the required Command Classes supported by the device and how to interpret their commands. For example, commands of the Basic command class can be interpreted completely differently for different classes of devices: for a two-position relay, Basic Set 0 turns off, 1-99 or 255 turn on, while for a thermostat they can be interpreted as temperature in units or 1/10 degrees Celsius , i.e. from 0 to 255 or from 0 to 25.5 degrees, respectively. All other Command Classes are clearly stated down to the interpretation of each command.
Reliability
Z-Wave - this mesh network ( mesh network A ), where each node knows its surrounding nodes and can guide them through the bags. Using routing allows you to successfully overcome obstacles between nodes that do not allow them to communicate directly. However, rearrangements of furniture and other changes in the situation, as well as failure of one unit, can lead to the appearance of non-working routes. To do this, they need to be updated periodically. The primary controller can do this prophylactically once a week or at the request of the user.
But in the Z-Wave protocol, there is another tool for replacing non-working routes with working ones, which appeared in protocol version 4.5. If the node could not reach the destination, it sends a special Explore Frame packet to all neighbors. Those, in turn, distribute it further on the network until some node says that the desired node was found in its direct line of sight. Thus, the sender will find a new route and remember it in their tables. This method is less economical than centrally updating the routes of the entire network: to bypass a dead node, each node needs to update each route that goes through an idle one by sending Explorer Frame. In addition, using Explorer Frame takes about 0.5-1 seconds, and during this time the network is clogged with these packets.
Up to 4 transmitter nodes may be contained along the route. Given the maximum distance between devices 10-30 meters in direct line of sight (depending on the antennas), we can say that the maximum range of packet delivery is 40-120 meters. Naturally, when passing floors and walls, the signal power drops significantly, which leads to a decrease in the transmission distance. In practice, a 4-storey building with a total area of 500 square meters is the limit of one Z-Wave protocol network with high-quality data transmission.
The conclusion is simple: update the route after the change of the network topology, and permutation of furniture or use only devices based on the protocol versions 4.5x and 6.x .
PC connection
Naturally, when creating at least some decent automation, the question arises about the connection with software running on a PC. There are several software packages for this purpose:
- Z-Wave.Me Z-Way (universal software for Unix / Linux / Mac OS X / Windows with an automation engine and simple GUI, only B2B available)
- Mi Casa Verde Vera (with an automation engine and simple GUI, runs on routers under the OpenWRT clone, sold as a router box)
- Fibaro Home Center (with an automation engine and simple GUI, runs its own hardware from Fibaro, sold as a box)
- Z-Wave.Me Z-Way.C (C library for working with the Z-Wave stack on Unix / Linux / Mac OS X / Windows, only B2B is available, but an inexpensive extension for Raspberry Pi will appear soon )
- OpenZWave (C ++ library for working with Z-Wave under Unix / Linux / Mac OS X / (possibly) Windows, Open Source)
- HomeSeer (for Windows, paid)
- Z-Command (for Windows, paid)
- LinuxMCE (Linux-based OS for media centers)
In addition, there is a cloud service:
- Z-Wave.Me Z-Cloud (for Unix / Linux / Mac OS X / Windows, free)
Create new devices
Sigma Designs sells not only chips, but also DevKit - a set of boards for prototyping new devices. Those who consider themselves cool can immediately make prototypes on bare ZM3102 modules. In addition, to create Z-Wave devices, you need the SDK (Software Development Kit) from the same Sigma Desgins, which implements the Z-Wave protocol up to and including the transport layer. This greatly simplifies the work of developers who just need to master this API (with documentation on 500 pages) and write all the "user" code that implements the application level and the behavior of the device itself (buttons, screen, LEDs, etc.). The cost of DevKit with the SDK is $ 3,000.
In addition to this, a C51 compiler from Keil (now owned by ARM) is needed. Somewhere else, $ 3,000. And a lot of patience and skills specific to the development of emdedded devices.
Security
Naturally, being a radio protocol, Z-Wave is quite easy to listen to (well, we all know that there are very few capable amateur radio enthusiasts in the whole country :) You can hack into any system - a matter of money and time. Becoming a hardware developer, buying an SDK and gaining a lot of knowledge can do just that! But given that this is a home automation system for light and climate, I don’t think it would occur to anyone to spend a couple hundred thousand rubles hacking your automation. Scrap is much cheaper!
But here is the answer to the paranoid: Z-Wave has full AES encryption with a key length of 128 bits. Naturally, encryption imposes its limitations: it works more slowly, because it is no longer enough just to send a packet - before this you need to exchange one-time keys (nonce). Because encryption is implemented so far only in window systems, door locks and PC controllers.
But what about other technologies?
Talking about wired technology here makes no sense. They have very different characteristics and applications. In finished objects, created without laying wires in all important places of the apartment, you can use only radio automation technology.
Who else is in the wireless world?
- 433 MHz is a cheap and widespread technology.
- Pros - cheap and cheerful, long range (lower frequency), low price
- Минусы — полная несовместимость устройств разных производителей (т.е. завязка на одном), нестыкуемость комплектов (полное отсутствие масштабируемости), обычно без маршрутизации, отсутствие правил со стороны регулятора по скважности сигнала, невозможность построения нескольких сетей рядом, полоса частот замусорена множеством устройств от бытовых до радиоуправляемых машинок.
- EnOcean — похожий на Z-Wave стандарт автоматизации домов и зданий (868.3 МГц)
- Плюсы — как и в Z-Wave есть стандартизация до прикладного уровня, возможность делать устройства без батареек на солнечных батареях и пьезо/индукционных элементах
- Минусы — нет подтверждения доставки пакета (особенно для устройств на пьезоэлементах, где энергии едва хватает на отправку, их ещё сложнее настраивать, т.к. долго они не могут принимать данные; в новых версиях протокола добавили обратную связь), частота не разрешена на территории РФ (разрешен к ввозу и использованию ограниченный список устройств нескольких компаний)
- ZigBee — очень популярный промышленный протокол. Используется в некоторых странах как стандарт для сбора данных с счётчиков и доставки до концентратора
- Плюсы — хорошо развит, имеет динамическую маршрутизацию (самоорганизующаяся сеть, где каждый узел хранит лишь таблицу с со списком кластеров и ближайшего соседа, который может доставить туда пакет — почти как в IP сетях), принят на вооружения многими телекомами и управляющими компаниями.
- Минусы — использует более загруженную полосу 2.4 ГГц (есть полоса 868 МГц, но она реже используется), стандартизирован лишь до транспортного уровня, что делает устройства разных производителей несовместимыми на прикладном уровне.
- ONE-NET, Bluetooth 3, Wifi,… на рынке нет готовых решений на базе этих протоколов. Думаю, в ближайшие годы они появятся.
Организационно-правовые аспекты
The Z-Wave protocol itself, as well as the patents for the solutions used in the protocol, are the property of Sigma Designs. The coordination of manufacturers, the development of the protocol and the conduct of advertising and training events are entrusted to the Z-Wave Aliance , a consortium of Z-Wave equipment manufacturers. Compatibility control is entrusted to certification offices (in the USA BuLogics and PepperoOne in Germany), which certify all devices entering the market, guaranteeing full compatibility between devices from different manufacturers. Only after passing such certification you can draw the Speaks Z-Wave logo on your device and sell it as a device running the Z-Wave protocol.
Sigma Designs and the Z-Wave Alliance are constantly conducting seminars for technicians of various levels, helping to quickly enter the market with high-quality devices.
Until recently, Z-Wave did not develop in Russia due to the lack of a permitted frequency. The European frequency of 868.42 MHz was not allowed by the SCRF, although the Russian government has acceded to some CEPT recommendations applicable to short-range devices. Since February 2012, Sigma Designs has allocated a separate frequency of 869.0 MHz for Russia. This frequency falls under the decision of the State Committee for Emergencies No. 07-20-03-001 of 05/07/2007 (Appendix 11). For the Russian frequency, the same chip is used as for Europe.
Scoop more info
A lot of information about the protocol can be obtained from open source projects such as OpenZWave , AZW , Linux MCE , as well as from this wiki site and the following articles: first , second , third
See alive
For those who have not yet held Z-Wave equipment in their hands, you can see and feel in the first MGTS salon at Novy Arbat, 2
Not covered
In this article, descriptions of such concepts of the Z-Wave protocol as SUC / SIS, Zensor and many other outdated and not relevant to the author’s views are completely omitted.