Echelon LNS Plug-in - Manual (Page 13)

configuration properties and enforce limits on configuration property values. You can create a device
plug-in executable that operates on multiple device types. The single executable that is able to operate
on multiple device types is a programming convenience. You can also create a separate device plug-in
for each functional block in a device, but it is typical to include the support for all functional blocks of
a device type in a single plug-in, and let the plug-in determine which object to act upon based on the
object that has been passed as a parameter.
System plug-ins apply to an entire network. For example, a system plug-in could provide a custom
interface that would allow you to test all devices on a network and see the results. A system plug-in
could also be designed to manage all of the devices in a room, or on a floor of a building. This
document focuses on device plug-ins; however, you can also implement a system plug-in based on the
instructions in Chapter 2, Creating and Redistributing LNS Device Plug-ins.
The LNS Plug-in API defines a single method, SendCommand(), and a number of properties that a
plug-in must implement.
LNS Plug-in Commands
The SendCommand() method is used by directors to ask a plug-in to perform a command (specified
by ID) on an object (specified by class ID and object path). Plug-ins can implement standard
commands defined by LNS or custom commands that they define. The plug-in designer is responsible
for having the plug-in implement commands in a way that makes sense (for example, if a plug-in
implements the Browse command, the plug-in designer must design the implementation of the
plug-in’s Browse command). The standard plug-in commands are listed in Appendix A, Standard
Plug-in Commands.
Device plug-ins typically implement the LcaCommandConfigure command. This command is used
by network tools to provide an option for network integrators to configure a device or functional block.
Device plug-ins may also implement the LcaCommandBrowse command if they are used for
monitoring and controlling the device in addition to configuring it. The device plug-in can also decide
whether to display the same user interface for these two commands.
Plug-ins can also implement custom commands. The values for custom command IDs are assigned by
the plug-in, and may be any value greater than or equal to LcaCommandUserStart (10000).
LNS Plug-in Properties
All plug-ins must also implement a standard set of properties along with any custom properties
required by the developer. The standard properties allow the director to tell the plug-in information
about the network is it operating on (such as the NetworkName and the NetworkInterfaceName
properties) as well as to control the appearance of the plug-in (such as the Left, Height, and Visible
properties). The complete list of required and optional properties is given in Appendix B, Standard
Plug-in Properties. Read access must be provided to all properties. Write access may optionally be
provided for most properties; however, some properties must be read-only or must be read-write as
noted in Appendix B, Standard Plug-in Properties.
Overview of the LNS Plug-in Framework Developer’s Kit
The LNS Plug-in Framework Developer’s Kit includes the following components needed for
interfacing with the COM-based LNS API in the .NET environment: the LNS Plug-in Framework and
the LNS .NET wrapper.
The LNS Plug-in Framework is a library of classes, interfaces, and value types that provides access to
LNS Plug-in functionality and is designed to be the foundation on which .NET-based plug-ins are
built. The LNS Plug-in Framework provides the following components:
• A COM Callable Wrapper (CCW) that lets a COM director application, such as the LonMaker
tool, call into the .NET plug-in assembly.
• An implementation of the full LNS Plug-in API interface (ILnsPlugin).