Re: Proposals for xAP TSC

["Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>]

Yeah, I'm a fan of multiplexing information into single-value
addressable endpoints, mainly because this allows the definition of a kind
of meta-endpoint-structures. In other words, we can combine multiples
schemas into a single table of endpoints. But I admit that this is a
personal opinion, not really related to this thread.

We agree in the important thing: managing optional parameters
"swells" endpoint tables sometimes unnecessarily. On the other
hand, being setpoint an optional data field, I guess we're not forced to
implement them, so this is not a blocking issue for me.

Daniel.

--- In xAP_developer@xxxxxxx, Kevin Hawkins <yahoogroupskh@...>
wrote:
>
> 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
> >
> >
> >
> >
> >
>




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