ZWave SUC Controller Mode

Most documentation I've seen seems to indicate that having an SUC in the network is useful to help keeping the network running properly, and healing properly...

The Zensys doc makes the following statements about static controllers (which is generally what most people have for openHAB - it's simply a controller that doesn't move).

---

Static Controller

The Static Controller is required to remain in a fixed position in the network, meaning that it should not be physically moved when it has been included in the network. Moreover it is required that the Static Controller is always in “listening mode” and it must therefore be mains powered. Other alternatives include mains-powered with battery backup as well as running from a large battery which regularly recharged or replaced.

The “always listening” advantage of the Static Controller allows other nodes to transmit frames to it whenever needed, both for uploading purposes as well as for consulting purposes. The Static Controller also exists in two variants used for more advanced installations. Both variants are described more thoroughly in the installation example chapters (4, 5):

Static Update Controller (SUC)

When a Static Controller is configured as a SUC, the primary controller automatically sends network updates to the SUC, e.g. when a new node is included to the network. The node will therefore automatically appear in the SUC’s topology map. Other controllers in the network may individually request a network topology update from the SUC. If no SUC is present the Primary Controller is responsible of updating all controllers in the network, which will typically be a manual process for the end-user. The SUC is capable of creating a new Primary Controller in case the original Primary Controller is lost or malfunctioning. There can only be one SUC in each individual network.

SUC ID Server (SIS) When a SUC is also configured as a node ID server (SIS) it enables all other controllers to include/exclude nodes. The SIS automatically becomes the Primary Controller in the network when enabled. There can only be one SIS in each individual network. To avoid inconsistency, all node ID allocations are maintained by the SIS.

---

Information from Vesternet says -:

** Networks with Portable Slaves 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:

• A SUC needs to be present in the network.
• The moved nodes must be a routing slave not a standard slave (to allow unsolicited messaging).
• 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.

---

Enabling SUC mode

SUC mode can be enabled within the binding by setting the zwave:setSUC=true line in the openhab.cfg file. This simply enables the SUC functionality in the controller - the binding doesn't do anything different other than enabling this function.

---

Recommended usage

Normally you would want your openHAB controller to be set as both the master (zwave:masterController) and as a SUC (zwave:setSUC). This will allow openHAB to include devices into the network, tells openHAB to configure the devices to send reports to openHAB, and allows the openHAB controller to respond to network topology update requests from any controllers that request it. (e.g.: scene controllers, secondary Z-sticks, etc.)