Re: Re: Proposals for xAP TSC

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

I'd been awaiting a response from someone a little more conversant
with
TSC but I'll add some of my thoughts over the next few days .  One of
the things I too would love to do is make it much more inkeeping with a
BSC type of operation / style but I know there's a lot more issues to
address.     Mostly I am in agreement with what you say although I need
to refresh myself on the TSC schema once again.

Let me mention one where I'm not convinced though...   [DB1] ...  The
point you make about single value endpoint  is awkward  in that there
are 'associated' parameters with an endpoint, setpoint being such an
example  (min, max and units are others).    We need to either group
them together ,especially if they are mandatory, or we need a way to
clearly identify their grouping/associations  should we separate them
into different endpoints.     There is a possibility of using
consecutive subIDs for this or perhaps the address naming hierarchy I
guess but it's a bit untidy.  Maybe there are better ways.

In BSC the association of state and level or indeed displaytext in any
BSC device is such an example and works well. So for all mandatory
parameters I don't see a problem of many parameters in one body
(endpoint)  but optional ones might merit different treatment although
I'm not convinced.   I think handling these extra parameters is a
necessary overhead of TSC - always the mandatory ones and likely the
optional ones too.    For simple devices BSC should be used

[DB2] and [DB6] I haven't really thought about yet......but the other
comments seem to make sense


K



On 17/04/2010 18:08, Daniel Berenguer wrote:
> 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
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>



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