[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Addressing vs Commands
--------------040606050708070300030003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Jerome,
BSC is a universal schema for simple devices. It can very neatly model a
device with an unlimited* number of endpoints where these can be
categorised as either binary, level or text. There are restrictions
however, for example that the level can't be negative and the units eg
degrees Celsius aren't formally presented. Other schema handle these
situations better.
BSC is extensively supported by almost every xAP controller and because
of this there is a tendency to try and model every device using BSC. For
example it would be possible to model an audio amplifier using BSC
creating endpoints for every control. Whilst achievable it would be far
better to use a different schema specifically designed for AV amps.
This is because then the amplifier is astracted to a functional device
and later should you change your ACME brand amplifier for a new Denon
and as long as both used the AV amp schema it would just swap without
any changes within your control system. Here the schema class is
defining the functionality . Having said that designing such schema is
not as simple as it sounds and we don't yet have the range of schema we
need, but anyone can create them.
Regarding your specific X10 question at the end about knowing the type
or functionality of a device. Using BSC you don't as the class is
generic so a good alternative is to include this information in the
source address. For example creating a 'lighting' category rather than
'X10' as your aim typically is to address the functionality rather than
the specific hardware used. As X10 offers lighting control does it
actually matter if C-Bus, ZigBee or X10 hardware is used. Then you
could do something like this to control 'LightName'.
target=*.*.lighting:LightName
and then whatever technology was used for your lighting it would work,
it could be mixed X10, ZigBee, C-Bus, Dynalite etc
Having said that it is very likely that the type of the device is
presented in the source address but that is up to you to configure.
source=ACME.controller.X10:LightName
source=ACME.X10.controller:LightName
source=ACME.controller.lighting.X10:LightName
or even better as it supports the target example above
source=ACME.X10.lighting:LightName
if only some of your X10 devices were used for lighting and others say
for irrigation you could instead name the endpoints at the sub address
level
source=ACME.controller.X10:lighting.LightName
source=ACME.controller.X10:irrigation.Sprinkler
still preserving that same flexibility across lighting technologies
target=>:lighting.LightName
If you do want to allow X10 device codes within BSC you could include
them instead of or additionally to the friendly name
source=ACME.X10.lighting:D7
source=ACME.X10.lighting:D7.LightName
then you could use this to control a specific X10 device
target=*.X10.*:D7
Addressing usage is very much your choice for your own installation -
how it works best for you.
I personally prefer the schema class defining the functionality of a
device but for the general BSC devices I use an address position to
include this information (as above) which allows me to choose and later
transparently swap at each endpoint level what technology is used.
The X10 schema still exists by the way and you can always have a device
that implements several schema, in this case both X10 and BSC should you
wish.
K
*PS If you are supporting BSC then do familiarise yourself with xAP v1.3
proposed changes . In a nutshell the UID format has changed from
FF123409 to FF.1234:09 ie a '.' and a ':' have been inserted to
delimit the three segments. Additionally each value can now be any
even number of uppercase hex digits, although there are common
combinations. The main reason for this was that in xAP v1.2 the last
two digits of the UI, '09' in the example above , previously
restricted the number of endpoints to 254 (01-FE) but this was found to
be too restrictive and so expanded in xAP v1.3 to support any number you
wish. As a consequence the ID= parameter in a BSC body now can include
any even number of uppercase hex digits.
On 01/06/2010 09:45, Jerome Kerdreux wrote:
> Thanks for the highlight, I missed that stuff. That looks quite
exactly
> what i'm looking for.
>
> So, if I clearly decode both mails, you say I should use BSC for this
> kind of devices. This is used for X10 in the new version .. but there
> is something that sound strange.
>
> If every device use a BSC schema, how could you know the type of
device,
> as every device has the same class. This could cause issues for
example
> to build a GUI or anything else, or is there a new X10 schema with a
BSC
> like behaviour ?
>
>
> Thanks
>
--------------040606050708070300030003
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>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">
<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** -->
Hi Jerome,<br>
<br>
BSC is a universal schema for simple devices. It can very neatly model
a device with an unlimited* number of endpoints where these can be
categorised as either binary, level or text. There are
restrictions
however, for example that the level can't be negative and the units eg
degrees Celsius aren't formally presented. Other schema
handle these
situations better. <br>
<br>
BSC is extensively supported by almost every xAP controller and because
of this there is a tendency to try and model every device using BSC.
For example it would be possible to model an audio amplifier using BSC
creating endpoints for every control. Whilst achievable it would
be
far better to use a different schema specifically designed for AV
amps. This is because then the amplifier is astracted to a
functional
device and later should you change your ACME brand amplifier for a new
Denon and as long as both used the AV amp schema it would just swap
without any changes within your control system. Here the schema
class
is defining the functionality . Having said that designing such schema
is not as simple as it sounds and we don't yet have the range of schema
we need, but anyone can create them.<br>
<br>
Regarding your specific X10 question at the end about knowing the type
or functionality of a device. Using BSC you don't as the class is
generic so a good alternative is to include this information in the
source address. For example creating a 'lighting' category rather than
'X10' as your aim typically is to address the functionality rather than
the specific hardware used. As X10 offers lighting
control does it
actually matter if C-Bus, ZigBee or X10 hardware is used. Then
you
could do something like this to control 'LightName'.<br>
<br>
<font face="Courier New, Courier,
monospace">target=*.*.lighting:LightName</font>
<br>
<br>
and then whatever technology was used for your lighting it would work,
it could be mixed X10, ZigBee, C-Bus, Dynalite etc<br>
<br>
Having said that it is very likely that the type of the device is
presented in the source address but that is up to you to
configure. <br>
<font face="Courier New, Courier, monospace"><br>
source=ACME.controller.X10:LightName</font><br>
<font face="Courier New, Courier,
monospace">source=ACME.X10.controller:LightName</font><br>
<font face="Courier New, Courier,
monospace">source=ACME.controller.lighting.X10:LightName</font><br>
or even better as it supports the target example above<br>
<font face="Courier New, Courier,
monospace">source=ACME.X10.lighting:LightName</font><br>
<br>
if only some of your X10 devices were used for lighting and others say
for irrigation you could instead name the endpoints at the sub address
level<br>
<font face="Courier New, Courier,
monospace">source=ACME.controller.X10:lighting.LightName</font><br>
<font face="Courier New, Courier,
monospace">source=ACME.controller.X10:irrigation.Sprinkler<br>
</font>still preserving that same flexibility across lighting
technologies<font face="Courier New, Courier,
monospace"><br>
target=>:lighting.LightName<br>
</font><br>
If you do want to allow X10 device codes within BSC you could
include
them instead of or additionally to the friendly name<br>
<br>
<font face="Courier New, Courier,
monospace">source=ACME.X10.lighting:D7<br>
source=ACME.X10.lighting:D7.LightName</font><br>
<br>
then you could use this to control a specific X10 device<br>
<br>
<font face="Courier New, Courier,
monospace">target=*.X10.*:D7</font><br>
<br>
Addressing usage is very much your choice for your own
installation -
how it works best for you. <br>
I personally prefer the schema class defining the functionality of a
device but for the general BSC devices I use an address position to
include this information (as above) which allows me to choose and later
transparently swap at each endpoint level what technology is
used.<br>
<br>
The X10 schema still exists by the way and you can always have a device
that implements several schema, in this case both X10 and BSC should
you wish. <br>
<br>
K<br>
<br>
*PS If you are supporting BSC then do familiarise yourself with xAP
v1.3 proposed changes . In a nutshell the UID format
has changed from
FF123409 to FF.1234:09 ie a '.' and a ':' have been
inserted to
delimit the three segments.
Additionally each value can now be any
even number of uppercase hex digits, although there are common
combinations. The main reason for this was that in xAP v1.2 the
last
two digits of the UI, '09' in the example above ,
previously
restricted the number of endpoints to 254 (01-FE) but this was found to
be too restrictive and so expanded in xAP v1.3 to support any number
you wish. As a consequence the ID= parameter in a BSC body now
can
include any even number of uppercase hex digits.<br>
<br>
<br>
<br>
On 01/06/2010 09:45, Jerome Kerdreux wrote:<br>
<blockquote
cite="mid:20100601104523.b4db7529.Jerome.Kerdreux@xxxxxxx"
type="cite">
<pre wrap="">Thanks for the highlight, I missed that stuff.
That looks quite exactly
what i'm looking for.
So, if I clearly decode both mails, you say I should use BSC for this
kind of devices. This is used for X10 in the new version .. but there
is something that sound strange.
If every device use a BSC schema, how could you know the type of device,
as every device has the same class. This could cause issues for example
to build a GUI or anything else, or is there a new X10 schema with a BSC
like behaviour ?
Thanks
</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=2159/stime=1275394142";
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=X3oDMTJmMDAwdWQ0BF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNzUzOTQxNDI-";>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=X3oDMTJkdTVybmJvBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjc1Mzk0MTQy";>
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>
--------------040606050708070300030003--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|