Re: X10 Schema and Preset Dim

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

> I agree with most of what you are saying but if there is going to be
> abstraction at all then I don't think the schema should be called X10.
I

Well, no matter what we do, even the current X10 schema is an abstraction
because it "abstracts" the actual X10 codes being used (binary
codes sent to
control the devices and such).  It's a very thin abstraction, but it's
there.  I think there are degrees of this and this, along with abstracting
the level stuff (and, in a future extension, the scene control stuff)
aren't
significantly "fattening" the abstraction layer and is providing
a necessary
buffer between the raw hardware and xPL "clients".

> think there should be a more generic "lighting" schema. One
side benefit
> of that would be that different xPL gateways could use the same schema

agreed and in fact, I'm embarking on this right now.  I've written an
UPB4Java API for controlling UPB devices.  After the first pass on the
code,
the second pass really isolated nearly all the UPB stuff into an adapter
protocol plugin class.  I'm working on normalizing name space right now and
am looking at adapting the UPB schema I posted on this list a few weeks ago
into a more generic lighting schema.  The idea is that one schema and one
API with plugins to cater to the underlying media and protocols.  One
clever
fellow I'm working with is considering using this for to control Insteon as
well.

But the fact is the current X10 schema cannot be migrated so.  It has to
remain basically as is.  It could be "extended" with a new schema
sub-type
that inherits from X10.basic to allow other things (like scenes and such),
but it is what it is.

Of course, once a general lighting schema is worked out, there is no reason
an X10 xPL adapter couldn't implement both schemas  - X10 for compatibility
and the lighting one for more advanced control.

And not to get too far off topic, but there is an entire discussion about
whether a lighting protocol is the right way to go.  X10 controls lights,
but people use it to turn on TVs, control lawn sprinklers, control
thermostats, etc.  Same issue for UPB and others -- it's not just lighting,
but even with that, we all know we want a general lighting schema/control
method.  To get full control over all devices of a protocol, you have to
expose the ugly bits, but doing so makes the schemas incompatible with each
other.  So then you start looking at the lighting schema as being a
"super-set" of the underlying protocol -- still allowing the raw
protocol to
be sent, but not requiring it for simpler things like light control.  It's
not a real technical hurdle, more a "philosophical" thing and I'd
prefer
more concrete to philosophy :-)

> One point I disagree with you on is that predim1 and predim2 aren't
> standard X10 just because all the devices out there don't support
them.

True -- though it was added on to the original protocol at a later date
(then again, a lot of stuff was -- extended codes, hail request/ack, status
on/off/request, etc).  Really doesn't matter -- predim is a mater of fact
and my comment was that if I had my druthers, it would have been handled
differently in the schema (hidden it or at least moved the "raw"
part of it
off some less dim-specific command (so that folks with devices like your
thermostat could still access it), but for pure dimming needs, make it
explicitly the responsibility of the xPL adapter/gateway to figure it out
(which is mostly how things are done now).  But it is what it is.

> If you go that route then on and off are the only standard X10
commands
> because not all devices support the other commands. I would also go as
> far as to say the most (if not all) modern devices that use the X-10
> protocol (not including devices actually from x10.com) support predim1
> and predim2 unless they are a relay type switch.

Actually, PCS switches and Leviton green/red line switches and some
SwitchLinc switches have different ways of dimming that do not use the
predim stuff (or use variations of it that aren't all compatible).  It's
this unfortunate "profusion" of dimming techniques (at least 4 I
know of --
standard X10 dim/bright, X10 predim, PCS microdim and Leviton direct
dimming) that makes me all pointy about abstracting this bit so the end xPL
client isn't having to figure the right way to do something.

> To get back to my original question. Where should I assume that the
> levels for preset dims will be in an xPL message? I have to support
them
> because my light switches use them as well as my thermostat.

Good question and the answer is -- it depends.  On the particular X10 xPL
controller you have.  If the controller is very "literal", then
the way you
do this is to take your 5 bit level and test the high bit.  if it's set,
you'd send predim2, if clear, send predim1.  Then encode the remaining 4
bits into a house code, A-P (note -- it's not a linear mapping as A is
"6",
"M" is 0 and "P" is 3, etc -- yikes!).  This is how X10
actually sends it.

A more "interpretive" approach would take a 5 bit value in the
level fields
and key off the predim (1 or 2) command and then locally encoded it as
necessary.

Yep -- absolutely less than ideal.  This area is a real mess in general in
the X10 protocol (which is why few of the more modern switches use the
predim stuff) and since it's not abstracted, you're sort of having to deal
with the ugly bits right there.

I looked at the source to the CM12 xPL X10 interface and it doesn't
implement the preset stuff (neither does my homevision xPL server).  There
is a windows HomeVision server that *might* implement them, but I can't get
to it right now (the site it lives on is being reorganized).

xPL is going through a maturation phase right now -- new clarifications and
details about how things should use the protocol and such -- but there is a
history that has to be respected (compatibility wise) and that's always a
bit of a chore :-)

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