Re: Re: Moving to TSC?

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

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
>
>
>
>
>



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