BSC 'snippets' from the real world

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

A little down the BSC implementation routes I thought I'd mention a
couple of things that seems to have emerged from my usage & may not be
apparent from the spec...

1)  It is not mandatory for a BSC device to be capable of both transmit
and receive although functionally its features are impacted if it isn't
a transceiver.  A send only BSC device might be a lightswitch for
example with only BSC switch  inputs that issue status and event
messages (and a heartbeat).  As inputs CAN'T have their state changed
via xAP it doesn't need to be a receiver.    A receiver only is perhaps
much less useful (and probably to be discouraged) as you cant confirm
the device is present or check it's status.,  it also won't be
recognised by controllers like HomeSeer, FloorPlan or Mapper even.
However on a cost basis they might exist.

2) BSC Inputs are designed for an application like a switch where the
physical state of the switch defines whether it is on or off.  An analog
input is much the same,  it reads the level of an analog voltage input.
Obvioulsy it is not possible to 'set' such inputs to a value using a xAP
BSC command . Thus xAP commands CANT be sent to inputs, only to outputs.
This has some ramifications where you might want to redefine what
you originally thought was an input to be an output instead. Take for
example a switch with an indicator light on it that shows whether it is
ON or OFF - now the indicator light is really an output. You could
possibly choose to represent such a switch as one input and one output.
If additionally the switch is in a two way lighting circuit (ie 2
switches control one light) then the state of SwitchA can change
depending on SwitchB (if you choose to view them logically as one
switch). Certainly when SwitchA turns the light ON then you probably
want the light on Switch B to glow.  Thus you may wish to consider
defining the actual switch as an output rather than an input.  Both
inputs and outputs can be 'mapped' to other outputs so there is no
problem there.  When the switch is momentary - and used to implement a
press to toggle state it is even more likley implementing it as an
output will be a good approach, this is because such implementatons
usualy employ an indicator and operate in multiway switching circuits .
This view is very dependent on how you choose to logically  view and
interconnect devices. xAP allows you to take any approach you feel
comfortable with (source controls destination or vica versa , and may
involve an intermediary controller if desired). Switches can be
logically viewed individually or as a group as can lights.
Lastly... if your switch has internal 'smarts' and is able to switch
multiple endpoints from addresses it stores internally then if it is an
'input' you can never send a xAP message to change its state so
implementing it as an output is likely to be desireable.

<aside> In the xAP Netiom we originally defined the 'counters' and
'latches' as inputs as they counted the input pulses on the hardware
I/O  inputs - but because they could also be reset/preset via xAP
commands we had to change them to BSC outputs

3) When using a switch to change the current state of a device you can
do this two ways (you can track a devices state and then switch it to
the new state) or you can just send a xAP 'toggle' command - the latter
is much easier and also correctly handles targets that are receivers
only and sources that are transmitters only.

4)  Don't take 'level' as the only type suitable for what appears to be
an apparently level based device.  Level is really aimed for a device
that goes from 0 to 100% of something eg a light dimmer or the depth of
your bath . It can represent this either as a % or a value/granularity
eg 20/1023  meaning it supports 1024 different levels and is currently
at level 20.  This does not handle (for example) temperature well - as
this has no defined top or bottom value and hence using  a text device
for temperature is better - and you can also include the units eg F or C
in the data.

5) The BSC spec doesnt make clear that it is NOT required to include all
the parameters in a xAPBSC.cmd message  block.  However you must include
two to accomplish anything useful.. The first essential is the mandatory
ID and the second at least one of the parameters of STATE LEVEL TEXT (or
DISPLAYTEXT). If you include just one of the parameters then it is
assumed that all other parameters are unchanged.  For example you could
have a light ON at 50% and just send it a Level=75% command and it would
stay ON but move to 75%..   However when a device reports it's state via
a BSC event or info message then it MUST report ALL the parameters
(except DisplayText which is optional).  ie a lamp dimmer must not
report Level=75/100 and omit the State= parameter.
This allows for persistent storage of a Dim level in a light between
ONOFF switching.  You can set a light to ON at 75% then send it a
State=OFF command and then send it a State=ON command and it will come
back on at 75%.
Interestingly, (and definitely my interpretation here as it allows
so much more functionality)  - assuming a light is ON at 75% you can
turn it OFF - send it a Level=20% command and turn it ON (State=ON) and
it will come ON at 20%.    There is an implicit understanding here that
a light showing a state of OFF is indeed OFF even though it may hold a
dim value in Level.   This last bit has proven really useful my C-Bus
implemntation as it allows you to preset /store the level a device will
next come on at, but others may have a different view on whether a
lighting device when turned off should report a Level=0 .


Kevin