Re: Consensus on BSC temperature reporting?

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

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
>
>