Re: Moving to TSC?

["Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>]

I support Lehane's proposal about re-working TSC. I think that, with
some minor changes, TSC could become pretty usable, even for embedded
devices with current BSC support.

Daniel.


--- In xAP_developer@xxxxxxx, "Lehane Kellett (g8kmh)"
<g8kmh@...> wrote:
>
> Kevin,
> I think xAPBSC and TSC can only co-exist in some simpler devices - my
> current (only) implementation is for the TOM10 where (a) the code is
C#
> .NET and so space isn't an issue and (b) the xAPBSC implementation
> hasn't changed from a previous version. Where the complexity of TSC is
> required then xAPBSC may be a subset, typically I'd expect for
> status/reporting purposes rather than control, although gross control
> (on/off) could be either.
>
> Given the status of TSC and the low number of adopters maybe we should
> look at some revisions or even deprecation of some elements in order
to
> help adoption?
>
> Lehane
>
>
>
> Kevin Hawkins wrote:
> >
> >
> > I had always envisaged BSC and TSC both existing side by side and
> > hopefully being supported by nearly all devices. My hope with TSC
was
> > that it would be sufficiently similar to BSC that it could share
large
> > areas of code and not really incur any extra overhead in
supporting both
> > rather than just say TSC. In a way TSC being BSC with extra
parameters
> > and a relaxation of some constraints on existing ones (eg decimal
> > places, negative values etc). Obviously by it's nature TSC will
be
> > more involved than BSC.
> >
> > At this stage I'm feeling we haven't quite achieved that but
maybe
> > others don't agree with an intention ever to try and do so ?
Having
> > played a little with TSC it doesn't present that commonality -
maybe
> > that's the nature of the beast - but I have a few reservations
about the
> > schema and had great difficulty in creating a sensible model to
> > implement it alongside BSC. Lehane - have you actually got both
BSC
> > and TSC fully implemented in your embedded devices ?
> >
> > K
> >
> > On 22/03/2010 17:29, Daniel Berenguer wrote:
> > > Thanks Kevin and Lehane for your responses.
> > >
> > > > From an academic point of view, I agree in that BSC and
TSC
> > shouldn't be mutually exclusive. However, managing multiple
schemas
> > into embedded devices is sometimes hard to do, mainly if both
schemas
> > don't follow identical mechanisms. Embedded controllers have
limited
> > flash space and the UDP parsing must be done in a very dynamic
way.
> > Thus, I would prefer to deal with a single schema for embedded
> > devices. That's all. Other more powerful controllers like opn-max
> > could manage (and map) as many schemas as nedded.
> > >
> > > On the other hand, this kind of discussions could be
addressed in a
> > future thread. At this moment, I just wanted to know about other
xAP
> > developers currently working (or planning to work) on a xAP TSC
> > implementation.
> > >
> > > Daniel.
> > >
> > >
> > > --- In xAP_developer@xxxxxxx
> > <mailto:xAP_developer%40yahoogroups.com>,
Kevin T<kevin@> wrote:
> > >
> > >> Gents
> > >>
> > >> Personaly I have never regarded TSC as a replacement for
BSC. I am
> > sure this
> > >> was not the intention.
> > >>
> > >> I have always regarded TSC more as a better way of
handing analog
> > rather
> > >> than digital vaules. The handling of analogs within BSC
was always a
> > >> compromise and TSC was the answer.
> > >>
> > >> Where I have tried to implement TSC it has always been
alongside
> > BSC, and
> > >> sometimes even alongside other schema like
xap-temperature. There is no
> > >> reason for the schema to be mutually exclusive, they can
co-exist,
> > and/or
> > >> you coulld chose to tuyrn one or the other off
> > >>
> > >> Kevin T
> > >> (the other Kevin)
> > >>
> > >> On 22 March 2010 06:49, Lehane Kellett
(g8kmh)<g8kmh@> wrote:
> > >>
> > >>
> > >>>
> > >>> Daniel,
> > >>> I think one reason for the current lack of TSC
adoption is there
> > are few
> > >>> devices supporting it, none public AFAIK. Hammering
out the
> > remaining issues
> > >>> shouldn't prove too difficult.
> > >>>
> > >>> A more widescale adoption would, I think, take xAP
adoption to a
> > new level.
> > >>> I don't see why TSC shouldn't be adopted by
Floorplan (James has
> > some hooks
> > >>> in already) and other widely used
applications/mappers over time
> > but right
> > >>> now there is no motivation to do so. Chicken and
Egg.
> > >>>
> > >>> Regards,
> > >>> Lehane
> > >>>
> > >>>
> > >>>
> > >>> Daniel Berenguer wrote:
> > >>>
> > >>>
> > >>>
> > >>> After reading Kevin's post about the necessity to
migrate to xAP TSC
> > >>> for actual telemetry applications I've being
considering doing the
> > >>> jump for my recent projects. First of all, I wanted
to do a first try
> > >>> on opn-mbs, my Modbus opnode. I didn't like how data
was being pushed
> > >>> into the BSC text field where data and units had to
coexist most of
> > >>> the time. For my own projects, I never add the units
at the end of the
> > >>> text field because this complicates data parsing on
other BSC
> > >>> applications but some other applications need to
know which kind of
> > >>> data is being transported by any BSC message. This
is what I call the
> > >>> "plug and play" feature. A temperature
controller can understand the
> > >>> data sent by temperature sensors with very little
programming on the
> > >>> controller.
> > >>>
> > >>> Some protocols like J1939, Zigbee and KNX specify
the type of data
> > >>> transported each time so converting these data to
xAP BSC would make
> > >>> us consider the following scenarios:
> > >>>
> > >>> 1. Lose of information. BSC doesn't inform about the
type of data
> > >>> transmitted.
> > >>> 2. Add units at the end of the BSC text field
> > >>> 3. Add proprietary field ("units",
"type" or whatever else)
> > >>>
> > >>> As you can see, moving to TSC is something
technically useful IMO
> > >>> although we should address some pending issues
regarding the current
> > >>> TSC draft too. However, what bothers me is that BSC
is the most
> > >>> implemented schema and abandoning it would reduce
interoperability to
> > >>> the TSC products. Obviously, we should combine both
BSC and TSC
> > >>> schemas, at least during the first years, in order
to guarantee
> > >>> interoperability with current BSC solutions but this
is something not
> > >>> desirable because of the increment of the xAP code
footprint.
> > >>>
> > >>> Based on the above reasoning, I'd always vote for
enriching xAP BSC
> > >>> instead of abandoning it regardless of TSC's
advantages.
> > >>> Interoperability and the current BSC implementations
are the best
> > >>> "heritage" of xAP IMO so we should take
this kind of decisions very
> > >>> carefully. But instead of starting a new
controversy, I want to do a
> > >>> simple question to the active xAP developers:
> > >>>
> > >>> How many among you are willing to move/implement TSC
into your current
> > >>> BSC applications in the short term?
> > >>>
> > >>> I wouldn't want my controllers to become a TSC
island into the BSC
> > >>> sea. As any other I/O device, they need
interoperability with major
> > >>> software like HomeSeer, HouseBot, Mr.House or Xlobby
but haven't heart
> > >>> about any intention to do the jump for these
applications.
> > >>>
> > >>> Thanks guys for your feedback.
> > >>>
> > >>> --
> > >>> Daniel Berenguer
> > >>> http://www.usapiens.com <http://www.usapiens.com>
> > >>> http://www.opnode.org <http://www.opnode.org>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> >
> >
>




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