Re: xAP BSC Questions for a MediaPortal Plugin

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Welcome Patrick,

ptgxap wrote:
> Hi everyone,
>
> First post and I already have questions :)
>
> I am working on a plugin for
> MediaPortal(http://www.team-mediaportal.com/)
> to control xAP BSC devices and had some questions.
> (Using the xAPFramework btw)
>

Sounds a great application :-)
> I was wondering if there were common conventions
> used in the BSC messages that are not part of the
> spec but are used commonly.
>
> One example I gathered from reading some posts is that
> a URL to an image is passed in the "DisplayText" via
> the HomeSeer plugin. I was going to let users show this
> image but was not sure what it represented.
> Is this a "Stateful" image or a general image representing
the device?
>
The 'displaytext' parameter was included in BSC really for a degree of
flexibility and its usage is at the developers discretion.  My original
intent was to allow a textual 'state' representation to be sent of a
level for example "High" "Low" "Warning"
"Alarm" etc but several
applications have used it for a URL as you noted, inparticular Michael
McSharry uses this I believe for images and xAP Floorplan can display
formatted text this way.  I think a stateful image or text  is the most
useful here rather than just a device graphic. There are also some apps
that (ab)use 'displaytext' to provide an enumerated state via a level
device for example 1=play 2=stop 3=rewind etc, allowing say a CD player
to be controlled. This latter application was not really the intent of
BSC and there is no easy way for a controller to determine the valid
states.  We do need a simple schema to do this though.....

A BSC Text device will handle these devices much better (displaytext is
still available within text devices too) .  Then you can just send say
'play' 'stop' etc but again no way of enumerating all the possible valid
states is currently available. I think such a mechanism may be useful
expansion to BSC - let me think on that.
> Another question is temp control.
> I know the BSC schema does not support a min value
> but is there a common way this is handled?
> Again for example, does HomeSeer have temp devices that are
> xAP enabled via the connector plugin?
> If so, how are these handled?
>

I mentioned on the MediaPortal site that there is an imminent release of
the xAPTSC schema due. Initially this will probably be released just as
TSC before being formalised into xAPTSC following feedback. TSC is
Telemetry Status and Control and aims to encompass sensor data in a nice
clean simple schema as BSC did for level/binary and text device. TSC
will support real world units (centigrade,bars,volts, metres,
pascals..whatever) and add min ,max average, negative values etc etc.
This of course is ideal for temperature...

In the BSC schema people have either just used a level based device (and
ignored negative values) or have put the values into a text device ,
sometimes with units appended  ie= -11 degrees C . The latter is
obviously preferable but doesn't automagically tie in with a level
display widget as it is a text string.

I should also mention it is permissible to include your own custom
parameters within a BSC block.  Any unexpected values found within a
block will (should) be gracefully ignored by receivers.    So if you
have a xAP BSC sender you could for example add  offset=+50 to a level
devices BSCevent or BSCinfo as a parameter allowing say a temperature
level device to always display positive values. However this is your
implementation only and as such becomes non standard .  Anything that
harms the integrity of BSC is discouraged though and the above example
would be strongly discouraged as it actually invalidates the level value
reported but you could fairly nicely add say a 'deviceicon=url'
parameter into a block to pass such info along with the device or add
some other statistical info inside the block (eg last max time).   The
TSC schema will be the recommended solution though and we hope TCS will
achieve 'grass roots' adoption in controllers in the same way that BSC
has.  BSC and TSC are there to make it really easy for such controllers
to support lots of xAP devices without having to implement a library of
schema or custom schema intpretation.

One very last point. If you find that BSC or TSC is not offering the
features that your device requires then you should add a richer schema
that does include these features naturally.  It may well be desirable to
offer two schemas concurrently , one of which is BSC/TSC and the other a
full implementation. This allows BSC capable controllers to discover and
interact with your device out of the box in basic ways and in enhanced
ways iof they support your richer schema. .  A good example is lighting
control.  BSC Level devices offer very attractive features here for
immediate level and state reporting/control but not for things like
'ramp rates' and 'scenes' or reporting of many states in single messages
(groups) .  You could add a ramprate= parameter into a BSC body but it
wouldn't be supported by standard BSC controllers. So best approach
would be to implement BSC for basic control and then add a 'lighting'
schema that includes the extra functionality. This is how my C-Bus
conduit works (implements both schema concurrently). Also the SlimServer
conduit is similar, basic control is exposed via BSC but the full
featureset is exposed using the xAP-Audio schema.

Cheers Kevin

>
>
> Thanks for any help!
> patrick
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>