|Moderated by: slychiu||Topic closed|
|This information is also found in the UCM/Zwave Manual which can be downloaded from http://www.cytech.biz/ucmzwave_manual.html
The Z-Wave network can have up to 232 nodes. Each Network has a 32-bit Home ID. Nodes can be either Controllers, or Slaves.
Controllers can be either Primary or Secondary. There can be only 1 Primary controller which is usually a remote control or PC-based device, whose role is to set up and manage the network. Secondary controllers receive the network information from the primary controller.
Z-Wave Slaves nodes are either Basic or Routing Slaves. Routing Slaves are able to transmit information or commands to other Z-Wave enabled devices without being requested to do so while Basic slaves can only send information when requested to do so. For example a Z-wave appliance module which is a basic slave may have a local button to toggle switch the connected device, but this will not send the status information to the network, whereas a Routing Slave will be able to do so.
Each node on the network is assigned a Node ID by the Primary Controller
The UCM/Zwave3 is a Secondary Controller in the Z-Wave network and has a Bridge Controller function. A Bridge Controller is a static controller that is able to represent up to 128 Virtual Nodes in the Z-wave Network. Note that Virtual Nodes will reduce the nodes available for the rest of the network, as the total number of nodes are limited to 232. Virtual Nodes are assigned to the UCM/Zwave3 which act as Slave nodes, allowing controllers and Routing Slaves to send commands or information to the virtual node.
Z-Wave Operations and Terminology
The following operations must be performed by the primary controller.
A new Z-Wave device must first be included in a Z-Wave network by the Primary controller. It is assigned a Node ID.
This is the process of copying the network information (Ids and routing) from a Primary to a Secondary Controller.
This is the process of linking a source Z-Wave ID (controller or routing slave) to a target ID (Slave) so that pressing the controller or routing slave button controls the slave. Many Z-Wave Ids can be associated to a Slave.
This is the process of removing the association between source and target.
This is the process of removing a Zwave Node from a network.
|Bridge Controllers and Virtual Nodes
A Bridge Controller in Zwave terminology is a controller which is able to create Virtual Nodes
A Virtual Node is a node in a Bridge Controller that appears like a physical node to the rest of the Zwave network. The purpose of a Virtual Node in the UCM/Zwave is to allow other zwave devices to associate with the node. This allows zwave nodes to send commands to Comfort.
Virtual Nodes in UCM/Zwave can be mapped to Counters, Flags, Outputs, Sensors, Arm, Panic functions, or Virtual Inputs
Virtual Inputs allows Zwave motion and door sensors to behave like a Physiacl Input in Comfort, ie they can trigger alarms depending on the Comfort zone type and security mode
Mapping Virtual Nodes to Counters will cause the Counter value to be updated and the Counter Response to be triggered
Mapping Virtual Nodes to Sensors will cause the Sensor value to be updated and the Sensor Response to be triggered
In Zwave, a device does not automatically send its status across the network when it is changed. For example, if a Zwave lighting switch is manually operated, other devices which are monitoring its status will not be informed about the change. The controller has to poll the device for its status in order to know the status. However constant polling is not permitted as it would cause excessive RF traffic and could cause communications to be lost. The UCM/Zwave 7.072 and above handles this problem by implementing "Smart Polling" which means that the Zwave devices are polled only when an application is using Comfort to look at the Zwave status.
To enable smart polling, set the Poll time to 0
This is the best possible solution to the Zwave limitation.