Re: Proposals for xAP TSC

["Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>]

No comments? Come on guys! ;-)


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




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