The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: 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 Main Index | xPL Thread Index | xPL Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.