5 Star Service
In the last guide, there was plenty of information about Z-Wave’s network, nodes and devices. In this guide, we look more deeply at the controllers and the server that controls your wireless home automation 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.
If there is one primary controller in the network, it will provide its routing table, to every secondary controller included in the network. However, the next time the primary controller includes or excludes a network device, the routing tables of all secondary controllers becomes invalid.
To ensure there is a single updated and valid routing table, the primary controller is the only device allowed to include/exclude devices. Secondary controllers then periodically request a routing table update.
However, for a user-friendly Z-Wave network we would expect that:
The best way to accomplish this is to configure a SUC /SIS controller in the network.
The Static Update Controller (SUC) is a special function of a static controller. Most static controllers (a controller with fixed location and mains-powered) can perform as a SUC. However, this functionality normally needs to be activated.
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 regularly request an updated routing table from the SUC.
To make sure that all other nodes, particularly other controllers, are aware of the presence of a SUC in the network, the Node ID of an activated SUC is periodically communicated within the network.
SUC in a Z-Wave Network
Having an active SUC allows a portable controller to perform the role of the primary controller. Every change of the network caused by inclusion or exclusion of a node by the primary controller will be reported to the SUC, this is available to all other controllers, even if the primary controller is not active.
Update of the SUC Routing Table
Since most portable 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, usually by pressing a button.
If the original portable 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.
Even having a SUC in the system does not solve the problem that only one controller has the primary privilege and therefore, is the only controller allowed to 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 that can be assigned by mobile controllers. Having a SIS present in the network allows every controller in the network to include devices. The controller will just request a new Node ID from the SIS and assign this new Node ID to the server. The SIS ensures that Node IDs are only assigned to one node - avoiding conflicts. The only requirement is that mobile controller has a network connection to the SIS server in order to request a Node ID.
SIS Server in a Z-Wave-Network
Using a SIS in your network as a number of advantages and disadvantages:
Since the SUC/SIS functionality is already included in the firmware of most modern static controllers, or USB dongles, most Z-Wave networks can take advantage of these functions if a static controller is present (as long as you activate it).
A static controller can also be used as a primary controller, as well as having SUC/SIS functionality. This configuration is typical in real networks.
Controller rules shown in a Gateway User Interface
If a SUC controller is present in the network it is able to determine a new position of a slave and update the network’s routing table accordingly. The procedure to achieve this is called “Get Lost –Algorithm” and only works for Routing Slaves (slaves that have some knowledge of the network’s routing information).
A normal slave is not allowed to send unsolicited messages and therefore, can never determine any change of its position in the network. However, Routing slaves are allowed to do this.
If a routing slave sends an unsolicited message that fails, it will assume that its routing table is no longer valid.
As a first step this node will send out a broadcast “cry for help” message to the network. A node that receives this message knows that the sender has found itself in a new location. This node, however, cannot provide the “crying” node with an updated routing table. If this node is a routing slave 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 it would do when including the device. The “cry for help” message is able to auto-heal a network in case a node has been moved.
In order to have a working auto-healing function within the network, the following requirements must to be fulfilled:
Hopefully this has given you an good insight into how to create a stable and robust Z-Wave network.
Vesternet is Europe’s leading home automation specialist, take a look at our huge range of Z-Wave products.
Copyright 2012 Vesternet Ltd.