Re: Re: Newbie to xPL

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

> The examples have been helping me out sofar, and I've started making
> some notes that I would like to convert into some kind of API
> documentation, unless your already busy with that?

I heartily welcome any info/effort you want to make on that front and if
you
want to share it, would be very happy to include it in the base
distribution.

> You have some valid points on using java, but to be totally honest I
> don't really like java (personal preference), so I'll mostly be

I understand, though depending on why you don't like Java, it may have
changed.  Some folks don't like it because the feel it's too slow or memory
hungry -- conditions which are basically not the case in later version (1.5
or 1.6).  Some didn't like the Java UI, though xPL4Java doesn't use that,
and again, starting in Java 1.5 and later, there have been huge strides
toward making the UI responsive and as "native" looking as
possible.

I'm not trying to be pushy, just thought I'd make a few points :-)

> But these timed events and scripting events "server" is only
available
> for java, right? What I would like to do is to write the linux side of
>  things. IE, a server very similiar to xPLHal and to your xPL Java
> server. I'm currently busy planning it and I'll be starting with it
> this weekend.

Well, the server runs under Java, but you really aren't programming in Java
when you write scripts.  Scripts are in a scripting language called BSH
(BeanShell) which is a fairly typical OO capable scripting language with
some java-esque attributes, but again, you don't need to know java or be
steeped in idioms to write scripts (I've got our receptionist to be able to
create a few scripts in BSH with about 2 hours intro for tailoring our
in-house ERP app) and other than having Java to run the engine, you're not
dealing with it at all.  The integration part with xPL is that it has all
sorts of built in primitives for easily sending xPL messages, listening for
xPL messages and even easily creating self-contained xPL
"Devices" with a
few lines of code.  The schedule and periodic timers are just one
additional
service,  but lot of things are written without them at all (just
responding
to receiving a given message and taking action on it is a common use).

I guess I look at it like this -- you have a lot of really great ideas, but
re-writing the scripting engine is going to take a *lot* of time to do it
right.  The scripting engine is there and available now and you don't have
to do any Java coding -- why not leverage off that and add on from there or
create all the other nifty xPL apps you've mentioned vs. going back and
re-inventing?

That said, I've done the reinventing thing myself more than a few times
when
it wasn't technically completely necessary because I wanted to do something
slightly different or just wanted to exercise my skills.  So please take
the
above as a note, not a suggestion/demand/etc :-)  If you really do want to
create your own engine, more power to you!

> (a) a webinterface using php interfacing with the server, but then you
> don't really have realtime updates

Either would be nice, but pulling off a web interface would be a bit
sweeter, if it works for you.

> What does the xPL->UPB do ? I'm not sure what UPB means?

UPB is a HA lighting control system.  It's comparable in concept to X10,
but
is much more powerful, full bi-directional and just about 100% reliable
(every command is ACKd by the receiving devices, messages are check summed,
the devices are mega configurable, etc).  I had a big X10 install here (72
Leviton Green line X10 switches) until recently when things went bad on the
noise front (from outside the house).  I couldn't attenuate it enough to
get
X10 working.  UPB works without incident, sees no noise and even when there
is noise, handles the occasional corrupt and/or lost packets reliably.
Great stuff.  This past weekend I finished putting the last of 76 UPB
switches into house.  Now to integrate them into the existing HA system
(step 1 - write an xPL-UPB bridge/gateway :-)

> The k8000 is a Velleman electronics kit. The kit interfaces to your
> parallel port and has like 16 digital io, and a couple of analog io. I
> use it for interfacing to my home alarm, doorbel, gate motor and some
> relay's for switching various devices. Check it out here:
> http://www.velleman.be/common/product.Aspx?lan=1&id=9383

Cool -- depending on what lines it needs, you could probably drive it with
xPLIO, but I would go with your gut to create a K8000 xPL specific module
as
that will have a much more native/compatible feel to it.

>>This is where I have to apologize on xPL4linux -- I've never
completely
>>finished the configuration stuff there (the framework for

> I see, but doesn't the configuration messages has a schema? So I'm
> thinking that it should be the responsibility of the xPL application
> to send out the configuration heart beats and respond to the
> configuration query messages ? Or am I misunderstanding how the
> messages are being sent?

Technically, the app can do it, but there are some integration issues that
are more at the framework level.  For one, the normal hbeat.app is replaced
with a config.app heartbeat until the device is first configured (that much
is already in xPL4Linux -- you just have to set the service as
configurable).  Then, when a valid configuration message is received, the
heartbeat needs to go back to hbeat.app and usually the instance ID changes
too (which requires a hbeat.end or config.end and then a new
hbeat/config.app with the new instance ID).

So you can do much of it outside the framework, but it's the sort of thing
that really should be done by the framework since the idea is the framework
takes a lot of "common" chores (like responding to requests for
configurables) off your plate.   Let me see if I can free up some time this
weekend to get configuration support finished.

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