A little bit about Z-Wave technology
In this article I would like to highlight some of the internals of the Z-Wave protocol. Considering that the protocol owner, Sigma Designs (which absorbed Zensys) asks to sign the NDA before disclosing the features of the implementation, and some of them don’t show anyone at all, no details can be found on the network. I'm not going to talk too much here so as not to upset the signed NDA. Hopefully, this information will be useful and will encourage someone to work on developing their own hardware on this protocol. So, let's begin!
Z-Wave is a common radio data transmission protocol designed for home automation. A characteristic feature of Z-Wave is standardization from the physical layer to the application level. Those. The protocol covers all levels of OSI classification, which allows ensuring compatibility of devices from different manufacturers when creating heterogeneous networks.
Z-Wave protocol was developed for apartments and small houses. Typically, such systems contain from 5 to 100 devices. The main feature of Z-Wave is that it refers to the DIY format, i.e. The owner can install and configure the system by himself. The protocol was developed specifically to control devices such as light, blinds, gates, thermostats, and other means of transmitting short commands that require little power. Typical small tasks solved with the help of Z-Wave are installation of pass-through switches, moving switches to a more convenient level, remote control of gates and blinds, turning on the light by motion sensors. All these tasks do not require shifting wires. There are also more complex apartment automation projects that are not inferior in complexity to industrial automation systems.
')
Let's go through all levels of the OSI model (except the missing representative one) and describe the main characteristics of the Z-Wave.
Data transmission is carried out at a frequency of 869.0 MHz (Russia) , 868.42 MHz (Europe, CEPT countries, China, Singapore, 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). Duration is no more than 1%. The maximum transmission power is 1 mW.
Packages are used with data integrity control (checksum) and recipient and sender addressing. A multicast address or broadcast can be used as a recipient (in this case, the packet is accepted by all network participants with the radio module turned on).
Z-Wave protocol defines a routing algorithm that allows data to be transferred between devices out of line of sight. All constantly working network nodes (there are still sleeping and “often listening” nodes) can participate in forwarding packets between other network members. Z-Wave uses Source Routing, i.e. the route is determined by the sender. Broadcast and multicast packets are not routed. If it is impossible to find the necessary node by the routes recorded in the memory, there is a mechanism for searching the node throughout the network by sending a special Explorer Frame package (see below) to all nodes in the network. After successfully locating the node, the new route is recorded by the sender in memory for later use.
At this level, Z-Wave guarantees delivery confirmation and re-shipment if the package has not been delivered to the recipient. Each node involved in the transfer, confirms the receipt of the message. To reduce the load of the ether in Z-Wave, the mechanism of “silent confirmations” is used: the node (A), which transmitted the packet to the next node (B) on the way of the packet, does not wait for confirmation from it, but sees that B has sent the packet further to node C and perceives it as a fact of confirming the successful forwarding of a packet from A to B. Upon receiving the packet, the end node sends back a delivery confirmation that travels back the same route to the original sender. Thus, the sender always knows if the packet has reached the destination point or not.
It is used only when using encryption, where short sessions with a one-time key are defined.
Z-Wave also defines the algorithm for interpreting the 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 that depend on the Device Class (Device Class), which determines the type of device.
Since 2012, the physical and channel levels 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 delivered in precompiled form (included in the SDK). On the one hand, the proprietary code is a minus, but there are some advantages in the closeness of this protocol: 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 compact. This is necessary to reduce the size of the packet, which has a positive effect on the time taken on the air, as well as a reduction in 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 data transfer size is 46 bytes (the data size of the application layer without encryption).
Theoretically, the Z-Wave protocol could be implemented on any hardware, but even here the manufacturer of the Sigma Designs protocol (formerly Zensys, which is 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 chips are available in two versions: the actual chip and the module containing the minimum required set of components for the radio module robots. For many devices, an additional non-volatile EEPROM memory chip may also be needed, but it is not a required component. The chips of the Z-Wave family are ZW0201, newer and 100% compatible with the previous ZW0301, SD3402. On their basis, the 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, embedded SPI, UART, TRIAC, WUT, GPT, WatchDog, four 12-bit ADC, PWM (PWM) hardware, 2 interrupt inputs, and Digital I / O legs.
The fourth generation of SD3402 chips has 16 KB of RAM, 64 KB of ROM, 64 bytes of NVRAM, embedded SPI hardware, UART, TRIAC, WUT, GPT, WatchDog, USB, 128-bit AES hardware encryption module, 128 buttons scanner .
Sigma Designs announced the release of the next 5 generation chips for the first quarter of 2013.
It is worth noting that each next generation of chips differs not only an increased set of embedded hardware, but also less power consumption. For example, the most popular module ZM3102 consumes 36 mA in data transfer mode, 23 mA in receive mode and only 2.5 µA in sleep mode.
More information about chips and modules can be found on the Sigma Designs website.
Most Z-Wave devices do not contain any more microcontrollers other than the Z-Wave module from Sigma Desgins and EEPROM (optional). This greatly simplifies the development of new devices and reduces their cost.
Above, we already mentioned the presence of routing in the protocol. Here it is worth to be distracted and tell about 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 in the network and is able to reach all network nodes from anywhere in the network (of course, provided that the network is simply connected). To devices of this type can not be accessed, because they do not appear in the routing table (being portable) - they can only respond to their request. Possible use: remote control. This device requires non-volatile EEPROM memory.
Similar to the portable, but it should not move in space and is designed to be always accessible to other members of the network. Typical application: PC controller, performer. This device requires non-volatile EEPROM memory.
A device that can only respond to a request that came to him, because does not know the network topology and does not store any routes. Such devices can only be sensors that are powered from the network and polled by other nodes, or performers. They do not know how to initiate sending data on their own (send unsolicited packets). Such devices are no longer produced, but they are still on the market.
A device capable of storing up to 4 routes for 5 nodes (the so-called "reverse routes"). These devices can initiate sending data (send unsolicited packets) and can also be asleep or “often listening”. Typical applications: 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. Such a device requires non-volatile EEPROM memory.
As we can see, most nodes know the routes to some nodes through their neighbors. The complete lists of neighbors of all nodes are stored on controllers that rely on their accuracy when forming routes. This means that all devices (except portable controllers) should not be moved in space . However, with the advent of the Explorer Frame feature (see below), this condition has become less severe. After moving the network devices, non-working routes are automatically corrected when needed.
Controllers (both static and portable) can have different roles in the network:
The primary controller is the network coordinator. This is the only node capable of including new nodes in the network and excluding existing ones. It also stores the latest information about the network topology and can update the lists of neighbors for all other (secondary) controllers and generate routes in all child nodes. The primary controller can be only one in the network. Typically, the primary is the controller that started building the network. However, in the future, the primary controller may 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 creating a network by a random number generator with noise from a radio receiver as a source of random numbers or assigned to Sigma Designs for older controllers). Multiple 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 requirement of the duty cycle (no more than 1% of the time is in the state of transmission), 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 switched on to the network. Also, when turned on, the included device remembers the Home ID of the primary controller for further communication. The network can contain up to 232 devices .
Switching on takes place by switching the controller to the special Enable mode ( Inclusion mode ; usually by some special button or key combination), and the device to be turned on to the Training mode ( Learn mode ; usually by single or triple pressing the button). In this case, the controller and the included device must be in direct view. Many modern (protocol versions 4.5x or 6.x) devices that are constantly feeding (not sleeping) for the first 3-5 minutes after switching on the power supply network automatically switch to a special training mode ( Network Wide Inclusion , NWI) if they are not yet included in the network . In this case, the condition of being in direct visibility is no longer required. This makes it quite easy to plug new devices into the network without running around the house.
Exclusion from the network is similar: the controller is switched to the Exclusion mode , and the child node is switched to the Training mode. After the exclusion, the Node ID and Home ID of the device will be reset to 0 (for NodeID controllers, it will be reset to 1, and HomeID to factory default). Most devices will reset all other user settings to their factory defaults.
It is worth noting that the device already registered in one network will not be included in another network. But any primary controller can be excluded from the network (even the device is not from its network).
Controllers and child devices are included in the network and excluded from it in the same way.
When included in the network, the primary controller receives information about the type of the included node and its NIF (see below).
A big plus of the Z-Wave protocol is the ability for devices to operate on batteries. There are two types of battery powered devices:
Sleeping Such devices will not participate in network routing as a repeater, but they can use other nodes to transfer their packets. Wake-up alerts, wake up periods and sleep sleep are regulated by the Wakeup Command Class, i.e. at the application level. Waking up, these devices report their awakening, waiting for commands from other devices on the network, and then falling asleep. The sooner the device falls asleep, the less battery power will be consumed. 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.
Frequently listening ( FLiRS = Frequently Listening Routing Slave) are devices that wake up every 0.25 or 1 second for a short time (a few milliseconds) in order to check if there is a special wake up beam on the air. Such a package is sent to them by other devices before communicating with them. This package lasts 0.25 or 1 second, respectively, takes the air for all this time, and allows the often sleeping device to wake up for a short while to see that there is a package for it. Having seen the “wake up” packet, it fully wakes up, receives the data intended for it, processes them, perhaps sends a response, and then goes back to sleep. This mechanism allows you to create devices, access to which should always, but the ability to hold a power supply network to the place of their installation is not possible. A typical example of such devices: door locks, sirens.
All application-level data is transmitted in the form of short packets of the following form:
First comes the Team Class, then the team in this class, then the data specific to this team. Thanks to a rigorous standard describing the 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 different types to be compatible at the minimum level. For example, a switch can send On / Off commands, which the dimmer and relay will interpret as light on / off, the thermostat as a transition between normal / energy-saving modes, and the louver control device as shutters movement / stop.
The list of Classes of Commands supported by the device is contained in the NIF ( Node Information Frame ) package. Thanks to him, you can define a 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 one or three times on the button (for most devices, see the documentation for the specific device).
Each device is characterized by its functional type (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 in completely different ways for different classes of devices: for a two-position relay, the Basic Set 0 turns off, 1-99 or 255 is turned 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 classes of teams clearly spelled out the interpretation of each command.
Z-Wave is a mesh network , where each node knows its surrounding nodes and can send packets through them. Using routing allows you to successfully overcome obstacles between nodes that do not allow them to communicate directly. However, furniture rearrangements and other changes in the situation, as well as the failure of a single node can lead to the emergence 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 means for replacing non-working routes with workers, which appeared in protocol version 4.5. If the node was unable to reach the destination, it sends a special Explore Frame packet to all its neighbors. Those in turn spread it further through the network, until some node says that the node in question was found in his direct line of sight. Thus, the sender will find a new route and will memorize it in its tables. This method is less economical than centralized updating of the routes of the entire network: to bypass the deceased node it is required that each node updates each route going through the non-working one by sending an Explorer Frame. In addition, using the Explorer Frame takes about 0.5-1 seconds, and at this time the network is clogged with these packages.
On the route can contain up to 4 nodes of transmitters . 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 delivery of the package is 40-120 meters. Naturally, when passing overlaps 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 a single Z-Wave network network with high-quality data transmission.
The conclusion is simple: update routes after changing the network topology and furniture rearrangements or use only devices based on 4.5x and 6.x versions of the protocol.
Naturally, when creating any decent automation, the question arises of communication with software running on a PC. There are several software systems 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 will need an 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 only need to master this API (with documentation on 500 pages) and write all the “user-defined” code that implements the application layer and the behavior of the device itself (buttons, small screen, LEDs, etc.). DevKit cost with SDK is $ 3000.
In addition to this, you need the Keil C51 compiler (now owned by ARM). Somewhere around $ 3,000. And a lot of patience and skills characteristic for the development of emded devices.
Naturally, being a radio protocol, Z-Wave is fairly easily heard (well, we know that there are very few capable radio amateurs left in the whole country :) You can hack into any system - a matter of money and time. Becoming a developer of hardware, buying an SDK and gaining a lot of knowledge can be done and not that! But considering that this is a home automation system for light and climate, I don’t think that someone would think to spend a couple of hundred thousand rubles on hacking your automation. Scrap is much cheaper!
But even here there is an answer to paranoids: Z-Wave has full AES encryption with a key length of 128 bits. Naturally, encryption imposes its own limitations: it works slower, because it is no longer enough to just send a package — you must exchange one-time keys (nonce) before. Therefore, encryption is implemented only in window systems, door locks and PC controllers.
To talk about wired technology here makes no sense. They have completely different characteristics and application. In finished objects created without laying wires to all important places of the apartment, you can use only radio automation technology.
Who else is in the wireless world?
Z-Wave, , Sigma Designs. , Z-Wave Aliance — Z-Wave. ( BuLogics PepperoOne), , . Speaks Z-Wave , Z-Wave.
Sigma Designs Z-Wave Aliance , .
Z-Wave - . 868.42 , CEPT, . 2012 Sigma Designs 869.0 . â„– 07-20-03-001 07.05.2007 ( 11). , .
open source , OpenZWave , AZW , Linux MCE , wiki- : , ,
, Z-Wave, , 2
Z-Wave, SUC/SIS, Zensor .
What is Z-Wave?
Z-Wave is a common radio data transmission protocol designed for home automation. A characteristic feature of Z-Wave is standardization from the physical layer to the application level. Those. The protocol covers all levels of OSI classification, which allows ensuring 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
- Control of blinds and other motors (10-230 V)
- Turn on / off any loads up to 3.5 kW (module in the socket or built-in relay)
- Remote control from the remote control
- Heating control (electric floor heating with overheating protection, electric boilers and radiators, thermostats for radiator water valves)
- Air conditioning control (via IR interface simulating the remote)
- Detection of alarm events (motion sensors, door / window openings, leaks, dry contacts)
- Condition monitoring (temperature, humidity, light sensors)
- A / V equipment control (via Z-Wave protocol or via IR interface simulating a remote control)
- Communication with any software via PC controller
- Data collection from counters
What tasks are best solved by Z-Wave?
Z-Wave protocol was developed for apartments and small houses. Typically, such systems contain from 5 to 100 devices. The main feature of Z-Wave is that it refers to the DIY format, i.e. The owner can install and configure the system by himself. The protocol was developed specifically to control devices such as light, blinds, gates, thermostats, and other means of transmitting short commands that require little power. Typical small tasks solved with the help of Z-Wave are installation of pass-through switches, moving switches to a more convenient level, remote control of gates and blinds, turning on the light by motion sensors. All these tasks do not require shifting wires. There are also more complex apartment automation projects that are not inferior in complexity to industrial automation systems.
')
Data transfer protocol
Let's go through all levels of the OSI model (except the missing representative one) and describe the main characteristics of the Z-Wave.
Physical level
Data transmission is carried out at a frequency of 869.0 MHz (Russia) , 868.42 MHz (Europe, CEPT countries, China, Singapore, 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). Duration is no more than 1%. The maximum transmission power is 1 mW.
Link level
Packages are used with data integrity control (checksum) and recipient and sender addressing. A multicast address or broadcast can be used as a recipient (in this case, the packet is accepted by all network participants with the radio module turned on).
Network layer
Z-Wave protocol defines a routing algorithm that allows data to be transferred between devices out of line of sight. All constantly working network nodes (there are still sleeping and “often listening” nodes) can participate in forwarding packets between other network members. Z-Wave uses Source Routing, i.e. the route is determined by the sender. Broadcast and multicast packets are not routed. If it is impossible to find the necessary node by the routes recorded in the memory, there is a mechanism for searching the node throughout the network by sending a special Explorer Frame package (see below) to all nodes in the network. After successfully locating the node, the new route is recorded by the sender in memory for later use.
Transport level
At this level, Z-Wave guarantees delivery confirmation and re-shipment if the package has not been delivered to the recipient. Each node involved in the transfer, confirms the receipt of the message. To reduce the load of the ether in Z-Wave, the mechanism of “silent confirmations” is used: the node (A), which transmitted the packet to the next node (B) on the way of the packet, does not wait for confirmation from it, but sees that B has sent the packet further to node C and perceives it as a fact of confirming the successful forwarding of a packet from A to B. Upon receiving the packet, the end node sends back a delivery confirmation that travels back the same route to the original sender. Thus, the sender always knows if the packet has reached the destination point or not.
Session Level
It is used only when using encryption, where short sessions with a one-time key are defined.
Application layer
Z-Wave also defines the algorithm for interpreting the 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 that depend on the Device Class (Device Class), which determines the type of device.
Since 2012, the physical and channel levels 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 delivered in precompiled form (included in the SDK). On the one hand, the proprietary code is a minus, but there are some advantages in the closeness of this protocol: 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 compact. This is necessary to reduce the size of the packet, which has a positive effect on the time taken on the air, as well as a reduction in 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 data transfer size is 46 bytes (the data size of the application layer without encryption).
Single chip solution
Theoretically, the Z-Wave protocol could be implemented on any hardware, but even here the manufacturer of the Sigma Designs protocol (formerly Zensys, which is 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 chips are available in two versions: the actual chip and the module containing the minimum required set of components for the radio module robots. For many devices, an additional non-volatile EEPROM memory chip may also be needed, but it is not a required component. The chips of the Z-Wave family are ZW0201, newer and 100% compatible with the previous ZW0301, SD3402. On their basis, the 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, embedded SPI, UART, TRIAC, WUT, GPT, WatchDog, four 12-bit ADC, PWM (PWM) hardware, 2 interrupt inputs, and Digital I / O legs.
The fourth generation of SD3402 chips has 16 KB of RAM, 64 KB of ROM, 64 bytes of NVRAM, embedded SPI hardware, UART, TRIAC, WUT, GPT, WatchDog, USB, 128-bit AES hardware encryption module, 128 buttons scanner .
Sigma Designs announced the release of the next 5 generation chips for the first quarter of 2013.
It is worth noting that each next generation of chips differs not only an increased set of embedded hardware, but also less power consumption. For example, the most popular module ZM3102 consumes 36 mA in data transfer mode, 23 mA in receive mode and only 2.5 µA in sleep mode.
More information about chips and modules can be found on the Sigma Designs website.
Most Z-Wave devices do not contain any more microcontrollers other than the Z-Wave module from Sigma Desgins and EEPROM (optional). This greatly simplifies the development of new devices and reduces their cost.
Types of nodes
Above, we already mentioned the presence of routing in the protocol. Here it is worth to be distracted and tell about 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 in the network and is able to reach all network nodes from anywhere in the network (of course, provided that the network is simply connected). To devices of this type can not be accessed, because they do not appear in the routing table (being portable) - they can only respond to their request. Possible use: remote control. This device requires non-volatile EEPROM memory.
Static Controller (Static Controller)
Similar to the portable, but it should not move in space and is designed to be always accessible to other members of the network. Typical application: PC controller, performer. This device requires non-volatile EEPROM memory.
Child device (Slave)
A device that can only respond to a request that came to him, because does not know the network topology and does not store any routes. Such devices can only be sensors that are powered from the network and polled by other nodes, or performers. They do not know how to initiate sending data on their own (send unsolicited packets). Such devices are no longer produced, but they are still on the market.
Routing Slave
A device capable of storing up to 4 routes for 5 nodes (the so-called "reverse routes"). These devices can initiate sending data (send unsolicited packets) and can also be asleep or “often listening”. Typical applications: 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. Such a device requires non-volatile EEPROM memory.
As we can see, most nodes know the routes to some nodes through their neighbors. The complete lists of neighbors of all nodes are stored on controllers that rely on their accuracy when forming routes. This means that all devices (except portable controllers) should not be moved in space . However, with the advent of the Explorer Frame feature (see below), this condition has become less severe. After moving the network devices, non-working routes are automatically corrected when needed.
Controllers (both static and portable) can have different roles in the network:
The primary controller is the network coordinator. This is the only node capable of including new nodes in the network and excluding existing ones. It also stores the latest information about the network topology and can update the lists of neighbors for all other (secondary) controllers and generate routes in all child nodes. The primary controller can be only one in the network. Typically, the primary is the controller that started building the network. However, in the future, the primary controller may 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 creating a network by a random number generator with noise from a radio receiver as a source of random numbers or assigned to Sigma Designs for older controllers). Multiple 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 requirement of the duty cycle (no more than 1% of the time is in the state of transmission), 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 switched on to the network. Also, when turned on, the included device remembers the Home ID of the primary controller for further communication. The network can contain up to 232 devices .
Switching on takes place by switching the controller to the special Enable mode ( Inclusion mode ; usually by some special button or key combination), and the device to be turned on to the Training mode ( Learn mode ; usually by single or triple pressing the button). In this case, the controller and the included device must be in direct view. Many modern (protocol versions 4.5x or 6.x) devices that are constantly feeding (not sleeping) for the first 3-5 minutes after switching on the power supply network automatically switch to a special training mode ( Network Wide Inclusion , NWI) if they are not yet included in the network . In this case, the condition of being in direct visibility is no longer required. This makes it quite easy to plug new devices into the network without running around the house.
Exclusion from the network is similar: the controller is switched to the Exclusion mode , and the child node is switched to the Training mode. After the exclusion, the Node ID and Home ID of the device will be reset to 0 (for NodeID controllers, it will be reset to 1, and HomeID to factory default). Most devices will reset all other user settings to their factory defaults.
It is worth noting that the device already registered in one network will not be included in another network. But any primary controller can be excluded from the network (even the device is not from its network).
Controllers and child devices are included in the network and excluded from it in the same way.
When included in the network, the primary controller receives information about the type of the included node and its NIF (see below).
Battery operation
A big plus of the Z-Wave protocol is the ability for devices to operate on batteries. There are two types of battery powered devices:
Sleeping Such devices will not participate in network routing as a repeater, but they can use other nodes to transfer their packets. Wake-up alerts, wake up periods and sleep sleep are regulated by the Wakeup Command Class, i.e. at the application level. Waking up, these devices report their awakening, waiting for commands from other devices on the network, and then falling asleep. The sooner the device falls asleep, the less battery power will be consumed. 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.
Frequently listening ( FLiRS = Frequently Listening Routing Slave) are devices that wake up every 0.25 or 1 second for a short time (a few milliseconds) in order to check if there is a special wake up beam on the air. Such a package is sent to them by other devices before communicating with them. This package lasts 0.25 or 1 second, respectively, takes the air for all this time, and allows the often sleeping device to wake up for a short while to see that there is a package for it. Having seen the “wake up” packet, it fully wakes up, receives the data intended for it, processes them, perhaps sends a response, and then goes back to sleep. This mechanism allows you to create devices, access to which should always, but the ability to hold a power supply network to the place of their installation is not possible. A typical example of such devices: door locks, sirens.
Command Classes (Team 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 the team in this class, then the data specific to this team. Thanks to a rigorous standard describing the 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 different types to be compatible at the minimum level. For example, a switch can send On / Off commands, which the dimmer and relay will interpret as light on / off, the thermostat as a transition between normal / energy-saving modes, and the louver control device as shutters movement / stop.
- Switch Binary / Switch Multilevel - used to control the lighting (relay / dimmer), as well as to control the 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 - is used to take readings and reset accumulated values ​​of counters.
- Association - allows you to establish connections between devices. For example, there are 3 buttons on the device. For them, there are 3 buttons corresponding to the group of associations. When you click on a button, Basic Set commands are sent to the appropriate 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 manufacturer’s device parameters. For example, the dimming speed of a light or the sensitivity of a motion sensor.
- Battery - allows you to request a battery charge devices.
- Wakeup - to control the parameters of waking up sleeping devices.
- MultiChannel - used to address a specific component of a complex device consisting of several elements. Ordinary Command Classes (Basic, Switch / Sensor Binary / Multilevel, Meter) are encapsulated into a command of this class with an indication of the element number. For example, a device may contain two relays or three sensors (temperature, humidity, and motion).
The list of Classes of Commands supported by the device is contained in the NIF ( Node Information Frame ) package. Thanks to him, you can define a 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 one or three times on the button (for most devices, see the documentation for the specific device).
Device classes
Each device is characterized by its functional type (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 in completely different ways for different classes of devices: for a two-position relay, the Basic Set 0 turns off, 1-99 or 255 is turned 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 classes of teams clearly spelled out the interpretation of each command.
Reliability
Z-Wave is a mesh network , where each node knows its surrounding nodes and can send packets through them. Using routing allows you to successfully overcome obstacles between nodes that do not allow them to communicate directly. However, furniture rearrangements and other changes in the situation, as well as the failure of a single node can lead to the emergence 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 means for replacing non-working routes with workers, which appeared in protocol version 4.5. If the node was unable to reach the destination, it sends a special Explore Frame packet to all its neighbors. Those in turn spread it further through the network, until some node says that the node in question was found in his direct line of sight. Thus, the sender will find a new route and will memorize it in its tables. This method is less economical than centralized updating of the routes of the entire network: to bypass the deceased node it is required that each node updates each route going through the non-working one by sending an Explorer Frame. In addition, using the Explorer Frame takes about 0.5-1 seconds, and at this time the network is clogged with these packages.
On the route can contain up to 4 nodes of transmitters . 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 delivery of the package is 40-120 meters. Naturally, when passing overlaps 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 a single Z-Wave network network with high-quality data transmission.
The conclusion is simple: update routes after changing the network topology and furniture rearrangements or use only devices based on 4.5x and 6.x versions of the protocol.
PC connection
Naturally, when creating any decent automation, the question arises of communication with software running on a PC. There are several software systems for this purpose:
- Z-Wave.Me Z-Way (universal software for Unix / Linux / Mac OS X / Windows with an automation engine and a simple GUI, only B2B is supplied)
- Mi Casa Verde Vera (with an automation engine and a simple GUI, runs on routers under the OpenWRT clone, sold as a box-router)
- Fibaro Home Center (with an automation engine and a 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 under Unix / Linux / Mac OS X / Windows, only B2B is supplied, but an inexpensive extension for Raspberry Pi will be available 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)
Creating 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 will need an 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 only need to master this API (with documentation on 500 pages) and write all the “user-defined” code that implements the application layer and the behavior of the device itself (buttons, small screen, LEDs, etc.). DevKit cost with SDK is $ 3000.
In addition to this, you need the Keil C51 compiler (now owned by ARM). Somewhere around $ 3,000. And a lot of patience and skills characteristic for the development of emded devices.
Security
Naturally, being a radio protocol, Z-Wave is fairly easily heard (well, we know that there are very few capable radio amateurs left in the whole country :) You can hack into any system - a matter of money and time. Becoming a developer of hardware, buying an SDK and gaining a lot of knowledge can be done and not that! But considering that this is a home automation system for light and climate, I don’t think that someone would think to spend a couple of hundred thousand rubles on hacking your automation. Scrap is much cheaper!
But even here there is an answer to paranoids: Z-Wave has full AES encryption with a key length of 128 bits. Naturally, encryption imposes its own limitations: it works slower, because it is no longer enough to just send a package — you must exchange one-time keys (nonce) before. Therefore, encryption is implemented only in window systems, door locks and PC controllers.
But what about other technologies?
To talk about wired technology here makes no sense. They have completely different characteristics and application. In finished objects created without laying wires to 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 (frequency lower), low price
- — (.. ), ( ), , , , .
- EnOcean — Z-Wave (868.3 )
- — Z-Wave , /
- — ( , , , .. ; ), ( )
- ZigBee — .
- — , ( , , — IP ), .
- — 2.4 ( 868 , ), , .
- ONE-NET, Bluetooth 3, Wifi,… . , .
-
Z-Wave, , Sigma Designs. , Z-Wave Aliance — Z-Wave. ( BuLogics PepperoOne), , . Speaks Z-Wave , Z-Wave.
Sigma Designs Z-Wave Aliance , .
Z-Wave - . 868.42 , CEPT, . 2012 Sigma Designs 869.0 . â„– 07-20-03-001 07.05.2007 ( 11). , .
open source , OpenZWave , AZW , Linux MCE , wiki- : , ,
, Z-Wave, , 2
Z-Wave, SUC/SIS, Zensor .
Source: https://habr.com/ru/post/163387/
All Articles