xAPBSC v1.3 clarifications....

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

Hi guys,

I've been working with a couple of developers recently who are
implementing BSC and each has raised the same questions so I wanted to
clarify the specification.

When a device endpoint  sends a xAPBSC.event or xAPBSC.info message
then it MUST include all the parameters that it can support. So for
example if it can support displaytext then it must ALWAYS report it even
if it is currently blank/empty.  If your device needs to send an info or
event and a value is unknown then for state it can send state=? and for
level it can send level=?/255 , text and displaytext can be blank of
course.  The level should report the resolution of the device as the
denominator.

When sending a  xAPBSC.cmd message it is NOT necessary to include
all the parameters and indeed there may be no valid parameters at all. (
The ID= parameter is mandatory ).   So a level device might be targeted
with a xAPBSC.cmd with just a state= parameter or  level= or a
displaytext= (or all or none). The device should respond with a
xAPBSC.info if the command did not cause a change of state or a
xAPBSC.event if it did change state.  In the current BSC v1.3 spec the
response should not contain a target= parameter. Note even if there are
no valid parameters in the block then the device must still respond with
a xAPBSC.info.  This is important as it allows device discovery,  for
example of source addresses from UID's.

Please also note that the xAPBSC.cmd message contain a target
parameter in the header and a mandatory  ID= parameter within the block
. The ID parameter either has a '*' value that means that all endpoints
that match the target are being addressed (this could be several
endpoints if the target= includes wildcards) or it can contain an
uppercase hex value that uniquely defines the sub address of the
intended endpoint. In this latter case only one endpoint could respond
but it is also possible that none respond if the ID did not match the
target=  parameter.       As we now have longer UID's with xAP v1.3 bear
in mind that you should handle correspondingly longer ID= values.   If
you use for example 4 digit sub addresses then ID=1A6C is valid.  Always
report all your sub addresses with the same number of digits, so with 6
digits report your sub address as 000001  not 01.

Lastly .. please make sure you support wildcard targeted
xAPBSC.cmd's  that  include a valid  ID= parameter (which could be a hex
value)  ,  especially those including sub address wildcards  eg  >:>
or
>:*.>   or the same combined with 
<vendor>.<device>.<instance>:*.> etc
and send an event or info in response. If your device/application does
not support wildcarding (shame on you) then you should hardcode
recognition of appropriate minimal wildcard contructs or your device
will not be discoverable by some other BSC applications.

cheers Kevin