Re: DMX and xPL

["g8kmh" <lehane@xxxxxxxxxxxxxxxxxxx>]

Exactly!
My (current)preference is for option 2. Only since it seems more
sense to program the switch to create the command to the light but
either way works. I envisaged a config item/items for the switch for
the command. It would always issue a trigger as well since it may be
that you want other actions based upon the event. No reason why this
couldn't extend to a dimmer control either but anything more complex
and it warrants only sensor outputs.

As you say, xPLHal doesn't have to be part of the system - it will
be but right now I'd like a belt and braces approach that works
stand alone but integrated - of that makes sense!

Lehane

--- In ukha_xpl@xxxxxxx, "John B" <home-automation@j...>
wrote:
> > 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