[Message Prev][Message Next][Thread Prev][Thread
Next][Message Index][Thread Index]
Proposals for xAP TSC
- Subject: Proposals for xAP TSC
- From: Daniel Berenguer <dberenguer@xxxxxxxxxxxx>
- Date: Wed, 14 Apr 2010 21:18:30 +0200
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
provide a way to associate an optional setpoint to any generic analog
input, not very straightforward.
I suggest to remove the setpoint feature and take any real setpoint as
a new endpoint. IMO, the "one value per endpoint" paradigm is
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 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
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:
output.temperature (an example of setpoint, see Question DB2)
In fact, "event", "cmd", "info" and
"query" are already contained in
the xAP class field.
"unit" field is supposed to be mandatory in TSC commands, events
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
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.
Why ID=* is not accepted? How can we control multiple endpoints in a
single TSC.cmd body?
Allow ID=*. This can be useful to reset outputs for example.
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.
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.
For real alarms, is the alarm body mandatory?
Is the capability class mandatory?
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).
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.
Thanks for your time,
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |