[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Re: Moving to TSC?
--------------090406050405030901000808
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
> >
> >
> >
> >
> >
>
>
--------------090406050405030901000808
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<head>
<style type="text/css">
<!--
/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}
div.photo-title
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;
}
div.attach-table div.attach-row {
clear: both;
}
div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}
p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}
div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}
div.attach-table div.attach-row div div span {
font-weight: normal;
}
div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<!-- **begin egp html banner** -->
<br><br>
<!-- **end egp html banner** -->
Kevin,<br>
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.<br>
<br>
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?<br>
<br>
Lehane<br>
<br>
<br>
<br>
Kevin Hawkins wrote:
<blockquote cite="mid:4BA802AD.5050300@xxxxxxx"
type="cite"><span
style="display: none;"> </span>
<div id="ygrp-text">
<p>I had always envisaged BSC and TSC both existing side by side and
<br>
hopefully being supported by nearly all devices. My hope with TSC was
<br>
that it would be sufficiently similar to BSC that it could share large
<br>
areas of code and not really incur any extra overhead in supporting
both <br>
rather than just say TSC. In a way TSC being BSC with extra parameters
<br>
and a relaxation of some constraints on existing ones (eg decimal
<br>
places, negative values etc). Obviously by it's nature TSC will be
<br>
more involved than BSC.<br>
<br>
At this stage I'm feeling we haven't quite achieved that but maybe
<br>
others don't agree with an intention ever to try and do so ? Having
<br>
played a little with TSC it doesn't present that commonality - maybe
<br>
that's the nature of the beast - but I have a few reservations about
the <br>
schema and had great difficulty in creating a sensible model to <br>
implement it alongside BSC. Lehane - have you actually got both BSC
<br>
and TSC fully implemented in your embedded devices ?<br>
<br>
K<br>
<br>
On 22/03/2010 17:29, Daniel Berenguer wrote:<br>
> Thanks Kevin and Lehane for your responses.<br>
><br>
> > 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.<br>
><br>
> 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.<br>
><br>
> Daniel.<br>
><br>
><br>
> --- In <a moz-do-not-send="true"
href="mailto:xAP_developer%40yahoogroups.com";>xAP_developer@<wbr>yahoogroups.<wbr>com</a>,
Kevin T<a class="moz-txt-link-rfc2396E" href="mailto:kevin@...";><kevin@...></a>
wrote:<br>
> <br>
>> Gents<br>
>><br>
>> Personaly I have never regarded TSC as a replacement for
BSC.
I am sure this<br>
>> was not the intention.<br>
>><br>
>> I have always regarded TSC more as a better way of handing
analog rather<br>
>> than digital vaules. The handling of analogs within BSC
was
always a<br>
>> compromise and TSC was the answer.<br>
>><br>
>> Where I have tried to implement TSC it has always been
alongside BSC, and<br>
>> sometimes even alongside other schema like
xap-temperature.
There is no<br>
>> reason for the schema to be mutually exclusive, they can
co-exist, and/or<br>
>> you coulld chose to tuyrn one or the other off<br>
>><br>
>> Kevin T<br>
>> (the other Kevin)<br>
>><br>
>> On 22 March 2010 06:49, Lehane Kellett
(g8kmh)<g8kmh@<wbr>...>
wrote:<br>
>><br>
>> <br>
>>><br>
>>> Daniel,<br>
>>> I think one reason for the current lack of TSC
adoption is
there are few<br>
>>> devices supporting it, none public AFAIK.
Hammering out
the remaining issues<br>
>>> shouldn't prove too difficult.<br>
>>><br>
>>> A more widescale adoption would, I think, take xAP
adoption to a new level.<br>
>>> I don't see why TSC shouldn't be adopted by
Floorplan
(James has some hooks<br>
>>> in already) and other widely used
applications/<wbr>mappers
over time but right<br>
>>> now there is no motivation to do so. Chicken and
Egg.<br>
>>><br>
>>> Regards,<br>
>>> Lehane<br>
>>><br>
>>><br>
>>><br>
>>> Daniel Berenguer wrote:<br>
>>><br>
>>><br>
>>><br>
>>> After reading Kevin's post about the necessity to
migrate
to xAP TSC<br>
>>> for actual telemetry applications I've being
considering
doing the<br>
>>> jump for my recent projects. First of all, I
wanted to do
a first try<br>
>>> on opn-mbs, my Modbus opnode. I didn't like how
data was
being pushed<br>
>>> into the BSC text field where data and units had
to
coexist most of<br>
>>> the time. For my own projects, I never add the
units at
the end of the<br>
>>> text field because this complicates data parsing
on other
BSC<br>
>>> applications but some other applications need to
know
which kind of<br>
>>> data is being transported by any BSC message. This
is what
I call the<br>
>>> "plug and play" feature. A temperature
controller can
understand the<br>
>>> data sent by temperature sensors with very little
programming on the<br>
>>> controller.<br>
>>><br>
>>> Some protocols like J1939, Zigbee and KNX specify
the type
of data<br>
>>> transported each time so converting these data to
xAP BSC
would make<br>
>>> us consider the following scenarios:<br>
>>><br>
>>> 1. Lose of information. BSC doesn't inform about
the type
of data<br>
>>> transmitted.<br>
>>> 2. Add units at the end of the BSC text
field<br>
>>> 3. Add proprietary field ("units",
"type" or whatever else)<br>
>>><br>
>>> As you can see, moving to TSC is something
technically
useful IMO<br>
>>> although we should address some pending issues
regarding
the current<br>
>>> TSC draft too. However, what bothers me is that
BSC is the
most<br>
>>> implemented schema and abandoning it would reduce
interoperability to<br>
>>> the TSC products. Obviously, we should combine
both BSC
and TSC<br>
>>> schemas, at least during the first years, in order
to
guarantee<br>
>>> interoperability with current BSC solutions but
this is
something not<br>
>>> desirable because of the increment of the xAP code
footprint.<br>
>>><br>
>>> Based on the above reasoning, I'd always vote for
enriching xAP BSC<br>
>>> instead of abandoning it regardless of TSC's
advantages.<br>
>>> Interoperability and the current BSC
implementations are
the best<br>
>>> "heritage" of xAP IMO so we should take
this kind of
decisions very<br>
>>> carefully. But instead of starting a new
controversy, I
want to do a<br>
>>> simple question to the active xAP
developers:<br>
>>><br>
>>> How many among you are willing to move/implement
TSC into
your current<br>
>>> BSC applications in the short term?<br>
>>><br>
>>> I wouldn't want my controllers to become a TSC
island into
the BSC<br>
>>> sea. As any other I/O device, they need
interoperability
with major<br>
>>> software like HomeSeer, HouseBot, Mr.House or
Xlobby but
haven't heart<br>
>>> about any intention to do the jump for these
applications.<br>
>>><br>
>>> Thanks guys for your feedback.<br>
>>><br>
>>> --<br>
>>> Daniel Berenguer<br>
>>> <a moz-do-not-send="true"
href="http://www.usapiens.com";>http://www.usapiens<wbr>.com</a><br>
>>> <a moz-do-not-send="true"
href="http://www.opnode.org";>http://www.opnode.<wbr>org</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> <br>
>> <br>
><br>
><br>
><br>
>
------------<wbr>---------<wbr>---------<wbr>------<br>
><br>
> Yahoo! Groups Links<br>
><br>
><br>
><br>
><br>
> <br>
<br>
</p>
</div>
<!-- end group email --></blockquote>
<br>
<!-- **begin egp html banner** -->
<br>
<br>
<!-- **end egp html banner** -->
<div width="1" style="color: white; clear:
both;"/>__._,_.___</div>
<!-- Start Recommendations -->
<!-- End Recommendations -->
<!-- **begin egp html banner** -->
<img src="http://geo.yahoo.com/serv?s=97476590/grpId=9629476/grpspId=1705007709/msgId=2109/stime=1269346114";
width="1" height="1"> <br>
<!-- **end egp html banner** -->
<!-- **begin egp html banner** -->
<br>
<div style="font-family: verdana; font-size: 77%; border-top: 1px
solid #666; padding: 5px 0;" >
Your email settings: Individual EmailTraditional <br>
<a href="http://groups.yahoo.com/group/xAP_developer/join;_ylc=X3oDMTJmOXNlOTdjBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNjkzNDYxMTQ-";>Change
settings via the Web</a> (Yahoo! ID required) <br>
Change settings via email: <a href="mailto:xAP_developer-digest@xxxxxxx?subject=Email
Delivery: Digest">Switch delivery to Daily Digest</a> <a
href = "mailto:xAP_developer-fullfeatured@xxxxxxx?subject=Change
Delivery Format: Fully Featured">Switch to Fully Featured</a>
<br>
<a href="http://groups.yahoo.com/group/xAP_developer;_ylc=X3oDMTJkNW50MG5rBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjY5MzQ2MTE0";>
Visit Your Group
</a>
<a href="http://docs.yahoo.com/info/terms/";>
Yahoo! Groups Terms of Use
</a>
<a href="mailto:xAP_developer-unsubscribe@xxxxxxx?subject=Unsubscribe";>
Unsubscribe
</a>
<br>
</div>
<br>
<!-- **end egp html banner** -->
<div style="color: white; clear:
both;"/>__,_._,___</div>
</body>
</html>
--------------090406050405030901000808--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|