Your plug-in can be one of two types: An ActiveX (COM) plug-in that will run under HomeSeer's compatibility interface, or a .NET DLL (assembly) that will be loaded into the HomeSeer application domain. It is recommended that plug-ins be written in .NET in either VB.NET or C#.
For HomeSeer to find a potential plug-in, the first criteria is that it is named starting with "hspi_" (hspi underscore). HSPI stands for HomeSeer Plug-In.
For each file that matches that criteria, HomeSeer then looks for the hspi classname in the file. For this reason, regardless of whether you have a COM or .NET plug-in, you must create an hspi class within the plug-in. With .NET plug-ins, the class name is case sensitive and thus should be all uppercase (HSPI). Under COM, you can create an ActiveX User Control, ActiveX DLL, or ActiveX EXE so long as there is a creatable HSPI class in the program. An ActiveX EXE is preferred since EXE programs run in their own process (thread) thus are easier to track. ActiveX DLLs or controls run under the process of hs_Compatibility.exe, so there is no means for controlling execution outside of HomeSeer.
Several of the interface facilities make use of an object within your plug-in as a reference. For instance, when you register a web page with your plug-in, an object is required so that HomeSeer can call procedures specific to that object when generating the web page or in processing data posted from the web page. In COM plug-ins, a form object works very well for this purpose. The form does not have to contain any controls, and can set its VISIBLE property to False to hide its appearance. Because your plug-in can have several form objects in it, there is no limit to the number of unique web pages or callbacks that can be registered within HomeSeer.