Re: Consensus on BSC temperature reporting?

["estratosapiens" <dberenguer@xxxxxxxxxxxxxxxxxxx>]

--- In xap_automation@xxxxxxx, Kevin Hawkins <lists@...> wrote:
>
> Hi Gregg,
>
>     When I wrote the BSC specification I was well aware that there
were
> some fairly common devices that BSC was not going to be able to handle
> well. As you say even apparently simple things like temperature have
> awkward issues like no fixed max/min, different units and negative
> values.  However I met considerable resistance to expanding BSC to
> handle such cases on the basis that these situations were not 'basic'
> and should be handled by a more appropriate schema.  Unfortunately the
> people most vocal to keeping BSC simple are also some of the least
vocal
> now in helping create alternative schema.  BSC has been hugely
> successful in promoting plug  and play and standards across xAP and
has
> been an ideal mechanism for incorporating xAP support in third party
> controller software quickly and conveniently.  One of the big
strengths
> of the 'x' protocols (xAP and xPL) is the abstraction of the
> functionality of a device to a schema which allows for
> interchangeability of devices regardless of manufacturer.  For
example a
> 'security' schema would allow any alarm system to be used or 'whole
> house audio' supporting many different mp3 players.  However these
> schema are actually surprisingly complex and time consuming to design
> well, even though they initially appear simple. Even the uPNP guys are
> struggling here with all their resource. Hence in our xAP world we've
> seen 'Meteor' or 'Asterisk' schema instead of CID or Telephony .
> Regardless of this any schema at least makes a device accessible to
xAP
> - it just makes the control of the device bespoke, which in turn
> requires lots of scripting and defeats interoperability of similar
devices.
>
>     Over the past few months I've had feedback & discussions with
a few
> people who feel that a BSCplus or something is required and I think we
> need to recognise that our ability to actually deliver a broad range
of
> rich schema is limited and hence BSCplus does have a role to fill. 
The
> other possibility is some form of instrumentation schema which maybe
is
> appropriate for temperature, weather, process control etc. Already the
> xAP/BSC specification allows people to place their own parameters
within
> a BSC body which a few people (myself included)  have utilised to
> address some of the issues. Perhaps now as you suggest is the time to
> discuss this and get some agreed standards . Here's a few thoughts off
> the top of my head.    Maybe with careful structure  we can augment
BSC
> with extra data (which shouldn't break BSC or any of its parsers) and
> still preserve the integrity of the BSC data
>
>     Maximum and Minimum values for levels (rather than the 0-100%)
>     Threshold/Warning levels perhaps for something as simple as a
thermostat
>     Offset values where the range is say -50 to +100, perhaps by
> allowing negative values or an offset parameter.
>     A declaration of units (eg degrees Kelvin, Centigrade,
Fahrenheit),
> or a statement of which must be used
>     How to handle url/http content in DisplayText and perhaps
associated
> images
>     How to handle list values for parameters , possibly using
> enumeration  eg Mode='StopPlayFastForwardRewindPauseRecord'
>     Incremental Level changes  eg Level=+10%  or Level=-50   (cf
> Level=50/255) say.
>
>    Kevin
>
>
>
>
>
>
>   Gregg Liming wrote:
> >
> > After having searched this list for methods for temperature
reporting
> > w/i BSC, I'm having difficulty determining a consensus. It seems
that
> > while there is a consensus on putting the temperature value in
the
text
> > field, a standard practice for units and scale are missing. In
most
> > cases, "degrees" for units seems implied (although,
I've noted at
least
> > one exception) and then the first letter of the scale is
appended. Is
> > this accurate? Does case matter? Can spaces exist between the
value
> > and "scale letter"?
> >
> > I realize that the "beauty" of BSC is informality, but
my preference
> > would be to drive to a consensus. Or, would adopting some other
schema
> > for temperature reporting be better altogether (i.e., is this
trying to
> > make BSC do too much)?
> >
> > Gregg
> >
> >
>

Nothing against that instrumentation schema but most of the analog
values could be accomodated in a xAP BSC message. It's just a matter
of agreement. Maybe the BSC scheme should impose the way analog values
are represented within the "text" field.

Daniel.