[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Re: Proposals for xAP TSC
--------------090702000907070803040109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>,
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.opnode.org <http://www.opnode.org>
> >
>
--------------090702000907070803040109
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">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<!-- **begin egp html banner** -->
<br><br>
<!-- **end egp html banner** -->
My comments in the text below. Apologies for the delay.<br>
<br>
Lehane<br>
<br>
On 17/04/2010 18:08, Daniel Berenguer wrote:
<blockquote cite="mid:hqcpti+9qvm@xxxxxxx"
type="cite"><span
style="display: none;"> </span>
<div id="ygrp-text">
<p>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>,
Daniel Berenguer <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>
></p>
</div>
</div>
</div>
</blockquote>
I disagree with the moving of, in this case, setpoint to a different
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>
<blockquote cite="mid:hqcpti+9qvm@xxxxxxx"
type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p>> 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>
</p>
</div>
</div>
</div>
</blockquote>
<br>
<br>
<br>
<blockquote cite="mid:hqcpti+9qvm@xxxxxxx"
type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p>> <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>
</p>
</div>
</div>
</div>
</blockquote>
The reason units was there was, for example, to change a setpoint.
Without the<br>
units it could be in Celsius or Fahrenheit. The controller
doesn't
need to maintain<br>
the units as long as internally it converts to the working value. It
also only reports<br>
in whatever value it wishes. So you could send 68F and get 20C in the
info.<br>
<blockquote cite="mid:hqcpti+9qvm@xxxxxxx"
type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p>> <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>
</p>
</div>
</div>
</div>
</blockquote>
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>
<blockquote cite="mid:hqcpti+9qvm@xxxxxxx"
type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p>> <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>
</p>
</div>
</div>
</div>
</blockquote>
Yes, this should be changed.<br>
<br>
<blockquote cite="mid:hqcpti+9qvm@xxxxxxx"
type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p>> <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>
</p>
</div>
</div>
</div>
</blockquote>
Currently, yes for alarms but it could be changed I guess. Normally
you'd want to<br>
know the current process value (temperature, etc) when the alarm is
triggered....<br>
<br>
Capability could be made optional but I think some more thought would
be 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
multipurpose and<br>
so control many (tens, hundreds) TSC devices/endpoints - in which case
I 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
system controller -<br>
in which case embedded would be fine.<br>
<br>
<br>
<blockquote cite="mid:hqcpti+9qvm@xxxxxxx"
type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p>> <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>
</p>
</div>
</div>
</div>
</blockquote>
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
(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>
<blockquote cite="mid:hqcpti+9qvm@xxxxxxx"
type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p>> <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><br>
> <a moz-do-not-send="true" href="http://www.opnode.org";>http://www.opnode.<wbr>org</a><br>
><br>
</p>
</div>
</div>
</div>
</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=2142/stime=1272359625";
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=X3oDMTJmaTB0NzAyBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNzIzNTk2MjU-";>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=X3oDMTJkN2Z0bGwwBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjcyMzU5NjI1";>
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>
--------------090702000907070803040109--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|