Re: Consensus on BSC temperature reporting?

[Gregg Liming <gregg@xxxxxxxxxxx>]

Hi Kevin,

Quoting Kevin Hawkins (8/29/06 9:50 AM):
>     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.

I had no intent of "throwing rocks" or "stirring the
hornet's nest".
Hopefully, the situation you describe doesn't completely remain in some
form of impasse.  Personally, I would be very much in favor of a
"reasonable" extension to BSC if it allowed the inclusion of so
many
more devices--especially if these extensions are optional and
non-intrusive.  When I worked on the misterhouse support, I could tell
this was a huge problem as so many "simple" devices had to be
relegated
to being treated as is they were BSC "streamers" (i.e., map the
state to
the text field).

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

I totally agree.

>  The
> other possibility is some form of instrumentation schema which maybe
is
> appropriate for temperature, weather, process control etc.

That would be better than doing nothing; but, there are plenty of
"simple devices" that can't be sufficiently mapped into BSC that
don't
(IMO) fit into an instrumentation schema.  Lighting (ramps, incremental
level adjusts, etc) are examples of what I would consider simple that
don't quite fit an instrumentation "genre".

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

Thanks for the reminder as I had forgotten.  Obviously, using such a
tactic can mean lack of certain interoperability.  But, possibly doing
so can alleviate the "stuff it all in the text field" tactic that
otherwise has to occur.

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

yep--although max is already supported--right?

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

I can't quite understand intended usage unless as argument in a command.
Is that correct?

>     A declaration of units (eg degrees Kelvin, Centigrade,
Fahrenheit),
> or a statement of which must be used

Definitely.  Implied units and/or scales is a horrid practice.

>     How to handle url/http content in DisplayText and perhaps
associated
> images

Perhaps you could elaborate "handle url/http content"?

>     How to handle list values for parameters , possibly using
> enumeration  eg Mode='StopPlayFastForwardRewindPauseRecord'

Likewise, what does "handle" mean?

>     Incremental Level changes  eg Level=+10%  or Level=-50   (cf
> Level=50/255) say.

Yes!! I'm quite surprised that something that "simple" could be
argued.