[SPAM-MED] Re: Interoperability, abstract protocols and BSC

["Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>]

Having a roadmap is something that I probably missed when I joined
this com=
munity. Maybe as other users, xAP seduced me by the fact of providing
rapid=
interoperability with other applications and also due to BSC's simplicity.=
However, I totally understand your point of view and even agree with your =
wish list. Indeed, instead of suggesting private schemas for standard
appro=
val, I'd like to see some kind of work groups directly prototyping future
s=
tandard schemas. This would guarantee general consensus among developers
an=
d more generic use cases.

This said and regardless of the level of abstraction, I still think that
xA=
P is lacking a complete M2M schema with the following features:

- Monitor and control
- Analog (temperatures, pressures, levels) and binary (on/off,
open/closed)=
values
- Common query/control/status mechanisms, regardless of the type of
endpoin=
t
- No value/state duality. A single endpoint per message, that's all.

Daniel.


--- In xAP_developer@xxxxxxx, "Lehane Kellett (g8kmh)"
<g8kmh@...> =
wrote:
>
> I think my aspirations are closer to Kevin's. A layered HA protocol
that=
=20
> can fit a number integration scenarios (example, with or without a=20
> controller) with minimal requirements to configure each=20
> application/endpoint.
>=20
> I think, as I've said before, there are two main areas that have
caused=20
> issues IMHO - the inappropriate use of BSC when a new schema should
have=
=20
> been created (and I think that is partly down to there not being a=20
> documented process for schema proposal, agreement and adoption) and
the=20
> fact we're now mostly running versions of xAP against an
unpublished=20
> (1.3) specification - the current published one (=20
> http://www.xapautomation.org/index.php?title=3DProtocol_definition
) is 9=
=20
> years old and anyone coming across it may well think xAP is dead.
>=20
> I think BSC shoud be one schema amongst many and I believe the=20
> abstraction is actually a weakness, how is a consuming M2M
application=20
> expected to understand a value/data type assigned in a text field=20
> (without the user understanding the context and configuring the=20
> application)?
> Value =3D 32
> Text =3D 32 F
> so what's that? Feathers, Footballs or Fahrenheit?
>=20
> Modbus, et al., have to abstract because they cannot adopt a rich=20
> schema. xAP can. NMEA 2000 tries to be, and mostly is,  prescriptive
and=
=20
> is plug and play across manufacturers, though as a boat owner, all
is=20
> not plain sailing (pun intended!). I think the best path is between
the t=
wo.
>=20
> What I'd like to see happen with xAP is:
>=20
> Finalise/publish 1.3
> Add JSON to xAP
> Agree a workflow for the creation and adoption of new schemas (and
a=20
> repository).
> Agree (or not!) on more in the way of device discovery/capabilities
and=20
> potentially, remote configuration.
>=20
> Lehane
>=20
>=20
>=20
> On 19/10/2011 18:21, Kevin Hawkins wrote:
> >
> > Daniel and I have had hours of conversation about this over the
last=20
> > few days and what was really interesting is not just the very=20
> > different application that we have for using the protocol but the
very=
=20
> > different aspirations that we have for xAP and it's role in
home=20
> > automation.    There was also quite a bit of misunderstanding as
to=20
> > where xAP was aiming and Daniel, quite rightly,  has commented
that=20
> > the xAP forums, website and protocol specification don't convey
well=20
> > these goals as they extend beyond the raw protocol  and into
the=20
> > importance of schema definitions and adoption.
> >
> >  I'm thinking now that we haven't communicated xAP's /*Raison
d'=EAtre*=
/=20
> > very  effectively beyond those involved early in the project.
> >
> > Daniel has a very practical 'want to use the protocol and get it
all=20
> > interacting' now approach, hence the questions below,  and mine
is far=
=20
> > more aspirational  .. 'hoping to create a near plug and play
model for=
=20
> > integrating many different devices' .to make HA easier to
implement. =
=20
> > Daniel's approach is very credible from the point of view of
getting=20
> > things moving forward and mine more ambitious but perhaps
idealistic .
> >
> > Regardless,  the fact  that xAP isn't snowballing with lots of
new=20
> > schema  in the way I would need it to in order to achieve my=20
> > aspirations is indicative that it's not going to work 'my way'.  
  So=
=20
> > before I respond with my thoughts (which are my own and not=20
> > necessarily representative of xAP persay) let's see what others
think .=
...
> >
> >    cheers Kevin
> >
> >
> >
> > On 19/10/2011 11:20, Daniel Berenguer wrote:
> >
> >> Dear potential and active developers,
> >>
> >> First of all, let me say that I'm posting this message as a
way of
> >> generating debate, not controversy. xAP has always worked
well for my
> >> needs so I have no special motivation in making things change
in any
> >> way. On the other hand. I feel myself somehow obliged to
contribute to
> >> this project and I think that a first debate may help us
understand
> >> everyone's needs in terms of monitoring&control
communications.
> >>
> >> In order to not to get too dispersed I'd like to concentrate
the
> >> current discussion about the importance of having a standard
> >> inter-operational schema, valid for most M2M applications.
Well, I'm
> >> sure that most of us have thought in BSC as our reference
schema, our
> >> widest deployed schema which has ensured interoperability
among an
> >> important number of Home Automation applications for years.
Kevin
> >> Hawkins and the rest of creators of the xAP initiative have
always
> >> said that xAP was created with the idea of generating
multiple schemas
> >> on top of it. Since I joined this community I've seen a dozen
of new
> >> schemas being created, almost all of the being based on
personal needs
> >> and focusing very vertical applications. However, time has
proven that
> >> BSC is still our preferred schema, maybe for the following
reasons:
> >>
> >> 1- BSC was there from the beginnings
> >> 2- It has been integrated in most HA applications available
so, in
> >> order to stay interoperable with them, xAP is our only option
nowadays
> >> 3- BSC is 80% an abstract schema. Except for those
informations
> >> contained in "level" and "state", the
"text" field allows the
> >> encapsulation of almost any data (type)
> >> 4- BSC is quite simple. Parsing BSC messages is quite
straightforward.
> >> Data structures to be maintained around BSC can be simple
too.
> >>
> >> > From the above strengths, I believe that the
"abstraction" feature i=
s
> >> what makes BSC so special. Other abstract protocols have also
proven
> >> to be long-lived too; I'm mainly thinking in Modbus, a
protocol
> >> created in the 70's that has even a TCP/IP implementation.
Even
> >> nowadays, Modbus (in all its forms: RS485 and TCP) is the the
widest
> >> deployed protocol in M2M applications. It's entirely abstract
so users
> >> can transport whatever information they need, encapsulated in
16-bit
> >> atoms.
> >>
> >> On the other hand, I admit that abstract protocols have a
drawback:
> >> some receivers have to know in advance what information is
being
> >> received. Since packets don't explicitly explain this,
Example: a
> >> heater controller receives information from a remote sensor
so the
> >> installer has to tell the controller to take the temperature
from that
> >> sensor. In summary, abstract protocols are less PLUG& 
PLAY than other
> >> more complete protocols.
> >>
> >> The above drawback may be of different importance depending
on the
> >> target application. Home Automation packs potentially
installable by
> >> end-users or low-skilled installers need to be easy to
install. Here
> >> the plug&  play capability is a plus.This is the case of
Lonworks,
> >> EIB, CanOpen, NMEA2000 or any other ultra-complete protocol.
In these
> >> cases, protocols are complemented by static data
dictionaries,
> >> functional profiles (the most) or self-explanatory packets
(the less).
> >> Fortunately, xAP brings us the possibility to navigate at
different
> >> levels. Do we need to elaborate a smart control of AV
equipment with
> >> ramps, sequences and zones? Want to do it plug&play
without having to
> >> configure any static parameter in the AV controller? OK,
let's define
> >> a custom xAP schema for controlling AV equipment. Do we need
to
> >> control this AV equipment from HomeSeer or HouseBot? Can we
configure
> >> the complex parameters into the AV controller using a Web
interface
> >> and then just send basic control information from the other
software?
> >> OK, BSC is our solution.
> >>
> >> And finally my questions:
> >>
> >> 1- Regarding your experience, do you think that BSC fits most
of your =
needs?
> >> 2- What do you like the most/lest about BSC?
> >> 3- Do think that an evolution from BSC is necessary?
> >> 4- Do you think we need an "interoperable" protocol
different than
> >> BSC? Please explain.
> >> 5- Have you ever created a custom schema for your
applications? Which
> >> applications were these custom schemas intended for?
> >>
> >> Any other reflection or question is welcome provided that we
remain
> >> into the current topic
> >>
> >> Thanks in advance for your contribution,
> >>
> >> Daniel
> >>
> >>
> >>
> >
> >
>




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