[Date Prev][Date
Next][Thread Prev][Thread Next][Date
Index][Thread Index]
RE: xAP xPL EIB C-BUS X10 - choice overload!
----- Original Message -----
From: "Kevin Hawkins" <lists@xxxxxxx>
Sent: Wed, 17 Mar 2004 01:06:05 -0000
To: <ukha_d@xxxxxxx>
Subject: RE: [ukha_d] xAP xPL EIB C-BUS X10 - choice overload!
> The 'non compatible' comment I made was that the two protocols by
> themselves present information in different ways and also use
different IP
> ports so are 'blind' to each other. xPLHAL provides a degree of
> interoperability as it has a scriptable bridge however it can not
currently
> represent itself as a true xAP device as it is still lacking certain
bits -
> for example xAP heartbeats and header parameter manipulation.
I know this is on the list to be improved in a future release - I'll see
how this is progressing.
><snip>
> the general 'status' and 'control' information can be translated
between xAP
> and xPL using xPLHAL and a clever bit of scripting could almost do
anything
> in terms of message content translation.
Just to build on what Kevin has said:
xPLHal isn't a bridge in the usual sense of the word - it would not be
possible to do a straight conversion without losing data from some part of
the message.
So, when a message from either xPL or xAP comes into xPLHal, it fires a
script (just a VBScript sub-routine).
This script examines the message, and can construct either an xAP or xPL
message to be sent out.
So an incoming xPL message from Comfort saying that an alarm had been
activated would be picked up by xPLHal, which would then do a quick check
to see if it was dark (by checking the value of a global variable) and if
so, would then send out an xAP message to C-Bus to turn on the lights.
A basic example I know, but hopefully it demonstrates how the two protocols
can be linked.
Now, because many people don't want to have to write any script, we have
something called "Determinators".
These are basically sets of rules that determine what happens to an
incoming message.
In other words: You select Comfort as the source device, select from a list
of things that Comfort can tell you (e.g. security alarm activated).
In the actions section, you define what you want to happen, and which xPL
devices you want to control.
Determinators make use of graphical wizards, and remove the need for any
scripting.
At present they are entirely xPL-based, as obviously xPLHal is still
primarily an xPL application, however I guess some xAP support could be
added if there was sufficient demand.
One of the things I like about xPL is being able to add a device (either
hardware or software) to my network and have xPLHal detect it and provide
me with a graphical configuration system, without me needing to go editing
text files or reading manuals before I can get the device up and running.
Basically I have a single central management console that I can run on any
computer in my house (xPLHal Manager) and see the status of every xPL
device on my network.
There are also context-sensitive menus to allow you to control absolutely
any xPL device instantly - it really does give you a level of control that
you would never imagine possible from a single place.
In summary, both the x protocols make seemingly complex tasks remarkably
easy to achieve - especially when you consider the growing number of
devices/software that has x support.
Regards,
John
UK Home Automation Meet 2004 - BOOK NOW!
http://www.ukha2004.com
http://www.automatedhome.co.uk
Post message: ukha_d@xxxxxxx
Subscribe: ukha_d-subscribe@xxxxxxx
Unsubscribe: ukha_d-unsubscribe@xxxxxxx
List owner: ukha_d-owner@xxxxxxx
Home |
Main Index |
Thread Index
|