[Message Prev][Message Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: [SPAM-MED] Re: Interoperability, abstract protocols and BSC
--------------010508090801010306010009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
I think my aspirations are closer to Kevin's. A layered HA protocol that
can fit a number integration scenarios (example, with or without a
controller) with minimal requirements to configure each
application/endpoint.
I think, as I've said before, there are two main areas that have caused
issues IMHO - the inappropriate use of BSC when a new schema should have
been created (and I think that is partly down to there not being a
documented process for schema proposal, agreement and adoption) and the
fact we're now mostly running versions of xAP against an unpublished
(1.3) specification - the current published one (
http://www.xapautomation.org/index.php?title=Protocol_definition
) is 9
years old and anyone coming across it may well think xAP is dead.
I think BSC shoud be one schema amongst many and I believe the
abstraction is actually a weakness, how is a consuming M2M application
expected to understand a value/data type assigned in a text field
(without the user understanding the context and configuring the
application)?
Value = 32
Text = 32 F
so what's that? Feathers, Footballs or Fahrenheit?
Modbus, et al., have to abstract because they cannot adopt a rich
schema. xAP can. NMEA 2000 tries to be, and mostly is, prescriptive and
is plug and play across manufacturers, though as a boat owner, all is
not plain sailing (pun intended!). I think the best path is between the
two.
What I'd like to see happen with xAP is:
Finalise/publish 1.3
Add JSON to xAP
Agree a workflow for the creation and adoption of new schemas (and a
repository).
Agree (or not!) on more in the way of device discovery/capabilities and
potentially, remote configuration.
Lehane
On 19/10/2011 18:21, Kevin Hawkins wrote:
>
> Daniel and I have had hours of conversation about this over the last
> few days and what was really interesting is not just the very
> different application that we have for using the protocol but the very
> different aspirations that we have for xAP and it's role in home
> automation. There was also quite a bit of misunderstanding as to
> where xAP was aiming and Daniel, quite rightly, has commented that
> the xAP forums, website and protocol specification don't convey well
> these goals as they extend beyond the raw protocol and into the
> importance of schema definitions and adoption.
>
> I'm thinking now that we haven't communicated xAP's /*Raison
d'être*/
> very effectively beyond those involved early in the project.
>
> Daniel has a very practical 'want to use the protocol and get it all
> interacting' now approach, hence the questions below, and mine is far
> more aspirational .. 'hoping to create a near plug and play model for
> integrating many different devices' .to make HA easier to implement.
> Daniel's approach is very credible from the point of view of getting
> things moving forward and mine more ambitious but perhaps idealistic .
>
> Regardless, the fact that xAP isn't snowballing with lots of new
> schema in the way I would need it to in order to achieve my
> aspirations is indicative that it's not going to work 'my way'. So
> before I respond with my thoughts (which are my own and not
> 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 is
>> 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
>>
>>
>>
>
>
--------------010508090801010306010009
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<head>
<style type="text/css">
<!--
/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}
div.photo-title
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;
}
div.attach-table div.attach-row {
clear: both;
}
div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}
p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}
div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}
div.attach-table div.attach-row div div span {
font-weight: normal;
}
div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<!-- **begin egp html banner** -->
<br><br>
<!-- **end egp html banner** -->
I think my aspirations are closer to Kevin's. A layered HA protocol
that can fit a number integration scenarios (example, with or
without a controller) with minimal requirements to configure each
application/endpoint.<br>
<br>
I think, as I've said before, there are two main areas that have
caused issues IMHO - the inappropriate use of BSC when a new schema
should have been created (and I think that is partly down to there
not being a documented process for schema proposal, agreement and
adoption) and the fact we're now mostly running versions of xAP
against an unpublished (1.3) specification - the current published
one (
<a class="moz-txt-link-freetext" href="http://www.xapautomation.org/index.php?title=Protocol_definition";>http://www.xapautomation.org/index.php?title=Protocol_definition</a>
)
is 9 years old and anyone coming across it may well think xAP is
dead. <br>
<br>
I think BSC shoud be one schema amongst many and I believe the
abstraction is actually a weakness, how is a consuming M2M
application expected to understand a value/data type assigned in a
text field (without the user understanding the context and
configuring the application)? <br>
Value = 32<br>
Text = 32 F <br>
so what's that? Feathers, Footballs or Fahrenheit?<br>
<br>
Modbus, et al., have to abstract because they cannot adopt a rich
schema. xAP can. NMEA 2000 tries to be, and mostly is,
prescriptive
and is plug and play across manufacturers, though as a boat owner,
all is not plain sailing (pun intended!). I think the best path is
between the two.<br>
<br>
What I'd like to see happen with xAP is:<br>
<br>
Finalise/publish 1.3<br>
Add JSON to xAP<br>
Agree a workflow for the creation and adoption of new schemas (and a
repository).<br>
Agree (or not!) on more in the way of device discovery/capabilities
and potentially, remote configuration.<br>
<br>
Lehane<br>
<br>
<br>
<br>
On 19/10/2011 18:21, Kevin Hawkins wrote:
<blockquote cite="mid:4E9F071E.8030109@xxxxxxx"
type="cite">
<span style="display:none"> </span>
<div id="ygrp-text">
<p> Daniel and I have had hours of conversation about this
over the last few days and what was really interesting is
not just the very different application that we have for
using the protocol but the very different aspirations that
we have for xAP and it's role in home automation.
There
was also quite a bit of misunderstanding as to where xAP
was aiming and Daniel, quite rightly, has commented that
the xAP forums, website and protocol specification don't
convey well these goals as they extend beyond the raw
protocol and into the importance of schema definitions
and adoption.<br>
<br>
I'm thinking now that we haven't communicated xAP's
<i><b>Raison
d'être</b></i> very effectively beyond
those involved
early in the project.<br>
<br>
Daniel has a very practical 'want to use the protocol and
get it all interacting' now approach, hence the questions
below, and mine is far more aspirational .. 'hoping to
create a near plug and play model for integrating many
different devices' .to make HA easier to implement.
Daniel's approach is very credible from the point of view
of getting things moving forward and mine more ambitious
but perhaps idealistic . <br>
<br>
Regardless, the fact that xAP isn't snowballing with
lots of new schema in the way I would need it to in order
to achieve my aspirations is indicative that it's not
going to work 'my way'. So before I respond
with my
thoughts (which are my own and not necessarily
representative of xAP persay) let's see what others think
....<br>
<br>
cheers Kevin<br>
<br>
<br>
<br>
On 19/10/2011 11:20, Daniel Berenguer wrote: </p>
<blockquote
cite="mid:CADBDe3c2GReKiOOnR-x1z7oJbThtvZySh+C152j7AQ5EC5MrOQ@xxxxxxx"
type="cite">
<pre wrap="">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 is
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
</pre>
</blockquote>
<br>
</div>
<!-- end group email -->
</blockquote>
<br>
<!-- **begin egp html banner** -->
<br>
<br>
<!-- **end egp html banner** -->
<div width="1" style="color: white; clear:
both;"/>__._,_.___</div>
<!-- Start Recommendations -->
<!-- End Recommendations -->
<!-- **begin egp html banner** -->
<img src="http://geo.yahoo.com/serv?s=97476590/grpId=9629476/grpspId=1705007709/msgId=2212/stime=1320111210";
width="1" height="1"> <br>
<!-- **end egp html banner** -->
<!-- **begin egp html banner** -->
<br>
<div style="font-family: verdana; font-size: 77%; border-top: 1px
solid #666; padding: 5px 0;" >
Your email settings: Individual EmailTraditional <br>
<a href="http://groups.yahoo.com/group/xAP_developer/join;_ylc=X3oDMTJmb3Bsa25oBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEzMjAxMTEyMTA-";>Change
settings via the Web</a> (Yahoo! ID required) <br>
Change settings via email: <a href="mailto:xAP_developer-digest@xxxxxxx?subject=Email
Delivery: Digest">Switch delivery to Daily Digest</a> <a
href = "mailto:xAP_developer-fullfeatured@xxxxxxx?subject=Change
Delivery Format: Fully Featured">Switch to Fully Featured</a>
<br>
<a href="http://groups.yahoo.com/group/xAP_developer;_ylc=X3oDMTJkb3U4b2JqBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMzIwMTExMjEw";>
Visit Your Group
</a>
<a href="http://docs.yahoo.com/info/terms/";>
Yahoo! Groups Terms of Use
</a>
<a href="mailto:xAP_developer-unsubscribe@xxxxxxx?subject=Unsubscribe";>
Unsubscribe
</a>
<br>
</div>
<br>
<!-- **end egp html banner** -->
<div style="color: white; clear:
both;"/>__,_._,___</div>
</body>
</html>
--------------010508090801010306010009--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|