What is Driver Wizard, and how is it different than DriverWorks?

What is DriverWorks?

2012-08-23T21:39:21Z

DriverWorks is the API used by installers / developers to create protocol drivers for 3rd-party devices. DriverWorks drivers are written in a language called Lua. Lua is a powerful, fast, lightweight, embeddable scripting language, that Control4 has embedded into it's driver architecture. The use of Lua allows development of drivers without having to compile drivers within Control4's C++/C# development environment. DriverWorks drivers are typically Protocol drivers, which translate between proxy drivers and a device's protocol. In order to do that, drivers typically use functions from the Proxy and Network or Serial interfaces. [b]PROXY INTERFACE[/b] A DriverWorks driver sends and receives messages from the proxy through the DriverWorks Proxy interface: ReceivedFromProxy(idBinding, strCommand, tParams) C4:SendToProxy(idBinding, strCommand, tParams) When a proxy sends a message to a DriverWorks protocol driver, the driver's 'ReceivedFromProxy' function gets called. Passed into ReceivedFromProxy are 3 parameters, a binding ID, which tells which proxy sent the message, a string command, and a Lua table of parameters. Here's a simple example of a ReceivedFromProxy function declaration: function ReceivedFromProxy(idBinding, strCommand, tParams) print("ReceivedFromProxy[" .. idBinding .. "]: " .. strCommand) if (tParams ~= nil) then for k,v in pairs(tParams) do print(k,v) end end end This example prints out the command and all parameters received from a proxy into the 'Lua Output' window in ComposerPro. The SendToProxy call is used when the protocol driver has notification information (state change) to send to the proxy. Here's a simple example of SendToProxy, sending information that the level of a particular light has changed to 33: C4:SendToProxy(5001, "LIGHT_LEVEL_CHANGED", {LEVEL = 33}) [b]NETWORK INTERFACE[/b] DriverWorks provides a simplified method for sending and receiving network (TCP/UDP) data. The connection for that data is transparent to the driver. The driver creates a network binding in the XML portion of the driver, and then uses the following network functions: ReceivedFromNetwork(idBinding, nPort, strData) -- Data has come in on the network binding / port C4:SendToNetwork(idBinding, nPort, strData) -- Send data out the network binding / port Data sent and received through the network interface functions is 8-bit safe, and could be binary data. [b]SERIAL INTERFACE[/b] DriverWorks also provides a simplified method for sending and receiving data over a serial (RS-232) connection. Similar to the Network interface, a serial binding is created in the XML portion of the driver, then the driver uses the following serial functions: ReceivedFromSerial(idBinding, strData) -- Data has come in on the serial binding C4:SendToSerial(idBinding, strData) -- Send data out the serial binding Data sent and received through the serial interface functions is 8-bit safe, and could be binary data. [b]EXAMPLE[/b] UI <----> Proxy Driver <----> Protocol Driver <----> Device (Navigator) (Light) (DriverWorks Driver) (3rd-party light) * A user presses 'Toggle' for a light on the Navigator UI. * A 'TOGGLE' Proxy command gets sent to the Light proxy driver * That command gets sent on to the protocol driver, whose 'ReceivedFromProxy' function gets called. * Inside the ReceivedFromProxy Lua code, the driver translates the TOGGLE command into the device-specific protocol, and sends it to the device using C4:SendToNetwork. * The device toggles, which changes it's light's state. The device sends a message to the protocol driver over the network. * The Protocol driver's 'ReceivedFromNetwork' function gets called. * Inside the ReceivedFromNetwork Lua code, the driver parses the protocol driver's message, retrieves the light level, and sends a notify to the proxy, using C4:SendToProxy. This is the major part of what a typical DriverWorks driver does. It receives messages from proxies, and sends them on to devices. It receives messages from devices, and sends them on to proxies, translating the messages each way. --------------------------------- More information about Lua can be found here: http://www.lua.org The DriverWorks SDK can be downloaded from the Cisco Automation Solutions 'Getting Started' page: [url=../../../web/as/start]http://developer.cisco.com/web/as/start[/url]

What is a Proxy driver?

2012-08-23T21:33:43Z

In Cisco Smart+Connected Home architecture, there are 2 types of drivers: Proxy drivers and Protocol drivers. [b]PROXY DRIVERS[/b] Proxy drivers are used to provide a consistent interface for UI devices. An example of a proxy driver is 'light'. The Light proxy provides a consistent set of commands and notifies, which can be used by Navigator to provide UI for a single light-type device (typically a dimmer or switch). Some examples of the commands that the Light proxy provides to the UI include: ON, OFF, TOGGLE (no parameters) SET_LEVEL (LEVEL: 0-100) RAMP_TO_LEVEL (LEVEL: 0-100, TIME: 0-100000 MS) The main notify that the Light proxy expects to receive from the device is LIGHT_LEVEL_CHANGED (LEVEL: 0-100). These proxy commands and notifies allow the Navigator UI to control *any* light, regardless of whether it's a Control4 light, a Lutron light, a Vantage light, or another 3rd-party light. With the proxy, the UI (Navigator) does not need to know the type of light to be able to control it and receive feedback. [b]PROTOCOL DRIVERS[/b] Protocol drivers translate between the proxy drivers' commands and notifies, and the device's protocol. Protocol drivers for 3rd-party devices are written in DriverWorks. [b]PROXY/PROTOCOL EXAMPLE[/b] UI <----> Proxy Driver <----> Protocol Driver <----> Device (Navigator) (Light) (DriverWorks Driver) (3rd-party light) Messages come from the UI, for example when someone presses a light on the UI, a Proxy command (TOGGLE) gets sent from the UI to the Light proxy. The Light proxy sends this on to the Protocol driver. The Protocol driver translates that TOGGLE command into the device's protocol, and sends the message to the device. The device toggles it's state, and will send back information that it's changed state. This is sent in the device's protocol. The protocol driver parses this information, creates a 'LIGHT_LEVEL_CHANGED' protocol message, which it sends to the Light proxy. The Light proxy relays this notification up to the UI. More information on Protocol drivers in DriverWorks can be found in the 'What is DriverWorks' topic.

What is Driver Wizard, and how is it different than DriverWorks?

2012-08-23T21:35:40Z

Cisco Smart+Connected Home solutions provides 2 ways for installers to create drivers for 3rd-party equipment, Driver Wizard, and DriverWorks: Driver Wizard is a tool, built into ComposerPro, which is used to create simple drivers for A/V equipment, which use either IR or one-way RS-232 (Serial) connections. As the name implies, Driver Wizard is a step-by-step wizard, which walks an installer through the processes of: * Determining the device type (Proxy) of the device * Capturing IR codes or entering serial codes * Defining the Inputs and Outputs available on the device * Defining macros using the above-defined codes to do things like: Power Control, Input Selection, etc. The main limitations of Driver Wizard include: * Can only create drivers for A/V devices: Devices like Security Panels, Lighting Control Systems, Thermostats, and any other non-AV equipment cannot be created in Driver Wizard. * Can only create one-way drivers. Driver Wizard drivers ignore any serial input from a device, and have no way to indicate state changes coming from a device. * Can only create 'simple' drivers. Driver Wizard can only create drivers which send static info. If a device requires dynamic checksums, or other 'calculated' data, Driver Wizard may not be appropriate. * Can only create IR/RS232 drivers. If a device requires an IP (UDP/TCP), ZigBee, or HTTP connection, it must be a DriverWorks driver. DriverWorks is not a wizard, but is an API, which allows installers / developers to create more sophisticated drivers for all types of devices, using nearly any protocol. DriverWorks does not come with a wizard built into ComposerPro, but may be developed using Driver Editor 2.0, which provides an IDE for creating DriverWorks drivers. For more information about Driver Wizard, consult the topic 'Driver Wizard' in ComposerPro's help (Help -> Index menu). For a more thorough introduction to DriverWorks, see the 'What is DriverWorks' topic.