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]

Re: Proposals for xAP TSC

  • Subject: Re: Proposals for xAP TSC
  • From: "Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>
  • Date: Sat, 17 Apr 2010 17:08:02 -0000

No comments? Come on guys! ;-)

--- In xAP_developer@xxxxxxx, Daniel Berenguer <dberenguer@...>
> 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
> 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
> 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
> 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
> 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
> 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.