Z-Wave Application Layer

So far we only looked at how different nodes can communicate with each other. The application layer of the Z-Wave product now defines and specifies what and why two nodes communicate with each other.

Types of Z-Wave Devices

In theory every controllable or controlling device in a home or office can be equipped with Z-Wave technology. Hence one should expect a broad variety of different devices and functions. However there are some basic functionality patterns that allow categorizing different devices. Each device will either control other devices or being controlled by other devices. In the Z-Wave terminology controlling devices are called controllers, reporting devices are called sensors and controlled devices are called actuators. It is also possible to combine a logical sensor controller or actor function within one physical device. Actors switch either digital (on / off for a electrical switch) or analogue signals (0 %. 100 % for a dimmer or venetian blind control). Sensors deliver either a digital signal (door, glass breaking, motion detector, window button on the wall) or an analogue signal (temperature, humidity, power).

In today’s market of Z-Wave device there is a surprisingly short list of different product categories. Nearly all Z-Wave devices on the market can be categorized into one of the following function groups:

1. Electrical switches are designed either as plug in modules for wall outlets or as replacement for traditional wall switches (digital actors). It’s also possible to have these actors already built into certain electrical appliances such as electrical stoves or heaters.
2. Electrical dimmers, either as plug in modules for wall outlets or as replacement for traditional wall switches (analogue actors)
3. Motor control, usually to open or close a door, a window, a window sun blind or a venetian blind (analogue or digital actors)
4. Electrical Display or other kind of signal emission such as siren, Led panel, etc (digital actors)
5. Sensors of different kind to measure parameters like temperature, humidity, gas concentration (e.g. carbon dioxide or carbon monoxide) (analogue or digital sensors)
6. Thermostat controls: either as a one knob control or using a temperature display (analogue sensors)
7. Thermostats controls such as TRVs (Thermostat Radiator Valves) or floor heating controls (analogue or digital actors)
8. Remote Controls either as universal remote control with IR support or as dedicated Z-Wave Remote Control with special keys for network functions, group and/or scene control
9. USB sticks and IP gateways to allow PC software to access Z-Wave networks. Using IP communication these interfaces also allow remote access over the internet

The following images give an idea about the variety of products based on the Z-Wave standard.

Figure 4.1: Different Z-Wave Devices

Command Classes

All communication within the Z-Wave network is organised in Command Classes. Command Classes are a group or commands and responses related to a certain function of a device.

Figure 4.2: Examples of different command classes

A normal on/off switch is referred to as a binary switch. The basic function of a binary switch is to be switched on and off. With a Z-Wave system it is also possible to know the status of the switch, hence a status request function and a status report function is required too. The Command Class for a binary switch consists of three different function responses, commands or reports.

• Binary Switch – Set: is sent from a controller to the switch to turn the switch on or off

• Binary Switch - Get: Is sent from the controller to the switch to request a report about the switching state.

• Binary Switch – Report: is sent from the switch back to the controller as a response to the Binary Switch Get Command.

These three commands and responses are grouped and referred to as command class „Binary Switch‟. If a certain Z-Wave device supports the command class binary switch it is supposed to be able to deal with all these commands:

• The switch need to understand the set command and set the switch accordingly

• The switch is able to receive a get command and is able to response with a report command in the proper format.

Annex A gives an overview of the different command classes defined in the Z-Wave protocol.

The command class „Basic“

Command Classes represent the functions of a certain Z-Wave device. Switches will support different command classes rather than thermostats.

To make sure Z-Wave devices can communicate with each other even without further knowledge about their specific function, there is one special command class called “basic”.

The basic command class consists of two commands and one response:

• SET: set a value between 0 and 255 (0x00 …0xff);

• GET: ask the device to report a value;

• REPORT: response to the Get command. Reports a value between 0 and 255 (0x00 … 0xff);

The specialty of the basic command class is that every device will interpret the basic commands dependent of its specific functionality.

• A binary switch will switch on when receiving a value 255 and switch off when receiving a value of 0;

• A thermostat may turn into a convenience temperature mode when receiving value = 0 and may turn into a energy saving mode when receiving a higher value;

• A temperature sensor will issue a basic report and send a integer temperature value;

• A door sensor will either send out a value = 0 in case the door is closed or a 0xff when the door is opened.

Figure 4.3: Basic Command Class

The basic command class is the smallest common denominator of all Z-Wave devices. Every Z-Wave device must support the Basic command class.

Device Classes

To allow inter-operability between different Z-Wave devices from different manufacturers, certain Z-Wave device must have certain well-defined functions above and beyond the basic command class. The structure behind these requirements is called device class. A device class refers to a typical device and defines which command classes are mandatory to support.

Device classes are organised as a hierarchy with three layers:

• Every device must belong to a basic device class;

• Devices can be further specified by assigning them to a generic device class;

• Further functionality can be defined as assigning the device to a specific device class.

Basic Device Class The BASIC device class makes a distinction merely whether the device is a controller, a Slave or a Routing-Slave. Therefore every device belongs to one basic device class.

Generic Device Class The generic device class defines the basic function as device is supposed to offer as a controller or slave. Current generic device classes are:

• General controller (GENERIC_CONTROLLER)

• Static controller (STATIC_CONTROLLER)

• Binary switch (BINARY_SWITCH)

• Multi level switch (MULTI_LEVEL_SWITCH)

• Binary sensor (BINARY_SENSOR)

• Multilevel-Sensor (MULTILEVEL_SENSOR)

• Meter (METER)

• Input controller (ENTRY_CONTROL)

• Thermostat (THERMOSTAT)

• Window Venetian blind controller (WINDOW_COVERING)

Specific Device Class Assigning a specific device class to a Z-Wave device allows it to specify the functionality of the device further. Each generic device class refers to a number of specific device classes. Assigning a specific device class is voluntary and only makes sense, if the device really supports all specific functions of a specific device class. Special device classes are, for example:

• Setback Thermostat (SETBACK_THERMOSTAT) is a specific device class of the generic device class “Thermostat“;

• Multi-level Power Switch (MULTILEVEL_POWER_SWITCH) is a specific device class of the generic device class Multilevel Switch;

In case the Z-Wave device is assigned to a specific device class, it is required to support a set of command classes as functions of this specific device class. These required command classes are called mandatory command classes and they are individual of certain generic and specific device classes. Above and beyond the mandatory device classes, Z-Wave devices can support further optional command classes. They may be very useful but the standard does not enforce the implementation of these classes. A Z-Wave manufacturer is allowed to implement an unlimited number of optional device classes, however if these device classes are implemented, the standard defines how these commands and functions are to be supported.

Figure 4.4: Optionally, recommended and mandatory Command Classes within a device class

The basic device class, the generic and, if available, the specific device class is announced by the device during inclusion, using a Node Information Frame. As well as the device classes, the Node information frame also announces all optional command classes of the device included. With this announcement, a controller can control and use an included Z-Wave device according to its functionality.

Figure 4.5: Different Implementation of a Device Class „Binary Power Switch“ by different vendors

A Z-Wave device works according to the Z-Wave standard if

• It belongs to a basic device class and a generic device class, and is able to report these classes on request using a Node Information Frame.

• It supports all mandatory command classes of the basic and generic command class by sending commands and reports as well as accepting and executing commands according specification of the command class;

• In case a specific device class is defined the mandatory command classes of this specific device class, needs to be supported as well and the specific device class needs to be reported on request;

• In case optional command classes are implemented, these command classes need to be announced in the Node Information Frame on request and need to be supported according to the Z-Wave command class specifications. Frame on request and need to be supported according to the Z-Wave command class specifications.

Z-Wave defines a broad variety of command classes covering almost every aspect of home automation and control. Nevertheless it‘s possible that manufacturers want to implement further functionality not already defined in a command class specification.

The command class “proprietary function” is defined to cover these needs. A proprietary function would allow a manufacturer to implement specific functions that can then be used only by other devices supporting this proprietary function as well.

The use of a proprietary function is subject to approval by the Z-Wave alliance certification authority and is required to be documented extensively. So far only very few device make use of this function. Typically new requirement result sooner or later in an amendment to the existing standard, which makes this function part of the official standard and any proprietary extension becomes obsolete.

One example shall illustrate the use of device classes and command classes:

Figure 4.6: Schuko Wall Plug

A manufacturer wants to offer an Schuko Plug-in Switch as shown in Figure 4.6. The basic function of this switch is switching the mains on and off. Since such a device can be used at multiple locations the basic device class “routing slave” is used. As a binary switch the device belongs into the generic device class “BINARY SWITCH”. It is allowed and in this case even recommended to use a specific device class Binary Power switch since this Schuko plug switch will always switch power lines.

• Basis class: Routing-Slave

• Generic class: Binary switch

• Special class: Binary switch for power

1. The binary switch device class requires the implementation of the mandatory command class “binary switch” and of course the implementation of the basic command class.
2. As binary power switch the device is furthermore requested to implement the so-called “switch all” command class. This is a command class a controller may send to all devices in the network to an “all off” function. The “switch all” device class also implements ways to configure the device under which circumstances it should react to this “switch all” command issued by a controller. A generic switch is not required to implement such a command class, since an “all off” command may not mean something useful to a generic switch. In case of a power switch an “all of” command is clearly defined and therefore a mandatory command class.

If would be allowed by the standard not to implement the “switch all” command class but in this case the device is not allowed to announce a specific device class “binary power switch”. A switching device without “Switch All support” which just announces a generic device class “Binary switch” would still be a valid Z-Wave compliant device.

1. The manufacturer wants to offer more a competitive product and adds further functionality to the switching device. One may be the so called “child protection”. A Child protection function on a binary switch means the ability to turn off all local control capability and only allow switching the device wirelessly.
2. If the manufacturer decides to implement such function the standard defines in the “protection” command class how to do this. Also the optional command class “child protection” needs to be announced in the Node Information Frame.
3. The manufacturer may decide to further enhance the switch by offering a special function, which randomly switches the device on and off. In conjunction with a lamp this function may be used as anti theft device in the home.

At the moment there is no command class defining such a capability. The manufacturer could now ask for approval to implement this function and still be certified as Z-Wave compliant device. Depending on the approval the function would be realized as “proprietary function”.

Configuration

The Z-Wave standard defines that every device shall be functional on factory defaults. Nevertheless there are device, which may require further user and application specific setups such as

• Sensitivity of a motion detector

• Behaviour of control LED lights

• Switching delay of an alarm sensor

• Specific behaviour under error conditions

The configuration of a device is performed using the optional command class “configuration”. The configuration command class allows the setting of up to 255 parameters with one value each. A configuration is device specific and all parameters and possible values need to be described in the manufacturers manual.

Figure 4.7: Example of a Configuration Interface in PC Software

In order to do a configuration the user needs to know the configuration parameter number and the desired value.

Example: Configuration of a status LED on a device.

Parameter # 2: switches the Led on the device on, off or blinking according to status of the device

Value = 0: Always off

Value = 1: Blinks when active

Value = 2: Always on

Configurations are usually done using static controllers, either as PC software or an IP gateway. This allows giving a nice graphical interface for setting up the configurations. Modern Software solutions use a verbal translation of the configuration parameter number by using databases that give further information about the configuration parameters and possible values.

Battery operated devices

Battery-operated devices are a special challenge within a Z Wave network, because they are mostly in a sleeping state for current savings reasons and cannot be reached from a controller in this state.

Battery operated device know two states:

• They are awake and can communicate with other devices of the network

• They are sleeping and do not communicate at all. For other controllers they may appear as non existing to damaged

In order to allow communication with battery operated devices a mains powered and therefore always active static controller needs to maintain a waiting queue, where all commands are stored which are to be sent to a sleeping device. When the battery operated device wakes up it will inform this controller and “empty the mailbox”.

At the moment a battery operated device wakes up it sends a so-called WAEKUP_NOTIFICATION to the controller and stays awake. The WAKEUP_NOTIFICATION indicates to the controller that the battery device is now listening to commands. If all commands are sent the controller will send a final command “NO_MORE_INFO” to indicate to the battery device that it can’t go back to sleeping mode. If the battery operated device does not receive a “NO_MORE_INFO” if will go back to sleeping mode after a defined time.

Figure 4.8: Sleeping and wakeup

The operation of battery-operated devices requires at least one static and mains powered controller in the network to store commands for sleeping battery devices. If a local action on a battery operated device is performed such as pressing a button the battery device is usually woken up immediately to issue a command according to this action. Each battery device needs to have a defined local action for wake up such as pressing a certain button.

Figure 4.9: Example of a wakeup time dialog

Most battery-operated devices will have an internal timer, which wakes up the device regularly to check for queued commands. This maximal sleeping time can be configured. A typical sleeping interval is between 30 seconds and days and can usually be configured on a user interface of the controller. Any change of the wakeup time will, like any other command sent to the battery device, become effective after the next wakeup.

Certain devices will limit the wakeup interval to a maximum and minimum value. Unfortunately it is not defined how the device shall react if a forbidden interval value is configured.

Therefore the wakeup command class was extended to allow manufacturers to announce a minimum and maximal wakeup time during configuration. If these new command classes are used a misconfiguration is impossible. Nevertheless its worth to refer to the manufacturers manual for further information.

To allow an initial configuration of a device after inclusion every battery device shall stay awake for a defined time, which may vary between 20 seconds and some minutes.

Table 4.1 summarized again the different states of a battery operated device and the conditions to change the status,

Situation	Awake	Sleeping
Inclusion	Right after inclusion	Turns into sleeping mode after a couple of minutes without any further user action.
Regularly	Wakes up after a defined interval and sends a notification to static controller. Typical Wakeup intervals are between minutes and hours and can be configured by the user within certain boundaries	Controller can turn back the battery-operated device by sending a command. Otherwise the battery device turns back into sleeping mode after a defined time (usually a minute)
Local operation of the device	Wakes up on every local operation and communicates status if needed (e.g. button pressed)	Immediately after finishing action

Table 4.1: Conditions to change state for battery operated devices

This wakeup/sleep behaviour may cause a couple of failures or unclear conditions.

Typical Failure during Inclusion into a Network

It’s a common approach to include multiple devices one after each other. However it can happen that a battery powered device may be sleeping already when the controller wants to include it. The controller will not “see” the device and may conclude that the device does not exist or is dead. The battery-operated device will usually wake up after a defined time interval but this may happen after multiple hours or days.

Therefore its recommended to configure the battery-operated device right after inclusion or make manually wakeup the device later on for configuration. In case of manually wakeup it may happen that the device goes back into sleeping mode right after wakeup if no further information is available from the static controller.

It’s possible that a battery-operated device wakes up but does not know where so send the wakeup information to. This happens if the device was not configured after inclusion to know the Node ID of the static controller who holds his command waiting queue. Therefore it’s highly recommended to configure a battery operated device right after inclusion and to have the static controller included first. Only then the static controller is able to configure the battery-operated device correctly.

Certain devices will stay awake after first power up only and go right into sleep state after first inclusion. This is not longer accepted by the standard but older model may behave like this. If the device is powered up using the batteries and is included into the network much later it may result again in an error since the battery device will not stay awake long enough after inclusion to allow correct configuration.

Therefore it is recommended to follow the following guideline when including battery devices into a Z-Wave network:

1. Include every battery-operated device right after inserting the batteries the first time. Make sure to configure a reasonable wakeup time before the device goes into sleeping state for the first time.
2. In case there is further configuration work to do configure a low wakeup time first but make sure that you configure a longer battery saving wakeup time when all configuration is finished.
3. Do not batch include and configure afterwards and don’t loose any time after inclusion to configure the device.
4. A reasonable wakeup time is a trade-off between two goals:
   1. A very long wakeup interval will save battery capacity but may create problems in case of network reorganization. The static controller may not hear anything from the battery device during the reorganization and then threat the device as not functioning.
   2. A very short wakeup time helps the controller to keep track of the device but costs battery lifetime.
5. The wakeup interval must be configured between the allowed boundaries. Refer to the manual of the manufacturer has set any boundaries.

Maximization of battery life time

The battery lifetime is the critical measure of battery-operated devices. Therefore some estimates should be given and taken into account.

• A typical Alkaline-Microcell (AAA) has an energy capacity of approx. 1000 mAh. A typical battery-operated sensor has 2 such batteries.
• A Z-Wave module of the class 300 consumes 2.5 myA in the hibernation state and 21 mA in the wakeup mode. During transmission of packets about 36 mA are required. Table 4.2 shows the current need of the single chip generations in their respective working conditions.
• Additional battery power can be used for the devices functionality such as operating an infrared sensor or moving a thermostat valve. This power consumption varies from device to device and is usually only a fraction of the power used for the electronics. For the following estimate this portion of the power usage should be neglected

Chip Generation	Hibernation (A)	Transmitting (mA)	Listening (mA)
100	31	25	21
200 (since 2005)	2.5	36	21
300 (since 2007)	2.5	36	21
400 (since 2009)	1	23	21

Table 4.2 Power consumptions of different chip generations

If a sensor is in the active reception mode constantly, his battery is empty after 1000 mAh / 21 mA = 47 hours = 2 days!

It is therefore mandatory to move a battery-operated device into the sleeping state. The maximum battery lifetime in the permanent sleeping state for the accepted configuration is 1000 mAh / 0.0025 mA = 400,000 hours = 16.666 days = 45 years. In this time even alkaline batteries will have become empty by self-unloading.

If a battery device is not turned back into sleeping mode right after wake up and exchange of queued commands from the mailbox the device will stay in listening mode for about one minute A transmitting time of 1% of the reception time is assumed corresponding with the regulation of the Z-Wave radio standard. The programmed wakeup interval determines, how long the battery will last.

Wakeup interval	Battery life time
120 Seconds	4 days
1800 Seconds = 30 Minutes (typical)	118 days
24 hours	2439 days

Table 4.3: Battery Lifetime as function of wakeup time

A battery lifetime of 118 days (under disregard of all local operations like blinking of a LED, moving of a motor etc.) is still unacceptable. Hence, it is necessary to operate a static controller in the network to manage battery-operated devices and shorten the wakeup time.

If a static controller is programmed in a way that he will send every device back into sleep mode right after wakeup and cleaning the mailbox the battery live time is extended dramatically.

Assuming typical wakeup intervals and assuming that 50 % of the wakeup time is used for transmitting signals from the battery operated device to the controller with a total communication time of 50ms. Table 4.4 shows the resulting battery lifetime.

Wakeup interval	Battery lifetime
120 seconds	59 days
1800 seconds = 30 minutes (typical)	850 days
24 hours	12400 days

Table 4.4: battery lifetime depends on wakeup interval

These numbers are only valid under the assumption that no additional power is used for the functionality of the battery-operated device, e.g. turning a valve of a heat of measuring some environmental data. Assuming a factor of 50 % of the total power consumption for these functions the resulting battery lifetime is in the neighbourhood of 1 year that confirms values given on vendor data sheets for typical battery operated devices.

However to reach these value the presence of static controller is mandatory managing the battery operated devices. In a network with only portable controllers the lifetime of battery powered devices will be shortened. The values of table 4.3 should apply in this case.

These estimate are only applicable for battery operated slave devices. Portable controllers, which are battery-operated devices as well, will always sleep unless pressing a button wakes them up. Hence, the battery life time of these device totally depends on the self discharging effect of batteries and the usage pattern and will typically reach 2…3 years.

Groups, Scenes and Associations

With Z-Wave, you can not only operate individual actions with appliances such as lights, heating and window blinds, but also create “Scenes” like “Leave for Work”, and select what you want to happen in your home, when you leave for the day. Also you can create “Events” which react when something happens – so for example, when a motion detector is tripped, a light can come on for 5 minutes. And if that wasn’t enough, there is a “Timer” setting where you can set the lights or the thermostat to go on or off at a certain time. If you are at work, its good to be reassured that lights are going off when they should for example. The VERA Gateway is great for this, as VERA can reassure you with an optional text message alert to tell you everything is ok! Through the FREE optimized iPhone application, VERA offers additional support to help you manage all your Z-Wave devices. VERA is focused on simplicity. It does “complicated” things but in a really simplistic way. It’s centred on usability and practicality, making managing your home energy consumption a joy rather than a chore. Literally, just plug in the VERA Gateway and setup is quick and automatic. It even doubles up as a pre-configured Wi-Fi access point, Firewall, gateway and router, giving you a secure wireless home network. Z-Wave technology is really effective when setting up a home security management system. You can control your alarms remotely using Z-Waves, as well as set your doors, windows and motion sensors to high alert. With the aid of Z-Waves, the components can be managed by a central home hub - Gateway VERA, so if a detector senses an intruder, then a signal to VERA will set off lights, alarms and even a text message to alert you at work. The uses of more complex usage patterns are best managed using Association, Groups and Scenes.

Associations

In a typical Z-Wave network, the controller communicates with slaves in two typical ways. They send out commands to change the status of slaves, e.g. switch them on or off – and they receive status information from sensors, e.g. movement info from a motion detector (only from routing slaves). Meaningful function in a network may include dependencies and interaction between two slaves as well. Example: One Z-Wave device is a motion detector, a second device shall be a power switch controlled by a remote control. It’s the desire that the switch shall switch on, if a motion is detected.

Figure 4.10: Small Z-Wave Network with Association

One setup would be that the motion detector sends a signal to the controller and as a second step the controller sends the switch command to the power switch. However this means that:

• The controller is added as additional source of failure;

• The communication takes much longer then necessary;

• The controller needs to be in the listening mode, which means it

needs to be a static controller;

An association allows that the motion detector sends its signal directly to the power switch without involving the controller. This allows using sensor even in a network without a static controller. This saves time, reduces the complexity of the communication and the amount of airtime, which directly translate into allocation of the wireless communication channel and the electromagnetic emission. To be able to use an association, the sending node (in the example the motion detector) must have the knowledge of a valid route to the destination (in the example the power switch). Therefore only a routing slave or a controller can use associations. A normal slave does not have any information about routes and only send signals as answer to received commands. In order to set an association the sender needs to learn about the node id (s) of the receiving node (s). There are two different ways to accomplish an association scenario:

Direct Association:

Figure 4.11: Direct Association

The source node of the association will be turned into an “association set mode” waiting to receive a node information frame from the device to associate. The receiving node needs to send out node information usually accomplished by just pressing a button. The node information frame received contains the Node ID of the association partner and allows the source node to set the association. Because the node information frame is always sending out as a broadcast to all nodes “in range” direct association only works if both sender and receiver as “in range” which means they have a direct not routed wireless connection established.

Assigned Association 

Figure 4.12: Assigned Association

Assigned associations allow connecting two Z-Wave devices, which are not in range. To do this the help of a third node –a controller with knowledge of the complete network and its routes is needed.

Figure 4.13: Wall controller with dedicated button for Association

The connecting controller needs to be turned into a association mode by either pressing dedicated buttons or selecting a function on a PC software controlling a USB connected Z-Wave transceiver. The controller now expects (1) a node information frame from the desired source and in a second step (2) a node information frame from the desired target node. Again the Node Information frame can only be received by nodes in range, hence the controller need to be brought in direct wireless range of the two nodes, but not at the same time. First the controller is near the source node receiving its Node information frame and in the second step it needs to be places near the target node to receive its node information frame as well. In a last step the controller will communicate with the source node and set the association by informing this node about the association target and the route to reach this target. The user accomplishes this without further interaction. Since the controller knows the route to the target node its not required to bring the controller back in range to the target to perform the final configuration.

A node needs to announce its capability to accept an assigned association configuration in his node information frame. It„s possible to have multiple target nodes assigned to one single source node. All these target nodes will receive the same command at the moment when the event takes place triggering the event, which was configured by association. It is possible that there are multiple different events, which may cause to send commands to different nodes. The number of target node that can be associated to this given node for the given event are called association groups. The number of different association groups (i.e. different event which can cause to send out a command to associated nodes) and the maximal number of nodes, which can be associated to a given group, are a performance indicator for Z-Wave devices.

An example of a Z-Wave device with association is a wall switch with two switching paddles.

Figure 4.14: Wall controller with two switching paddles

For this particular product there should be at least two association groups, one for the left and one of the right paddle. A lot of vendors of wall switches offer even more groups, which get activated when doing a double press or press both paddles at the same time. The number of receiving nodes per groups is typically limited to five devices. This limitation is caused by the limited memory space of the device, hence it’s possible that certain device without memory constrains offer many more possible target nodes. If nodes are assigned to one of the association groups of a device this device will send a signal to all the target devices every time this groups gets activated – typically by pressing a button, a combination of buttons or when a sensor value reached a certain level. To make sure a maximum number of different target devices can be controlled, most devices with association functions will use the BASIC command class to control target devices. However there are devices on the market offering to configure which command class to be used to control target devices. With this feature it„s possible to execute very special functions on the target device. The inclusion function of a device includes the device into a network and makes sure that the device is able to communicate with other devices in the network. The association function describes a specific action between a specific sending and a specific receiving node. The action is triggered by a certain condition at the sending node (e.g. button pressed) and will cause a certain action at the receiving node. Associations are also used to assign certain remote control buttons to certain devices in a Z-Wave network.

Groups

It is possible and usual to connect multiple devices from one single button on a remote control. These controllers, joins certain devices into a group and control them, as if they are one device. This means that all devices are switched simultaneously when the button is pressed. Since all devices in a group receive the very same switching commands, it‘s useful to only group similar devices into one group. If different devices are mixed, the result can be surprising and confusing. Similar to associations, most remote controls only use the BASIC command class to control groups. This allows mixing different devices but only to a certain extent. Mixing a dimmer and a switch will result in the dimmer acting as a switch. Most remote controls describe the switching of groups but don’t refer to the switching of a single device. In order to switch a single device it’s possible to just place this single device into a group and switch the group. It„s also possible to assign one device into different groups.

Scenes

The definition and the usage of scenes is a very powerful tool to control Z-Wave networks. Like a group, a scene groups together multiple Z-Wave devices. While groups tread all devices similarly, scenes cause a controller to send different commands to different devices. This results in endless possibilities such as: “turn switch off and open the window B” or “dim all lamps to 50 % and turn on the TV”. Scenes are very flexible and much more powerful than groups, but take a lot of memory to store the different commands. Hence in a remote control the number of scenes is typically much smaller than the number of groups. Static controllers such as IP gateway or PC software typically allow an almost unlimited amount of scenes.

Comparison of groups, scenes and associations

Groups, Scenes and Associations are different ways to realize functions and interactions within the z-wave network.

	Used in	Function
Associations	Slaves	Sends control signals to one of more target devices (Slaves or controller)
Groups	Slaves and controllers	Grouping of multiple devices receiving the same control message - typically via association (from Slaves or controllers)
Scenes	To controllers	Activation of a scenes leads to switching different devices using different control messages

Usage of IP-Gateways

IP gateways allow a very user-friendly configuration and usage of a Z-Wave network. Different functions and sensor values can be access using a convenient web interface or even a mobile phone like the iPhone.

The user friendly and usually self-explaining web interface allows performing all relevant functions of a Z-Wave network in a convenient way. These gateways offer user interfaces for user management and special interfaces for mobile access. In order to increase usability, devices can be assigned to different rooms or zones of the home. Some gateways offer an upload opportunity for floor plans.

The central function of an IP gateway is the definition and activation of scenes. Scenes define a certain switching state for different devices; e.g. switch is switched off, window is closed, dimmer is at 50 %, window blind is 90 % open. Scenes can be defined for the whole home or for different parts of the home, such as different rooms. Defined Scenes can be activated depending on certain conditions, e.g.:

• A certain sensor values (Activate open window scene with open windows, and heat turned down when CO2 sensor reached 100 ppm);

• A certain button is pressed (Turn off al electrical devices and turn down all light when the “all off” button near the front door is pressed);

• A certain time is reached (Turn down all window blinds 30 minutes after sun set);

• A Boolean logic determines the event (Turn on all outside lights when time is between 18.00 and 0600 AND all off button is pressed);

It‟s typically possible to run multiple scenes in parallel. In this case the user need to make sure no contradicting commands and settings are defined.

Figure 4.15: Scene Setup Dialog

Besides switching devices the activation of a scene may trigger more functions such as sending of an email or an SMS or calling a predefined phone number. During configuration and usage of an IP gateway there are three challenges worth to be discussed:

• Reporting of status changes of devices cause by local usage rather than initiated via the wireless network;

• Associations configured directly on the devices rather than set by the user GUI of the IP Gateway;

• Scene activation using Z-Wave remote controls or other wall controllers.

Display of Switching Status Information

Users want to see the status of their electrical devices on their mobile phone or PC screen. The gateway is able to poll the states of each devices but the poll interval is way too long to ensure a real-time update of the status. In case the status is changed from the gateway using a phone or the PC interface, the gateway is initiating the status change and is able to request the new status right after executing the switching command. However, certain devices offer to switch the state locally by pressing a button (e.g. a wall plug switch of a simple wall switch). In this case the gateway does not get any update information from this particular switch.

Figure 4.16: Missing status message

Activating a scene from a wall controller or a remote control is a desirable function of a Z-Wave network. In order to activate the scene, the IP gateway must receive information, if and which button of a remote control or a wall controller is pressed. So whether it‟s by Groups, Associations, Scenes or all three, you can personalise your Z-Wave wireless system to the way you want it.

The Lutron-Patent

The US company Lutron has filed the patent 5.905.442 in the mid nineties describing the wireless control of lights from wall switches. The patent relates specifically to wireless networks with mesh routing functions. That’s why a lot of the simpler wireless technologies on the market do not infringe the patent but Z-Wave would do. The key patent claim #1 describes:

1. Apparatus for controlling at least one electrical device by remote control comprising: at least one control device coupled to the electrical device by a wire connection for providing power to the electrical device, the control device having a controllably conductive device for adjusting the status of said electrical device, the control device further having a manual actuator for adjusting the status of the electrical device, the control device further having a radio frequency transmitter/receiver and antenna coupled thereto for adjusting the status of the electrical device in response to control information in a radio frequency signal, the transmitter/receiver being coupled to the antenna of the control device for receiving the radio frequency signal and for transmitting a status radio frequency signal having status information therein regarding the status of the electrical device as affected by the control information and the manual actuator; a master control unit having at least one actuator and status indicator thereon, the master unit comprising a transmitter/receiver for transmitting a radio frequency signal having the control information therein to control the status of said at least one electrical device and for receiving the status information from the control device, the status indicator indicating the status of the electrical device in response to the status information; and a repeater transmitter/receiver for receiving the radio frequency signal from the master unit and transmitting the control information to the control device and for receiving the status information from the control device and transmitting the status information to the master unit.

Every sending of a status signal as result of a status change of a wireless device in a routed network infringes the patent. This is the reason why manufacturers of Z-Wave device intentionally did not implement a status report function as a result of local status change.

As a result the gateway does not recognize a local status chance of the device and will remain showing a wrong status of this particular device.

Meanwhile people found – as almost always – a way to solve the problem without infringing the Lutron Patent. Devices such as wall switches, wall dimmers or Outlet plug switches and dimmers with a local button to operate offer an association group. Using the local button is not only switching the local state but is causing to send a switching command to an association group. The main difference to the patent-protected scenario is that there is no longer a status report (protected by patent) but a switching command (allowed by the patent). Beside other switches, which can be switched simultaneously with the particular button on one switch the Gateway itself may also be a target device. In this case the gateway must emulate the behaviour of a standard switch to be able to receive switching commands. Receiving a switching command from a wall switch will not cause the gateway to switch on a lamp but to immediately check the status of this particular switch and, subsequently, update the switch state on the gateways GUI.

Unfortunately not all wall switches and dimmer already support this association function yet,

Using controllers to switch scenes

Activating a scene from a wall controller or a remote control is a desirable function of a Z-Wave network. In order to activate the scene the IP gateway must receive an information if and which button of a remote control or a wall controller is pressed. To realize this function Z-Wave offers multiple ways:

Associations

An association means to send a switching command from a Z-Wave device to another Z-Wave device. This command is initiated by a local condition such as a sensor value or a button pressed. To activate a scene in an IP gateway using an association the controller must set an association to the IP gateway and the IP gateway must refer the switching command from a particular device to the activation process of a specific scene.

A very typical command setup for such a relation would be the activation of a (I am back home) scene by a motion detector (on the main front door). The motion detector recognizes a movement and sends a switching command to the association group related to the motion detection (Most motion detectors just have one single association group which gets activated when the motion detector gets triggered)

Using associations for scene switching is a common setup in a Z-Wave network but bears two major challenges:

1. Typically the association is set from the IP gateway using the “assigned association” function. This works fine for mains powered devices that are always active. Setting up a battery-operated device will work fine as well. However the user either need to wakeup the battery operated device for configuration or need to wait until the next interval wakeup with cause the IP gateway to send all queued commands. Certain Z-Wave controllers may not support assigned associations but direct associations only; In this case the IP gateway is not able to set the proper association function in this device. The annex B gives some overview of current remote controls and their support for assigned associations.
2. Association commands are typically BASIC commands just sending 0 or 1. As long a there is only one association group in a device – means one basic function such as one button or one sensor- this does not cause any problems. Remote controls or wall switches with more than one paddle typically offer more than one association group to support the different functions of the device. If more than one groups will send basic commands to the IP gateway for scene switching the gateway is not able to distinguish the different groups. Hence it’s not possible to switch more than one scene from one specific device. All groups – in case of a remote control all buttons – create the very same switching command, which is received from the very same device.

Hence associations are only suitable for scene switching, if only one button on a device is available or only one sensor of a device is present.

Scene Configuration

There are remote controls available which were developed particularly to allow scene switching in an IP gateway. These remote controls support a special command class for scene switching (SCENE_CONTROLLER_CONF).

IP Gateway recognizes this command class and can perfectly activate scenes based on these commands. Each button of a remote control will send a different scene activation value to the gateway allowing activating different scenes based on these values.

Scene Replication

Some Remote Controls are able to handle scenes by themselves. They offer scene-switching buttons and can store the whole scene (certain commands to certain devices to a scene) in their own memory.

It is possible to load scenes from the IP Gateway into the remote control. The remote control will then activate the scene by sending all the commands directly to the target nodes instead informing the IP gateway to send out these commands.

Figure 4.17: Dedicated buttons to control scenes on a universal remote

Scene replication – the ability to store whole scenes from a different controller into a remote control – are only available on few remote controls and not even then they are implemented in a very powerful und flexible way. Hence they are only used rarely.

Double Inclusion

The configuration of scene activation from a battery-operated device such as a remote control causes a hen-egg problem.

The configuration dialog of the scene switching will only offer the scene switching once the remote control is included in the network and the Node ID is known. After inclusion the battery operated remote control will go into sleep mode. After inclusion the gateway is able to use the node ID and other device specific information to offer a scene activation dialog. Every configuration done in this dialog however is only stored in the gateway and not yet known in the Z-Wave device. To configure a battery operated device such as a remote control, the user must give the IP gateway the opportunity to configure this remote control. This is typically done during inclusion process. Therefore a remote control used for scene switching needs to be included twice into the Z-Wave network: first time before scene activation configuration and another time right after the scene activation configuration.

For scene activation by Z-Wave devices the following rules apply:

1. The best way is to directly set scene activation in a gateway using the scene activation command class. However not all remote controls offer this capability.
2. Replicating a complete scene into the remote control is the second best option, but only very few remote control support this and even then the implementation is limited in functionality
3. Associations are a good way to activate scenes, but only as long as there is only one single button or one single sensor in one physical device. Otherwise the Gateway is not able to distinguish different scene activation from the very same device.
4. Associations need to be set from the controller using “assigned association”. Not all controllers allow assigned associations.

IP gateway will always try to automatically find the best way to use other Z-Wave controllers and devices for scene activation. Different options and some unclear implementation in older devices may still cause problems. Regardless of the option used a double inclusion of a battery-operated device is typically required in order to load a configuration back into this device.

Annex B shows a list of known European Remote Controls and their scene switching capabilities.

Configuration of Devices by the gateway

• During inclusion the IP Gateway will recognize the device and read all interesting device parameters.

• All manufacturer specific information such as vendor, vendors product ID and product type

• All firmware and Z-Wave version information

• All switching and reporting capabilities including current switching states and sensor values.

• Number and maximum size of association groups

• Configuration values if known

The Gateways will then do some initial setup:

• If needed a certain predefined wakeup interval is set for battery operated devices

• If available and requested certain standard defaults behaviours are configured in the device

• If association groups are available the gateway will always put its own Node ID into these association groups in order to be informed about status changes and to be prepared for using associations for scene switching

The user can change all values. However it needs to be clear that particularly removing the gateways Node ID from the association groups may cause malfunctions of the gateway.