Re: Vendor ID and a question

[Gerry Duprey <gerry@xxxxxxxxxxx>]

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