Re: Proposals for xAP TSC

["Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>]

Thanks Lehane for the feedback.

Responding to your last question, I primarily use xAP for bridging between
IP and other buses. I'm currently maintaining two kind of controllers,
communicating under xAP BSC:

A) Gateways: they basically pipe field bus information from 1-Wire, Modbus,
CAN, etc to xAP BSC. The gateway maintains an internal table of endpoints
so that the gateway is seen from the outside as an IO controller with a
variable amount of endpoints (up to 500 endpoints in some cases).Working as
pure mappers, these gateways are continuously polling or listening for
information on the lower bus and provide a full BSC interface to the xAP
network. Most of the low level devices connected to these gateways are
generic IO devices (multi-master or slaves) that can be used from xAP BSC
for any purpose, including heating control or alarm signalization. Thus,
I'd have expected TSC (or any other new schema) to provide more generic
mechanisms to implement "data piping".

Implementing TSC for this case would involve:

- Using BSC for binary endpoints and text, TSC for analog endpoints.
- Double use of BSC and TSC for analog endpoints during the first months as
we need to provide compatibility with the existing BSC products before
their switch to TSC.
- Maintain two different arrays of endpoints or merge both schemas into a
common structure.

B) Main controller (opn-max, but also valid for HomeSeer or Mr.House I
guess): this device queries all available BSC endpoints in the network in a
simple manner. Then, the controller stores every endpoint information and
maintains a live copy of the BSC network in memory. Then, users can work
with this data from scripts, Web server, etc.

In both cases, data is stored in endpoint structures. The more compact is
the information stored, the more endpoints can be managed by a single
controller.

xAP BSC is perfect for most of the M2M applications I think. The only
objections are IMO the level-text different management and the lack of a
"unit" field. But for the rest of features, BSC is a very good
abstract schema that lets you pipe almost any information through UDP/IP.
Because of this, I'd have preferred to work on a possible evolution of BSC
instead of switching to a new schema. I now understand the motivations of
TSC and agree in that TSC is specially suitable for vertical
"peer-to-peer" applications like heating control. There is no
objection then, I surely was wrong about considering TSC as an evolution
(improvement) of BSC. Kevin's post about spoiling us towards the switch to
TSC didn't help either ;-)

Daniel.


--- In xAP_developer@xxxxxxx, "Lehane Kellett (g8kmh)"
<g8kmh@...> wrote:
>
> My comments in the text below. Apologies for the delay.
>
> Lehane
>
> On 17/04/2010 18:08, Daniel Berenguer wrote:
> >
> > No comments? Come on guys! ;-)
> >
> > --- In xAP_developer@xxxxxxx
> > <mailto:xAP_developer%40yahoogroups.com>,
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.
> > >
> >
> I disagree with the moving of, in this case, setpoint to a different
> endpoint.
> Indeed management of a number of values to an endpoint doesn't
> seem too big an overhead. It would also create even more divergence
from
> BSC, something TSC is already crticised for.
>
> At the smaller end of the CPU scale the IO device probably is only
managing
> a temp and setpoint.
>
> > > 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.
> >
> The reason units was there was, for example, to change a setpoint.
> Without the
> units it could be in Celsius or Fahrenheit. The controller doesn't 
need
> to  maintain
> the units as long as internally it converts to the working value. It
> also only reports
> in whatever value it wishes. So you could send 68F and get 20C in the
info.
> >
> > >
> > > 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.
> >
> It wasn't included as the intended consequences could be unpredictable
with
> the complexity of TSC. I think if we go with this it will require some
> clarity of documentation as to how it can be used but this is doable.
>
> In what context do you see this working?
>
> > >
> > > 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.
> >
> Yes, this should be changed.
>
> > >
> > > 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).
> >
> Currently, yes for alarms but it could be changed I guess. Normally
> you'd want to
> know the current process value (temperature, etc) when the alarm is
> triggered....
>
> Capability could be made optional but I think some more thought would
be
> needed
> around how devices advertise their features.
>
> The aim of TSC wasn't about simplicity but to be comprehensive and,
yes,
> endpoints in themselves would be more complex to code than BSC but
typically
> an embedded device only has a few endpoints.
>
> I guess the question around controllers is whether they aim to be
> multipurpose and
> so control many (tens, hundreds) TSC devices/endpoints - in which case
I
> don't believe
> embedded systems are they way to go (though some recent devices have
more
> power and RAM than my first PC!) - or single purpose, like a heating
> system controller -
> in which case embedded would be fine.
>
>
> > >
> > > 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.
> >
> Daneil,
> Can you expand on the kind of devices you envisage a problem with?
Maybe my
> view is that a simple device, like a thermostat, has one or two
sensors
> (temp/RH)
> and is a single endpoint. Or a watt/hour meter, maybe two endpoints.
And TSC
> and BSC can co-exist, with some additional coding complexity agreed.
>
> I didn't envisage a simple controller doing both and perhaps that's
what you
> are aiming for.
>
> Lehane
>
>
>
> > >
> > > Thanks for your time,
> > >
> > > --
> > > Daniel Berenguer
> > > http://www.usapiens.com <http://www.usapiens.com>
> > > http://www.opnode.org <http://www.opnode.org>
> > >
> >
>




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