[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Re: Proposals for xAP TSC
--------------080308020005060804010909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Daniel,
I'm not sure I agree that TSC isn't suitable as it would remove many of
the ambiguities inherent in BSC's representation of real world data.
However, I do now understand the problem with the capabilities requests,
since I guess as a gateway you may not know the capabilities of the
remote network/systems.
I wouldn't say TSC is only suitable for P2P but I accept a controller
with multiple (hundreds) TSC endpoints, of varying type, will require
more horspower - so probably along the lines of Floorplan, Housebot,
Homeseer, etc. There the application can maintain all the information
relevant to each endpoint. Whilst in an embedded controller application
you are more interested in compact data structures, in a (Java, c++,
C#,...) you use the applicable data structure to meet the program goals,
making trade offs as required. So, if I needed 500 endpoints at 10Kb per
endpoint, it wouldn't worry me - well, not too much ;-)
I disagree about BSC being good as you can pipe abstract data through it
- that's led to some of the issues, such as encoding of temperature data
and using text strings where knowledge of the endpoint is required to
interpret it. My personal view is that the consuming
device/controller/application should, from the class/schema, be able to
derive what the 'type' of data or control is. I'd rather we had more
schemas....
So, as Keven says in another mail, maybe what is required is a TSC lite
or Basic TSC?
Lehane
On 27/04/2010 14:27, Daniel Berenguer wrote:
>
> Thanks Lehane for the feedback.
>
> Responding to your last question, I primarily use xAP for bridging
> between IP and other buses. I'm currently maintaining two kind of
> controllers, communicating under xAP BSC:
>
> A) Gateways: they basically pipe field bus information from 1-Wire,
> Modbus, CAN, etc to xAP BSC. The gateway maintains an internal table
> of endpoints so that the gateway is seen from the outside as an IO
> controller with a variable amount of endpoints (up to 500 endpoints in
> some cases).Working as pure mappers, these gateways are continuously
> polling or listening for information on the lower bus and provide a
> full BSC interface to the xAP network. Most of the low level devices
> connected to these gateways are generic IO devices (multi-master or
> slaves) that can be used from xAP BSC for any purpose, including
> heating control or alarm signalization. Thus, I'd have expected TSC
> (or any other new schema) to provide more generic mechanisms to
> implement "data piping".
>
> Implementing TSC for this case would involve:
>
> - Using BSC for binary endpoints and text, TSC for analog endpoints.
> - Double use of BSC and TSC for analog endpoints during the first
> months as we need to provide compatibility with the existing BSC
> products before their switch to TSC.
> - Maintain two different arrays of endpoints or merge both schemas
> into a common structure.
>
> B) Main controller (opn-max, but also valid for HomeSeer or Mr.House I
> guess): this device queries all available BSC endpoints in the network
> in a simple manner. Then, the controller stores every endpoint
> information and maintains a live copy of the BSC network in memory.
> Then, users can work with this data from scripts, Web server, etc.
>
> In both cases, data is stored in endpoint structures. The more compact
> is the information stored, the more endpoints can be managed by a
> single controller.
>
> xAP BSC is perfect for most of the M2M applications I think. The only
> objections are IMO the level-text different management and the lack of
> a "unit" field. But for the rest of features, BSC is a very
good
> abstract schema that lets you pipe almost any information through
> UDP/IP. Because of this, I'd have preferred to work on a possible
> evolution of BSC instead of switching to a new schema. I now
> understand the motivations of TSC and agree in that TSC is specially
> suitable for vertical "peer-to-peer" applications like
heating
> control. There is no objection then, I surely was wrong about
> considering TSC as an evolution (improvement) of BSC. Kevin's post
> about spoiling us towards the switch to TSC didn't help either ;-)
>
> Daniel.
>
> --- In xAP_developer@xxxxxxx
> <mailto:xAP_developer%40yahoogroups.com>,
"Lehane Kellett (g8kmh)"
> <g8kmh@...> wrote:
> >
> > My comments in the text below. Apologies for the delay.
> >
> > Lehane
> >
> > On 17/04/2010 18:08, Daniel Berenguer wrote:
> > >
> > > No comments? Come on guys! ;-)
> > >
> > > --- In xAP_developer@xxxxxxx
> <mailto:xAP_developer%40yahoogroups.com>
> > > <mailto:xAP_developer%40yahoogroups.com>,
Daniel Berenguer
> > > <dberenguer@> wrote:
> > > >
> > > > I'm just starting to code the TSC extension for the
opnode libxap
> > > > library and have some remarks regarding the current TSC
specs:
> > > >
> > > > Question DB1: (DB is me :-))
> > > > Setpoints will force us to manage at least two values
per
> endpoint (a
> > > > temperature value and a setpoint) and an additional
keyword
> > > > ("setpoint") in the section title. Generic IO
devices will have to
> > > > provide a way to associate an optional setpoint to any
generic
> analog
> > > > input, not very straightforward.
> > > >
> > > > Proposal DB2:
> > > > I suggest to remove the setpoint feature and take any
real
> setpoint as
> > > > a new endpoint. IMO, the "one value per
endpoint" paradigm is much
> > > > easier to implement in embedded devices, against the
"multiple
> values
> > > > per endpoint". When I say "value" I
really mean "variable
> value". xAP
> > > > BSC brought this problem too, where a single endpoint
could have a
> > > > value (text or level) and a binary state. We could then
simplify
> > > > things for TSC. Doing this, we'll be able to compact
endpoint tables
> > > > in memory and simplify message parsing.
> > > >
> > >
> > I disagree with the moving of, in this case, setpoint to a
different
> > endpoint.
> > Indeed management of a number of values to an endpoint doesn't
> > seem too big an overhead. It would also create even more
divergence from
> > BSC, something TSC is already crticised for.
> >
> > At the smaller end of the CPU scale the IO device probably is
only
> managing
> > a temp and setpoint.
> >
> > > > Question DB2:
> > > > I was expecting to deal with TSC.capability as an
optional
> class, not
> > > > supported in the first versions. TSC.info is IMO a
simpler way to
> > > > discover devices because it's sent periodically whilst
> TSC.capability
> > > > is sent only as a response to a TSC.query with
request.capability
> > > > body. Am I right? I know that TSC.capability will
provide more
> > > > detailed results than TSC.info but for most
applications I think
> that
> > > > infos will be more than enough. I just try to start
things in a
> simple
> > > > manner.
> > > >
> > > > Proposal DB2:
> > > > OK, assuming that we're allowed to not to support
TSC.capability,
> > > > could we maybe move the type=input/output information
to the
> TSC.info
> > > > body? Master applications like opn-max need to know
whether
> endpoints
> > > > are controllable (outputs) or not (inputs). BSC
contained this
> > > > information in the section ttile. E.g: output.state.1,
> input.state.1.
> > > > I'd suggest to follow the BSC way regarding this too.
As result,
> we'd
> > > > have section titles like the following ones, at least
for TSC cmd's,
> > > > events, infos and queries:
> > > >
> > > > input.humidity
> > > > output.temperature (an example of setpoint, see
Question DB2)
> > > > output.level
> > > >
> > > > instead of:
> > > > event.humidity
> > > > cmd.temperature
> > > > info.level
> > > >
> > > > In fact, "event", "cmd",
"info" and "query" are already contained in
> > > > the xAP class field.
> > >
> >
> >
> >
> > > >
> > > > Question DB3:
> > > > "unit" field is supposed to be mandatory in
TSC commands, events and
> > > > infos. I can agree in that events and infos must
contain the unit
> > > > information but, why commands? I'm thinking in master
> controllers like
> > > > opn-max: A very lightweight implementation of TSC would
force the
> > > > controller to maintain the unit information in the
table of
> endpoints
> > > > too.
> > > >
> > > > Proposal DB3:
> > > > Remove "uni"t from the TSC.cmd body. In fact,
TSC.cmd's could
> > > > transport only the relevant information to be changed
in the target
> > > > device, something like xAP BSC
> > > > This has a minor importance but I'd also make unit
optional when no
> > > > unit is specified (no unit field instead of unit=arb).
> > > > This proposal would abstract the source device from the
type of data
> > > > to be controlled in the target device. This would
reduce the size of
> > > > TSC commands too.
> > >
> > The reason units was there was, for example, to change a
setpoint.
> > Without the
> > units it could be in Celsius or Fahrenheit. The controller
doesn't need
> > to maintain
> > the units as long as internally it converts to the working value.
It
> > also only reports
> > in whatever value it wishes. So you could send 68F and get 20C in
> the info.
> > >
> > > >
> > > > Question DB4:
> > > > Why ID=* is not accepted? How can we control multiple
endpoints in a
> > > > single TSC.cmd body?
> > > >
> > > > Proposal DB4:
> > > > Allow ID=*. This can be useful to reset outputs for
example.
> > >
> > It wasn't included as the intended consequences could be
> unpredictable with
> > the complexity of TSC. I think if we go with this it will require
some
> > clarity of documentation as to how it can be used but this is
doable.
> >
> > In what context do you see this working?
> >
> > > >
> > > > Question DB5:
> > > > According to the TSC draft, counters are a special case
where
> inbound
> > > > commands produce outbound infos. This will force us to
treat
> counters
> > > > apart, not as any other endpoint.
> > > >
> > > > Proposal DB5:
> > > > We should keep here the command->event /
query->info mechanism too,
> > > > similar to xAP BSC. Thus, reseting a counter will proce
a TSC event,
> > > > not an info.
> > >
> > Yes, this should be changed.
> >
> > > >
> > > > Question DB6:
> > > > For real alarms, is the alarm body mandatory?
> > > > Is the capability class mandatory?
> > > >
> > > > Proposal DB6:
> > > > Make any body other than cmd, event and info optional.
This will
> allow
> > > > lightweight implementations of TSC (very important for
the first
> > > > adoption stages). Again, this will compact messages in
simple
> > > > implementations (embedded controllers).
> > >
> > Currently, yes for alarms but it could be changed I guess.
Normally
> > you'd want to
> > know the current process value (temperature, etc) when the alarm
is
> > triggered....
> >
> > Capability could be made optional but I think some more thought
> would be
> > needed
> > around how devices advertise their features.
> >
> > The aim of TSC wasn't about simplicity but to be comprehensive
and, yes,
> > endpoints in themselves would be more complex to code than BSC
but
> typically
> > an embedded device only has a few endpoints.
> >
> > I guess the question around controllers is whether they aim to be
> > multipurpose and
> > so control many (tens, hundreds) TSC devices/endpoints - in which
> case I
> > don't believe
> > embedded systems are they way to go (though some recent devices
have
> more
> > power and RAM than my first PC!) - or single purpose, like a
heating
> > system controller -
> > in which case embedded would be fine.
> >
> >
> > > >
> > > > As you see, most of my questions/proposals are aimed to
make xAP TSC
> > > > more compact, simpler to implement and more similar to
BSC. This
> will
> > > > definitely simplify its adoption, at least in embedded
devices, and
> > > > will make TSC and BSC more cohabitable.
> > >
> > Daneil,
> > Can you expand on the kind of devices you envisage a problem
with?
> Maybe my
> > view is that a simple device, like a thermostat, has one or two
sensors
> > (temp/RH)
> > and is a single endpoint. Or a watt/hour meter, maybe two
endpoints.
> And TSC
> > and BSC can co-exist, with some additional coding complexity
agreed.
> >
> > I didn't envisage a simple controller doing both and perhaps
that's
> what you
> > are aiming for.
> >
> > Lehane
> >
> >
> >
> > > >
> > > > Thanks for your time,
> > > >
> > > > --
> > > > Daniel Berenguer
> > > > http://www.usapiens.com <http://www.usapiens.com>
> <http://www.usapiens.com <http://www.usapiens.com>>
> > > > http://www.opnode.org <http://www.opnode.org>
> <http://www.opnode.org <http://www.opnode.org>>
> > > >
> > >
> >
>
>
--------------080308020005060804010909
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'm not sure I agree that TSC isn't suitable as it would remove many of
the ambiguities inherent in BSC's representation of real world data.
However, I do now understand the problem with the capabilities
requests, since I guess as a gateway you may not know the capabilities
of the remote network/systems. <br>
<br>
I wouldn't say TSC is only suitable for P2P but I accept a controller
with multiple (hundreds) TSC endpoints, of varying type, will require
more horspower - so probably along the lines of Floorplan, Housebot,
Homeseer, etc. There the application can maintain all the information
relevant to each endpoint. Whilst in an embedded controller application
you are more interested in compact data structures, in a (Java, c++,
C#,...) you use the applicable data structure to meet the program
goals, making trade offs as required. So, if I needed 500 endpoints at
10Kb per endpoint, it wouldn't worry me - well, not too much ;-)<br>
<br>
I disagree about BSC being good as you can pipe abstract data through
it - that's led to some of the issues, such as encoding of temperature
data and using text strings where knowledge of the endpoint is required
to interpret it. My personal view is that the consuming
device/controller/application should, from the class/schema, be able to
derive what the 'type' of data or control is. I'd rather we had more
schemas....<br>
<br>
So, as Keven says in another mail, maybe what is required is a TSC lite
or Basic TSC?<br>
<br>
Lehane<br>
<br>
<br>
<br>
On 27/04/2010 14:27, Daniel Berenguer wrote:
<blockquote cite="mid:hr6oo5+1dtm@xxxxxxx"
type="cite"><span
style="display: none;"> </span>
<div id="ygrp-text">
<p>Thanks Lehane for the feedback.<br>
<br>
Responding to your last question, I primarily use xAP for bridging
between IP and other buses. I'm currently maintaining two kind of
controllers, communicating under xAP BSC:<br>
<br>
A) Gateways: they basically pipe field bus information from 1-Wire,
Modbus, CAN, etc to xAP BSC. The gateway maintains an internal table of
endpoints so that the gateway is seen from the outside as an IO
controller with a variable amount of endpoints (up to 500 endpoints in
some cases).Working as pure mappers, these gateways are continuously
polling or listening for information on the lower bus and provide a
full BSC interface to the xAP network. Most of the low level devices
connected to these gateways are generic IO devices (multi-master or
slaves) that can be used from xAP BSC for any purpose, including
heating control or alarm signalization. Thus, I'd have expected TSC (or
any other new schema) to provide more generic mechanisms to implement
"data piping".<br>
<br>
Implementing TSC for this case would involve:<br>
<br>
- Using BSC for binary endpoints and text, TSC for analog
endpoints.<br>
- Double use of BSC and TSC for analog endpoints during the first
months as we need to provide compatibility with the existing BSC
products before their switch to TSC.<br>
- Maintain two different arrays of endpoints or merge both schemas into
a common structure.<br>
<br>
B) Main controller (opn-max, but also valid for HomeSeer or Mr.House I
guess): this device queries all available BSC endpoints in the network
in a simple manner. Then, the controller stores every endpoint
information and maintains a live copy of the BSC network in memory.
Then, users can work with this data from scripts, Web server,
etc.<br>
<br>
In both cases, data is stored in endpoint structures. The more compact
is the information stored, the more endpoints can be managed by a
single controller.<br>
<br>
xAP BSC is perfect for most of the M2M applications I think. The only
objections are IMO the level-text different management and the lack of
a "unit" field. But for the rest of features, BSC is a very good
abstract schema that lets you pipe almost any information through
UDP/IP. Because of this, I'd have preferred to work on a possible
evolution of BSC instead of switching to a new schema. I now understand
the motivations of TSC and agree in that TSC is specially suitable for
vertical "peer-to-peer" applications like heating control. There
is no
objection then, I surely was wrong about considering TSC as an
evolution (improvement) of BSC. Kevin's post about spoiling us towards
the switch to TSC didn't help either ;-)<br>
<br>
Daniel.<br>
<br>
--- In <a moz-do-not-send="true"
href="mailto:xAP_developer%40yahoogroups.com";>xAP_developer@<wbr>yahoogroups.<wbr>com</a>,
"Lehane Kellett (g8kmh)" <a
class="moz-txt-link-rfc2396E" href="mailto:g8kmh@...";><g8kmh@...></a>
wrote:<br>
><br>
> My comments in the text below. Apologies for the delay.<br>
> <br>
> Lehane<br>
> <br>
> On 17/04/2010 18:08, Daniel Berenguer wrote:<br>
> ><br>
> > No comments? Come on guys! ;-)<br>
> ><br>
> > --- In <a moz-do-not-send="true"
href="mailto:xAP_developer%40yahoogroups.com";>xAP_developer@<wbr>yahoogroups.<wbr>com</a>
<br>
> > <<a class="moz-txt-link-freetext"
href="mailto:xAP_";>mailto:xAP_</a><wbr>developer%<wbr>40yahoogroups.<wbr>com>,
Daniel Berenguer <br>
> > <dberenguer@<wbr>> wrote:<br>
> > ><br>
> > > I'm just starting to code the TSC extension for
the
opnode libxap<br>
> > > library and have some remarks regarding the
current TSC
specs:<br>
> > ><br>
> > > Question DB1: (DB is me :-))<br>
> > > Setpoints will force us to manage at least two
values
per endpoint (a<br>
> > > temperature value and a setpoint) and an
additional
keyword<br>
> > > ("setpoint") in the section title.
Generic IO devices
will have to<br>
> > > provide a way to associate an optional setpoint
to any
generic analog<br>
> > > input, not very straightforward.<br>
> > ><br>
> > > Proposal DB2:<br>
> > > I suggest to remove the setpoint feature and
take any
real setpoint as<br>
> > > a new endpoint. IMO, the "one value per
endpoint"
paradigm is much<br>
> > > easier to implement in embedded devices, against
the
"multiple values<br>
> > > per endpoint". When I say "value"
I really mean
"variable value". xAP<br>
> > > BSC brought this problem too, where a single
endpoint
could have a<br>
> > > value (text or level) and a binary state. We
could then
simplify<br>
> > > things for TSC. Doing this, we'll be able to
compact
endpoint tables<br>
> > > in memory and simplify message
parsing.<br>
> > ><br>
> ><br>
> I disagree with the moving of, in this case, setpoint to a
different <br>
> endpoint.<br>
> Indeed management of a number of values to an endpoint
doesn't<br>
> seem too big an overhead. It would also create even more
divergence from<br>
> BSC, something TSC is already crticised for.<br>
> <br>
> At the smaller end of the CPU scale the IO device probably is only
managing<br>
> a temp and setpoint.<br>
> <br>
> > > Question DB2:<br>
> > > I was expecting to deal with TSC.capability as
an
optional class, not<br>
> > > supported in the first versions. TSC.info is IMO
a
simpler way to<br>
> > > discover devices because it's sent periodically
whilst
TSC.capability<br>
> > > is sent only as a response to a TSC.query with
request.capability<br>
> > > body. Am I right? I know that TSC.capability
will
provide more<br>
> > > detailed results than TSC.info but for most
applications
I think that<br>
> > > infos will be more than enough. I just try to
start
things in a simple<br>
> > > manner.<br>
> > ><br>
> > > Proposal DB2:<br>
> > > OK, assuming that we're allowed to not to
support
TSC.capability,<br>
> > > could we maybe move the type=input/output
information to
the TSC.info<br>
> > > body? Master applications like opn-max need to
know
whether endpoints<br>
> > > are controllable (outputs) or not (inputs). BSC
contained this<br>
> > > information in the section ttile. E.g:
output.state.<wbr>1,
input.state.<wbr>1.<br>
> > > I'd suggest to follow the BSC way regarding this
too. As
result, we'd<br>
> > > have section titles like the following ones, at
least
for TSC cmd's,<br>
> > > events, infos and queries:<br>
> > ><br>
> > > input.humidity<br>
> > > output.temperature (an example of setpoint, see
Question
DB2)<br>
> > > output.level<br>
> > ><br>
> > > instead of:<br>
> > > event.humidity<br>
> > > cmd.temperature<br>
> > > info.level<br>
> > ><br>
> > > In fact, "event", "cmd",
"info" and "query" are already
contained in<br>
> > > the xAP class field.<br>
> ><br>
> <br>
> <br>
> <br>
> > ><br>
> > > Question DB3:<br>
> > > "unit" field is supposed to be
mandatory in TSC
commands, events and<br>
> > > infos. I can agree in that events and infos must
contain
the unit<br>
> > > information but, why commands? I'm thinking in
master
controllers like<br>
> > > opn-max: A very lightweight implementation of
TSC would
force the<br>
> > > controller to maintain the unit information in
the table
of endpoints<br>
> > > too.<br>
> > ><br>
> > > Proposal DB3:<br>
> > > Remove "uni"t from the TSC.cmd body.
In fact, TSC.cmd's
could<br>
> > > transport only the relevant information to be
changed in
the target<br>
> > > device, something like xAP BSC<br>
> > > This has a minor importance but I'd also make
unit
optional when no<br>
> > > unit is specified (no unit field instead of
unit=arb).<br>
> > > This proposal would abstract the source device
from the
type of data<br>
> > > to be controlled in the target device. This
would reduce
the size of<br>
> > > TSC commands too.<br>
> ><br>
> The reason units was there was, for example, to change a setpoint.
<br>
> Without the<br>
> units it could be in Celsius or Fahrenheit. The controller doesn't
need <br>
> to maintain<br>
> the units as long as internally it converts to the working value.
It <br>
> also only reports<br>
> in whatever value it wishes. So you could send 68F and get 20C in
the info.<br>
> ><br>
> > ><br>
> > > Question DB4:<br>
> > > Why ID=* is not accepted? How can we control
multiple
endpoints in a<br>
> > > single TSC.cmd body?<br>
> > ><br>
> > > Proposal DB4:<br>
> > > Allow ID=*. This can be useful to reset outputs
for
example.<br>
> ><br>
> It wasn't included as the intended consequences could be
unpredictable with<br>
> the complexity of TSC. I think if we go with this it will require
some<br>
> clarity of documentation as to how it can be used but this is
doable.<br>
> <br>
> In what context do you see this working?<br>
> <br>
> > ><br>
> > > Question DB5:<br>
> > > According to the TSC draft, counters are a
special case
where inbound<br>
> > > commands produce outbound infos. This will force
us to
treat counters<br>
> > > apart, not as any other endpoint.<br>
> > ><br>
> > > Proposal DB5:<br>
> > > We should keep here the command->event /
query->info mechanism too,<br>
> > > similar to xAP BSC. Thus, reseting a counter
will proce
a TSC event,<br>
> > > not an info.<br>
> ><br>
> Yes, this should be changed.<br>
> <br>
> > ><br>
> > > Question DB6:<br>
> > > For real alarms, is the alarm body
mandatory?<br>
> > > Is the capability class mandatory?<br>
> > ><br>
> > > Proposal DB6:<br>
> > > Make any body other than cmd, event and info
optional.
This will allow<br>
> > > lightweight implementations of TSC (very
important for
the first<br>
> > > adoption stages). Again, this will compact
messages in
simple<br>
> > > implementations (embedded
controllers)<wbr>.<br>
> ><br>
> Currently, yes for alarms but it could be changed I guess.
Normally <br>
> you'd want to<br>
> know the current process value (temperature, etc) when the alarm
is <br>
> triggered...<wbr>.<br>
> <br>
> Capability could be made optional but I think some more thought
would be <br>
> needed<br>
> around how devices advertise their features.<br>
> <br>
> The aim of TSC wasn't about simplicity but to be comprehensive
and, yes,<br>
> endpoints in themselves would be more complex to code than BSC but
typically<br>
> an embedded device only has a few endpoints.<br>
> <br>
> I guess the question around controllers is whether they aim to be
<br>
> multipurpose and<br>
> so control many (tens, hundreds) TSC devices/endpoints - in which
case I <br>
> don't believe<br>
> embedded systems are they way to go (though some recent devices
have more<br>
> power and RAM than my first PC!) - or single purpose, like a
heating <br>
> system controller -<br>
> in which case embedded would be fine.<br>
> <br>
> <br>
> > ><br>
> > > As you see, most of my questions/proposals are
aimed to
make xAP TSC<br>
> > > more compact, simpler to implement and more
similar to
BSC. This will<br>
> > > definitely simplify its adoption, at least in
embedded
devices, and<br>
> > > will make TSC and BSC more
cohabitable.<br>
> ><br>
> Daneil,<br>
> Can you expand on the kind of devices you envisage a problem with?
Maybe my<br>
> view is that a simple device, like a thermostat, has one or two
sensors <br>
> (temp/RH)<br>
> and is a single endpoint. Or a watt/hour meter, maybe two
endpoints. And TSC<br>
> and BSC can co-exist, with some additional coding complexity
agreed.<br>
> <br>
> I didn't envisage a simple controller doing both and perhaps
that's what you<br>
> are aiming for.<br>
> <br>
> Lehane<br>
> <br>
> <br>
> <br>
> > ><br>
> > > Thanks for your time,<br>
> > ><br>
> > > --<br>
> > > Daniel Berenguer<br>
> > > <a moz-do-not-send="true"
href="http://www.usapiens.com";>http://www.usapiens<wbr>.com</a>
<<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>
<<a moz-do-not-send="true" href="http://www.opnode.org";>http://www.opnode.<wbr>org</a>><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=2146/stime=1272442558";
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=X3oDMTJmY3FjdHU3BF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNzI0NDI1NTg-";>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=X3oDMTJkdDdzN2I3BF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjcyNDQyNTU4";>
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>
--------------080308020005060804010909--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|