Leviton ViziaRF

This driver is for the Leviton ViziaRF lighting control system using the VRC0P-1LW Plug-In Serial Interface Module.

Release History

1.0 Initial release of the driver

1.1 Added support for non-Leviton (Tested with Cooper Wiring Devices AspireRF dimmers) dimmers and switches.

Added support for door locks (Tested with Kwikset and Yale locks).

1.11 Added Get Node Status, Get Lock Status, and Get Lock Battery Levels driver commands.

Re-arranged node and lock query routines in driver.

1.12 Fixes issue where node and lock mapping doesn't initialize, therefore hindering operation.

1.2 Added waiting for response variables for door locks.

Disabled variable writing without a response from door locks.

Added Lock Battery Low, Critical, and Too Low variables and events.

Config Settings

RS-232 Serial Port Settings

The RS-232 connection on the Leviton Plug-In Serial Interface Module (use supplied RS232 to CPU cable) should be connected directly to the processor serial adapter; a null modem is not required.

Serial Interface Node ID

Enter the node address assigned to the Plug-In Serial Interface Module.

Node Mapping

Node mapping is used for re-assigning node addresses. By default all mapping slots are set to the appropriate node (I.E. Node 1 slot = 1, Node 24 slot = 24, etc).

Re-mapping example:

Node 5 Slot = 12

Node 12 Slot = 5

The above example would re-route all node feedback from the physical node 12 to node 5 and vice versa in the driver. Driver control for the physical node 12 would then use node 5 as the control node. This re-mapping allows for quick changes in the event of a switch/dimmer hardware failure. By remapping, the system programming is kept to a minimum as only the configuration needs to be updated along with a download to the processor. The user interface/s can be left untouched as long as the device was replaced with the same type of device.

Lock Mapping

Lock Mapping is used for mapping the node assigned to a lock to a lock slot. Door Lock Control driver commands and Variables should follow the Lock Mapping slot number and not the actual Node ID of the lock.

Lock Mapping example:

Lock 1 Slot = 22

Driver commands for Door Lock Control would then be configured with a 1 in the Mapped Lock Slot ID in order to control the lock using Node ID of 22. Driver variables to be used for Node ID 22 would then be the variables for Lock 1.

Driver Notes

- All dimmers/switches and door locks need to be associated to the Plug-In Serial Interface Module for unsolicited feedback to work. These settings can be found in the RS232 setup of the Vizia VRCPG documentation (lighting only) or under Diagnostics/RS232 Setup in the Vizia RF + Installer Tool Software (lighting and door locks).

- Feedback variables are provided for Node Status, Node Level, General Lock Status, Advanced Lock Status, Lock Battery Level, Lock Battery Notifications, and Lock Waiting for Response.

- Store Scene and Recall Scene Node IDs must match for proper operation.

- The Node ID in the first position of a Group Control command is the ID used for feedback. If Group Set Level or Group Ramp Level is to be used, make sure the Node ID in the first position of the command is that of a level capable device (dimmer).

- Initial feedback for lighting is performed by the driver to help with response speed. Once the command is executed, an update command is sent to the Leviton Plug-In Serial Interface Module. The module should then respond with the final feedback status for the command which was just performed.

- When using door locks outside of the RF range of the VRC0P-1LW Plug-In Serial Interface Module, the device (hopping device) which the lock communicates through must have Zensys firmware of 4.52, 4.53, or 5.02. Example devices are Leviton's ViziaRF+ plug-in lamp modules, Leviton's ViziaRF+ 4 button zone controllers, and Leviton's ViziaRF+ 4 button scene controllers.

- When executing door lock commands (toggle, lock, and unlock), each lock has to verify a secure connection with the Plug-In Serial Interface Module independently. The secure connection process time may vary so it is recommended there be a delay between sending lock commands. In most circumstances this will not be an issue with individual lock control, but when lock controls are included in macros and delays are not set correctly, some lock commands may not execute.

- When executing door lock commands for lock and unlock, the General Lock Status variable for the respective lock is tested. If the command being executed already matches the variable, IE lock is sent but the door lock is already locked, the command is not sent. This helps minimize false status results for the Waiting for Response variables.

- Lock Waiting for Response variables are set when a command is sent to a lock. The waiting variable is cleared when the lock responds whether or not the response pertains to the command that was sent.

- Lock Battery Low, Critical, and Too Low variables and events have been implemented as the protocol supports them, but they have not been verified as operational with the test locks used during driver development.

- Driver commands for Get Node Status, Get Lock Status, and Get Lock Battery Levels are to be executed upon necessity and should not be used on a regular basis. Due to the nature of the ViziaRF system these are not performed during the driver initialization. Recommended use would be for battery level updating to be performed daily via a daily event or periodic event. Keep in mind that when a node or lock is operated a status query is sent shortly after the device has been operated. Battery level updating is only performed when the Update Lock Battery Levels command is executed. If nodes or locks are included in the command, but cannot be found on the system (are offline, have poor reception, not configured properly), the system may freeze up and require a reboot. Make sure all devices are online and working before adding them to the updating commands.

- Driver query routines have been re-organized so door lock queries have priority over standard node queries. This means that if a number of lights are turned on and waiting for final feedback and a lock is operated, the lock query routines will interrupt the standard node query routines. Once the lock query routines are finished, the standard node query routines will continue until completed or interrupted again.