I PM'ed Michael McSharry my explanation and he kindly replied with a very detailed explanation of the concepts of xAP. I wanted to post this explanation (along with my original question to him) as a lot of good information was contained in his response. I would like to thank Michael for generously spending the time and effort for his reply along with his permission to post it for our members:
My Original Post:
QUOTE (Rupp @ Sep 10 2005, 10:11 AM)
Michael McSherry wrote some kind of a xAP UPB plugin but personally I do not want to "mess" with yet another piece of software to communicate with yet another piece of software.
I don't think people understand the theory and use for xAP (I admit I don't understand it fully myself).
Right now I have a CM11a, NetCallerID device, Ocelot, and Caddx system hooked into my Homeseer computer via serial interfaces. Each one of these devices has its separate plugin written by different people. Each one of these people has different programming techniques that are using my memory, CPU, and other computer resources. None of these people communicated with each other when they wrote their programs! So the chances of something conflicting with a computer resource seem high. This situation is exacerbated with the total amount of programs/plugins one installs.
Well, what if you needed only ONE plugin to communicate with those devices? This plugin would have a "standard" communication/data collection method that would be "enforced" for all peripherals it communicated with. This is the direction xAP is going. Not only that xAP can handle serial as well as Ethernet interfaces. Also, another direction many are going with is to buy $35 Lantronix serial to ethernet interfaces and convert their serial ports to Ethernet ports and get rid of those Edgeport multiple serial adapters many of us have to now resort to. That plus the fact that we need to run those serial lines from our peripherals to the computer.
So, the general theory of xAP would actually make your system much more stable as you don't have to add multiple plugins written by multiple authors.
I realize the documentation is sparse relating to xAP and its implementation, but hopefully that will change once the technology matures. I don't use it yet, but would like to dabble in it soon (I purchased my first Lantronix serial to Ethernet unit off of EBay).
Michael McSharry is the xAP champion and I'm sure he can extend/expand this simple explanation!
Michael's Response To This Explanation:
I think that the typical user does not care about the technical apects of xAP and is being pushed away from it because they think they need to understand it before they can use it. People are interested in INSTEON, UPB, X10 for what it will do for them. There is no need to explain the INSTEON protocol for a user to connect an INSTEON switch to Homeseer. They need only know that they need to install the INSTEON plugin and the desired INSTEON switch. For someone to use an xAP application in Homeseer they need to install the xAP plugin, xAP hub, and the desired xAP application.
There are issues of compatibility and interference as you indicate when everything is put under the same hood, but I would not dwell on this aspect. It is more about the system design approach that best fits the users needs and that options to the design are available.
When one designs an architecture there is a toolbox of components that can be used. One can limit themselves to a single tool if they desire and try to make it do everyting. A screwdriver makes a fine pry bar in some situations and that screwdriver is very handy.
HST defined a software interface specification to allow its software to talk with other software in a mode pretty close to as if the other software was written as part of the single Homeseer.exe. This interface carries with it the full overhead of devices, events, triggers, conditions, actions, and callbacks supported by Homeseer. It makes the full power of Homeseer available. It also makes Homeseer vulnerable to this new extension of itself.
HA is all about control of things. That means that there needs to be a way to get access to the things one wants to control. Serial ports, usb ports, IP ports, parallel ports are the means typically available to those that use a PC for their control software. The desired type of port is selected based upon what is appropriate. No one solution is right for all situations. Circa 1980 USB was not available and IP was expensive so options were limited. Today both of these are standard "jelly bean" tools for the system designer. While the future is unknown, the IP connection does seem to be expanding in its use and more and more widgets use it.
If the scope of one's automation can be covered by a single PC with serial, parallel, and usb wires eminating from it then the Homeseer computing model will fit the bill nicely. If the scope goes to multi-point control and may include automated backup and recovery then that Homeseer screwdriver just may not have enough leverage.
Homeseer provides a user/software model of an X10 interface, an IO interface, and an IR interface. Multiple hardware-oriented plugins have been written to bridge the hardware-specific protocol to the Homeseer X10/IO/IR protocol. One of these plugins is an xAP plugin that bridges the gap between the Homeseer X10/IO/IR to an IP connection. It turns out that the IP connection is a pretty powerful tool in the toolbox. One of the things that this tool fits is a C-bus controller that is popular in Europe. Another is a NetIOcom module that provides generic analog and digital IO. Another is the SliMP3 network music player.
When a component does not exist with an IP connection and one desires to control it with Homeseer then they can add an interface to Homeseer and make a plugin that will talk to it. Rather than writing the plugin to conform to the Homeseer SDK, then could write a bridge that translates the serial/parallel (or whatever) into IP and use the IP interface that is already exists within Homeseer via the xAP plugin.
This bridge does not carry the burden of the full Homeseer SDK. It makes the hardware control available from Homeseer or any of multiple control points. The hardware is now a shared resource on the LAN rather than being dedicted to Homeseer. The bridge does not perterb existing Homeseer plugins since it was not loaded into Homeseer. Someday a company will come out with that hardware with an IP connection and the bridge will no longer be needed.
There are some situations where a tight coupling with Homeseer is the desired system design approach. Elegant triggering and device action schemes will tend to make use the SDK a preferred solution. The SDK can be used for simple device interfacing as well, but other design alternative may be more attractive. The sledge hammer will sink the nail. The sledge hammer will also leave dents that can sometimes be pretty deep.
