[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Moving to TSC?
--------------070905070303070108040603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>
>
>
--------------070905070303070108040603
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** -->
Daniel,<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
Lehane<br>
<br>
<br>
Daniel Berenguer wrote:
<blockquote
cite="mid:79fe8d321003210453t4c2808b9pc59fa3ba063a875d@xxxxxxx"
type="cite"><span style="display:
none;"> </span>
<div id="ygrp-text">
<p>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
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>
</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=2105/stime=1269240653";
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=X3oDMTJmZzJmNDlpBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNjkyNDA2NTM-";>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=X3oDMTJkODlsbXViBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjY5MjQwNjUz";>
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>
--------------070905070303070108040603--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|