Re: Re: Moving to TSC?

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

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, 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.opnode.org
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>



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