Premise C++ or C#

[nov0798]

Ok, I would like to learn more when it comes to code for drivers, etc. Is Premise written in C++, or C# or some other language like VB? Which is the easiest to use(I guess this is an open ended question), and learn?

Thanks

 

[123]

...I would like to learn more when it comes to code for drivers ...

Based on all outward appearances, Premise's source code is written in C++. However, this should not influence your choice of programming language for driver development.

To my knowledge, there are three ways to write a Premise device driver.

Type		IDE				Language
------------------------------------------
Module		Builder			VBScript
Native		Visual Studio	C++
Minibroker	Visual Studio	C#, VB.NET,
								JavaScript,
								other
------------------------------------------

I've written drivers using all three techniques so, based on my experience, here's my opinion of their relative merits.

Module
A Module-based driver is the easiest to develop. Builder provides a good Integrated Development Environment (IDE) that lets you modify and test your driver in 'real time'. There's no need to unload/load drivers. Change a line of code and exit the editor (or press F12) and the modifications are immediately in effect. Modules are written in VBScript .

VBScript is a well-documented language that is easy to learn owing to the many Internet-based tutorials and code examples. VBScript also lets you access COM objects and, with a workaround, the WIN32 programming interface. However, you cannot have callback functions so a COM object's events cannot be serviced by a Module (at least not in my experience).

A Module's programming model is object-oriented (supports inheritance, containment, and extension) and is completely event-driven. Builder's IDE lets you easily create new classes, properties, and methods. Modules let you handle serial (text/binary protocols) and TCP/IP-based communications so that covers most Home Automation devices. The caveat is that all Modules run in the same thread. You cannot use blocking commands like VBScript's "Sleep" because it would stop the execution of all Modules. In fact, Sleep is not recognized by Premise's VBScript interpreter.

An effective workaround to the lack of "Sleep", and the single-thread limitation, is to use Timers. A Timer runs in its own thread and lets you execute a function according to a specified frequency (i.e. one-shot or recurring). Timers can be used for polling and delays in a non-blocking manner.

Last, but not least, Builder includes the very handy "Class Wizard". The Wizard lets you indicate the intended purpose of the driver (control a TV, Receiver, thermostat, etc), the means of communications (serial or IR) and then automatically generates the "skeleton" of a driver.

Native
Premise provides a powerful Software Development Kit (SDK) for creating drivers in C++. The SDK includes an excellent example of how to write a native driver. Native drivers share none of a Module's limitations and offer the developer complete freedom. However, native driver-development requires familiarity with Visual Studio and the intricacies of C++ in a Windows environment.

Minibroker
Minibroker is a COM object that exposes Premise's classes, properties, and methods to external applications. The applications can be written using any programming language that is capable of accessing a COM object such as C, C++, C#, VB.NET, VB, Javascript, Perl, etc. The developer has complete programming freedom in crafting the application. Existing Minibroker-based applications are written in C#, VB.NET and Javascript. Several examples can be downloaded from the old Premise Support forum.

Whereas native drivers have an architecture that includes useful driver-related services (serial port-handling, logging, heartbeats, etc), Minibroker is simply an Application Programming Interface (API) and the application must provide its own driver-related services. For example, building a Minibroker-based driver using .NET is a good choice because you can take advantage of .NET's comprehensive Framework. In addition, certain programming constructs, such as events and threading, are greatly simplified in C#/VB.NET than in C++.

A Minibroker application can reside on any Windows PC that is able to communicate, via the network, with the Premise server. Unlike Modules or Native drivers, Minibroker apps do not have to reside on the Premise Server.

Here's a sampling of some of the drivers I've written and what I used to create them:

1. ELK M1 driver
   Written as a Module because it was the easiest approach.
2. USB-UIRT driver
   Written as a Native driver because the device communicates via a supplied DLL that uses callback functions (hence the need for the greater flexibility provided by C++).
3. Speech driver
   I'm putting the finishing touches on a Minibroker-based Speech driver because I wanted it to be capable of running on a remote PC (i.e. a PC not equipped with Premise Server).