Re: Moving to TSC?

["Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>]

This is something that we can't postpone IMO. Although I had expected 
a higher interest on this subject, I agree with Lehane in that someone
should take the first step and try to implement TSC into a controller. This
would give us a better idea about the strengths and weakness of TSC in
embedded devices and maybe will inspire other developers as well.

In a few weeks, Kevin H and me are going to work on a TSC implementation
for opn-mbs. This will give us the opportunity to take a more practical
glance at the issue. We'll come back then with new questions so we'll be
able to start a debate in a proper way.

Daniel.


--- In xAP_developer@xxxxxxx, "Daniel Berenguer"
<dberenguer@...> wrote:
>
> 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
>




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