Your Guide to a User Friendly & Stable Z-Wave Network

THE GUIDE TO A USER FRIENDLY & STABLE Z-WAVE NETWORK

In the last guide, there was plenty of information about Z-Wave’s network, nodes and devices. In this guide, we look deeper in to the controllers and the server which controls your home wireless communication system. With so many potential components, and electronic messages operating wireless, it is important to achieve a user friendly and stable Z-Wave network in your home.


Static Update Controller (SUC) and SUC ID Server (SIS)

If there is one primary controller in the network, it will hand over its routing table, to every secondary controller included. After the next inclusion or exclusion of a device, by the primary controller the routing tables of all secondary controllers become invalid.

To make sure that there is at least one updated and valid routing table only, the primary controller shall have the privilege to include/exclude devices. For a secondary controller it is always possible to request an update of his routing table.

The requirement for a user friendly and stable network is, that:

  • Every battery operated mobile controller shall be able to include devices.
  • The routing tables of all controllers in the network are kept consistent and an update shall allow every controller to control every device in the network.

This goal is accomplished by activating a SUC /SIS controller in the network.


Static Update-Controller (SUC)

The Static update controller (SUC) is a special function of a static controller. Most static controllers (a controller with fixed location and powered by mains) can perform as an SUC. However, the function typically needs to be activated first.

The SUC receives the updated routing table from the primary controller and offers this routing table to all other controllers in the network. Because the SUC is a static controller and therefore always active in the network, any other controller can frequently request an updated routing table from the SUC.

To make sure that all other nodes and particularly other controllers are aware of the presence of a SUC in the network, the Node ID of an activated SUC is communicated within the network periodically.

Having an active SUC in the network allows you to keep the primary controller role on a portable controller. Every change of the network caused by inclusion or exclusion of a node by the primary controller will be reported to the SUC and is then available to all other controllers, even if the primary controller is not active.

Since most of the controllers are battery operated and therefore not active all the time, these controllers have to request an updated routing table periodically or at least when woken up, by pressing a button. To perform this task the mobile battery operated controllers need to be informed about the presence of a SUC in the network.

If the original – mobile – battery operated primary controller is lost or damaged, the SUC can assign the primary privilege to a new mobile controller, protecting the user from re-establishing the whole network with a brand new primary controller, and having a different Home ID.


Static ID Server (SIS)

Even a SUC in the system does not solve the problem that only one controller has the primary privilege and can include new devices. This limitation is overcome by enhancing the SUC functionality by another function called ‘SIS‘ = Static ID Server.

The SIS acts as depot for new Node IDs which can be assigned by mobile controllers. Having an SIS present in the network allows every controller in the network to include a further device. The controller will just request a new node ID from the SIS and assign this new Node ID to the server. With the SIS it is made sure that no two nodes get assigned the same node ID. The only requirement is a mobile controller needs to fulfil in order to include new devices, is that it has a network connection to the SIS server to request a node ID.

This kind of configuration with server SIS has following advantages and disadvantages:


Advantages:

  • The actual network topology and the information about all nodes are saved in a static controller and are therefore better protected than within a mobile battery powered device.
  • All controllers in a network can integrate new devices.
  • The network configuration and handling becomes very flexible.


Disadvantages:

  • Function is available only from the firmware version 3.40. It is possible that there are some devices in the network with older firmware which do not support this configuration.
  • Inclusion controller can integrate only devices if it has a wireless connection to the SIS.
  • With the SIS there exists a "Single Point of Failure". A damaged SIS result in a complete new network setup.

Since the SUC/SIS functionality is already included in the firmware of most modern static controller, or a USB dongle, most Z-Wave networks can take advantage of these functions if a static controller is present. However, this function needs to be activated.

A static controller can also be a primary controller, as well as have SUC/SIS functionality. This configuration is typical in real networks.


Networks with portable slaves

If an SUC controller is present in the network it is able to determine a new position of a slave and update the networks routing table accordingly. The procedure to achieve this is called in Z-Wave terms “Get Lost –Algorithm” and only works for routing slaves.

A normal slave is not allowed to send unsolicited messages and can therefore never determine any change of its position in the network, since no unsolicited message can fail. Routing slaves however have this ability.

If the sending of an unsolicited message from a routing slave fails, this routing slave will conclude that its routing table is not longer valid.

As a first step this node will send out a broadcasting message to anybody with a “cry for help” message. A node which received an unsolicited “cry of help” message knows that the sender of this message has found itself in a new location. This node, however, is not possible to help the crying node with an updated routing table. If this node is also a routing slave and does have routing information about how to reach the SUC in the network, it will forward the “cry for help” message to the SUC.

The SUC can update its own routing table and assign new routes to the crying node by performing the same steps he would do when including the device. The “cry for help” message is able to auto-heal a network incase a node has been moved.

In order to have a working auto-healing function within the network, the following requirements need to be fulfilled:

  • A SUC need to be present in the network;
  • The moved nodes must be a routing slave not a standard slave;
  • In the new position there must be at least one routing slave in range;
  • The moved node must detect that he was moved. This is only possible if this node sends out an unsolicited message.


Copyright 2012 Vesternet Ltd.