Re: Comments about TSC

["estratosapiens" <dberenguer@xxxxxxxxxxxx>]

Following my own considerations...

We could implement point 2 without altering the current spec as follows:

value=[0, 1]
min=0
max=1

Thus we get a nice binary signal through TSC.

Daniel.


--- In xAP_developer@xxxxxxx, "estratosapiens"
<dberenguer@...> wrote:
>
> 4. I'd prefer to do
>
> unit=(unit designation)
> -- desirable
>
> rather than
>
> unit=(unit designation)
> -- mandatory
>
> Thus, instead of doing unit=arb, the sender wouldn't include this
field in the body. This is a way of compacting information a little more,
mainly if my second suggestion gets somehow accepted :-)
>
> Daniel.
>
> --- In xAP_developer@xxxxxxx, Daniel Berenguer <dberenguer@>
wrote:
> >
> > Following Kevin's call-up request, I've revisited the TSC (v.42)
> > specification draft and have found some points that I would like
to
> > discuss here:
> >
> > 1. TSC.query vs TSC.request
> > The document mixes both classes so I understand that it's an
error.
> > Which is the correct class?
> >
> > 2. TSC for numeric values - BSC for states
> > I understand that BSC can still be used for many applications but
I
> > believe that TSC should be able to manage binary states too.
> > Otherwise, we'll be force to do dual-implementations almost in
any
> > device. BSC's main strengths are interoperability and the fact
that
> > it's a common schema for all. I agree that TSC is a more complete
> > schema that could replace BSC for most applications but having to
> > manage TSC for numeric and BSC for binary is a nonsense in my
opinion.
> > Why not using value=on/off in TSC too? From my point of view, we
need
> > simple mechanisms capable to do complex things. One schema for
all is
> > perfect for gateways and embedded controllers. Otherwise, we'll
have
> > to manage with queries/commands from different schemas, send
> > duplicated events/infos, ... I also agree that we'll have to keep
BSC
> > for backward compatibility in current designs but once TSC will
be
> > widely adopted, TSC is a perfect candidate for becoming the main
xAP
> > interoperable schema for control and telemetry applications.
> >
> > 3. Response to TSC.cmd resets
> > The specification states that the response to a TSC.cmd (counter)
> > reset has to be a TSC.info after having reseted the counter. This
> > breaks BSC's command/event query/info mechanisms and, will force
us to
> > manage a exception when receiving RESET commands. Why not sending
a
> > TSC.event after reseting the counter? Reseting a counter means
that
> > the endpoint will change its value (if not 0 before that).
> >
> > There are a lot of common points between BSC and TSC and I
appreciate
> > this as it will simplify the adoption of the later schema. On the
> > other hand, all my suggestions are targeted to simplify the
> > implementation (lines of code and processing speed) and give more
> > power to TSC. Instead of creating a new schema, I'd have
preferred to
> > enrich BSC with new fields but the creation of TSC is something
good
> > because we have now the opportunity to customize this schema for
M2M
> > apps. On the other hand, implementing new protocosl or schemas is
> > something time-costly so we'll have to be very precise and
effective
> > in our work.
> >
> > I vote for one schema for all in the M2M area. TSC for M2M and
BSC for
> > basic home automation stuff. Isn't it too late for coming here
with
> > such arguments?
> >
> > Thanks for your time,
> >
> > --
> > Daniel Berenguer
> > http://www.usapiens.com
> > http://www.opnode.org
> >
>




------------------------------------