RE: Floorplan beta 3 released

["Paul Gale" <groups@xxxxxxxxxxxxxxxx>]

Thanks Kevin,

So are there any hardware devices that support BSC yet - or is it all
software?

-----Original Message-----
From: xap_automation@xxxxxxx
[mailto:xap_automation@xxxxxxx] On
Behalf Of Kevin Hawkins
Sent: 23 June 2005 20:37
To: xap_automation@xxxxxxx
Subject: Re: [xap_automation] Floorplan beta 3 released

Paul Gale wrote:

>
>
>
> Also, can someone explain what BSC is and does?
>
>
>
> Thanks,
>
>
>
> Paul.
>
Hi Paul,

OK - here we go....

Short version  "BSC allows simple devices to be discovered &
interoperate in a realtime plug and play fashion using xAP"
Switches & lighting / X10 type devices are a
good example.

Long version...

BSC is a xAP schema - a definition of a xAP message content if you
like, it defines what parameters are to be included in messages of
specific types.  BSC stands for "Basic Status and Control" and
pretty
much does what it says on the tin.  It is designed to provide a way of
discovering, controlling and tracking the status of a simple device in
realtime.  A simple device is an endpoint that can be represented as any

of 3 distinct types.... BINARY onoff,  LEVEL (in any number of steps eg

0-100 or 0-65535 , 50% etc)  or lastly TEXT which is any value
represented as a text string eg "32 degrees Centigrade", 
"BBC1" ,
"Rain" , "12:56" or "ColdPlay" etc - ie just
about anything that doesn't

drop in as a BINARY or LEVEL device.

An important clarification is that this applies to an endpoint (or
node) so a single device that has say 8 digital inputs, 8 digital
outputs, 4 analog inputs and a serial port has in fact got 22 endpoints
, 16 x BINARY, 4 x LEVEL and 2 x TEXT .  xAP very neatly supports sub
addressing which allows a device to have one main xAP address and then a

sub address for each endpoint - in this case 22 sub address endpoints
This allows a single xAP device to parent many different endpoints eg

source = ACME.Controller.Main:Sprinklers      -     note the :

... would be the endpoint "Sprinklers" attached to the device
ACME.Controller.Main  - likely this is a BINARY endpoint by which you
can turn the sprinklers on and off.    Now because all our 'endpoints'
are sub addresses of the main ACME controller we can use the wildcard
addressing capability of xAP  to ask the ACME controller what endpoints
it has and what capabilities each supports - we can also check the
status of any individual enpoint or indeed groups or all of the
endpoints at once.  This is an amazingly powerful aspect of xAP that
comes from supporting sub addresses and wildcarding of the target
addresses .

The overall effect is that devices can be discovered, and their
capabilities are announced allowing them to be controlled and tracked
immediately in realtime in an almost 'plug and play' fashion.  This is
very useful for controllers, be they hardware or software like xAP
Desktop, HomeSeer, XLobby, xAP Floorplan, BSC Mapper etc as they don't
need to understand a device specific schema to handle the device.    BSC

is if you like a 'lowest common denominator' of control for many devices

and 95% of devices can fit into a BSC model.

The above doesn't imply that people should only use BSC - indeed more

complex devices eg a big AV amplifier would have a richer schema to
control it , it may expose a limited subset of its functionality via BSC

though, perhaps ONOFF and VOLUME or something.    Many devices support
both a BSC schema alongside a richer , more focussed schema - the Netiom

does this as does Edwards X10 conduit and my C-Bus lighting.     You
will see for example that lighting drops nicely in as a LEVEL device,
such devices have a 'State' too which can be ON or OFF  so in a way a
LEVEL device is a superset of a BINARY device.  So BSC works very nicely

to control X10 or C-Bus , but BSC doesn't offer a feature to set 'ramp
rate' which is the time a light takes to move from say 10% to 50%  - to
use this feature you would move to the richer lighting schema.  Neatly
however, even when you use a richer schema the BSC schema still sends
out its 'status' and 'event' messages so HomeSeer, Floorplan etc can
track status - nice :-)   In fact this has a reverse application - any
device a controller can see can be represented back on xAP via BSC - so
as there is say a 'Comfort' plugin for Homeseer then Comfort can be
represented  (and hence controlled) via xAP - instantly our library of
xAP devices has expanded by all the plugins available for Homeseer.

Had there not already been a 'Meteor' plugin for xAP then it would be
achievable using the Meteor HomeSeer plugin :-)

As you are considering xAP Floorplan at the moment Paul,  BSC
provides a way for Floorplan to immediately recognise devices and
control them which is ideal.  Of course it can be used with devices that

use their own schema too - eg the Meteor CID schema from xAPTel - but
that just takes a little more setting up.


For more bedtime reading the BSC spec is published here -

http://www.xapautomation.org/modules.php?name=xAP_Content&pa=showpage&pi
d=xapbsc

Kevin