[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Moving to TSC?
--001517447dd88387760482652ded
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Gents
Personaly I have never regarded TSC as a replacement for BSC. I am sure
thi=
s
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@xxxxxxx> 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
iss=
ues
> shouldn't prove too difficult.
>
> A more widescale adoption would, I think, take xAP adoption to a new
leve=
l.
> I don't see why TSC shouldn't be adopted by Floorplan (James has some
hoo=
ks
> in already) and other widely used applications/mappers over time but
righ=
t
> 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
>
>
>=20=20
>
--001517447dd88387760482652ded
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<head>
<style type=3D"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=20
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;=20
}
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>
<html>
<head>
<style type=3D"text/css">
<!--
#ygrp-mkp {
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 10px 0;
padding: 0 10px;
}
#ygrp-mkp hr {
border: 1px solid #d8d8d8;
}
#ygrp-mkp #hd {
color: #628c2a;
font-size: 85%;
font-weight: 700;
line-height: 122%;
margin: 10px 0;
}
#ygrp-mkp #ads {
margin-bottom: 10px;
}
#ygrp-mkp .ad {
padding: 0 0;
}
#ygrp-mkp .ad a {
color: #0000ff;
text-decoration: none;
}
-->
</style>
<body>
<!-- **begin egp html banner** -->
<br><br>
<!-- **end egp html banner** -->
<div>Gents</div>
<div>=A0</div>
<div>Personaly I have never regarded TSC as a replacement for BSC. I
am sur=
e this was not the intention. </div>
<div>=A0</div>
<div>I have always regarded TSC=A0more as a better way of handing
analog ra=
ther than digital vaules. The handling of analogs within BSC was always a
c=
ompromise and TSC was the answer. </div>
<div>=A0</div>
<div>Where I have tried to implement TSC it has always been alongside
BSC, =
and sometimes even alongside other schema like xap-temperature.=A0 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</div>
<div>=A0</div>
<div>Kevin T</div>
<div>(the other Kevin)<br><br></div>
<div class=3D"gmail_quote">On 22 March 2010 06:49, Lehane
Kellett (g8kmh) <=
span dir=3D"ltr"><<a href=3D"mailto:g8kmh@xxxxxxx";>g8kmh@xxxxxxx=
</a>></span> wrote:<br>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px
0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">
<div style=3D"BACKGROUND-COLOR:
#fff"><span>=A0</span>=20
<div>
<div>
<div>
<p>Daniel,<br>I think one reason for the current lack of TSC
adoption is th=
ere are few devices supporting it, none public AFAIK. Hammering out the
rem=
aining issues shouldn't prove too difficult.<br><br>A
more widescale ad=
option would, I think, take xAP adoption to a new level. I don't
see wh=
y TSC shouldn't be adopted by Floorplan (James has some hooks in
alread=
y) 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=20
<div>
<div></div>
<div class=3D"h5"><br><br><br>Daniel
Berenguer wrote:=20
<blockquote type=3D"cite"><span>=A0</span>=20
<div>
<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<b=
r>into the BSC text field where data and units had to coexist most
of<br>th=
e 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>applicatio=
ns 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 p=
lay" feature. A temperature controller can understand
the<br>
data sent by temperature sensors with very little programming on
the<br>con=
troller.<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 doe=
sn'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", &=
quot;type" or whatever else)<br>
<br>As you can see, moving to TSC is something technically useful
IMO<br>al=
though we should address some pending issues regarding the
current<br>TSC d=
raft too. However, what bothers me is that BSC is the
most<br>implemented s=
chema 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>Interop=
erability and the current BSC implementations are the
best<br>"heritag=
e" 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>sim=
ple question to the active xAP developers:<br><br>How many
among you are wi=
lling to move/implement TSC into your current<br>BSC applications in
the sh=
ort 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>s=
oftware like HomeSeer, HouseBot, Mr.House or Xlobby but haven't
heart<b=
r>
about any intention to do the jump for these
applications.<br><br>Thanks gu=
ys for your feedback.<br><br>-- <br>Daniel
Berenguer<br><a href=3D"http://w=
ww.usapiens.com/" target=3D"_blank">http://www.usapiens.com</a><br><a
href=
=3D"http://www.opnode.org/";
target=3D"_blank">http://www.opnode.org</a><br>
</p></div></blockquote><br></div></div>
<p></p></p></div>
<div style=3D"MIN-HEIGHT: 0px; COLOR:
#fff"></div></div></blockquote></div>=
<br>
<!-- **begin egp html banner** -->
<br>
=20=20=20=20
=20=20=20=20
<br>
<!-- **end egp html banner** -->
<div width=3D"1" style=3D"color: white; clear:
both;"/>__._,_.___</div>
<!-- Start Recommendations -->
<!-- End Recommendations -->
<!-- **begin egp html banner** -->
<img src=3D"http://geo.yahoo.com/serv?s=3D97476590/grpId=3D9629476/grpspI=
d=3D1705007709/msgId=3D2106/stime=3D1269270983" width=3D"1"
height=3D"1"> <=
br>
<!-- **end egp html banner** -->
=20=20
<!-- **begin egp html banner** -->
<br>
<div style=3D"font-family: verdana; font-size: 77%; border-top: 1px
s=
olid #666; padding: 5px 0;" >
Your email settings: Individual EmailTraditional <br>
<a href=3D"http://groups.yahoo.com/group/xAP_developer/join;_ylc=3DX3=
oDMTJmZDZha2VjBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5B=
HNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNjkyNzA5ODM-">Change settings
via the We=
b</a> (Yahoo! ID required) <br>
Change settings via email: <a href=3D"mailto:xAP_developer-digest@yah=
oogroups.com?subject=3DEmail Delivery: Digest">Switch delivery to
Daily Dig=
est</a> <a href =3D "mailto:xAP_developer-fullfeatured@xxxxxxx?su=
bject=3DChange Delivery Format: Fully Featured">Switch to Fully
Featured</a=
> <br>
<a href=3D"http://groups.yahoo.com/group/xAP_developer;_ylc=3DX3=
oDMTJkamk2NzIyBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5B=
HNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjY5MjcwOTgz">
Visit Your Group=20
</a>
<a href=3D"http://docs.yahoo.com/info/terms/";>
Yahoo! Groups Terms of Use
</a>
<a href=3D"mailto:xAP_developer-unsubscribe@xxxxxxx?subject=
=3DUnsubscribe">
Unsubscribe=20
</a>=20
<br>
</div>
<br>
<!-- **end egp html banner** -->
<div style=3D"color: white; clear:
both;"/>__,_._,___</div>
</body>
</html>
--001517447dd88387760482652ded--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|