Re: xAP BSC Questions for a MediaPortal Plugin

["ptgxap" <ptgxap@xxxxxxxxx>]

Hi Kevin,

Thanks for the reply!

> I think a stateful image or text is the most
> useful here rather than just a device graphic.
OK, that is pretty much the way I handle it now.
If the text looks like it points to an image, it is(should be)
displayed in MediaPortal as a "state" image.
Else is its displayed as simple text.

> I mentioned on the MediaPortal site that there is an imminent release
of
> the xAPTSC schema due.
OK, I will wait on specifically adding a temperature
device representation until the TSC schema is available.

> I should also mention it is permissible to include your own custom
> parameters within a BSC block.
I think this is a question I was wanting to ask just did not know how
to word it.
If there are simple optional parameters commonly added that would
make (from the perspective of within a GUI frontend) a device
appear more "self configured".
For example, James said that there could be optional name
and location parameters in a message with Homeseer to help xAP Floorplan.
These fit perfectly with my plugin and allow less, from the user,
to setup the device for viewing from within MediaPortal.


> This is how my C-Bus conduit works (implements both schema
concurrently).
I had not thought about that, though I should have.
I guess I will need to add some type on "priority" to my xAP
decoders
to start with the more specific then try the more generic.


Thanks again, you guys have been great!

patrick





--- In xap_automation@xxxxxxx, Kevin Hawkins <lists@...> wrote:
>
> 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
> >
> >
> >
> >
> >
> >
>