Buch Kapitel 5
Z-Wave in action – Tips and Tricks
This chapter will provide some useful and practical tips how to build, manage and use a Z-Wave network.
5.1 Building the network – general workflow
Every Z-Wave network is built following the same steps:
- define the desired functions
- pick the right devices
- include all devices into one network
- configure the devices according to the users need
- set all association and define all scenes
- do some final housekeeping work
5.1.1 Defining the desired functions
A Smart Home can have plenty of functions and the planning process can be overwhelming. It makes sense to clearly define the high level services first. These services should be broken down by rooms or floors and by the basic functions of an intelligent home network:
- door lock,
- media and entertainment,
- energy management,
This is a high level list with items that may overlap with each other. Having as example a window open-close control this is both – a security feature and a climate control feature.
A second step is to define where the Smart Home shall be controlled from:
Wall controllers – where placed?
- Remote controls – how many?
- Smart Phone
- Web Browser
- Wall panel
The third step of planning is to create a list of all rooms or floors and assign what functions shall be available in what rooms. There may be functions that are applied to all rooms and functions that only apply to the whole home as such. Such a list might look like this:
- Sleeping room: safety (smoke), light, window control
- Kitchen: light, heating, safety(smoke + water leakage), window control
- Living room: light, heating, media
- All rooms: energy management
- House: main door control, back door control
A few advantages of Z-Wave are that it
- can be used to retrofit existing homes and
- can be applied step by step overtime.
If the planning of a whole home looks too big or expensive or complicated, it is no problem to start with a very small network focusing on one or two applications. Typical small and single focus networks may solve problems like:
- Only managing the main door to avoid phone calls like “I forgot my key”.
- Just combining a second wall switch beside the bed to avoid the typical way to get into the bedroom: turn on ceiling light work to bed turn on bed light work back to door turn off ceiling light work back to bed go to bed turn off bed light
- Installing a central energy meter to get an idea when the most energy is consumed.
- Being able to turn off all big standby consumers such as computers, TV, HIFI etc. when leaving the home.
- Being able to turn up the heat while being on the way home.
These solutions can easily be expanded step by step. This is one of the big advantages of wireless technologies in general and Z-Wave in particular.
5.1.2 Picking the right devices
The selection of the devices is a complex task, because multiple aspects need to be taken into consideration:
- Light control:
- What kind (color, shape) of wall control elements are suitable?
- Shall light be switched or dimmed?
- What kind of lighting elements are installed (traditional light, high voltage halogen, low voltage halogen, LED, CFL)?
- What kind of power wiring system is available in the house (2 wire or 3 wire cabling)?
- How many lights are there per room? Are they wired – like ceiling or wall lampsï¿½ or do they stand alone – like a floor light?
- What kind of heating system is already installed or planned and how it is going to be controlled (central boiler, floor heating with central control, floor heating with zones, radio thermostats, 240 V controlled HVAC,…)?
- Shall the heating be controlled in the room with local elements?
- Is heating and cooling combined?
- What kind of doors are used (thickness, locking system, dimension of door)?
- Shall there be handles on the outside, are the doors left/right winged?
- Which colors and finishes will match the design of the doors best?Doors:
- Shall the windows just be monitored or also moved?
- Roof windows or standard windows?
- What kind of jalousie controller shall be installed ?
- Energy Management:
- What devices beyond lighting and heating shall be monitored (Dish Washer, washing machine, freezer, fridge, sauna, computer)?
This book does not intend to give correct product recommendations but to list down the right questions. There are well organized online shops and home automation professionals available for help in picking the devices and calculating the costs. Two links to major sites can be found in the Annex 9.
Here are some more technical Z-Wave related constrains for device picking:
- If there is at least one battery-operated sensor or actor (FLIRS devices are ok), there must be a static controller like an IP gateway.
- If devices shall be controlled from a web browser or a smart phone, an IP gateway is a must too.
- Battery-operated devices cannot route. If a network only consists of battery-operated devices, there is no routing and the wireless coverage is limited. Its recommended to have a fair distribution of mains powered devices to maintain network functions and network stability.
5.1.3 Z-Wave Wall Switches versus Wall Inserts
There are two ways to upgrade existing installation for light or blind control to wirelessly controllable devices:
- Replace the existing wall switch by a new product with wireless capabilities.
- Keep the conventional analog switch in place but put a so-called wireless switching insert behind the old switch. The switch itself will then not longer directly control the 230 V mains but sends a control signal to the insert only. This insert will then control the mains depending on wireless signals or the position of the conventional switch.
In Europe all electrical installation needs to comply with international IEC norms but there are several common norms for outlet types and plugs. The IEC plug types E and F are most common in Europe and use the standardized 60 mm diameter wall box for mounting. They come in three different depths: 35 mm dedicated for wall outlets, 45 mm deep for switches and other gear in standard brick or concrete walls and 65 mm deep for switches in plaster walls.
Wall Inserts are installed inside the wall box behind the conventional switch. The switches need a depth of 28 mm (IEC norm). Even the smallest inserts are 16 mm high. That is why they can only be placed in 65 mm deep boxes. Application in 45 mm boxes is possible in theory but requires perfect cable and a lot of effort.
Wall Switches comply with the IEC norm with a depth of max 28 mm. They will therefore fit into every 45 or 65 mm deep box and can even be mounted into 35 mm deep boxes.
The intuitive operation of dimmers and blind controls is similar to the window lifter in cars. There is a neutral position without any action. A short click on the upper or lower part of the paddle moves the motor in one of the end positions respective turns the dimmer entirely on or off. Keeping the paddle pushed allows positioning the motor on the desired position between the end points resp. set the dimmer to a desired level.
Z-Wave wall switches implement the control functions in the very same way. Wall inserts however use the switching paddles of the conventional wall switch. Typically they offer two control options. Due to the lack of a neutral position they are used in a ’toogle’ mode. Every switch into the ON-position results in the change of the switching state (on after off respective off after on). Keeping the switch in the on position emulates the ’click and hold’ function to dim a light or to position a motor. This allows to dim and set the motor but is a very unexpected function of a wall switch. Guests and other family members may not appreciate this strange way to operate a wall switch.
Therefore more switching inserts simply detect the position of the switch and translate them into the control state of the insert. The paddle in ON position will result in switching on the load and the paddle in OFF-Position will turn the load off. This mode realizes the intuitively expected behavior of a wall switch but does not allow to dim the dimmer into any dimming level except full on and full off and to set a controlled motor into any other position than the end position.
Furthermore a switching status change caused by a wireless command may contradict with the paddle position of the locally controlling conventional switch â€“ a situation known from the so-called hotel circuit where two switches can simultaneously control only one single light.
Wall inserts however have one big advantage over wireless wall switches. The design of the wall element remains unchanged. Wall switches are available in a series of different designs but conventional switches are available in many more design versions. In case there is no design available identical or similar to the rest of the installation a wall insert may be the only option to keep identical wall element design while enjoying the advantage of wirelessly controlled smart home functions.
All these facts result in some simple guidelines. Choose wireless wall switches if
- you have 35 or 45 mm wall boxes OR
- you do a complete new installation of all wall elements OR
- there is a wall switch that looks similar to your existing design.
Choose Wall Inserts if
- you have 65 mm wall boxes AND
- you already have installed wall switches in a certain design AND
- there is no wall switch available that matches your wall switch design.
5.1.4 Including everything into a single network
Unless there are very special requirements or super large networks all devices shall be included into one single wireless network. A Z-Wave network can manage up to 232 devices, however a typical amount of nodes in a fully equipped home is in the range of 50 to 80. This means there is plenty of room for future expansion and enhancements.
A Z-Wave network is built by a controller. There is always one single primary controller that is responsible for the network. In case there is an IP gateway available this IP gateway should be picked as main controller simply because the user interface is very convenient and the IP gateway offers backup and restore functions in case something goes wrong.
If no IP gateway is available, any other controller can act as primary controller and the role of the primary controller can also be handed over to a different controller when desired.
For the setup and the configuration of a network it may even be desirable to have different controllers to do the work. All inclusions can be done with a remote control as primary controller and the role of the primary controller is then handed over to an IP gateway for further operations. The IP gateway may however have to reconfigure all devices to make sure the wakeup interval targets are set correctly and all information generated during the device interview is available.
It is also possible to do it the other way around. An IP gateway of software may be very beneficial for the setup work even if the network is later only operated by wall controllers and remote controls. The software then acts as an installer tool just for setup and configuration.
5.1.5 Way to include Devices
The basic process of inclusion is described in chapter 3.1.3.
- The controller is turned into an inclusion mode.
- The new device is in factory default. It was not included into a different network or it was reset.
- Depending on the different methods of inclusion this inclusion needs to be confirmed on the device:
- The most convenient way is the so-called auto-inclusion. The device is just powered up to confirm inclusion. Typically a device remains about 30 seconds in the auto inclusion mode and will confirm any inclusion attempt by a controller in this time if the device was not yet included before.
- With the so-called network wide inclusion the device can be included being in every position in the home as long as there is at least one Z-Wave device of this network in wireless range.
- The standard inclusion requires to have the new device in wireless range of the including controller.
- The meanwhile almost obsolete Low Power-Inclusion requires the device to be in direct proximity (up to 50 cm) of the including controller.
- Technically the new device needs to send out a Node Information Frame to confirm inclusion.
When Z-Wave was developed in the early 2000 years, security considerations have driven the decision for the inclusion mode and a high hurdle for inclusion – the low power inclusion mode – was established.
After gaining more experience in the field the developers have realized that end users appreciate convenience more than a very high level of security. The first step was the standard inclusion, followed by the network wide inclusion and finally the auto inclusion function. However even in the auto inclusion function the user needs to be in physical possession of the device to complete the process. Even in case that he wants to include a device but the same time a neighbor was just a blink of a second earlier and ’got’ the device he is still able to exclude the device and repeat the process until his own controller included the new device successfully.
Wall controllers or remote controls typically have either dedicated buttons for inclusion (like shown in Figure 5.3) or they use a special key sequence to turn the controller into the inclusion mode.
The inclusion mode is indicated by a blinking LED or by any other reasonable way. The inclusion mode typically times out if no inclusion takes place. If the controller was successfully including a device, it will either terminate the inclusion mode or continue with the inclusion until the mode times out or a special button terminates the inclusion mode. The behavior depends on the manufacturers implementation. Please refer to the manual of the controller for further details
IP gateways or Z-Wave control software solutions follow the same process. They offer virtual buttons for inclusion and for exclusion and will indicate when the inclusion mode is active and when it was terminated. Figure 5.4 shows an example of a user interface of a Z-Wave software indicating that it is in active inclusion mode.
As mentioned before the new device needs to confirm the inclusion right on the device. Different ways are possible:
- Initial powering of the device confirms inclusion if this very device supports the auto inclusion function.
- Single click on a button of the device, e.g. the rocker.
- Triple Click of a button within a defined time. This time depends on the vendor and may be between 1 and 3 seconds.
- Keep a button pushed for some time.
Z-Wave does not specify the way an inclusion is to be confirmed. It is only mandatory that an inclusion of the device is possible and that the process to do this is described in the manual.
The auto inclusion and the single or triple click are a common way to confirm inclusion of a device. Nevertheless manufacturers are creative to find new and unexpected ways for the inclusion process. Therefore Z-Wave Plus – for information on Z-Wave Plus please refer to chapter 4.6 – has further limited the possible options to include a device. Figure 5.5 shows an example of a manual description of a inclusion process.
There are a couple of reasons why an inclusion can fail. The by far most frequent reason is that the device to be included was already included in a different network. The simple fix of this problem is to use the exclusion function of the controller to exclude the device first before it gets included again. Exclusion can be done by any controller not only the controller that was used for inclusion
5.1.6 Inclusion of Controllers
From the user point of view the inclusion of a controller by another controller looks like a normal inclusion of a device by the controller. However behind the scenes more information needs to be exchanged to get the new controller ’up to speed’ to be able to act as a secondary controller in the network. All the network information of the primary controller needs to be copied to the new secondary controller. This is why a controller inclusion is sometimes also referred to as controller replication. Figure 5.6 shows the process on the network level.
A controller is able to include a device as a primary controller or inclusion controller but at the same time the device can be included by a different controller as secondary controller in his network. Both processes must not be mixed. In case a controller has a dedicated button “inclusion” this usually means that the use of this button turns the controller into the inclusion more to include other devices. The mode to be included is therefore also referred to as Learn Mode. The manual of the controller shall provide information about both processes.
Figure 5.6 shows the process of including a controller as secondary controller. It is also possible to include a new controller into the network and hand over the primary controller function to this new controller. The process is the same but the primary controller needs to be turned into a special mode called Primary Change, Primary Shift or Controller Shift.
Primary Change The other controller needs to be in the learn mode as well and both modes will time out similar to the normal inclusion mode.
Please refer to the manual of the controller if and how this controller supports the ’primary change’ functions. Not all controllers support this function. Figure 5.7 shows the user interface of the software supporting this function.
Bring the prophet to the mountain or the mountain to the prophet?
Chapter 3.5.3 already explained the difference between the two main ways to organize networks: Explorer Frames and static update controller (SUC).
- the device to be included does not support Explorer Frame or
- the controller itself does not support Explorer Frame or
- there is no sufficient amount of Explorer Frame capable devices in the network to ensure routing of Explorer Frames,
the network will not benefit from the Explorer Frame and new devices MUST be in direct radio range to the including controller.
There are two options for this:
- Bringing all devices to the controller, include them and then install them in the final location.
- Installing all devices at their final location and use a mobile controller for inclusion into the network.
Option (1) means to always change the network right after a new device was included because this new device moves to a different location within the network. This requires a network rediscovery be performed right after the device was installed at its final location. The network rediscovery process will certainly manage all mains powered devices and update all routing tables accordingly but may fail for battery-operated devices for reasons mentioned in chapter 3.5.3. Additionally all devices that will be mains operated and powered by fixed wires in the wall need to be powered temporarily just for inclusion when brought to the controller location.
Option (2) requires a mobile controller. Even then the management of battery-operated devices remains an issue. The popular IP Gateway VERA from Micasaverde follows this approach.
What happens if I don’t care at all about all this SUC and Explorer Frame stuff?
Well, in 99% of the cases nothing will happen and the network will just work fine. However, according to Murphy’s Law it’s the 1% that will kick in at the wrong moment and the wrong place. So it’s recommended to understand what is going on behind the scenes to know what to do given a mixed set of devices and a network problem.
5.1.7 Inclusion of battery-operated devices
The big challenge of battery-operated devices is the deep sleep state. Once the battery is included the device should go right into deep sleep state but wake up when a button is pressed.
However, there are bad implementations of battery-operated devices that may cause trouble:
- They do not go into deep sleep right after batteries are inserted because they wait for an inclusion. If they get never included they will waste valuable battery lifetime.
- If nothing happens, they will go into deep sleep and not wake up anymore. It’s impossible then to include the device.
The certification process meanwhile ensures that all new devices behave properly, but in order to avoid confusion it’s recommended to follow these guidelines:
- Include every battery-operated device right after inserting the batteries. Make sure to configure a reasonable wake-up time before the device goes into deep sleep state for the first time.
- In case there is further configuration work needed set a low wakeup interval first but make sure that you configure a longer battery saving wakeup interval when all configuration work is finished. Alternatively it’s possible to wake up the device manually for finishing the configuration work.
- Do not include and configure multiple devices at once and don’t lose any time between inserting batteries and initial inclusion.
- A reasonable wakeup time is a trade-off between two goals:
- A very long wakeup interval will save battery capacity but may create problems in case of network rediscovery. The static controller may not receive anything from the battery device during the rediscovery and then assume the device as not functioning.
- A very short wakeup time helps the controller to keep track of the device but costs battery lifetime.
- The wakeup interval must be configured between the allowed boundaries. Refer to the manual of the manufacturer for more information about reasonable wakeup times. Reasonable wakeup intervals are between 15 minutes and a couple of days depending on the function of the device.
The second step after inclusion is the configuration of the device. For the reason and the general approach of configuration please refer to chapter 4.2.3. Changing configuration values in software or IP in gateways can be very efficient depending on the device type:
- Mains powered devices: right after saving or confirming the configuration parameter change in the user interface of the configuration tool.
- FLIRS devices: right after saving or confirming the configuration parameter change in the user interface of the configuration tool.
- Battery-operated devices with periodical wake-up: After the new configuration parameters are saved in the software the device needs to wake up. This may take as long as the defined wakeup interval. Attention: If the wakeup interval was changed, the device is still in deep sleep for the time period of the previous setting. Only after successfully sending the new wakeup interval setting to the device the device will change its wakeup behavior. It is possible and recommended to manually wake up the device to speed up the process. Please refer to the manual of the device how to manually wake up the device.
- Battery-powered portable controller: After the new configuration parameters are saved in the software the devices need to be manually woken up in order to allow the controller to store the new configuration values in the device.
Certain devices will not wakeup if wakeup is not configured correctly. If they don’t know where to send the wakeup notification to they will simply stay quite. Other devices solve the situation by sending a wakeup notification as broadcast command. As long as the primary controller is within wireless of the device waking up this will work fine.
5.1.9 Association and Scenes
It’s possible to mix scenes and associations but it is recommended to stay with one system just for simplification.
Associations make much sense when there are simple and direct control relationships such as motion detector light. It would only make the whole system more complicated to have this relation done using a gateway scene. Additionally, the direct control relationship between the motion detector and the light is more reliable – simply because there is less communication involved.
As soon as there are more complex switching setups needed scenes in gateways are the better choice.
Similar to configuration settings also association settings need to be stored in the device before they become effective. For the different behavior on when this will happen after storing the association in the installer tool or IP gateway please refer to chapter 5.1.8.
5.2 Housekeeping – How to get a stable network?
Z-Wave is a quite robust wireless network that will work out of the box. Nevertheless there are some housekeeping rules and guidelines to be taken into account. They are intended to make the network more stable and more robust.
5.2.1 Radio Layer
Here are some tips to avoid problems on the radio layer:
- Avoid metal wall boxes whenever possible. It is possible to run Z-Wave within a metal box but it may attenuate the radio signal. There are vendors that have designed products particularly for application in metal boxes but the majority of products may have problems in such an environment.
- Check the minimum wireless range and follow the recommendation given in section 2.3 in regard to radio shadow, installation height, reflection etc. Try to position all devices with a minimum distance of 30 cm from large metal constructions.
- The fact that a Z-Wave network works properly during installation is no guarantee that it will work 24/7. There are plenty of ways to change the radio signal situation in a home. Even small changes like moving furniture or opening/closing a door may have impact. This is rare but not impossible.
Certain installer tools or software solutions visualize the routing table of a network. They show whether or not two nodes have a direct radio link. Certain tools also measure the round trip time of radio signals to estimate the quality of a radio link.
5.2.2 Z-Wave Networking and Routing
To get a stable network that works well according to user expectation there are some general goals to be met:
- Avoid any traffic to nodes that will not respond anymore.
- Avoid any unneeded traffic to keep the air free for the real important messages.
- Make sure all devices always know how to communicate to each other.
This translates into the following practical recommendations:
Exclude devices that are no longer needed or that are moved outside the network. If one device it taken from the network – e.g. a wall plug by just unplugging – the device should be excluded from the network. Otherwise this device is not reached anymore and will create overhead traffic until it’s marked as failed.
- If a device is obviously failed or broken, remove it from the controller. Controllers typically have functions to remove failed nodes.
- Don’t forget to remove all disappeared nodes from all association groups where they were once included. The device having this association group will otherwise always try to communicate with these lost devices creating delay and waste valuable battery lifetime.
- If a device is moved within the network, a network reorganization is always needed.
- Try to avoid longer routes since they increase the chance of routing failures. Z-Wave allows routes up to 4 hops (refer to chapter 3.2 for details) however longer routes with more than 2 intermediate nodes tend to be unstable.
- The worst-case scenario for the routing algorithm is a device that is just in wireless range but drops out of direct range from time to time. Whenever the device is in direct wireless range the direct range communication will be preferred and all other routes are discontinued. Whenever direct range does not work anymore the algorithms will need to redetect a valid route again causing a lot of traffic in the network.
- Reduce polling intensity. Every controller will poll all nodes from time to time to see if they are alive or to call certain status values. It is desired to poll very often to always have very updated values available in the controller. Heavy polling however creates a lot of traffic in the network and should therefore be limited. Some controllers only allow to set polling intervals for the whole network while others even allow to define polling behavior for every device. Figure 5.8 shows a user interface of the IP Gateway VERA that allows to set polling intervals for every device.
(a) Choose the poll time that is reasonable. It’s not recommended to pull more often than once per minute, even 5 minutes is a very reasonable number.
(b) Don’t poll FLIRS devices.
(c) Try to enable unsolicited reporting of sensor values wherever possible. Most metering devices (power, temperature) allow to be configured so that they send sensor updates frequently or when changes occur. Make heavy use of these functions and limit the polling of the corresponding command classes.
(d) Sensors report the value of the actual moment while meters accumulate values. Meters should therefore not be polled more often than once per hour or even less.
(e) If there is already one device class polled delivering the status of a device ï¿½ e.g. switch binary command classes for a binary switch, there is no need to poll additional command classes – e.g. the basic command class- to get the very same value.
Network reorganization is also a good prevention tests and it is recommended after any change of the network (include device, exclude devices, remove failed nodes, move nodes). Please be aware that changes in the environment such as new furniture may also change the wireless communication environment. A regular network reorganization is therefore a good practice to keep the network healthy and stable. The net-net of these recommendations are:
Avoid metal surfaces closer than 30 cm.
- Use Explorer Frame capable device as much as you can.
- Avoid wireless links that are at the edge of direct wireless range.
- Get rid of all devices not used anymore.
- Perform a network reorganization after every change of the network.
5.3 Known Problems and Trouble Shooting
In general Z-Wave is a very stable and easy to use technology. However, it needs to be taken into account that users have to deal with technologies of different manufacturers, different quality of documentation and different quality of products.
Z-Wave guarantees interoperability but not quality.
With over 1000 different products introduced over the course of 10 years there are certain differences in functionality of devices. Here is a list of typical challenges, pitfalls and problems:
5.3.1 Mismatch of Language
The Z-Wave alliance enforces the use for common language for the most critical processes and functions of Z-Wave:
- Inclusion and Exclusion
- Meshing and Routing
Every term beyond this short list may be interpreted differently by different manufacturers. Manuals in other languages than English bear another reason for confusion, since local language translations even of the core terms of Z-Wave are not monitored and controlled by the Z-Wave Alliance.
5.3.3 No forward compatibility
Um die Benutzung von Z-Wave-Geräten zu vereinfachen, haben manche Hersteller – besonders von Fernbedienungen – die Schritte Inklusion und Assoziation in einem einzigen Schritt miteinander verbunden. Diese Produkte ermöglichen dann die Inklusion eines neuen Gerätes in eine Gruppe. Dies ist die Beschreibung zum Setzen einer Assoziation. Erfahrene Nutzer werden hier den ersten Schritt – die Inklusion vermissen und sind verwirrt. Die Kombination aus zwei ohnehin nacheinander durchzuführenden Schritten ist keine schlechte Idee – sie muss nur entsprechend beschrieben werden.
5.3.3 Keine Vorwärts-Kompatibilität
The core value of Z-Wave is interoperability. This is maintained among others by making sure that all new devices are backward compatible to existing products. As a result it is still possible to use a first generation product that is 10 years old in todays modern networks. Taking into account the product life cycles in information technology this is a remarkable achievement. Figure 5.9 shows one of the first Z-Wave products of the first generation, developed in the early 2000s. It’s no longer in production but the device will work well even in modern networks and can be controlled by any Z-Wave controller that was ever designed.
However, compatibility is only a one-way street. It’s impossible to develop products that will be compatible to functions that will be invented in the future. This does not violate interoperability and compatibility but may be perceived as such.
A remote control developed in 2007 is able to operate switches, dimmers and control motors to move blinds or doors. It was certified and works well. In the 2009/2010 time frame a new category of lighting devices becomes available – multi color LEDs. Multi color LEDs can adapt the temperature of the light to the user needs or can be turned into almost any color imaginable.
The Z-Wave alliance has reacted to this new product category and has specified a way how Z-Wave controller can define the color of a multi-color LED. This command class Color Control Command Class was finalized in 2010 and right after finalizing the first products using this technology were hitting the streets.
The multi-color-LEDs are backward compatible. They can still be switched and dimmed the way a light was switched or dimmed before. A user can use his old remote control to dim and switch the LED but he can not choose the LEDs light color by this remote control because this color picking function did not exist when the remote control was developed. Users may perceive this as incompatibility.
5.3.4 Multi Channels versus Multi Instances
There is no rule without exception and while Z-Wave maintains backward compatibility at no compromise, the exception is called Multi Instance Command Class. Here is the story:
Initially it was assumed that every device only has one function of its kind. A switch device has one relay, a dimmer device has one dimmer. Later on it became obvious that it makes sense to have similar functions in one device. A good example would be a power strip where all the outlets shall be switches. The power strip shall be controlled by one single Z-Wave transceiver but the Switch Binary command class does not support multiple switching functions.
In order to maintain backward compatibility of all devices supporting and controlling binary switches another command class was introduced that allows differentiating multiple instances of a device. This device class was called Multi Instance Command Class.
After the introduction of this command class it turned out that the command creates more problems than it solved and quickly a second version of the command class was developed. To differentiate from the first version it was called Multi Channel Command Class. For some intermediate time devices with the Multi Instance Command Class were still accepted in certification but meanwhile the command class is really abandoned and must not be used anymore. Fortunately, only very few devices were ever introduced using the old Multi Instance Command Class, among them however a lot of devices from the German manufacturer Merten, now part of Schneider Elektrik.
As a result there are quite a few incompatibilities between Multi Instance Command Class products and all other Z-Wave products. Very few gateways – like Z-Way from z-wave.me[Fehler! Verweisquelle konnte nicht gefunden werden.] – support both Multi Instance Command Class and Multi Channel Command Class but the majority just ignores the old Multi Instance Command Class.
Together with the introduction of the Multi Channel Command Class a new command class for handling associations with these devices was needed. The Multi Channel Association Command Class extends the normal Association command class allowing to set different instances of a device into an association group.
5.3.5 Sins from the past
When Z-Wave was introduced to the market in the early 2000s, the certification was less strict so that devices were certified that would not get a certification granted anymore. These old devices may create problems because they simply don’t follow the standard in all aspects. Fortunately, these products more and more disappear. However, some of them may still be around. Appendix 9 points to an online resource of a black list of products that fall into this category. The vast majority of these products are in the list because of missing support of Multi Channel Association Command Class as just explained above
Smart Homes are at the intersection of two different worlds. On the one hand there is the conservative world of facility management, house installation and installers. They don’t have the intention to ’play’ with products for too long. Their technology is stable and well proven.
On the other hand there is the information technology and here namely the software business. Here we see frequent product updates, software patches and release changes.
IP gateways certainly belong into the group of IT equipment. Frequent software updates, feature enhancements, bug fixes etc. cause a constant change of the system if the user wants to follow all the updates. It’s not uncommon that a firmware for an IP gateway gets released just followed by another one after few days fixing a bug that was just introduced in the first place.
5.3.7 Weak Check Sum
Chapter 3.1.5 describes the Checksum algorithm used in Z-Wave and discusses the weakness of the legacy solution. Particularly for data collection and large messages the weak checksum results in wrong transmissions from time to time. Z-Wave has therefore introduced a new system that protects metering and sensor data with another 16 bit strong check sum. In order to use this new strong protection of data both the device and the controller need to support it.