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: Newbie to xPL



Howdy Tom,

Welcome to xPL -- I think you're going to like developing with it.

> small utility to log schema messages. I'm doing everything under linux
> using the xPL4Linux tools and framework and it works like a dream. I

I'm glad you're figuring it out OK.  I haven't written as much
documentation
for it as I'd like, but with luck, the examples should help get you
boostrapped.

I'm also a heavy linux user, though have been shifting over to Java because
I'm just plain sick and tired of 1) losing everything when I change
platforms and 2) writing complex things that a lot of people can't use
since
their not on the same platform.

But right now, the core of my house is running on xpl4linux and xpl4java
(xpl4linux is used to integrate my HomeVision unit (via hvsrv) and my
statnet thermostats (via tsrv).  As you may have found, hvsrv and tsrv are
available on the xpl4linux area too (along with all source code).

> * You need a hub for every pc with different xPL applications running.
> For windows, I tried the xPL monkey hub and for linux the xPLhub. Both
> works very nicely. Now, the xPLHal and the xPLHal Manager is actually
> not a hub but a service doing all kinds of events depending on
> incoming messages? and the xPLHal Manager is used to configure the
> xPLHal service? Is there such a service for Linux (because if there
> isn't one then I'm seriously considering developing one).

You're understanding of xPLHAL and it's xPLHAL Manager are pretty spot on.

There are parts that can basically do about the same under linux (or
anything else -- Java based).  A tool called "DCM" allows you to
configure
xPL devices just like xPLHal allows.  The xPL scripting engine in xPL4Java
allows you to very easily write complex (or simple) scripts to execute.  It
comes with built in primitives for having timed events (periodic (i.e.
every
5 minutes) or scheduled (every weekday at 5PM)) if you want those sorts of
things.  You can also use it to knit together xPL devices (I have a very
simple script that, when I hears the HomeVision knows we're away, lowers
the
thermostats after 30 minutes) with just a few lines.

I've toyed with the idea of creating a graphical script creator/editor tool
(that didn't expose the scripting language, just higher level things) that
would auto-parse scripts and then write them back out again after they were
edited.  The idea was to make the xPL4Java "server" in the
background not
need a GUI, but put a GUI in the foreground for editing/updating work.

If you're interested in pursuing this, I'd be happy to help (there is no
requirement such a front end would have to be written on Java, so pick your
strong suite).

I'm also working (early stages) on a tool to create graphical control
panels
that are xPL aware (more of a toolkit and designer).  It will depend
heavily
on vendor plugin files and schema definition files (addressed below) to
allow dynamic control over xPL devices.  But it's pretty early yet -- I
have
to finish my xPL->UPB module first.

> * Are there any python libraries available for working with xPL ?

I think there is -- check out the frameworks downloads at the xPL site.

> * A xPL device gateway communicates with a connected device and sends
> xPL messages according to the device status and also handles incoming
> messages?

In general, I think of any device that knows how to talk to another device
in it's native language and translated it into applicable xPL (and xPL back
to the devices language) as a gateway, so with that interpretation, there
are a number of gateway xPL modules out there.

If you mean simply trafficking data around (over serial or parallel ports)
to and from the xPL network, there is xPLIO which is a module that allows
just that.

I designed xPLIO as a means to control simple devices that a person didn't
otherwise have a driver for.  Ideally, it's just a stop gap until a xPL
driver/gateway/module is created for that device, but realistically, not
all
devices will have an xPL driver written for them.

> * I also started on a xPL - K8000 gateway(?) last night, does
> something like this exist or can I continue.

Not sure what a K8000 is, but I don't recall seeing it mentioned before.
For curiosities sake, what is it?

> * what is the difference between xAP and xPL?

Some philosophical differences about nailing things down and complexity.
They are very similar (xPL coming from xAP roots), but simplified (header
is
simpler, body layout much simpler) and more explicitly typed (xAP supports
the idea of schema class and type, but seem (to me) pretty cavalier toward
using new schemas and not having much in the way of inheritance and there
are more "gray areas" in xAP).

In short, xPL is a simplified version of xAP that doesn't sacrifice
power/flexibility, but is generally easier to use, more nailed down (i.e.
very few if any gray areas) and easy to code for.

> * I saw that there is xPL messages for sending configuration messages,
> how does that work?

This is where I have to apologize on xPL4linux -- I've never completely
finished the configuration stuff there (the framework for configuration is
all in place and I should probably complete it as I've been through the
entire process in Java before).

In short, devices that are configurable and new to the network send a
special heartbeat out that devices (like DCM and xPLHAL) can detect.  Once
detected, the controllers send the device a request for the devices list of
configurables and current config values, then after the user configures
them, more messages are sent to the device to install the new values.  Once
a device receives those values, it's expected to store them and re-use them
at the next startup (so the "config" heartbeats shouldn't happen
every time
the device starts -- just until it's been configured that first time).

After the initial configuration, there is no specific way that just
"know" a
device is configurable, so configuration tools tend to send a request to a
device (as soon as they first see it) asking for a list of configurables.
If the device doesn't respond, it's not configurable.  If it does respond,
the tool that asked for those values typically then allows the user to edit
them and send them back to the device anytime (certain restrictions apply).

It's not too complicated and if you know what to look for, all the details
are in the xPL protocol spec, but it probably needs a bit of different
organizing sometime (I found everything there, but while some stuff seemed
related, other things seemed a bit scattered -- it's been a while since I
read that over though).

> I'll probably have alot more questions in the next couple of days, but
> I'm glad I found this and I would like to improve linux applications
> and features for xpl as it seems very minimal (?).

Feel free to ask any questions and if you want to pursue the schema thing,
let me know -- there are some older messages that were posted (in October
and just a week ago) about this and should be in the archives along with an
initial proposal for the schema XML file spec (which is based in large part
on the vendor plugin spec, if you are wondering about the genesis of some
terminology as you read it :-)

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.