[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: My list of possible xAP Enhancements
--------------060109020200000502010508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 16/03/2010 13:11, Neil Wrightson wrote:
>
>
> Hi Lehane / Kevin,
> I'm not sure how I'm breaking a schema. Perhaps we are talk about two
> separate things.
> As an example
> {
> InstanceRename=House
> }
> In the message body. If the device did not know anything about
> "InstanceRename" wouldn't it just ignore this message?
> All I'm doing is adding some extra parameters.
Your original message example was
{
v=12
hop=1
uid=FF123400
class=xAPBSC.cmd
source=ACME.Controller.Central
target=ACME.Lighting.apartment
}
{
InstanceRename=House
}
and the BSC specification implements three types of devices , and in
each of these a state= parameter is mandatory. A level device includes
an additional mandatory level= parameter and a 'text' device includes a
mandatory text= parameter. Hence your message breaks BSC.
> Are you suggesting that there should be another class for
> configuration? If so would this need to be two different classes then?
> One for the general xAP and one for xAPBSC.
> I.e. class=xap.config or class=xapbsc.config
> This is because xap.config does not have endpoints.
BSC is just one of hundreds of possible BSC schema and its purpose as it
states is 'Basic Status and Control' - a configuration schema shouldn't
be implemented in BSC because that is not it's purpose. Also BSC is a
bidirectional schema and many devices that require configuration are
listeners only. Adding an extra schema class to xAPBSC ie xAPBSC.config
could be problematic too. Config should have its own schema.
> Watchdog's versus Pulsed outputs.
> They are TWO different things.
> I use watchdog's all of the time both in the hardware sense, where it
> is supervising the embedded processor and from a software perspective.
> The hardware watchdog is used to ensure the embedded processor is
> reset incase of lock up. Possibly due to a firmware bug, EMI, Sun spot
> whatever.
> The software watchdog is used if the main controller (PC) stops
> talking to the embedded device after a preset time. Here the embedded
> device turns off all outputs.
> I have been doing this style of thing for a few decades now and
> believe, both are required.
> This is completely different to a pulsed about, where you send the
> embedded device a signal telling it to turn on it's output for a
> preset period i.e. 5min, 30min whatever.
> In a watering of the garden scenario, a pulsed output of 30min may be
> fine.
> However in a closed loop scenario, i.e. where a PC is controlling the
> water level in the swimming pool. The PC interrogates the embedded
> control for the water level and if the water level is too low, it
> tells the embedded device to set an output to fill the pool. The PC
> controller would tell the embedded processor to turn ON (not pulsed)
> the water inlet valve. The PC must at appropriate intervals,
> continually tell the embedded controller to set the output to ON.
> Because of this continual refresh, the embedded controller keeps this
> output ON until it is told to turn OFF. If the comms from the PC dies,
> the software watchdog in the embedded device kicks in and turns off
> the output before the pool overflows.
> I know I'm using backyard scenarios here but in my world these apply,
> as well as systems I've done for filling truck fuel tankers, gas
> cylinders, grain loading into ships etc.
> Both hardware and software watchdogs must exist.
> However a pulsed output if a defined period, is fine to turn on the
> veranda/porch light.
> I believe that the designers of xAP, intended this to be more than
> just a backyard controller protocol. They hoped it would move into
> commercial products, so now we need to think in a commercial real
> world manner. I for one, don't want to be responsible for why the gas
> cylinder was over filled and exploded.
My point here was that you could replace an 'on for 30 minutes' with say
60 pulse on for 30 second messages to achieve a 30 minute watchdog type
scenario fpor existing hardware (that didn't have the hardware watchdog
facility) . In practicality you would probably issue 59 turn on for 1
minute pulses. I agree hardware watchdogs are vital in process control.
Watchdogs in embedded processor devices can have the effect of masking
firmware bugs because they effectively reset the processor. In my
embedded firmware xAP devices during the beta phase , which is
effectively the last 4 years (!) I have never enabled the watchdogs as I
want to be aware of any issues. IN a full production/commercial world
they would likely be enabled with some form of trigger logging.
> The reason I specified byte here, relates to the above. The software
> watchdog is an emergency safety switch. 1..255 seconds is a bloody
> long time when something is overflowing etc.
> The other thing that is always in the back of my mind, is that my
> embedded controller doesn't have 1.5TB of parameter storage :-( Only
> some EEPROM. Bytes count.
Artificial restrictions have always come back to haunt us (as in the UID
value for example) so I would suggest it isn't fixed at byte level.
However my particular issue was not with the watchdog time but
WD_Timeout_Val : Byte ; // 0/1/255
BSC Level is not restricted to a 0-255 value being often 16 bit or even
odd ranges 0-3600 maybe. Or you could use a 0-100% value and sacrifice
granularity.
Yep.. I''m well aware of the memory issues - as I have had to scour my
own code looking for integers that can become byte or even bit values.
I'm absolutely using every byte at the moment.
> In regard to the watchdog's being endpoints in their own write, and
> concatenated messages as per your example. Sounds good.
> As far as the time stamp goes', I'm only talking about down to the
> second level. Also having a Julian/LongInt representation in the same
> message might not go astray. It's easy to do quick comparisons on a
> Longint.
> RTC's for use in embedded devices are quite cheap these days.
I think having a longint value is a good idea...
> In regard to the optional RestoreState facility. I see this more for
> reasonably dum things, like light controllers. The power dies and
> comes back in 10 seconds, the light comes on with the power.
> I.e. like some X10 fittings that remember there last state. Meanwhile,
> 10 minutes later the server has finished booting and is in control
again.
> Yes I know.... UPS. Personally, I have four hours of UPS runtime
> driving my servers but not everybody has this luxury.
Again - taking a lead from C-Bus there is a possible additional
consideration of phased recovery of outputs eg that on a 12 channel
relay they come on sequentially with a preset delay to avoid surges.
> As you also said Lehane, "xAP is not predicated on the use of
> controllers". Just that statement says that the devices on the
xAP
> network should go back their prior state.
> This is one of the big differences between xAP and xPL.
People are free to add their own 'smarts' to any device they create for
xAP - it's part of product differentiation. For me having 'restore
last state' could be useful for a couple of my devices but not the
majority - and in hardware terms it requires some form of retentive
memory on the device which can be awkward to implement. But by all means
create such a device and if it's an optional feature then you have a
feature differentiator which is attractive. At power restore and if
using BSC it will announce its power recovery state to the whole network
although not all of those listeners and or the network routers might
have yet fully recovered. Power fail recovery for lighting is fairly
straightforward but it can become very involved for devices with
sequenced startup, other state dependencies, time scheduling and
handling of 'catch up' of thing that should have happened whilst there
was an outage.
> The final other point is, that just because some endpoint controllers
> don't have some functionality (i.e. RTC facilities), doesn't mean we
> should restrict the specification to the dumbest/leanest hardware.
I agree ... but BSC was created for 'BASIC' status and control - it is
just one schema and we shouldn't shoehorn everything into it. In a way
its purposed at these simple devices. Although totally possible to
model an AV amplifier for example using BSC it isn't appropriate and
defeats abstraction of devices (plug and play exchange of your amp
model). Once there are multiple capabilities of BSC devices then things
get more uncertain and you also need to be able to ascertain each
devices capabilities somehow. I personally am loathe to enhance BSC as
it is a very defined schema and this has been instrumental in its
widespread adoption but we could of course have discussions around BSC2
or something. One other aspect that might help here but is missing in
xAP messages at the moment is versioning of schema eg reporting that a
device adheres to BSC v1.3 . You are totally free to add your own
additional parameters within BSC blocks and to create your own schema
classes (as long as they don't start with the three reserved letters
'xap' as in xapbsc.cmd) so there's no restriction to what you're trying
to do - it would be just nice to get it adopted in a formalised way.
K
>
> Regards,
>
> *Neil Wrightson.*
> */N.W.Electronics/*
> ABN 76 768 513 867
> Embedded Controllers and Home Automation Products
> Skype : Neil_Wrightson
> Web :_ www.nwe.net.au_
>
> _,___
>
--------------060109020200000502010508
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** -->
On 16/03/2010 13:11, Neil Wrightson wrote:
<blockquote
cite="mid:F8C23952C3464124ABC70CD1A93C2DD8@xxxxxxx"
type="cite">
<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>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<meta name="GENERATOR" content="MSHTML
8.00.6001.18876">
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">Hi Lehane /
Kevin,</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"></span> </div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">I'm not sure how I'm breaking
a schema. Perhaps
we are talk about two separate
things.</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">As an
example</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><span
lang="en-au"><font size="2"
face="Arial">{</font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">InstanceRename=<wbr>House</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">}</font></span> </span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">In the message body. If the
device did not know
anything about "InstanceRename" wouldn't it just ignore this
message?</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">All I'm doing is adding some
extra parameters.</font></span></div>
</blockquote>
<br>
Your original message example was<br>
<br>
<span lang="en-au"><font size="2"
face="Arial">{</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">v=12</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">hop=1</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">uid=FF123400</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">class=xAPBSC.cmd</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">source=ACME.Controller.Central</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">target=ACME.Lighting.apartment</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">}</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">{</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">InstanceRename=House</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">}</font></span>
<br>
<br>
and the BSC specification implements three types of devices , and in
each of these a state= parameter is mandatory. A level device includes
an additional mandatory level= parameter and a 'text' device includes a
mandatory text= parameter. Hence your message breaks
BSC.<br>
<br>
<br>
<blockquote
cite="mid:F8C23952C3464124ABC70CD1A93C2DD8@xxxxxxx"
type="cite">
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">Are you suggesting that there
should be another
class for configuration? If so would this need to be two different
classes then? </font></span></div>
</blockquote>
<blockquote
cite="mid:F8C23952C3464124ABC70CD1A93C2DD8@xxxxxxx"
type="cite">
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">One for the general xAP and
one for xAPBSC.</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">I.e. class=xap.config or
class=xapbsc.config</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">This is because xap.config
does not have
endpoints.</font></span></div>
</blockquote>
BSC is just one of hundreds of possible BSC schema and its purpose as
it states is 'Basic Status and Control' - a configuration schema
shouldn't be implemented in BSC because that is not it's purpose. Also
BSC is a bidirectional schema and many devices that require
configuration are listeners only. Adding an extra schema class to
xAPBSC ie xAPBSC.config could be problematic too. Config should
have
its own schema.<br>
<blockquote
cite="mid:F8C23952C3464124ABC70CD1A93C2DD8@xxxxxxx"
type="cite">
<div dir="ltr" align="left"><span
class="514494411-16032010"></span> </div>
<div dir="ltr" align="left"><span
class="514494411-16032010"></span> </div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">Watchdog's versus Pulsed
outputs.</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">They are TWO different
things.</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">I use watchdog's all of the
time both in the
hardware sense, where it is supervising the embedded processor and from
a software perspective. </font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">The hardware watchdog is used
to ensure the
embedded processor is reset incase of lock up. Possibly due to a
firmware bug, EMI, Sun spot whatever.</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">The software watchdog is
used if the main
controller (PC) stops talking to the embedded device after a preset
time. Here the embedded device turns off all outputs.
</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">I have been doing this style
of thing for a few
decades now and believe, both are
required.</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">This is completely different
to a pulsed about,
where you send the embedded device a signal telling it to turn on it's
output for a preset period i.e. 5min, 30min
whatever.</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">In a watering of the garden
scenario, a pulsed
output of 30min may be fine. </font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">However in a closed loop
scenario, i.e. where a
PC is controlling the water level in the swimming pool. The PC
interrogates the embedded control for the water level and if the water
level is too low, it tells the embedded device to set an output to fill
the pool. The PC controller would tell the embedded processor to turn
ON (not pulsed) the water inlet valve. The PC must at appropriate
intervals, continually tell the embedded controller to set the
output
to ON.</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">Because of this continual
refresh, the embedded
controller keeps this output ON until it is told to turn OFF.
If the
comms from the PC dies, the software watchdog in the embedded device
kicks in and turns off the output before the pool overflows.
</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">I know I'm using backyard
scenarios here but in
my world these apply, as well as systems I've done for filling truck
fuel tankers, gas cylinders, grain loading into ships etc.
</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">Both hardware and software
watchdogs must exist.
</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">However a pulsed output if a
defined period, is
fine to turn on the veranda/porch
light.</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">I believe that the designers
of xAP, intended
this to be more than just a backyard controller protocol. They hoped it
would move into commercial products, so now we need to think in a
commercial real world manner. I for one, don't want to be responsible
for why the gas cylinder was over filled and
exploded.</font></span></div>
</blockquote>
<br>
My point here was that you could replace an 'on for 30 minutes' with
say 60 pulse on for 30 second messages to achieve a 30 minute watchdog
type scenario fpor existing hardware (that didn't have the hardware
watchdog facility) . In practicality you would probably issue 59 turn
on for 1 minute pulses. I agree hardware watchdogs are
vital in
process control. <br>
<br>
Watchdogs in embedded processor devices can have the effect of masking
firmware bugs because they effectively reset the processor. In my
embedded firmware xAP devices during the beta phase , which is
effectively the last 4 years (!) I have never enabled the watchdogs as
I want to be aware of any issues. IN a full production/commercial
world they would likely be enabled with some form of trigger
logging.<br>
<blockquote
cite="mid:F8C23952C3464124ABC70CD1A93C2DD8@xxxxxxx"
type="cite">
<div dir="ltr" align="left"><span
class="514494411-16032010"></span> </div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">The reason I specified byte
here, relates to the
above. The software watchdog is an emergency safety switch. 1..255
seconds is a bloody long time when something is overflowing
etc.</font></span></div>
<div dir="ltr" align="left"><span
class="514494411-16032010"><font
size="2" face="Arial">The other thing that is always
in the back of my
mind, is that my embedded controller doesn't have 1.5TB of parameter
storage :-( Only some EEPROM. Bytes
count.</font></span></div>
</blockquote>
Artificial restrictions have always come back to haunt us (as in the
UID value for example) so I would suggest it isn't fixed at byte level.
However my particular issue was not with the watchdog time but <br>
<br>
<span lang="en-au"><font size="2"
face="Arial">WD_Timeout_Val
:
Byte ; //
0/1/255<br>
<br>
BSC Level is not restricted to a 0-255 value being often 16 bit or even
odd ranges 0-3600 maybe. Or you could use a 0-100% value and
sacrifice
granularity.<br>
<br>
Yep.. I''m well aware of the memory issues - as I have had to scour my
own code looking for integers that can become byte or even bit
values.
I'm absolutely using every byte at the moment.<br>
<br>
<br>
</font></span>
<blockquote
cite="mid:F8C23952C3464124ABC70CD1A93C2DD8@xxxxxxx"
type="cite">
<div dir="ltr" align="left"><span
class="514494411-16032010"></span> </div>
<div dir="ltr" align="left"><span
class="514494411-16032010"></span> </div>
<div><font size="2" face="Arial"><span
class="514494411-16032010">In
regard to the watchdog's being endpoints in their own write, and
concatenated messages as per your example. Sounds
good.</span></font></div>
<div><font size="2" face="Arial"><span
class="514494411-16032010"></span></font> </div>
<div><font size="2" face="Arial"><span
class="514494411-16032010"></span></font> </div>
<div><font size="2" face="Arial"><span
class="514494411-16032010">As
far as the time stamp goes', I'm only talking about down to the second
level. Also having a Julian/LongInt representation in the same message
might not go astray. It's easy to do quick comparisons on a
Longint.</span></font></div>
<div><font size="2" face="Arial"><span
class="514494411-16032010">RTC's
for use in embedded devices are quite cheap these
days.</span></font></div>
</blockquote>
I think having a longint value is a good idea...<br>
<blockquote
cite="mid:F8C23952C3464124ABC70CD1A93C2DD8@xxxxxxx"
type="cite">
<div><font size="2" face="Arial"><span
class="514494411-16032010"></span></font> </div>
<div><font size="2" face="Arial"><span
class="514494411-16032010"></span></font> </div>
<div><font size="2" face="Arial"><span
class="514494411-16032010">In
regard to the optional RestoreState facility. I see this more for
reasonably dum things, like light controllers. The power dies and
comes
back in 10 seconds, the light comes on with the
power.</span></font></div>
<div><font size="2" face="Arial"><span
class="514494411-16032010"><span
class="514494411-16032010"><span
class="514494411-16032010">I.e. like
some X10 fittings that remember there last state. Meanwhile,
</span></span>10
minutes later the server has finished booting and is in control again.
</span></font></div>
<div><font size="2" face="Arial"><span
class="514494411-16032010">Yes
I know.... UPS. Personally, I have
four hours of UPS runtime driving
my servers but not everybody has this
luxury.</span></font></div>
</blockquote>
Again - taking a lead from C-Bus there is a possible additional
consideration of phased recovery of outputs eg that on a 12 channel
relay they come on sequentially with a preset delay to avoid
surges.<br>
<blockquote
cite="mid:F8C23952C3464124ABC70CD1A93C2DD8@xxxxxxx"
type="cite">
<div><font size="2" face="Arial"><span
class="514494411-16032010"><span
class="514494411-16032010"> </span></span></font></div>
<div><font size="2" face="Arial"><span
class="514494411-16032010"><span
class="514494411-16032010"></span>As you also said
Lehane, "xAP is not
predicated on the use of controllers". Just that statement says that
the devices on the xAP network should go back their prior
state.</span></font></div>
<div><font size="2" face="Arial"><span
class="514494411-16032010">This
is one of the big differences between xAP and xPL.
</span></font></div>
</blockquote>
<br>
People are free to add their own 'smarts' to any device they create for
xAP - it's part of product differentiation. For me
having 'restore
last state' could be useful for a couple of my devices but not the
majority - and in hardware terms it requires some form of retentive
memory on the device which can be awkward to implement. But by all
means create such a device and if it's an optional feature then you
have a feature differentiator which is attractive. At power
restore
and if using BSC it will announce its power recovery state to the whole
network although not all of those listeners and or the network
routers
might have yet fully recovered. Power fail recovery for lighting
is
fairly straightforward but it can become very involved for devices with
sequenced startup, other state dependencies, time
scheduling and
handling of 'catch up' of thing that should have happened whilst there
was an outage. <br>
<blockquote
cite="mid:F8C23952C3464124ABC70CD1A93C2DD8@xxxxxxx"
type="cite">
<div><font size="2" face="Arial"><span
class="514494411-16032010"></span></font> </div>
<div><font size="2" face="Arial"><span
class="514494411-16032010">The
final other point is, that just because some endpoint controllers don't
have some functionality (i.e. RTC facilities), doesn't mean we should
restrict the specification to the dumbest/leanest
hardware.</span></font></div>
</blockquote>
<br>
I agree ... but BSC was created for 'BASIC' status and control - it is
just one schema and we shouldn't shoehorn everything into it. In a way
its purposed at these simple devices. Although totally possible
to
model an AV amplifier for example using BSC it isn't appropriate and
defeats abstraction of devices (plug and play exchange of your
amp
model). Once there are multiple capabilities of BSC devices then things
get more uncertain and you also need to be able to ascertain each
devices capabilities somehow. I personally am loathe to
enhance BSC
as it is a very defined schema and this has been instrumental in its
widespread adoption but we could of course have discussions around BSC2
or something. One other aspect that might help here but is
missing in
xAP messages at the moment is versioning of schema eg reporting that a
device adheres to BSC v1.3 . You are totally free to add your
own
additional parameters within BSC blocks and to create your own schema
classes (as long as they don't start with the three reserved letters
'xap' as in xapbsc.cmd) so there's no restriction to what you're
trying to do - it would be just nice to get it adopted in a formalised
way.<br>
<br>
K<br>
<blockquote
cite="mid:F8C23952C3464124ABC70CD1A93C2DD8@xxxxxxx"
type="cite">
<div><font size="2" face="Arial"><span
class="514494411-16032010"></span></font> </div>
<div><font size="2" color="#0000ff"
face="Arial"><span
class="514494411-16032010"></span></font> </div>
<div class="Section1">
<p><span style="font-family: Arial; font-size:
10pt;">Regards,</span>
</p>
<p><b><span style="font-size: 13.5pt;">Neil
Wrightson.</span></b> <br>
<b><i><span style="font-size:
13.5pt;">N.W.Electronics</span></i></b>
<br>
<span style="font-size: 10pt;">ABN 76 768 513
867</span> <br>
<span style="font-family: Arial; font-size: 10pt;">Embedded
Controllers and Home Automation Products</span> <br>
Skype : <span class="SpellE">Neil_Wrightson</span>
<br>
<span style="font-family: Arial; font-size:
10pt;">Web
:</span><u>
<span style="color: blue;"><a
class="moz-txt-link-abbreviated" href="http://www.nwe.net.au";>www.nwe.net.au</a></span></u>
</p>
</div>
<div> </div>
<blockquote
style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px;
margin-left: 5px; margin-right: 0px;">
<div style="color: white; clear: both;">_,___</div>
</blockquote>
</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=2095/stime=1268754120";
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=X3oDMTJmNGthb29yBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNjg3NTQxMjA-";>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=X3oDMTJkZzhhbGN2BF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjY4NzU0MTIw";>
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>
--------------060109020200000502010508--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|