Echelon LNS Plug-in - Manual (Page 32)

How Plug-ins Are Represented in the LNS Object Server
The LNS network database represents physical objects on a L ON W ORKS network with objects in the
database. For example, network databases contain Router, Channel and AppDevice objects.
The LNS Object Server represents a plug-in and its functionality through ComponentApp objects.
There is one ComponentApp object for each action that a plug-in implements and one
ComponentApp object for the plug-in itself that is used to register the plug-in. Each ComponentApp
object defines, among other things, an action, which is a command/object class pair. This means that it
defines a specific command (such as LcaCommandTest) that the plug-in can perform on a specific
class of object (such as an AppDevice). This means that if a plug-in can perform the same command
on many different classes of objects, it represents this by multiple ComponentApp objects (all with
the same command ID, but each with a different object class ID). For example, a plug-in might
implement two actions, a test command of AppDevice objects and a test command of Router objects.
Each of these actions would be represented by a ComponentApp object (one with a command
ID/object class pair of [LcaCommandTest (33), LcaClassIdAppDevice (7)] and the other with
command ID/object class pair of [LcaCommandTest (33), LcaClassIdRouter (9)].
Similarly, if a plug-in can perform many different commands on a particular class of object, each of
these commands is represented by a separate ComponentApp object (all with the same object class
ID, but each with a different command ID). For example a plug-in might implement two actions, a
Test command of AppDevice objects and a Configure command of AppDevice objects. Each of these
actions would be represented by a ComponentApp object (one with a command ID/object class pair
of [LcaCommandTest (33), LcaClassIdAppDevice (7)] and the other with command ID/object class
pair of [LcaCommandConfigure (13), LcaClassIdAppDevice (7)].
The successful completion of plug-in registration is also represented in the LNS Object Server by a
ComponentApp object. In this case, the command ID of the ComponentApp object representing
successful registration is LcaCommandRegister (50).
Four classes of objects in the LNS Object Server contain ComponentApps collections: the
ObjectServer object, System objects, DeviceTemplate objects, and LonMarkObject objects. The
ComponentApps collection to which a ComponentApp object belongs defines the scope of the
command represented by the ComponentApp.
If an item is in the ObjectServer object’s ComponentApps collection, the item applies to all systems
managed by the LNS Object Server. If an item is in a System object’s ComponentApps collection,
the item applies only to that system. If an item is in a DeviceTemplate object’s ComponentApps
collection, the item applies only to devices of that type in that particular system. If an item is in a
LonMarkObject object’s ComponentApps collection, the item applies only to functional blocks of
that type on devices of that type in that particular system.
How Plug-ins are Installed and Made Visible to LNS
To the user, installing a plug-in is a simple process. As with all Windows applications, the user runs a
setup program that copies all of the files required by the application onto their machine and that makes
whatever changes in the Windows registry the application requires. The next time that the user runs a
director, the new plug-in will be listed as available and the user can then register the plug-in with LNS.
Note that the manner in which the director treats new plug-ins is up to the director. Some directors
may display the new plug-ins in list boxes and let the user select which ones are registered; other
directors may automatically register all new plug-ins (although this not recommended because it may
result in lots of time spent registering plug-ins that the user does not want to use).
Once a plug-in is registered with LNS, the user can then use the plug-in’s functionality and, depending
upon how the director has exposed plug-ins, may not even be aware that they are doing so. As with all
software, much is going on behind the scenes to make this process easy for the end-user.
When the user runs the plug-in’s setup program to install the plug-in onto their computer, a number of
things happen. The setup program copies all of the files needed to run the plug-in onto the user’s