One way to look at it is that the extra $50 for a VRC0P gets you a
free zWave driver. Unless you feel compelled to write a new driver (always welcome), that's a pretty good deal.
I'm no zWave expert but my understanding is that you'll need something other than the VRC0P to act as the primary controller. I believe the Z-Stick can serve this purpose. Buy both, use the VRC0P with the free driver today. While that is working nicely with your zWave lights, motion detectors, thermostats, and locks, take your time learning how to write a driver for the Z-Stick.
Native drivers require use of the HSDK which means you need to know how to code in C++ and have Visual Studio (not Express because the HSDK includes macros, to build classes, that do not work in Express). I wrote the USB-UIRT driver using the HSDK and it took me awhile to wrap my head around it.
If you use MiniBroker (a COM object that exposes Premise's internals) you can code a driver using any language that supports COM objects.
The easiest way to write a driver is as a Module. Builder provides a nice development environment that includes an interactive debugger (code-completion, breakpoints, observe variable values, etc). The best thing is that the development cycle is fast. What do I mean by that? Compare the following:
Compiled Driver
Writing a driver with the HSDK or MiniBroker using a third-party tool like Visual Studio.(very similar to how drivers are created in many HA programs):
- Write some code. Save it.
- Compile/link/whatever to generate a DLL (i.e. the driver).
- Unload the existing driver from Premise.
- Load the new driver in Premise.
- Test the driver.
- Uh-oh. A bug. Repeat edit/compile/unload/reload/test.
Interpreted Driver
Writing a driver as a Module using Builder:
- Write some code. Press F12.
- Test the driver.
- Uh-oh. A bug. Repeat edit/test.
Plus you have an interactive debugger at your disposal so in step 2 you can stop execution wherever you want and observe the state of the variables to help you find the bug.
Being object-oriented is an enormous benefit. Premise has a truckload of classes designed to simplify your life, accelerate software development, and maintain consistency. For example, let's say you need to store temperature. You could just create a
Real variable and store it as a Fahrenheit value. Folks outside the US will naturally ask you to add Fahrenheit -> Celsius and Celsius -> Fahrenheit conversions. This is not the right way to do it in Premise!
The solution? Don't use a Real variable, use the
Temperature Property class. Let's say you call your Temperature Property variable ExteriorTemp and you are reading the exterior temperature in Fahrenheit. Just do this:
ExteriorTemp.Fahrenheit = 73
If you need the value in Celsius you use the Celsius method like so:
x = ExteriorTemp.Celsius
Premise is actually storing ExteriorTemp in Kelvin units. Premise has Property classes for Speed, Length, TimeSpan, Voltage, etc (see attached image or
this document).
Premise's object-oriented architecture lets you easily model complicated real-world devices. You can build a single driver that support multiple physical devices. For example, one serial port can communicate with several Adicon Bobcat sensors. In Premise, the driver is seen as a single root node (the part that talks to the serial port) with multiple child nodes (representing several sensors). The HAI Omnistat driver I created lets you use one serial port to talk to multiple Omnistat thermostats. Each Omnistat appears as a child-object of the root driver.
OmnistatNet
.......Omnistat1
.......Omnistat2
You can create classes to represent real-world situations more clearly. For example, an ELK M1 Zone has numerous properties including:
- Status
- Logical State
- Physical State
- Definition
- Area
- Trouble
- Bypassed
In many HA systems, these properties are represented as
arrays. If you want to know the Logical State of zone 43, the LaundryWindow sensor, you'd go to the M1 > LogicalState array and look at array element 42 (zero-based array).
Premise lets you build classes containing properties and methods that do a better job of modeling a device. In Premise you'd go to:
M1 > Zones > LaundryWindow > LogicalState
The LaundryWindow object, a Zone, contains all of its properties (LogicalState, Status, Definition, etc) in one place.
Premise stores objects using a hierarchical linked list which means you never have to predefine the number of elements like you would with an array. Create a parent object and as many child-objects as needed, on the fly. Child-objects can also have child-objects so you can see that this degree of flexibility lets you model some very complex real-world systems
The best way to learn how to construct a driver as a Module is to download an existing one and examine how it is written. Sometimes the device's complexity makes the driver hard to understand to I recommend you look at a simple one like
Weeder Digital I/O driver. This driver demonstrates several techniques:
- Read/write via a serial port.
- Parse ASCII Text protocol.
- Single driver supporting multiple devices.
- "Watchdog". Device is polled and alert is raised if unresponsive.
This gadget has I/O ports that can be designated as Input or Output by the end-user. The driver demonstrates a special ability of Premise to swap one class (Input) for another (Output) on the fly ("Transformable").
Have fun!
