Re: Consensus on BSC temperature reporting?

["Daniel Berenguer" <dberenguer@xxxxxxxxxxxxxxxxxxx>]

--- In xap_automation@xxxxxxx, Gregg Liming <gregg@...> wrote:
>
> Hi Lehane,
>
> Quoting Lehane Kellett (8/29/06 3:44 PM):
> > Gregg Liming wrote:
> >> Quoting Lehane Kellett (8/29/06 1:01 PM):
> >>
> >>> OK - so how about new classes - sensor.report and
sensor.cmd?
> >>>
> >>> Devices could be simple (one wire) or complex (complete
CH system).
> >>>
> >>
> >> One reaction that I had is that it appears that each
sensor.report
> >> message has a single body.  Is that correct?  I am asking as
a
result of
> >> having wrestled w/ how to treat one of my physical devices
that
reports
> >> both humidity and temperature (the chip itself does that). 
For
the time
> >> being, I've decided to "virtualize" this single
device into multiple
> >> subaddresses--each having their own xAP UID.  While that
keeps the
> >> mapping of single block to single device clean, it does cause
some
> >> complications--among them having to track multiple UIDs to
single
real
> >> device (which often has it's own real ID).  It also means
that the
> >> reporting interval is somewhat arbitrary from a command
standpoint in
> >> that both ought to give out their values together.  On the
other
hand,
> >> it does make sense from an event standpoint (vice info) as
one of
the 2
> >> measurements passed some delta (change) and not both
> >>
> >
> > I prefer not to virtualise for the reasons you stated and the
complexity
> > is in the sensor - possibly a
> > small device. In most cases determining which value has changed
is
> > trivial in the recipient,
> > assuming you actually need to.
> >
> > However, I'd have no problem with the concept if that was the
consensus.
>
> Well, to be honest, having multiple sections reporting different
sensed
> values as well as handling intantaneous vs averaged values makes
things
> far easier.  Since we're not talking about BSC here (which my
> understanding would prevent this sort of a concept), then the multiple
> section concept is quite plausible?
>
> FWIW: My comment above regarding a "forced virtualization"
was to be
> compliant w/ my interpretation of BSC.  If that's not necessary, then
> I'd definitely like to know as it can be a nuisance.
>
> Gregg
>

I think virtualizing is not so bad. The idea is to address endpoints
and not devices. BSC matches very well with this concept.

On the other hand, having the possibility of receiving the status
about several endpoints, devices or groups in the same message could
save a lot of UDP traffic in some situations. Just as the HomeSeer
schema does. For "event" reporting, BSC does a great job but as
"info"
we could use BSC.info or the new schema, with a summary of different
values.

Daniel.