The UK Home Automation Archive

Archive Home
Group Home
Search Archive

Advanced Search

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

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
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. 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 but for most applications I think that
infos will be more than enough. I just try to start things in a simple

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

instead of:

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

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


xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.