Proposals for xAP TSC

[Daniel Berenguer <dberenguer@xxxxxxxxxxxx>]

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.

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.

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.

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.

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).

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,

--
Daniel Berenguer
http://www.usapiens.com
http://www.opnode.org


------------------------------------