[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Re: Moving to TSC?
------=_NextPart_000_003F_01CAE587.F84FDE90
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi K,
currently I'm working with the RCM3720 and DinamicC 9.62. I want to
develop=
3 different xap based devices, now I'm with the first of them, building th=
e xap library that is common to all these devices. I have some
funcionaliti=
es yet coded so when I finish the testing of the xap library I can reuse
it=
in the other devices.
I don't know softools but I will try to search for it to know something
abo=
ut it.
About the TSC implementation, the device I want to develop is a
currentcost=
gateway, an energy meter from www.currentcost.com and I will need TSC to s=
end with xap, values of power and temperature at a specific time.
Best regards
Jose
From: Kevin Hawkins=20
Sent: Monday, April 26, 2010 12:38 PM
To: xAP_developer@xxxxxxx=20
Subject: Re: [xAP_developer] Re: Moving to TSC?
=20=20
Do let me know how you get on with Rabbit - which processor and=20
development environment are you using ? My xAP gateway devices are=20
based on the 3700 and DC9.62 but I'm looking at moving now to Softools.
K
On 29/03/2010 23:41, jlgalindo wrote:
> I will need the TSC capabilites in a near future, to develop an
applicati=
on for a rabbit microcontroller, so I'm with Daniel and the others for a
fi=
nal implementation of the TSC schema or another solution to work with real
=
numbers and units, maybe it's possible to add this feature to the BSC
schem=
a, for example adding optional fields like "value" and
"unit".
>
> Jose Luis
>
> --- In xAP_developer@xxxxxxx, Kevin Hawkins<yahoogroupskh@...>
wr=
ote:
>=20
>> 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:
>>=20
>>> 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 shoul=
d take the first step and try to implement TSC into a controller. This
woul=
d 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
implementatio=
n for opn-mbs. This will give us the opportunity to take a more practical
g=
lance at the issue. We'll come back then with new questions so we'll be
abl=
e to start a debate in a proper way.
>>>
>>> Daniel.
>>>
>>>
>>> --- In xAP_developer@xxxxxxx, "Daniel
Berenguer"<dberenguer@> w=
rote:
>>>
>>>=20
>>>> I support Lehane's proposal about re-working TSC. I think
that, with s=
ome minor changes, TSC could become pretty usable, even for embedded
device=
s with current BSC support.
>>>>
>>>> Daniel.
>>>>
>>>>
>>>> --- In xAP_developer@xxxxxxx, "Lehane Kellett
(g8kmh)"<g8kmh@>=
wrote:
>>>>
>>>>=20
>>>>> 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 i=
s
>>>>> 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 shoul=
d
>>>>> look at some revisions or even deprecation of some
elements in order =
to
>>>>> help adoption?
>>>>>
>>>>> Lehane
>>>>>
>>>>>
>>>>>
>>>>> Kevin Hawkins wrote:
>>>>>
>>>>>=20
>>>>>>
>>>>>> I had always envisaged BSC and TSC both existing
side by side and
>>>>>> hopefully being supported by nearly all devices.
My hope with TSC wa=
s
>>>>>> that it would be sufficiently similar to BSC that
it could share lar=
ge
>>>>>> 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 paramete=
rs
>>>>>> 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:
>>>>>>
>>>>>>=20
>>>>>>> Thanks Kevin and Lehane for your responses.
>>>>>>>
>>>>>>>
>>>>>>>=20
>>>>>>>> From an academic point of view, I agree in
that BSC and TSC
>>>>>>>>
>>>>>>>>=20
>>>>>> shouldn't be mutually exclusive. However, managing
multiple schemas
>>>>>> into embedded devices is sometimes hard to do,
mainly if both schema=
s
>>>>>> 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.
>>>>>>
>>>>>>=20
>>>>>>> On the other hand, this kind of discussions
could be addressed in a
>>>>>>>
>>>>>>>=20
>>>>>> 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.
>>>>>>
>>>>>>=20
>>>>>>> Daniel.
>>>>>>>
>>>>>>>
>>>>>>> --- In xAP_developer@xxxxxxx
>>>>>>>
>>>>>>>=20
>>>>>> <mailto:xAP_developer%40yahoogroups.com>,
Kevin T<kevin@> wrote:
>>>>>>
>>>>>>=20
>>>>>>>
>>>>>>>=20
>>>>>>>> Gents
>>>>>>>>
>>>>>>>> Personaly I have never regarded TSC as a
replacement for BSC. I am
>>>>>>>>
>>>>>>>>=20
>>>>>> sure this
>>>>>>
>>>>>>=20
>>>>>>>> was not the intention.
>>>>>>>>
>>>>>>>> I have always regarded TSC more as a
better way of handing analog
>>>>>>>>
>>>>>>>>=20
>>>>>> rather
>>>>>>
>>>>>>=20
>>>>>>>> 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
>>>>>>>>
>>>>>>>>=20
>>>>>> BSC, and
>>>>>>
>>>>>>=20
>>>>>>>> sometimes even alongside other schema like
xap-temperature. There =
is no
>>>>>>>> reason for the schema to be mutually
exclusive, they can co-exist,
>>>>>>>>
>>>>>>>>=20
>>>>>> and/or
>>>>>>
>>>>>>=20
>>>>>>>> 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:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>=20
>>>>>>>>> Daniel,
>>>>>>>>> I think one reason for the current
lack of TSC adoption is there
>>>>>>>>>
>>>>>>>>>=20
>>>>>> are few
>>>>>>
>>>>>>=20
>>>>>>>>> devices supporting it, none public
AFAIK. Hammering out the
>>>>>>>>>
>>>>>>>>>=20
>>>>>> remaining issues
>>>>>>
>>>>>>=20
>>>>>>>>> shouldn't prove too difficult.
>>>>>>>>>
>>>>>>>>> A more widescale adoption would, I
think, take xAP adoption to a
>>>>>>>>>
>>>>>>>>>=20
>>>>>> new level.
>>>>>>
>>>>>>=20
>>>>>>>>> I don't see why TSC shouldn't be
adopted by Floorplan (James has
>>>>>>>>>
>>>>>>>>>=20
>>>>>> some hooks
>>>>>>
>>>>>>=20
>>>>>>>>> in already) and other widely used
applications/mappers over time
>>>>>>>>>
>>>>>>>>>=20
>>>>>> but right
>>>>>>
>>>>>>=20
>>>>>>>>> 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 th=
e
>>>>>>>>> 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 pu=
shed
>>>>>>>>> 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 o=
f 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 dat=
a
>>>>>>>>> transported each time so converting
these data to xAP BSC would m=
ake
>>>>>>>>> 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 curr=
ent
>>>>>>>>> TSC draft too. However, what bothers
me is that BSC is the most
>>>>>>>>> implemented schema and abandoning it
would reduce interoperabilit=
y 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 B=
SC
>>>>>>>>> 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 ve=
ry
>>>>>>>>> carefully. But instead of starting a
new controversy, I want to d=
o a
>>>>>>>>> simple question to the active xAP
developers:
>>>>>>>>>
>>>>>>>>> How many among you are willing to
move/implement TSC into your cu=
rrent
>>>>>>>>> BSC applications in the short term?
>>>>>>>>>
>>>>>>>>> I wouldn't want my controllers to
become a TSC island into the BS=
C
>>>>>>>>> sea. As any other I/O device, they
need interoperability with maj=
or
>>>>>>>>> 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>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>=20
>>>>>>>>
>>>>>>>>=20
>>>>>>>
>>>>>>> ------------------------------------
>>>>>>>
>>>>>>> Yahoo! Groups Links
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>=20
>>>>>>
>>>>>>=20
>>>>>
>>>>>=20
>>>>
>>>>=20
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>=20
>>=20
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>=20
------=_NextPart_000_003F_01CAE587.F84FDE90
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.0
Transitional//EN">
<HTML><HEAD>
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML
8.00.6001.18904"></HEAD>
<BODY
style="BACKGROUND-COLOR: #fff; PADDING-LEFT: 10px; PADDING-RIGHT:
10px; PADDING-TOP: 15px"
id=MailContainerBody leftMargin=0 topMargin=0
CanvasTabStop="true"
name="Compose message area">
<!-- **begin egp html banner** -->
<br><br>
<!-- **end egp html banner** -->
<DIV><FONT face=Calibri>Hi K,</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>currently I'm working with the
RCM3720 and DinamicC
9.62. I want to develop 3 different xap based devices, now I'm with the
first of
them, building the xap library that is common to all these
devices. I have
some funcionalities yet coded so when I finish the testing of the xap
library I
can reuse it in the other devices.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>I don't know softools but I will try to
search for it to
know something about it.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>About the TSC implementation, the
device I want to
develop is a currentcost gateway, an energy meter from <A
href="http://www.currentcost.com";>www.currentcost.com</A> and
I will need
TSC to send with xap, values of power and temperature at a specific
time.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>Best regards</FONT></DIV>
<DIV><FONT face=Calibri>Jose</FONT></DIV>
<DIV style="FONT: 10pt Tahoma">
<DIV><BR></DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B>
<A
title=yahoogroupskh@xxxxxxx
href="mailto:yahoogroupskh@xxxxxxx";>Kevin
Hawkins</A> </DIV>
<DIV><B>Sent:</B> Monday, April 26, 2010 12:38
PM</DIV>
<DIV><B>To:</B> <A title=xAP_developer@xxxxxxx
href="mailto:xAP_developer@xxxxxxx";>xAP_developer@xxxxxxx</A>
</DIV>
<DIV><B>Subject:</B> Re: [xAP_developer] Re: Moving to
TSC?</DIV></DIV></DIV>
<DIV><BR></DIV><SPAN style="DISPLAY:
none"> </SPAN>
<DIV id=ygrp-text>
<P>Do let me know how you get on with Rabbit - which processor and
<BR>development environment are you using ? My xAP gateway devices
are <BR>based
on the 3700 and DC9.62 but I'm looking at moving now to
Softools.<BR><BR>K<BR><BR>On 29/03/2010 23:41,
jlgalindo wrote:<BR>> I will
need the TSC capabilites in a near future, to develop an application for a
rabbit microcontroller, so I'm with Daniel and the others for a final
implementation of the TSC schema or another solution to work with real
numbers
and units, maybe it's possible to add this feature to the BSC schema, for
example adding optional fields like "value" and
"unit".<BR>><BR>> Jose
Luis<BR>><BR>> --- In <A
href="mailto:xAP_developer%40yahoogroups.com";>xAP_developer@<WBR>yahoogroups.<WBR>com</A>,
Kevin Hawkins<yahoogroups<WBR>kh@...>
wrote:<BR>> <BR>>> I did
take a look at including TSC in my xAP gateway (although
there<BR>>>
wasn't a real need for it). In the end I couldn't practically
support<BR>>> it all and some aspects I found confusing
so I backed it
out. I think<BR>>> it's important that TSC is an 'all
or nothing'
implementation as<BR>>> otherwise it won't achieve
seamless
interoperability.<BR>>><BR>>>
K<BR>>><BR>>> On
29/03/2010 13:29, Daniel Berenguer wrote:<BR>>>
<BR>>>> 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.<BR>>>><BR>>>>
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.<BR>>>><BR>>>>
Daniel.<BR>>>><BR>>>><BR>>>>
--- In <A
href="mailto:xAP_developer%40yahoogroups.com";>xAP_developer@<WBR>yahoogroups.<WBR>com</A>,
"Daniel Berenguer"<dberengu<WBR>er@>
wrote:<BR>>>><BR>>>>
<BR>>>>> 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.<BR>>>>><BR>>>>>
Daniel.<BR>>>>><BR>>>>><BR>>>>>
--- In <A
href="mailto:xAP_developer%40yahoogroups.com";>xAP_developer@<WBR>yahoogroups.<WBR>com</A>,
"Lehane Kellett (g8kmh)"<g8kmh@<WBR>>
wrote:<BR>>>>><BR>>>>>
<BR>>>>>>
Kevin,<BR>>>>>> I think xAPBSC and
TSC can only co-exist in some
simpler devices - my<BR>>>>>>
current (only) implementation is
for the TOM10 where (a) the code is
C#<BR>>>>>> .NET and so space
isn't an issue and (b) the xAPBSC
implementation<BR>>>>>> hasn't
changed from a previous version. Where the complexity of TSC
is<BR>>>>>> required then xAPBSC
may be a subset, typically I'd
expect for<BR>>>>>>
status/reporting purposes rather than
control, although gross
control<BR>>>>>> (on/off) could be
either.<BR>>>>>><BR>>>>>>
Given the status of TSC
and the low number of adopters maybe we
should<BR>>>>>> look at
some revisions or even deprecation of some elements in order
to<BR>>>>>> help
adoption?<BR>>>>>><BR>>>>>>
Lehane<BR>>>>>><BR>>>>>><BR>>>>>><BR>>>>>>
Kevin Hawkins
wrote:<BR>>>>>><BR>>>>>>
<BR>>>>>>><BR>>>>>>>
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>>>>>>><BR>>>>>>>
<BR>>>>>>>> Thanks
Kevin and Lehane for your
responses.<BR>>>>>>>><BR>>>>>>>><BR>>>>>>>>
<BR>>>>>>>>>
From an academic point of view, I agree in
that BSC and
TSC<BR>>>>>>>>><BR>>>>>>>>>
<BR>>>>>>> shouldn't be
mutually exclusive. However, managing
multiple schemas<BR>>>>>>>
into embedded devices is sometimes
hard to do, mainly if both
schemas<BR>>>>>>> don't
follow
identical mechanisms. Embedded controllers have
limited<BR>>>>>>> flash
space and the UDP parsing must be done
in a very dynamic
way.<BR>>>>>>> Thus, I
would prefer to deal
with a single schema for
embedded<BR>>>>>>> devices.
That's
all. Other more powerful controllers like
opn-max<BR>>>>>>>
could manage (and map) as many schemas as
nedded.<BR>>>>>>><BR>>>>>>>
<BR>>>>>>>> On the
other hand, this kind of discussions
could be addressed in
a<BR>>>>>>>><BR>>>>>>>>
<BR>>>>>>> future thread.
At this moment, I just wanted to
know about other
xAP<BR>>>>>>> developers
currently working
(or planning to work) on a xAP
TSC<BR>>>>>>>
implementation.<BR>>>>>>><BR>>>>>>>
<BR>>>>>>>>
Daniel.<BR>>>>>>>><BR>>>>>>>><BR>>>>>>>>
--- In <A
href="mailto:xAP_developer%40yahoogroups.com";>xAP_developer@<WBR>yahoogroups.<WBR>com</A><BR>>>>>>>><BR>>>>>>>>
<BR>>>>>>>
<mailto:xAP_<WBR>developer%<WBR>40yahoogroups.<WBR>com>,
Kevin
T<kevin@>
wrote:<BR>>>>>>><BR>>>>>>>
<BR>>>>>>>><BR>>>>>>>>
<BR>>>>>>>>>
Gents<BR>>>>>>>>><BR>>>>>>>>>
Personaly I have never regarded TSC as a replacement for BSC. I
am<BR>>>>>>>>><BR>>>>>>>>>
<BR>>>>>>> sure
this<BR>>>>>>><BR>>>>>>>
<BR>>>>>>>>>
was not the
intention.<BR>>>>>>>>><BR>>>>>>>>>
I have always regarded TSC more as a better way of handing
analog<BR>>>>>>>>><BR>>>>>>>>>
<BR>>>>>>>
rather<BR>>>>>>><BR>>>>>>>
<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<BR>>>>>>>>><BR>>>>>>>>>
<BR>>>>>>> BSC,
and<BR>>>>>>><BR>>>>>>>
<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,<BR>>>>>>>>><BR>>>>>>>>>
<BR>>>>>>>
and/or<BR>>>>>>><BR>>>>>>>
<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>>>>>>>>>
<BR>>>>>>>>>>
Daniel,<BR>>>>>>>>>>
I think one reason for the
current lack of TSC adoption is
there<BR>>>>>>>>>><BR>>>>>>>>>>
<BR>>>>>>> are
few<BR>>>>>>><BR>>>>>>>
<BR>>>>>>>>>>
devices supporting it, none public
AFAIK. Hammering out
the<BR>>>>>>>>>><BR>>>>>>>>>>
<BR>>>>>>> remaining
issues<BR>>>>>>><BR>>>>>>>
<BR>>>>>>>>>>
shouldn't prove too
difficult.<BR>>>>>>>>>><BR>>>>>>>>>>
A more widescale adoption would, I think, take xAP adoption to
a<BR>>>>>>>>>><BR>>>>>>>>>>
<BR>>>>>>> new
level.<BR>>>>>>><BR>>>>>>>
<BR>>>>>>>>>>
I don't see why TSC shouldn't be
adopted by Floorplan (James
has<BR>>>>>>>>>><BR>>>>>>>>>>
<BR>>>>>>> some
hooks<BR>>>>>>><BR>>>>>>>
<BR>>>>>>>>>>
in already) and other widely used
applications/<WBR>mappers over
time<BR>>>>>>>>>><BR>>>>>>>>>>
<BR>>>>>>> but
right<BR>>>>>>><BR>>>>>>>
<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
href="http://www.usapiens.com";>http://www.usapiens<WBR>.com</A><<A
href="http://www.usapiens.com";>http://www.usapiens<WBR>.com</A>><BR>>>>>>>>>>
<A href="http://www.opnode.org";>http://www.opnode.<WBR>org</A><<A
href="http://www.opnode.org";>http://www.opnode.<WBR>org</A>><BR>>>>>>>>>><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>>>>>>>>
<BR>>>>>>><BR>>>>>>>
<BR>>>>>><BR>>>>>>
<BR>>>>><BR>>>>>
<BR>>>><BR>>>><BR>>>>
------------<WBR>---------<WBR>---------<WBR>------<BR>>>><BR>>>>
Yahoo! Groups
Links<BR>>>><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 -->
<!-- **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=2141/stime=1272323099";
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=X3oDMTJmMmM3aTMwBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNzIzMjMwOTk-";>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=X3oDMTJkM2lxcjBlBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjcyMzIzMDk5";>
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>
------=_NextPart_000_003F_01CAE587.F84FDE90--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|