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: Re: DMX and xPL




Then the issue is really one of how to connect these devices, so the switch
can transmit to the lamp.  The nice thing about X10 is that it is easily
retrofitted since it uses existing wiring.  Unfortunately most switches
have
only two wires run to them, which means either placing the logic with the
lamp, or some form of wireless device (or a lot of dust and redecorating!)

I wonder if the time is right for a Super-X10 - a higher speed and reliable
protocol but still using mains wiring?

Is it even possible, or is there just too much noise on the line?

Mal







----- Original Message -----
From: "g8kmh" <lehane@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Tuesday, October 26, 2004 8:13 PM
Subject: [ukha_xpl] Re: DMX and xPL


>
>
> 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
>
>
>
>
>
>
> xPL Links: http://www.xplproject.org.uk http://www.xplhal.com
http://www.xpl.myby.co.uk
> To Post a Message: ukha_xpl@xxxxxxx
> To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> Yahoo! Groups Links
>
>
>
>
>
>
>




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.