RE: Vendor ID and a question

["Eric Vickery" <ericvic@xxxxxxxxxxx>]

Gerry,

Thanks for the good info. I plan on using your Java framework but I
haven't had a chance to dig into it yet.

For your UPB implementation how does an xPL GUI determine what UPB
devices are out there not just the presence of your xPL2UPB bridge?

On a bit of a different question. I'm going to take a look at xPLHAL but
I have a few reservations. I don't care that it is Windows only because
even though I prefer to code in Java I run Windows. The problem I have
is that it doesn't seem to be open source and I like to have the source
for anything I'm going to put into my home automation project this time.
I have used other commercial home automation applications but have
finally decided to create my own because there was always something that
I wanted to do differently in each one I tried.

Eric

-----Original Message-----
From: ukha_xpl@xxxxxxx [mailto:ukha_xpl@xxxxxxx] On
Behalf Of Gerry Duprey
Sent: Friday, December 09, 2005 3:54 PM
To: ukha_xpl@xxxxxxx
Subject: Re: [ukha_xpl] Vendor ID and a question


Howdy Eric,

On the vendor ID, it's best if you suggest the ID you'd like.  There is
an 8
character limit and it should be all lower case (you can have numbers in

there too).

> devices hidden. Would I have to have a different xPL device for each
> light or could just the instance ID change? For instance could I say
> (I know this is not realy valid xPL but it is just for example)

Generally, the device id portion describes a higher level device.  For
example, in my xPL2UPB gateway, the device ID is always upb and the
instance
ID is pretty fixed too (assigned often by the end user).  For example,
my
main machine has a complete device identifier of cdp1802-upb.server (the

"server" part being assigned by my during device configuration,
the
cdp1802-upb fixed no matter how many instances of it are running on the
network).

While it can be useful to address devices by their device identifier,
its
common to address them by schema.  This is because a single xPL device
may
in fact be controlling several disperate things.

A great example is a gateway for the HomeVision automation controller.
The
controller can control X10, UPB, digital inputs and outputs analog
inputs,
infrared, caller ID, etc.  The gateway, being a single device, is always

"cdp1802-hvision.server".  However, it speaks the x10 schema
(x10.basic
and
an x10.advanced), control/sensor schemas (for the digital
inputs/outputs), a
caller ID schema, etc.

So when I want to turn an X10 light on, I'll address a broadcast message
to
anyone interested in an x10.basic message.  Inside the message is a
command=on and a device=A7 (to turn on device A7).  The appropriate
device
picks it up and acts on it.

If you have multiple devices that do similar things (i.e. two different
devices that both have digital outputs (like Toms K8000)), then you'd be

looking for a non-broadcast message to insure the right units digital
outputs are acted on.  Again, the schema is important. If you direct an
X10.basic schema message to the K8000, it's just going to ignore it
because
it doesn't know what that schema is.

Now, the real linch pin for future "generic clients" (that is, a
client
that
can discover and control devices it's author never heard of) is a
combination of encoding each schema into a machine readable XML file
(which
describes what any device that implements that schema supports) and
additions to the Vendor Plugin file to indicate which schema object each

product/device the vendor produces uses.  With those two bits, you can
"discover" a new device on the network, lookup it's vendor plugin
file,
find
out what schemas it supports and proceed to operate on a device you may
never have heard on when you wrote the program.

These last two items, along with a few others, are in the discussion
stage
right now.  Right now, for well known schemas, you can mostly work
around it
by fetching a vendor plugin file and scanning it for references to
schemas.
They are present and easy to parse out, but since it's not currently
presented as an enumeration of supported schemas, you are
"scraping" the

data out and it may not be complete (though likely it is).

Finally, since you want to get coding, I'd suggest considering using one
of
the existing xPL frameworks (if you haven't already).  They wrap up all
the
difficult to get right (at least the first time) parts of xPL and let
you
focus on the really important, unique parts that you want to do.  There
are
platform specific ones available for Windows and Linux and there are a
few
platform independent ones for Java, perl and python.  They really can
massively shorten the time you need to spend to get a working prototype.

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org



xPL Links: http://www.xplproject.org.uk http://www.xplhal.com
http://www.xpl.myby.co.uk To Post
a Message: ukha_xpl@xxxxxxx To
Subscribe:  ukha_xpl-subscribe@xxxxxxx
To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx