The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Interoperability, abstract protocols and BSC



--------------040409000906010407060301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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
>
>
>


--------------040409000906010407060301
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** -->



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.&nbsp; &nbsp; There was also quite a bit of
misunderstanding
as to where xAP was aiming and Daniel, quite rightly,&nbsp; has
commented
that the xAP forums, website and protocol specification don't convey
well these goals as they extend beyond the raw protocol&nbsp; and into
the importance of schema definitions and adoption.<br>
<br>
&nbsp;I'm thinking now that we haven't communicated xAP's
<i><b>Raison
d'&ecirc;tre</b></i> very&nbsp; 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,&nbsp; and mine is
far more aspirational&nbsp; .. 'hoping to create a near plug and play
model for integrating many different devices' .to make HA easier to
implement.&nbsp; Daniel's approach is very credible from the point of
view of getting things moving forward and mine more ambitious but
perhaps idealistic .&nbsp; <br>
<br>
Regardless,&nbsp; the fact&nbsp; that xAP isn't snowballing with
lots of new
schema&nbsp; 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'.
&nbsp;&nbsp;&nbsp;
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>
&nbsp;&nbsp; cheers Kevin<br>
<br>
<br>
<br>
On 19/10/2011 11:20, Daniel Berenguer wrote:
<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&amp;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.

&gt;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 &amp; 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 &amp; 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&amp;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>




<!-- **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=2205/stime=1319044938";
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=X3oDMTJmZ2kwYTBvBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEzMTkwNDQ5Mzg-";>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=X3oDMTJkMnFocDZjBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMzE5MDQ0OTM4";>
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>

--------------040409000906010407060301--

  • Follow-Ups:
    • UID
      • From: Allens Bad
xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.