Z-Wave
From HomeSeer
Z-Wave is a purely-RF mesh network protocol. All devices must be added to the network via the primary controller; this sets up security and routing data. Because of the latter, devices should not be moved after adding them; if that is required, the device should either be deleted and re-added, or the "Optimize Network" method in HomeSeer should be used.
Z-Wave networks are limited to 232 devices per network, just a bit less than the 256 supported by an X-10 network across all house codes. However, Z-Wave can support multiple networks in the same RF space at the same time, and Z-Wave supports ~ 4,294,967,294 networks.
For much more information on Z-Wave, see Z-Wave at Wikipedia.org
Contents |
[edit] Comparisons to Other Technologies
[edit] Compared to X10
X-10 is primarily a PLC (powerline) protocol, with an ancillary RF protocol that devices such as the RR501 can transcode from the RF to the PLC. Being older and PLC-based, X-10 suffers in comparison to Z-Wave as slower and less reliable.
But because Z-Wave routes messages specifically to the destination device, other devices cannot necessarily "listen in" on it. Additionally, because all devices must be members of the network, a remote control must be taught the network (or be the primary controller, in which case it teaches the rest of the network.)
[edit] Compared to Insteon
Insteon at Wikipedia.org Unlike Z-Wave, Insteon can support both RF and PLC, but apparently not within the same device. In practice, most contemporary devices are purely PLC devices. While Z-Wave uses routing tables to get a message to a module that is otherwise out of range, Insteon broadcasts the message indiscriminately, which requires it limit hops to prevent "data storms". Z-Wave doesn't have this issue. On the other hand, Insteon devices don't need to be formally "added" to the network either.
Insteon theoretically supports thousands of devices on a network, but the effects of controlling a single device in a large network have not been fully tested or published. Since messages are broadcast with hop limits, a large network with even a low hop count would create an RF transmission that would have to end before a subsequent transmission could take place. With more devices, this blackout period would keep increasing, reducing the throughput of the network.
Z-Wave has a theoretical advantage in having come to market in 2003 versus 2005 for Insteon (which even then had a rough start), but Insteon is supported by their parent, SmartHome, which is probably the dominant home automation outlet in the U.S. In 2008 however, SmartHome continues to be the single source for Insteon products and continue to struggle with making the technology reliable and stable.
[edit] Compared to ZigBee
http://en.wikipedia.org/wiki/ZigBee ZigBee at Wikipedia.org] ZigBee is currently a non-player in the Home Automation field, but is regularly listed as a primary competitor to Z-Wave. ZigBee is an 802.15.4 technology using the 2.4GHz frequency rather than the 900MHz used by Insteon and the 908.42MHz (US) and 868.42MHz (Europe) bands used by Z-Wave; this results in significantly lower "penetration" and has necessitated some redesign for home automation. ZigBee's design was created using a Committee/Alliance type project as well as being built on top of the 802.15.4 protocol, and therefore is less prone to a single supplier and also does not require a license fee. The large partners in ZigBee, such as Intel, Cisco, T.I. and Motorola, are not typical Home Automation players. ZigBee protcol devices are extremely rare currently.
ZigBee supports thousands of devices on a network and is limited only by IP addressing technologies available, compared to the 232 devices supported by a single Z-Wave network.
The major disadvantage of ZigBee over Z-Wave is that from the beginning Z-Wave was designed to always be interoperable. Zigbee on the other hand was designed to communicate seamlessly with products from other companies, but because companies so far have always kept their encryption/security information private, the net result is that there are many Zigbee products on the market which are all contained within the proprietary product offerings of their manufacturer. In other words, a CentraLite Zigbee based lighting device can not be controlled by a Control4 Zigbee touchscreen because CentraLite and Control4 will not publish their security/encryption keys. Once added to the same network, Z-Wave devices from all manufacturers will work with one another, within the limitations imposed by the capabilities of the device classes supported by each product.
[edit] General Comparisons
Z-Wave is currently the best selling RF home automation system. Note that this excludes RF-bridged Insteon and X-10 devices, which are inherently PLC.
Unlike X10, but currently very much like Insteon, Z-Wave is dependent on a single provider. In this case, all Z-Wave chips come from Zensys. In 2006, Zensys announced that was opening up manufacturing of Z-Wave chips to other manufacturers. This was driven primarily by Leviton, which did not want to enter the Z-Wave market using a single supplier.
Zensys is occasionally caught masquerading their marketing department as independent analysts. See, for example, this CNET comparison of ZigBee and Z-Wave and then check out who the author was. (Hint: the "VP of Alliances" at ZenSys and former Z-Wave Alliance Board Member for Danfoss A/S.) Such stunts are typically reserved for those losing in the struggle for survival, a description that doesn't otherwise appear to fit. #Note 3
But that said, Z-Wave appears anecdotally to be far more reliable than X-10 or Insteon. Because neither [UPB] nor ZigBee have much current penetration, their reliability is hard to gauge, but UPB is a powerline protocol prone to the same noise problems afflicting X10 and Insteon.
[edit] Technical Protocol Information
[edit] Network Hierarchy
The next paragraph is taken from Wikipedia:Z-Wave Topology and routing Z-wave uses an intelligent mesh network topology and has no master node. Devices can communicate to another around household obstacles or radio dead spots that might occur. A message from node A to node C can be successfully delivered even if the two nodes are not within range, providing that a third node B can communicate with nodes A and C. If the preferred route is unavailable, the message originator will attempt other routes until a path is found to the "C" node. Therefore a Z-Wave network can span much further than the radio range of a single unit. In order for Z-Wave units to be able to route unsolicited messages, they cannot be in sleep mode. Therefore, most battery-operated devices are not designed as repeater units. A Z-wave network can consist of up to 232 devices with the option of bridging networks if more devices are required.
While there are no master nodes that all communication must go through, Z-Wave does use some concepts adapted from the use of a master node. Each node holds a routing table with information on how to route frames to the other nodes in the network. Only the master controller (primary) holds the master routing table with information on which nodes can communicate with one another over the entire network.
A Z-Wave network must have a primary controller, as only the primary can add or remove nodes from the network and perform other specialized functions. Additional controllers may be present in the network, such as a handheld remote control or a wall controller. Like the primary controller, these controllers hold copies of the entire network routing table for use in determining routes to devices, but unlike the primary controller, they are never updated automatically - they are updated only when the primary controller copies (replicates) the network information and routing table to another controller.
Non-controllers are most frequently slave type nodes. Most of today's slave nodes (devices) are routing slaves, which mean that they contain information on how to route frames to the other nodes in the network typically four different ways, and they can also send unsolicited frames to other nodes in the network.
A key function that HomeSeer uses (referred to as "Optimize/Optimization") is REQUEST_NODE_NEIGHBOR_UPDATE. This function, which can only be initiated and managed from the primary controller, instructs a node to broadcast a specialized frame that seeks a response from surrounding nodes. Responses are relayed back to the primary controller for the purpose of updating the routing table in the primary as well as the individual node's routing information. This function is done whenever a new node is added to the network, but that frequently does not facilitate more than to adequately seat the new node amongst its neighbors and the routing table. Nodes out of range of the new node that was added will not have their routing tables updated and will not know about the new node until they too do an optimization.
Consider this sample network:
Note that before node 9 was added, there was no path from node 1 directly to node 7. After node 9 was added, more paths through node 9 opened up to node 7. However, when the REQUEST_NODE_NEIGHBOR_UPDATE (optimize) was done, node 9 did not get a response from node 1 because it is out of range, so the routing table in node 1 still shows the same routes it had before to node 7. If node 6 is removed, all routes to node 7 previously were through node 6, and so node 1 would not be able to route to node 7 because it does not know that node 9 has a connection to node 7. However, if we were to "Optimize" node 1, then the routing information in node 1 would be updated to reflect that there are paths to node 7 through node 9.
In this scenario, node 9 is shown as not being able to directly communicate with node 1. In reality, the proper alignment of the moon, the stars, and a day of the week ending in the letter "y" might have allowed nodes 1 and 9 to communicate freely. The next time an optimization is done, the conditions may not be the same, so the relationship of 1 to 9 could be severed. Thus, the old axiom applies: If it ain't broke, don't fix it.
Despite the fact that static controllers such as the Cooper Scene Controller, Leviton Scene Controller, and Leviton Zone Controller respond like any other node to an Optimization, this only affects the controller's role similar to that of a routing slave - it does not update the controller's routing table. Using the above network example, if Node 4 was a static controller, it would not be able to control Node 9 after it was added as part of a scene that was programmed into it because it would have no knowledge of that node, UNTIL such time as replication from the primary controller updates it. #Note 4
[edit] Associations
Z-Wave devices can support "associations". An "association" allows the given device (the source) to send a command to other devices (the destination) when specific events occur in the source device. Typically, the event that causes the command to be sent is a change in state, such as turning on, and the command sent is usually the same event type. For example, a BASIC command class ON signal will turn on virtually all Z-Wave devices. When the source device is turned ON and it has node(s) that it is associated with, then it will usually send a BASIC ON command to the destination nodes. The original ACT HomePro switches, for example, support both notifying HomeSeer (when so associated) and also controlling other Z-Wave devices. This allows the creation of virtual 3-way circuits controlling multiple lights, for example, without any HomeSeer events. Devices only send the commands to their associated devices (nodes). (Of course an event in HomeSeer triggered on "State Set" would do the same thing, but would also require creating a trigger based on each switch.)
Not all devices support associations, and therefore, instant status. For example, the Leviton ViziaRF lamp and relay module do, but the Intermatic lamp and relay module do not. So the ViziaRF line can provide instant status change notifications to HomeSeer when so associated, but the Intermatics cannot. (This also means the Intermatics are not capable of serving as "virtual devices". Because they cannot be "associated", they cannot notify HomeSeer of a received "set". In other words, HomeSeer can poll to see if a device turned from "Off" to "On", but it cannot determine if a device that was already "Off" was sent another "Off". So not only would a status change have a polling latency, but only actual state changes, not state commands, would be able to trigger events in HomeSeer.)
Even devices that do support Associations may be inconsistent in the application. For example, if a Leviton ViziaRF lamp or relay module is toggled using local control, it will alert the associated devices. But if they are toggled by a secondary controller such as the Intermatic HA09, they will not... with the surprise effect that HomeSeer has no idea what the status is until the next scheduled polling cycle! This is by design, however, to avoid circular association references. Both Cooper and Leviton avoid circular association references by not sending commands to associated devices if their state changed as a result of an incoming Z-Wave command - they only transmit the associated command when they are operated locally. #Note
Associations use group ID numbers to support multiple groupings of nodes. Each group can support a manufacturer designated number of nodes. For example, newer ACT products no longer support associations on Group 1, however the Z-Wave protocol specifically calls for association group numbers to start at 1, so these groups should indicate that they support 0 nodes. When you add a node to an association group, and that node would then exceed the number of nodes supported in the association group, the node will typically "bump" one of the existing nodes out of the group. #Note 2
[edit] Scenes
After several companies were tested in their use of associations against a Lutron patent, the Scene class was created by a Z-Wave working group and Zensys. Lutron holds a patent that effectively prevents any company from producing a light switch that immediately reports its status when operated. Several companies had been using #Associations as a means to send 'instant status' notifications to HomeSeer and other controllers, but fear of being sued or actually being sued caused the Z-Wave manufacturers to take a different tack. Both Leviton and Cooper negotiated a license with Lutron. The exact amount settled upon is not known, but an employee of one of those companies described it as 'very expensive', and helps to explain why products from these companies are much more expensive than their ACT and Intermatic counterparts. ACT has not negotiated a license agreement with Lutron, and as such as modified their products to no longer support any devices for association in Group 1, the group that is activated when the switch is operated.
The scene class, along with the HAIL class, together serve to resolve this as well as to provide new and better functionality. Although Lutron and Leviton could both use associations for instant status, they both chose the increased functionality of the scene class in their products.
The scene class is actually several classes - SCENE CONTROLLER CONFIGURATION, SCENE ACTUATOR CONFIGURATION, and SCENE ACTIVATION. The SCENE CONTROLLER CONFIGURATION class provides methods for configuring scenes within scene controllers. The SCENE ACTUATOR CONFIGURATION class configures scenes in a scene device, which includes setting the scene properties such as the dimming duration. The SCENE ACTIVATION class allows a device to activate a scene - while the controller configuration class typically lives only in a controller, and the actuator configuration in a device, the activation class can live in both device types and more, enabling them to activate a scene once it has been configured.
Scenes are a collection of devices (Nodes) which will be set to a specified level, over a specified period of time. A device that supports activation of multiple scenes will use an association group to associate the scene with an activation trigger - in the case of a wall controller, the association group is the button number that the scene is being programmed to. Scene IDs (numbers) themselves are values from 1-255. Generally, Scene IDs should not be reused and should be kept unique. However, there is no technical limitation preventing you from re-using the same Scene ID with two different groups of devices. For example, you could program nodes 1, 3, and 5 with a scene configuration for Scene ID 20; and you could program nodes 2, 4, and 6 to also have a scene configuration at Scene ID 20. When a scene is activated, generally a multicast command is sent to activate the scene, and this is so that all of the devices can start responding to the scene at the same time. However, because multicast commands are not routable, the controller should also follow up the multicast with scene activation commands directed to the specific nodes that are in the scene. During the multicast activation of the scene, all of the nodes in the above example (1-6) would go to their programmed level when the multicast for Scene ID 20 was sent. This is where re-using Scene IDs can cause unwanted behavior.
When a device is programmed to be a part of a scene, it is given a scene ID number, a ramping (or dimming) duration, and a level. The dimming duration can be set from instant to as long as 127 minutes. The duration is not a waiting period - that is to say, the device will change constantly over the period of the duration until it ends up at the desired level.
The number of devices that you can have be a part of a scene is manufacturer dependent, and is likely to be similar to the number of devices in an association group, because an association group is still used to hold the scene information in the scene controller.
Here is how a scene is constructed:
- The scene controller is configured with a Scene ID, a list of nodes that are a part of the scene, and an association group ID number. The group ID number corresponds to the button you will push on the controller to activate the scene.
- Each node that is a part of the scene is provided the Scene ID number, the level it should go to when the scene is activated, and the period of time it should take to reach the desired level, regardless of whether the device has to brighten or dim to get there. #Note 5
[edit] Node Info
When a Z-Wave node is added to the network, activating the inclusion mechanism on the node being added causes it to send out a low-power Z-Wave transmission of its node info frame. This is done using a low power transmission so that somebody pressing the button on a light at the other side of the house at the same time that you are in "inclusion mode" on your primary controller will not result in the wrong node being added (or removed).
The node info frame that is exchanged contains at least 6 bytes of critical information about the node which is called the 'Protocol Info'. The first two bytes are Capability and Security, most of which is obscured to developers, but does include a bit that signifies whether the node 'listens' for commands and what speed the node is capable of sending and receiving. Since battery operated devices normally power off the radio when they are not transmitting, these would be an example of a non-listening device. Non-listening devices are excluded automatically from HomeSeer's Z-Health feature is an unattended optimization, so it automatically skips over nodes in your network that have been marked as non-listening nodes. To optimize these nodes, you must do them individually from the device properties page, after you have awakened the device as per the manufacturer's instructions.
Three of the bytes are the key descriptors of the type of node that the device is, and these bytes describe the BASIC device class, GENERIC device class, and SPECIFIC device class of the node. These pieces of information are used by HomeSeer when the initial device to represent the node is created, which is where HomeSeer gets its device type of GENERIC CONTROLLER, REMOTE SWITCH, THERMOSTAT, etc. These DEVICE classes define a basic set of features that these nodes must subscribe to, and that HomeSeer is aware of, so that HomeSeer knows how to work with the node.
Additionally, the node information frame can include a list of one or more COMMAND classes that the node supports. An example of the command classes are ASSOCIATION and SCENE ACTUATOR CONFIGURATION, which tells HomeSeer that the node in this case supports the entire set of association commands, and the ability to be configured for a scene.
Since HomeSeer 2.3.0.0, the command classes that a node supports are stored as a part of the device information in the HomeSeer database instead of querying the controller for this information each time it is needed. If this information becomes lost through database troubles, the "Resync" button in the device properties page is there for this purpose. The "Resync" button asks the node to again send its node information frame, but this time it is done as a directed request upon the node, which means that Z-Wave network issues could prevent the node information frame from being heard by the HomeSeer controller. "Resync" is different from "Import" in that Resync requests the specific node configuration information, at the Z-Wave protocol level, and Import simply scans for nodes in the Z-Wave interface that do not have corresponding devices in HomeSeer, and attempts to create them if they are missing.
[edit] Notes
[edit] Note
- 1. Note that while the Cooper and some Leviton devices do not transmit associated commands when they receive a Z-Wave command, they also support the HAIL class, and so when they receive a Z-Wave command that changes their state, they can send a HAIL command to node(s) associated in a special association group. HomeSeer uses this to then immediately query the device for its current level so that events can be immediately triggered.
[edit] Note
- 2. While Zensys specified that association groups must start at 1, they did not specify that they had to be contiguous from there. Some manufacturers have then established a specific association group for the purpose of having the node issue a different type of associated command than the typical BASIC commands. For example, on a Cooper wall switch or controller, associating a node into association group 255 results in the node receiving a HAIL command when the device changes state.
[edit] Note
- 3. This paragraph is opinionated and will be removed in a future edit. The author's information is clearly published at the bottom of the article, including the fact that he works for Zensys. Furthermore, the article was never promoted as an independent analysis. Publishers eager for content, such as Electronic House, routinely publish biased articles written by or for their advertisers. The only thing the statement demonstrates is that the Zigbee Alliance did not advertise adequately in the EE Times.--Rtinker 12:36, 7 January 2009 (EST)
[edit] Note
- 4. Consult the manufacturer's instructions to determine how to place a controller into the replicate receive mode so that it can receive network information, via replication, from a primary controller. For the HomeSeer Z-Troller, automatic replication was built into the device. To update a static (wall) controller when your primary controller is a Z-Troller, take the Z-Troller to the device, press and hold the Add button on the Z-Troller, and then activate the wall controller as you would do as if you were adding the controller to the network for the first time. When this happens on a node that is already added to the network, the Z-Troller automatically begins replication and updates the secondary/static controller.
[edit] Note
- 5. Normally, only devices that support the SCENE ACTUATOR CONFIGURATION command class can be supported to be a part of a scene. However, Cooper Wiring has created a proprietary method for allowing non-scene capable devices to be a part of their scenes. The non-scene devices will not be able to support the ramp duration, but they will be set to the specified level using the BASIC command class when the scene is activated. HomeSeer has incorporated this method into the scene configuration features in HomeSeer versions 2.2.0.74 and later.
[edit] Specifications
- 900MHz
- Technically 908.42MHz in U.S., 868.42MHz in Europe
- Mesh network with routing
- No master node, but all devices must be added (or removed) via master controller.
- Supports 232 devices, including the master controller.
