Re: DMX and xPL

["John B" <home-automation@xxxxxxxxxxxxxxxx>]

> I think the basic problem with your plan is that the xPL design
expects
> there to be an xplHal (or other message processing equivalent).

There seems to be a misconception that xPL *requires* xPLHal - this is
certainly not the case, although xPLHal does play a big part in a lot of
peoples' installations.

For example, we have a lot of users out there who are using the xPL support
in SlimServer with no xPLHal installation - they just use things like
command-line senders to send xPL messages to control SlimServer.

> As far as I can tell from the docs, xpl devices never send commands
directly
> to each other - xplHal sends all the commands, based on scripts and
the
> trigger messages it receives (someone PLEASE correct me if I'm wrong
about
> this - it's pretty fundamental!)

Firstly, xPLHal is just a regular xPL device on the network - the only
thing that is special about xPLHal is that it acts as a configuration
manager.
This means that it responds to config.* messages from other xPL devices.

Any device on the network can send an xPL command message if it wishes.

E.g. I have a desktop shortcut that fires an xpl-cmnd message directly to
control some C-Bus lights - there is no involvement by xPLHal in this
process.

> So, a light switch sends a trigger when it changes state (using
> sensor.basic - control.basic has no trigger form).  xPLHal picks this
up and
> sends commands to lights etc according to the scripts it is running.

Yep, this is certainly how a lot of people are using xPL (myself included)
however it does mean that failure of xPLHal will result in failure of any
xPL devices that rely on it.

> Having said that, I don't see why you couldn't have your lightswitch
send
> both control.basic commands (to the light) and sensor.basic trigger
messages
> as you suggest.  You would just have to not script xplHal to send
commands
> to the lights as well ;-)

I guess it depends on where you want your logic - I can see 3 ways of
approaching this:

1. Using xPLHal for logic:
a) Light switch sends sensor.basic message when button is pressed.
b) xPLHal detects this and sends control.basic message to lights
c) Lights (C-Bus, DMX etc.) pick up this message and switch lights on

Advantages: Easy to add complex logic via xPLHal.
Disadvantages: Failure of xPLHal means you are in the dark!

2. Logic in light switch
a) Light switch sends control.basic messages to control lights directly
when button is pressed (may also send sensor.basic messages as well)
b) Lights pick up control.basic messages and switch on lights.

Advantages: Quick, reliable.
Disadvantages: More complex hardware required in light switch - need to
have some way of storing/executing/programming logic.

3. Logic in lights themselves
a) Light switch sends sensor.basic trigger message when button is pressed.
b) Lights detect the sensor.basic message and determine what actions to
take.

Advantages/disadvantages are the same as option (2), it's just that the
logic is in the lights themselves rather than in the light switches.

Hope this all makes sense, and clarifies the various options that are
available.

Regards,

John