[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
RE: Re: xPL/xAP an alternative to C-Bu$ ?
- Subject: RE: Re: xPL/xAP an alternative to C-Bu$ ?
- From: "Kevin Hawkins" <lists@xxxxxxxxxxxxxxxxx>
- Date: Thu, 20 May 2004 15:17:10 +0100
=20
> -----Original Message-----
> From: steve.cooper@xxxxxxx=20
> [mailto:steve.cooper@xxxxxxx]=20
> Sent: 20 May 2004 14:00
> To: ukha_d@xxxxxxx
> Subject: Re: [ukha_d] Re: xPL/xAP an alternative to C-Bu$ ?
This has turned into a long post but I hope it is of interest to some...
RE the use of external switches instead of C-Bus switches possibly via xAP,
a little bit of background first might help...sorry I do intent to write
this up one some webpages more formally soon ! The xAP to C-Bus gateway
allows for two types of control of C-Bus loads (groups). A fancy control
schema that supports all the whizzo groups, scenes and ramp times and the
new xAP 'Basic Status and Control' schema which as the name implies is a
basic system for interoperabilty across many devices that support ON OFF
LEVEL or 'STREAM/TEXT' data. X10 nicely falls into this model as do most
typical devices around your home. Using BSC it is possible to just link
inputs to outputs (or indeed outputs to outputs) such that when one changes
the other does too. We have a very simple (very fast) application released
called 'xAP BSC Mapper' that does exactly this.
So if you have a xAP input device it can generate directly the commands to
switch C-Bus loads ON and OFF or set them to a level. It can also check the
status of all C-Bus loads and receives events when they change state - a
sort of ideal version of how X10 should have been designed if you like.
Bea=
r
in mind that X10 achieves its price positioning by not having all these
feature sthough. Most X10 output devices are receive only for example and
most senders (switches) are transmit only.
So what hardware devices can generate xAP BSC messages and as such control
C-Bus output ? Well we have HomeVision as a supported device such that you
can set C-Bus loads to track the level of a HomeVision variable, or if you
have a switch attached to an input port on HomeVision then altering that
switch will cause a C-Bus light to follow. Likewise the xAP C-Bus gateway
board has some parallel input lines free that you can attach a switch to -
indeed the board will support a keyboard matrix as well. There will also be
a personality available for this board to support the Phaedrus VIOM module
giving you all those inputs (and outputs) that can be married with a C-Bus
equivalent. We also have the ability to send BSC commands from X10 so now
you can switch C-Bus loads from X10 or indeed X10 loads from C-Bus. The
Barix Barionet device has xAP already and IanB's xAP relay board will add
BSC shortly I believe.
Just to mention HomeSeer for which we now have the xAP plugin. Now devices
can be created in HomeSeer that automatically track xAP devices - given
C-Bus appears as a xAP device you end up with a Homeseer device for every
C-Bus load you have so you can apply all your logic and scheduling within
HomeSeer. Conversley -and here's the GREAT bit - any device that exists in
HS can link to a xAP and hence onward to C-Bus. These devices are anything
already in Homeseer. So ANY plugin that already exists for HomeSeer and
creates a device with a state becomes xAP enabled :-) :-) it can send state
change events to xAP and can have its state set by xAP, and could be
'mapped' to a C-Bus endpoint. This means your ' ACME Multi Whizzo I/O' card
that you use in HomeSeer already can be directly lionked to xAP and onwards
to C-Bus - toggle an input and the C-Bus load changes - switch a C-Bus
switch and the Ouput on Whizzo changes.
There are some differences between a true C-Bus switch and a switch
connected via say the C-Bus gateway or C-Gate. Timewise the xAP message has
to be formed, sent out, received, decoded, checked,recoded to the C_Bus
protocol and sent via the SIM module to C-Bus. This introduces a slight
delay between changing your switch and the light changing. Indeed I suspect
currently that both the C-Bus SIM and the RS232 interface introduce a
somewhat unnecessarily long delay here. C-Bus also always 'soft starts'
loads on dimmer units. Way back at UKHA2003 I used C-Gate as my bridge
between xAP and C-Bus which added another step in the sequence and also
restricted me on the set of commands C-Gate exposed rather than the full
C-Bus range. I am working to optimise the speed of response as we speak
although what happens in the SIM or the RS232 firmware is out of my
control=
.
The delay between the switch being pressed and the gateway starting to send
the command to C-Bus is only about 1/20 second currently which is pretty
good.=20
A C-Bus native switch is 'instant' and a true 'C-Bus device allowing
participation in some fairly complex interaction with all the other C-Bus
devices. For example a conflict reconcilliation process takes place every
few seconds to ensure that all switches and loads remain in synch. Although
there is almost never a difference it can happen when for example you break
and then rejoing a network. C-Bus switches also contain light indicators,
frequently dual colour orange/blue and have backlighting. These can all be
utilised in very sophisticated ways for example flashing to indicate timed
delays or at night you can turn off all the switch indicators. When you
first press a switch at night it doesn=92t transmit a keypress but lights
t=
he
switch and status indicators up - very useful in say a bedroom. Switches
also have short press and long press functionality and the type of press eg
ONOFF or DIMMER or DOORBELL is configurable. The fancier switches eg the
Neo's and the Saturn ranges have inbuilt scene controllers too allowing you
to preset a group of loads to come on over a period of time to varying
levels of brightness. Additionally the Neos can receive infra red commands
directly. So regarding a C-Bus switch as just a switch is not the way to
look at it. The 2000 series of switches are lower cost but do away with the
scenes functionality and dual colour LED's. However they are still rather
costly, particulalry in single gang configurations.
So to put all this in perspective I think the C-Bus switches match the
'quality' of the C-Bus experience. They work fast and have great
functionality but you can augment them with full control via xAP for things
like scheduling and logic control - 'if this - then that' type sequences.
You can add low cost hardware switches via xAP and this is very useful in
different setups - and of course you can use the C-Bus Bus Coupler to
attac=
h
4 switches to C-Bus using any standard toggle or momentary switches
(momentary prefereably). This retails at =A375 though which is the same
cos=
t
as an E2000 series 4 gang switch (surprising).
>=20
>=20
> > I disagree with the unreliable claim. An X-10 system can be
very=20
> > reliable if it is planned correctly with the appropriate=20
> number of=20
> > filters and amplifiers.
>=20
> I have to agree with this.=20
I still operate a hybrid C-Bus and X10 system. Mainly as people have
said to do with the cost of the C-Bus switches (particulalrly where you
nee=
d
single gang) but also for a couple of areas where I don=92t have the
approriate wiring for C-Bus. I have found that my X10 is nearly always
reliable and the main drawbacks are the known 'limitations' rather than
reliability. I do have a couple of places in my home where X10 just doesn=
=92t
work including one particular socket in the middle of a ring - adjacent
sockets work fine. The known drawbacks are the latency in turning on due
t=
o
the X10 transmission time , the lack of status feedback and the 'on at
full=
'
type operation of some modules, really the ones that cant be DIN rail
mounted. I have one reliability issue with my external floods in that I
can always switch them on but rarely can switch them off via X10. However
without X10 I wouldn=92t have automation in these areas due to
practicaliti=
es
and cost. Plus the ability to mix and match X10 and C-Bus using xAP and BSC
makes it all seem the same anyway !
Kevin
UKHA_D Main Index |
UKHA_D Thread Index |
UKHA_D Home |
Archives Home
|