Tag Archives: controller

CH ZWave Server is almost ready to hit the road

The ZWave protocol is not complicate at all but every Home Automation solutions seem to rely on the (excellent?) OpenZWave library.
Even the AllSeen Alliance based their framework AllJoyn over it and Microsoft included the framework into the official ISO of Windows-IoT.

I decided to write from scratch my own implementation to be able to troubleshot and manage things a bit more directly and to learn something more about the ZWave and whole home automation scene.

I’ll try to release a working version before Xmas 2015.
The application will be able to manage every ZWave controllers  that expose a virtual serial port and it will run over Microsoft Windows; typically an USB Stick. Im using for my tests the excellent AEOTEC ZW090A (Ill do a linux port at some point ).
Link to another post for my initial impressions about the key.

It should be able to manage
1. “learn mode” : inclusion and esclusion of the USB STICK as a secondary controller.
2. “add node” : include new devices to the zwave network.
3. “remove node”: esclude devices from the zwave network.
4. “Recognize BINARY SWITCHES, receive feedbacks and send commands.
5. “Recognize BINARY SENSORS, receive feebacks.
6. Dinamycally monitoring Windows virtual serial ports.
7. Reset the ZWave configuration of the USB STICK.I will implement shortly other neat features (expose the devices over the network for user friendly clients, more complete support of the ZWave protocol, more devices).


Difference between SUC and SIS controller

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 device. 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 as signed 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 I D to the server. With the SI S it is made sure that no two nodes get as signed 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 the following advantages and disadvantages:


  • 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.


  • Function is available only from the firmware version 3.40. It is possible that there are some devices in the network with older firmware that 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.