HS and UPB Plugin


Active Member
With UPB being a great alternative I'm glad to see HS support it.

I am disappointed that a plugin cost $59.95.

I mainly use Zwave so this isn't a big issue personaly. But that brings the price to $250.00 for someone wanting control of UPB. I have several customers that want basic control of UPB and I have to recommend HAL mainly because of price.

I know this issue sort of has been brought up before but this proves to me the direction of HS.

For the 59.95 just about buy the HAL version that supports UPB since late November 2004.
Just curious... is there a HS plugin for the Elk M1 yet? And if there is doesn't that give you UPB control by default?
There appears to be a 3rd party plugin for the M1:

Elk-M1 Plug-In

PI-ELKM1 (download/unlock codes)
HomeSeer interface for the Elk-M1 automation panel.

(supports HomeSeer v1.7 or v2.0)

Yes, I imagine it would give you control of UPB devices for someone with an M1 but I think Brian was referring to just someone that wanted control of UPB with just Homeseer. If you use HS and M1 I imagine you just need the $30 plugin instead of the $60 plugin. :(

Anybody know if this plugin supports ethernet, or just serial? Also, why is it that the HAI Omni plug in seems to be a 'corporate' plugin and the M1 is a 3rd party? And, is there a way to see more detailed info on the plug ins? The web just lists basic info - where do you need to go to get detailed info?
Steve said:
Yes, I imagine it would give you control of UPB devices for someone with an M1 but I think Brian was referring to just someone that wanted control of UPB with just Homeseer. If you use HS and M1 I imagine you just need the $30 plugin instead of the $60 plugin.
Or, use the FREEE my.Elk plugin written by electron HERE. :(
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.
hehe, I had an xAP prelimary explanation, but deleted it until I had a chance to check on the accuracy of it!

EDIT: I PM'ed Michael with my explanation to make sure it is accurate and did not contain any errors. I will post it after his review.
I have a couple of UPB switches and the pc interface ready to install. I plan on using the xap interface. I was going to upgrade to HS 2.0 but for another $60 I think I'll wait. I'll let ya all know how hard it was once I get it running sometime next week.
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.
Thanks Michael and BSR.

BSR, I waiting for another one of your excellent "xAP-How-To-For-JohnBullard- Dummies" so I can understand it!

I think Michael is a very brillant person with exceptional talent, but he loses me real quick :(
I second John's request for more xAP and xPL info for those of us who are technically challenged. I used to use the xAP plugin with homeseer to access my Slimserver. Then I stopped using homeseer and Damage showed me how to do the same thing directly with xPL (no homeseer required). Going forward will I need to use xAP for some things and xPL for others? Do they get along OK together? Which protocol will CQC be supporting?

I would really like to be able to use these protocols better but I just can't get enough of the basics from reading their respective forums.
So let me throw out my understanding and see if it gets slammed down.

For example, to use the xAP UPB "device" that Michael is so kindly providing, you don't need HS - you just need a computer, a network and some other device to talk to. The xAP plugin basically makes HS a xAP device on the network so it can talk to other xAP devices out there?

So, if the above is true, I could load the xAP UPB program on a PC near my power panel so that my UPB controller is as close as possible to the power distribution for my house. Then I could load the xAP hub and xAP Plugin on the HS box and talk to the UPB controller via HS?

I hope I'm on the right track here as this could be fun.....

(PS, just noticed that I'm now an "Advanced Cocooner" I feel so special)
So it looks like the idea of using those Lantronix EPS1 print servers for IP to serial connectivity is finally catching on! I first got that going with my Ocelot a couple of years ago and then other ADI forum members followed suit, now it looks like writing native IP connectivity directly into programs has ensued.

Once you get to taste the flexibility of IP connectivity, you don't ever want to go back to serial ports again.
Also, why is it that the HAI Omni plug in seems to be a 'corporate' plugin and the M1 is a 3rd party?

Mostly it's a question of "How much does HomeSeer need this plugin", and if a third party author has already started it. In the case of the HAI plugin, several people lobbied Rich for it. In the case of the Elk plugin, a third-party author took the ball and ran with it. IMHO, in the future that HS will focus more on technologies (ie UPB, Insteon, touchscreens) than products (HAI, Elk, etc).

And, is there a way to see more detailed info on the plug ins?

I haven't compared the write-ups on the HS web-page vs the write-ups in the updater, so I don't know if they differ. However, the best source of information is the plug-in catagory on the HS board.
Thanks for the comp. There are several people I've helped with this technology with simply a request that they document what they did so other could benefit from it. Hopefully we will see something that might help give a novice perspective.

I looked at both xAP and xPL and purely by chance I went down the xAP path. The hub I use will act as a hub for both xAP and xPL and it bridges the basic control xPL schema into xAP. Other than that I have not done much with xPL. In retrospect I think the xPL strain is a little more of what I would like to see, but both can accomplish the same objective.

You have the concept correct. For me Homeseer is primarily a collection pot of xAP messages and does not get very involved with the control itself. It could be more involved, but I elect to localize my control logic.

My UPB node is running by itself and it listens for traffic generated by my W800 node from hawkeye motion. The UPB node then activates the UPB light based upon logic that is triggered by the motion message. It also could have been done using a W800 plugin to Homeseer and the traffic routed from W800 plugin to Homeseer to xAP plugin. It could also have been done with script run by Homeseer based upon the W800 motion event that commands a UPB action.

There is all sorts of flexibility with the architecture. No matter how you do it the exact same user experience exists no matter where the computes and xAP nodes are located. You still select the device code from the HS device page and activate the UPB light just like you do now with an X10 device that is directly connected to Homeseer. The only difference you will see is that with UPB the control selection is much more than just ON/OFF/DIM.

I would not worry about where you put your UPB PIM module. UPB is so robust that it is hard to not have it work.

I agree that the IP connection is fantastic. When I was testing my HS2 plugins I had the full hardware IO suite at my disposal on a second computer without changing a cable or worry about location of the HS2-test computer. The only thing I could not make work was the DS9097U 1-wire adapter. This adapter is dumb and depends upon timing from the PC and this timing is lost when routed over IP.

It is nice we have Ebay were we can get the EPS and ETS units for slightly more than a shipping charge.

I read the preliminary manual for the HS UPB plugin. It is about 2 pages. Its hard to see what UPB features they have included. They do support the ExecX10 method to generate Activate/Deactivate/Relative DIM. They also allow the extended byte (4th parameter) to be used for Absolute DIM. They indicated that SetDeviceValue can be used, but gave no indication of what it might be used to do. They do support direct module control as well as Link control, but no discussion on how they are supported. This area can be very elegant or can be very basic.

I did receive feedback from one of the xapmcsUPB users after they tried the HS UPB plugin and found it to be a step backward from xapmcsUPB. It could also be that the HS documentation is not adequate and he could not figure out how to do things.

I did not volunteer to be a HST Beta tester for their UPB plugin primarily because it is HS2 only and HS2 is too much of a struggle for me now.