Re: Moving to TSC?

["Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>]

Hi Jose Luis,

Extending BSC is indeed possible but doing so would overlap some of the
features provided by TSC. I'd prefer in fact to re-work TSC a little
instead of implementing such extensions on BSC. On the other hand any xAP
developer is allowed to add any proprietary field into a xAP BSC body. The
problem is that other applications won't probably be aware of those
proprietary fields.

Daniel.


--- In xAP_developer@xxxxxxx, "jlgalindo" <jlgalindo@...>
wrote:
>
> I will need the TSC capabilites in a near future, to develop an
application for a rabbit microcontroller, so I'm with Daniel and the others
for a final implementation of the TSC schema or another solution to work
with real numbers and units, maybe it's possible to add this feature to the
BSC schema, for example adding optional fields like "value" and
"unit".
>
> Jose Luis
>
> --- In xAP_developer@xxxxxxx, Kevin Hawkins <yahoogroupskh@>
wrote:
> >
> > I did take a look at including TSC in my xAP gateway (although
there
> > wasn't a real need for it).  In the end I couldn't practically
support
> > it all and some aspects I found confusing so I backed it out.  I
think
> > it's important that TSC is an 'all or nothing' implementation as
> > otherwise it won't achieve seamless interoperability.
> >
> > K
> >
> >   On 29/03/2010 13:29, Daniel Berenguer wrote:
> > > 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
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> >
>




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