Introduction to Z-Wave

Z-Wave™ is a technology that uses radio frequency (RF) signals to control compatible devices.  Using RF signals allows wireless control of the devices, so there's no need to run new wires around the home.

Each Z-Wave device is assigned a unique identification number, or "node ID", to distinguish it from other Z-Wave devices.  So even if you have ten of the same type of light switches installed, each one will have its own node ID.  The node is not factory-set – it's set at the time the device is added to the Z-Wave "network".  This is done when the device is synced to the Z-Wave Remote Control Unit.

Z-Wave employs each node in the network as an intelligent router.  Thus, a failure by a controller to communicate directly with a device will cause the controller to hand off the control request to a nearby device.  The nearby device will look in the routing table it has constructed of the network and will determine which node to hand the control request to so that it gets routed to the appropriate node in the shortest amount of time.  The same path is used for the information returned by the node that received the control request.  Z-Wave is inherently two-way, which means all commands are acknowledged and information is returned that alerts the system as to whether or not the command was able to be carried out.  Z-Wave is also very fast compared with defacto standard lighting control systems in use over the past 30 years.  Typically, a Z-Wave control signal makes a round-trip completion in 80ms as compared to 666ms, in just one direction, for X-10. The system supports up to 232 nodes.

You can learn about setting up Z-Wave in the topic Setting Up Z-Wave.

If you wish to learn more about Z-Wave, please read on.


Z-Wave is a mesh network - that is, all devices can communicate with all devices (with some exceptions).  There is a hierarchy for some types of functions such as adding or removing nodes from the network, optimizing the network, etc. and that is that those functions must be done by the Primary Controller.  A Z-Wave network can have many secondary controllers, and they are created by copying network information from the primary controller to secondary controllers.  It is even possible to transfer the role of primary controller between controllers - for example, you can transfer the role of primary controller from the HomeSeer Z-Wave interface to a handheld controller, so that you can then use the handheld controller to add or remove nodes from the network, and then transfer the network information and the primary role back to the HomeSeer Z-Wave interface when you are done.


Controllers can send and receive Z-Wave commands.  Although every node in the network is capable of this, controllers do have additional functions that make them special in the network.  (See the Topology discussion above.)  Some controllers are portable controllers - that is, they can move around and do not rely on being in a fixed location.  When they send a command, they try to communicate with the destination node directly, and if they cannot then they will hand off the command to a node that knows of a way to get the command to the destination node.  Since a portable controller does not always know which nodes are around it, this can take a little bit of trial and error before it finds a route to the device - although the total time is probably still less than one second!  A static controller is just the opposite - it expects like most nodes to be in a fixed location, and so its information on how to route commands is based upon nodes that it knows are near it, so if it cannot talk to the destination node directly, it's handoff to another node is going to be one that it knows can talk to the destination node or knows how to get it there.  Even if there is a surprise such as a node in the network is not functioning, Z-Wave nodes (which include controllers) will make a few attempts to find other routes before they give up and let the sender know that the command could not be delivered.   Some controllers are designed to be computer interfaces as they have a USB or RS-232 interface, although in this form factor there are also both portable and static controllers.  HomeSeer's Z-Troller™ interface has an RS-232 connection so that it can be your HomeSeer interface, but it is also a portable controller in that you can disconnect it from HomeSeer temporarily so that you can add or remove nodes from the network. HomeSeer also offers the Z-Stick, which is a battery powered USB interface.


As mentioned before, nodes are added or removed from the network using the primary controller.  When a node is added, it must not already be a part of another network.  This is why you cannot have two primary controllers - each primary controller has a unique network ID number, and when a node is added to the network it is imprinted with that network ID, and so the node cannot communicate with devices on the other network - this is how it is not possible for your neighbor's Z-Wave controller to control the devices in your home.  If a node you are adding was already added to a network perhaps as a test from the factory where it was made, or because you bought it used or are re-using one that you removed earlier, then you will first have to remove it from its current network before you can add it to your network.  You do not need the primary controller from the network the node was added to in order to be able to remove it - any primary controller can tell a node that it is no longer a part of a network.  This is still secure however because the process for adding or removing a node involves having the node send a specific signal at the proper time, and that signal is a very low power signal so that other controllers do not hear it.  This is why adding or removing nodes must be done with a portable controller or by placing the controller near the node being added or removed - it was designed to use a low power signal for security purposes and so it must be within a couple of feet of the controller when it is added or removed.

All nodes are not listening!  Although most of the Z-Wave nodes added to your network will be listening for Z-Wave traffic and helping to route commands to/from other nodes, there are some that do not listen at all, and do not participate in routing on the network.  These devices are typically battery operated devices because having the RF radio on all the time listening for commands would drain the batteries in a VERY short time.  Examples of these types of devices are battery operated motion detectors, door/window sensors, or battery operated transmitters.  This also includes most handheld controllers!  That's right - even if a handheld controller is the primary controller, it usually will not be listening and will not participate in routing on the network to conserve battery power.  For these devices, many support a Z-Wave class called "WAKE" which means that they can be configured to wake up at a regular interval so that other devices can communicate with it.  With many battery operated devices, the wake class (or Wake-Up as it is also known) will be used to ask the device when it wakes up what the battery level is at, so that monitoring of the battery can be done to avoid the device failing outright.  Some of these devices do not support the Wake-Up class, and in this case for purposes of adding the node to the network and configuring it, they should support a method for keeping the device awake for a period of time -- for example, when you first insert batteries in some motion detectors, they will stay awake for 10 minutes so you can communicate with them.

Working with HomeSeer

It is helpful to point out how a few things about Z-Wave fit in with HomeSeer.  While we were pioneers of adopting the technology, we are not the makers of most of the Z-Wave enabled products, and all products incorporate the heart of the Z-Wave functionality using electronics from Zensys, the makers of Z-Wave.  The process of using Z-Wave with HomeSeer involves (of course) having an interface on your HomeSeer PC so that HomeSeer HS2 can send and receive Z-Wave signals.  As mentioned before, it does not matter whether the interface is a primary controller or not, but the interface you choose will determine how you will go about adding nodes to your network.  After nodes are added to the network and (if necessary) copied or transferred to your HomeSeer interface, you will then need to import the node information to HomeSeer so that it can compare the nodes on the network with the nodes it already knows about, and create devices for the new nodes that you added.  When this happens, HomeSeer has to communicate with the nodes to gather information about them - what type of node they are, what their capabilities are (whether they are listening nodes or not), and what Z-Wave "classes" they support, which define many of the features that HomeSeer will make available for them.  For this purpose, when you are transferring node information into HomeSeer, it is important that the node you added is awake and listening for commands, and also that your HomeSeer Z-Wave interface has a way to communicate with that device.  For example, if the device is the second node you added to your network and it is on the second floor, and your HomeSeer interface is on the computer in the basement, then there is not enough of a Z-Wave network to route signals to the node upstairs, and it will be unlikely that HomeSeer can communicate with that node.  If your home or apartment is small, this may not be a problem since the nominal range of Z-Wave devices is quite far, but remember also that metal (HVAC duct work, refrigerators, appliances) can block RF signals and make communication with a node only 20 feet away nearly impossible.  Build the network starting around the HomeSeer interface if possible, and the addition of nodes will allow you to expand your network as you go.


HomeSeer includes an "Optimize" feature, which will appear if your HomeSeer interface is also the primary controller for your network, because optimization can only be done using the primary controller.  When a node is added to the network, the primary controller asks the node to discover which nodes are its neighbors, so that it can build a routing table for the new node that lists which nodes can communicate with it.  This routing table is what the controller and other nodes will use to know where to send a signal in order to be able to reach each node in the network, if it fails to communicate with it directly.  There are, however, four sets of routing information for each node in the network.  This means that if the other 3 entries were never filled in or are outdated because you have changed your network, then nodes may not have good information for knowing how to get commands to a node.  HomeSeer's optimize feature, which is at the heart of the Z-Health™ system, uses the primary controller to instruct a node to discover its neighbors.  When this is done four times for a node, it can be assumed that all four copies of the node routing information are up-to-date so that the most number of routes are available.  Optimizing should certainly be done whenever a node is added or removed from the network, but it should also be done if you perhaps rearranged the furniture and potentially changed the RF characteristics of the house to make some working communication paths inoperable.  The danger of optimizing when it is not needed involves "fringe" nodes, or nodes that are near the outside of the network and have unreliable communications.  With fringe nodes, they may only have one node that can reach them, and if there is a problem with that one node communicating with the fringe node when the optimize is done, then the result of the optimize could be that there are now NO routes.  For this reason it is always best to mesh your network thoroughly.


One of the features of Z-Wave is that it is a fully two-way communicating protocol.  This means that when a node is sent a command, the node will respond when it receives this command, so the originating device will know it was received.  This should not be confused, however, with "two-way" features of other technologies which meant that when the device was operated locally (e.g. with your finger) that it would send a signal that it changed.  This feature does NOT exist in Z-Wave.  There are ways of getting "instant status" reports though, and thanks to a basic class that almost every listening (awake) node supports, HomeSeer can also be set up to query the node on a regular basis for its status.  A couple of ways that a node can report its status immediately is with the Association Command Class (Association for short), or with the Scene Class if HomeSeer is made to be a part of the scene.  Whenever possible, HomeSeer will use one of these methods and will program the device so that HomeSeer can receive instant status of changes.  If a device does not support either of these features, then the most likely reason is that the manufacturer did not license a patent owned by Lutron for instant status notification of electronic devices.  The association class allows a device which was made to be an association source, transmit commands to other devices.  The recipient devices do not need to support the association class to receive these commands - the commands are essentially the same ones that HomeSeer uses to turn a device on, off, or to a specific level.  An example of this is a transmitter, that does not have a light that it controls itself, but looks like other wall switches in your home.  When you press the transmitter to turn on an association group, the nodes that were made a part of that group receive an "On" command from the transmitter.  Some types of transmitters support multiple groups, so that if you press the transmitter once, it sends a command to Group 1, press the transmitter twice or press a different button, and it sends a command to Group 2.  There may be multiple devices that are a part of any group.  When a device supports being an association source, HomeSeer will attempt to add itself to one of the association groups so that it will be notified when the device is operated.  Association is how a device such as a motion detector is configured to turn on a light in a hallway when it detects motion.  If the device does not support associations but supports the scene class, then HomeSeer will attempt to add itself as a member of the scene.  It does this so that when the scene is activated, HomeSeer will receive the scene activation command and can then update the status of the scene device that sent the scene activation to show it as being "On".  The final way for HomeSeer to receive status of a device to know whether it is on or off is through polling.  This is not instant status, since the polling takes place at a regular interval, but by setting a polling frequency in the device properties in HomeSeer, you can cause HomeSeer to ask the device for its status at that frequency, and so it will eventually learn of changes in the status of the device and can trigger events based upon it.   Keep in mind that due to the Lutron patent, some manufacturers who did not license the patent can still support the association class, but eliminate the ability for the device to have any associated devices when it is turned on/off locally.  Make sure you understand its ability to report instant status before you make a purchase!

The scene class sounds redundant when you consider that a HomeSeer event that operates multiple Z-Wave devices is the same as a scene, but the scene class is actually quite different and useful.  When HomeSeer sends a Z-Wave command to several devices, it will try to send a single command to operate all of them at once, but more often it ends up sending individual commands.  Although individual commands are very fast with Z-Wave, there can still be a bit of a lag before all of the devices are at the level you specified, and they all went to the level you specified immediately, or at least as fast as the default ramp rate it was configured for if the device supports a configurable ramp rate.  Scene capable devices have support for a ramp rate for the scene itself, and the ramp rate could be anywhere from one second (on instantly) to as long as 10 minutes or more.  In this case, the light (if it is a dimmable light) slowly increases its level, ever so slightly, so that it ends at the desired level at the end of the desired time (ramp rate).  If you are automating a theatre or putting the kids to bed, the ability for the lights to change over a period of time is quite useful.  So to summarize the difference with an example, a light that does not support scenes that you want to turn on to 80% in 5 minutes can be controlled by HomeSeer to do that if you create a series of event actions with delays and set levels that the device is set to - very inconvenient to set up.  Or, you can configure a single delay of 5 minutes in HomeSeer, and then the light goes to 80% instantly.  With a scene, however, HomeSeer activates the scene and then slowly over that 5 minute period the light gets brighter and brighter until at the end of 5 minutes, it is at 80% brightness as you desired.


You can learn about setting up Z-Wave in the topic Setting Up Z-Wave.