Re: Consensus on BSC temperature reporting?

["Kevin Hawkins" <lists@xxxxxxxxxxxxxxxxx>]

--- In xap_automation@xxxxxxx, Gregg Liming <gregg@...> wrote:

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

Nah - not taken that way at all - you've identified a really important
issue we need to address in a nice simple way - BSC did that but
maybe should be broader..  It's really good having people making
constructive input :-)

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

I think an instrumentation schema has value as well - I know KevinT
has some strong feelings on this as he's quite involved in process
control.  Temperature was one of his frustartions too...

Ahh - forgot that and actually 'ramp' one is one I myself push into
BSC and those with a C-Bus controller could stick the parameter in and
it will work ;-)  I did add a second 'C-Bus' schema too that has this
documented and if at some stage Lehane (DMX) , Edward (Dynalite) and I
(C-Bus) have a chat we can hopefully produce a unified Lighting schema


> >     Maximum and Minimum values for levels (rather than the
0-100%)
>
> yep--although max is already supported--right?

Well - sort of - in one sense a range extends from 0%-100% maybe 0/255
to 255/255 for a light but temperature is another weird one where the
top/bottom limit is only a restriction of the measuring device -
something might want to report a subset of a range eg 10-50 degrees as
being accurate but might actually have values outside of this with
less accuracy - and shouldnt be zero referenced.

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

This was a way of handling say negative temperature in a level BSC
device. Suppose a device reports 0/1023 to 1023/1023 as representing
the range -10 to +90   negative values being not permissable in the
spec.  You could actually accomodate this by offsetting the reported
value around the 0 reference by an OFFSET=-102 parameter .  Just one
way of preserving existing BSC compatability  - not recommending it as
a good one by any means...

> >     How to handle url/http content in DisplayText and perhaps
associated
> > images
>
> Perhaps you could elaborate "handle url/http content"?


In several applications people have wanted to display html for values
- allowing say bold red text to appear when a value goes above a
certain level perhaps. They have done this by adding html to the
DisplayText parameter. Or again people might want an icon instead of a
value and have added the .jpg or .gif url to the DisplayText to
achieve this. Bulb on / bulb off type thing. Alternatively often this
is added by a display application programatically. Michael McSharry in
the mcs/HomeSeer application uses this a lot for icons and display
values. It would be nice to have an endorsed way of doing it.

>
> >     How to handle list values for parameters , possibly using
> > enumeration  eg Mode='StopPlayFastForwardRewindPauseRecord'
>
> Likewise, what does "handle" mean?
>
Sorry handle means 'manage' - which really encompasses how a xAP
application can ask a device what values are permissable in a certain
parameter. BSC defines these rigidly currently except for TEXT devices
where they are unknown.  Such a feature might present a drop down list
of permissable values to a user 'red' green' 'blue' or 2secs 5secs
10secs for ramp rates.  Unfortunately this apparently simple idea can
get involved too where a device offers different options based on its
current state, a device already in record might not now offer a record
option or only offers 'pause' when in 'play' or 'record' but not when
started by the automatic timer. Also where one parameter is tied in
with another for example you can only set a mode to say 'heat' when
the fan is enabled and the temperature below '20'.  Not ideal examples
but you get the idea...

> >     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.
>
This one was because we had a particular discussion on accomodating
X10 within BSC and it was thought that we shouldn't as X10 was a
schema in its own right.    This is a common request though and I
would expect it to be a 'given' really.

K