[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: My list of possible xAP Enhancements
--------------060907040103040606010906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Neill,
I agree with Lehane's comments below - in particular the need for a
separate configuration schema - you couldn't implement it in the way you
propose within BSC as it would break the existing schema specification
and hence all existing BSC implementations and devices.Configuration is
quite an involved area that also encompasses device discovery, internal
parameter config, UID allocation etc as well as the renaming of
devices. I would heartily welcome a thorough schema proposal here.
Re the watchdogs - I can see that it is useful for some devices Within
BSC it could be done by supplementing additional parameters within a
xAPBSC.cmd message. This is allowable within the existing
specification. There are some additional aspects to consider such as
how do you know whether the endpoint you are controlling supports
watchdogs or not and how could you recover (read) any values you had set ?
The watchdog is essentially a hardware feature supplemented by a need to
configure it from software. As such existing controllers like the very
popular xAP Netiom couldn't be supported. A limited software only
watchdog is possible by a controller monitoring output states but that
assumes network connectivity remains available or is restored. The
application you are using in a way is requiring a programmable pulse
output with a cancel/retrigger feature . You could achieve this in
hardware (eg a Netiom) by attaching a diode/capacitor that is used as a
timer into a highish impedance circuit. Also Phaedrus make a device
called the Viom which supports pulse outputs and internal smarts
although this is not available in a xAP version. You could attach
this to a xAP driven serial port , such as the one available on the xAP
Netiom for example or roll your own hardware , as I suspect is your
preference.
Another approach instead of , or additional to the inclusion of watchdog
parameters within the xAPBSC.cmd message would be to expose the watchdog
parameters as BSC endpoints in their own right. That way you can
clearly see if the device has watchdog support and you have a way to set
or read the values .
source=acme.irrigation.controller:lawn.sprinkler
source=acme.irrigation.controller:lawn.WD.timer
source=acme.irrigation.controller:lawn.WD.enable
source=acme.irrigation.controller:lawn.WD.timeout
BTW I don't think there should be byte value restrictions imposed.
Because xAP supports concatenated messages you could include all the
xapbsc.cmd's within one xAP message which ensures that all are received
and actioned coincident. Note however that the feature to include a
different target = line within each message body will be deprecated in
xAP v1.3 and so your addressing of the differing endpoints for each body
block would be achieved by means of the ID= parameter. Doing it this
way doesn't need any specific schema changes although it doesn't address
discovery of endpoint watchdog capabilities (aside from naming).
Re the time stamp - there is actually an existing date/time schema for
xAP used in a xAP clock application which I could dig out ( I see its
schema is not listed on the web site) although it might be preferable to
have better resolution and some accuracy / priority indication.
Interestingly I'm passingly familiar with the C-Bus time application
which handles different accuracy time sources and master slave
negotiation. As that attests it is horrendously complex to implement in
a complete way that caters for different capability time sources that
might come and go as well as time zones, summer time etc. I'm sure the
need here is just for something simple so an adaption of the original
xAP clock application is probably fine. The C-Bus time application
document is available for download from their site if anyone's interested.
K
On 15/03/2010 11:03, Lehane Kellett (g8kmh) wrote:
>
>
> Hi Neil,
> I think that these wouldn't fall into BSC but into a (new)
> configuration schema. Something which, from my viewpoint, is missing.
> This would allow dumb/unconfigured devices to be attached to the
> network and remotely configured.
>
> The watchdog is a good idea - I think there needs to be some
> flexibility as to whether it is seconds/minutes/hours/days since
> repeat messages aren't something most xAP controllers/mappers perform.
> Therefore the behaviour might be slightly different from your proposal
> in that once sent a command with the watchdog entries, it will
> fallback when the timers expire. So if the controller expects to turn
> off the watering after, at most, 3 hours then the watchdog is set to
> that value but can turn off after period up to that.
>
> My preference is for the controller to perform the state restores
> rather than the endpoint devices and can, if it wishes, keep
> persistent the previous device states. Most endpoints aren't going to
> have the smarts to know how long power was off. Of course, xAP isn't
> predicated on the use of controllers but most installations use one.
>
> Just as update on my current activities. I've started working on using
> the PIC32 since the cost (£45) of the Ethernet board (Starter
Kit) is
> comparable to the Modtronix one but with a much better CPU - the
> downside is the connector. The implementation is using Free RTOS, so
> multitasking, and my first project is a colour touchscreen controller.
>
> Lehane
>
>
>
> Neil Wrightson wrote:
>>
>> Hi All,
>>
>> Below are the following points that I would like to see added to
the
>> xAP Schema.
>>
>> xAP Address renaming
>> This is a means of changing the instance field and the Sub Address
>> field.
>> Note - The UID does not change. This is specified by the
manufacture
>> of the product.
>> The Logical human readable area of the message is what I propose
that
>> we allow the name changing of.
>>
>> To Change the Instance name of a device I suggest the following
schema
>> {
>> v=12
>> hop=1
>> uid=FF123400
>> class=xAPBSC.cmd
>> source=ACME.Controller.Central
>> target=ACME.Lighting.apartment
>> }
>> {
>> InstanceRename=House
>> }
>>
>> This would now mean that the device has been renamed to
>> target=ACME.Lighting.House
>>
>> To Change the SubAddress name of a device I suggest the following
schema
>> {
>> v=12
>> hop=1
>> uid=FF123405
>> class=xAPBSC.cmd
>> source=ACME.Controller.Central
>> target=ACME.Lighting.apartment:KitchenLight
>> }
>> {
>> SubAddrRename=HallLight
>> }
>>
>> This would now mean that this device SubAddress has been renamed
to
>> ACME.Lighting.apartment:HallLight
>>
>>
>> Or would both of the above examples be better as a separate class
>> {
>> v=12
>> hop=1
>> uid=FF123400
>> class=xAPBSC.rename
>> source=ACME.Controller.Central
>> target=ACME.Lighting.house
>> }
>>
>> OR
>>
>> {
>> v=12
>> hop=1
>> uid=FF123405
>> class=xAPBSC.rename
>> source=ACME.Controller.Central
>> target=ACME.Lighting.apartment:KitchenLight
>> }
>>
>> The other area I would like to look at are Watch Dog capabilities
on
>> the BSC outputs.
>> For those that aren't familiar with the WatchDog terminology. A
>> example should set the scene.
>> I have a xAP device with a relay output that is used to control
the
>> watering system on my garden.
>> An application on my server monitors the rain fall in the area via
>> the internet weather.
>> When it has been determined that the ground is probably too dry,
it
>> turns on the xAP devices relay.
>> Half an hour later it turns the relay back off.
>> Well it was supposed to , the network switch died and the server
was
>> unable to talk to the xAP Device and the garden has been watered
for
>> the next 6 hours until I got home and saw the mess.
>>
>> However, if I had watchdog facility in the xAP device hardware, it
>> would have automatically turned the output off after a preset
period.
>>
>> So in this instance the "WatchDog" functionality is a
software
>> function in the xAP device, that monitors the xAP commands
received
>> and safely puts the outputs into a certain state.
>>
>> See _http://en.wikipedia.org/wiki/Watchdog_timer_
>> <http://en.wikipedia.org/wiki/Watchdog_timer>
>> <_http://en.wikipedia.org/wiki/Watchdog_timer_
>> <http://en.wikipedia.org/wiki/Watchdog_timer>>
for some further
>> information.
>>
>> So what I'm proposing, is the following functionality be added to
the
>> BSC commands and applies to each sub address.
>> WD_Enable : Boolean ; //
>> WD_Timer_Val : Byte ; // Seconds
>> WD_Timeout_Val : Byte ; // 0/1/255
>>
>> WD_Enable
>> If ON then this Sub address has watchdog functionality turned ON
>>
>> WD_Timer_Val
>> This is how long to wait before changing the output to the
>> WD_Timeout_Value
>> This value is in seconds.
>>
>> In the watering example above, if the server sent a command to
turn
>> the device relay on every 120 seconds, than you would probably
want
>> the WD_Timer_Val set at 240 seconds.
>>
>> This allows a bit of time in case the server does a brief go slow.
>> The draw back here is that the server needs to send an output
command
>> every two minutes for the half hour watering period, otherwise the
>> watchdog kicks in and turns the output off.
>>
>> WD_Timeout_Val
>> This is the value the device outputs when the watchdog state has
been
>> triggered for this device and sub address.
>> A 0 or 1 to be used for a logic output or a value from 0..255 for
an
>> analogue output.
>>
>> Sometimes the output would be best set to ON, to turn on an ERROR
>> lamp to indicate a fault or turn on minimal lighting when the
server
>> has died instead of leaving the house in darkness.
>>
>> The other BSC command is
>> RestoreLastState : Boolean ; //
>> RestoreLastStateTimer : Byte ; // Minutes
>>
>> The idea of this, is that when a xAP device experiences a brief
(say
>> 30 second) power loss, it restores itself to the last known state.
>>
>> I.e. the 240VAC mains into the house was briefly interrupted, it
>> would be preferable if the light outputs went back to their last
>> known state.
>>
>> RestoreLastState
>> If ON then the specified sub address is restored to its prior
state
>>
>>
>> RestoreLastStateTimer
>> If this value is 0 then the output is restored to its previous
value
>> regardless of how long the power was off.
>> If the value is greater than 0 and it is less than (the last known
>> time - the current time) then the output is restored to its last
>> state else left off.
>>
>> Xap-TimeStamp
>> Send a timestamp message to the network at pre-defined periods.
>> This is used to synchronize any devices that are not capable of
NTP.
>>
>> 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_ <file://www.nwe.net.au>
>>
>
>
>
>
--------------060907040103040606010906
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 Neill,<br>
<br>
I agree with Lehane's comments below - in particular the need for a
separate configuration schema - you couldn't implement it in the way
you propose within BSC
as it would break the existing schema specification and hence all
existing BSC implementations and devices.Configuration is quite an
involved area that also encompasses device discovery, internal
parameter config, UID allocation etc as well as the renaming of
devices. I would heartily welcome a thorough schema proposal
here.<br>
<br>
Re the watchdogs - I can see that it is useful for some devices
Within
BSC it could be done by supplementing additional parameters
within a
xAPBSC.cmd message. This is allowable within the existing
specification. There are some additional
aspects to consider such as
how do you know whether the endpoint you are controlling supports
watchdogs or not and how could you recover (read) any values you had
set ?<br>
<br>
The watchdog is essentially a hardware feature supplemented by a need
to configure it from software. As such existing controllers like
the
very popular xAP Netiom couldn't be supported. A limited
software
only watchdog is possible by a controller monitoring output states but
that assumes network connectivity remains available or is restored.
The application you are using in a way is requiring a programmable
pulse output with a cancel/retrigger feature . You could achieve
this
in hardware (eg a Netiom) by attaching a diode/capacitor that is
used
as a timer into a highish impedance
circuit. Also Phaedrus make a
device called the Viom which supports pulse outputs and internal smarts
although this is not available in a xAP
version. You could attach
this to a xAP driven serial port , such as the one available on
the
xAP Netiom for example or roll your own hardware , as I suspect is your
preference.<br>
<br>
Another approach instead of , or additional to the inclusion of
watchdog parameters within the xAPBSC.cmd message would be to expose
the watchdog parameters as BSC endpoints in their own right. That
way
you can clearly see if the device has watchdog support and you have a
way to set or read the values . <br>
<br>
source=acme.irrigation.controller:lawn.sprinkler<br>
source=acme.irrigation.controller:lawn.WD.timer<br>
source=acme.irrigation.controller:lawn.WD.enable<br>
source=acme.irrigation.controller:lawn.WD.timeout <br>
<br>
BTW I don't think there should be byte value restrictions
imposed.<br>
<br>
Because xAP supports concatenated messages you could include all the
xapbsc.cmd's within one xAP message which ensures that all are received
and actioned coincident. Note however that the feature to include
a
different target = line within each message body will be deprecated in
xAP v1.3 and so your addressing of the differing endpoints for each
body block would be achieved by means of the ID= parameter.
Doing
it this way doesn't need any specific schema changes although it
doesn't address discovery of endpoint watchdog capabilities (aside from
naming).<br>
<br>
Re the time stamp - there is actually an existing date/time schema for
xAP used in a xAP clock application which I could dig out ( I see its
schema is not listed on the web site) although it might be preferable
to have better resolution and some accuracy / priority
indication.
Interestingly I'm passingly familiar with the C-Bus time application
which handles different accuracy time sources and master slave
negotiation. As that attests it is horrendously complex to
implement
in a complete way that caters for different capability time
sources
that might come and go as well as time zones, summer time
etc. I'm
sure the need here is just for something simple so an adaption of the
original xAP clock application is probably fine. The C-Bus time
application document is available for download from their site if
anyone's interested.<br>
<br>
K<br>
<br>
<br>
<br>
<br>
<br>
On 15/03/2010 11:03, Lehane Kellett (g8kmh) wrote:
<blockquote cite="mid:4B9E140E.7070900@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">
Hi Neil,<br>
I think that these wouldn't fall into BSC but into a (new)
configuration schema. Something which, from my viewpoint, is missing.
This would allow dumb/unconfigured devices to be attached to the
network and remotely configured.<br>
<br>
The watchdog is a good idea - I think there needs to be some
flexibility as to whether it is seconds/minutes/hours/days since repeat
messages aren't something most xAP controllers/mappers perform.
Therefore the behaviour might be slightly different from your proposal
in that once sent a command with the watchdog entries, it will fallback
when the timers expire. So if the controller expects to turn off the
watering after, at most, 3 hours then the watchdog is set to that value
but can turn off after period up to that.<br>
<br>
My preference is for the controller to perform the state restores
rather than the endpoint devices and can, if it wishes, keep persistent
the previous device states. Most endpoints aren't going to have the
smarts to know how long power was off. Of course, xAP isn't predicated
on the use of controllers but most installations use one.<br>
<br>
Just as update on my current activities. I've started working on using
the PIC32 since the cost (£45) of the Ethernet board (Starter
Kit) is
comparable to the Modtronix one but with a much better CPU - the
downside is the connector. The implementation is using Free RTOS, so
multitasking, and my first project is a colour touchscreen
controller.<br>
<br>
Lehane<br>
<br>
<br>
<br>
Neil Wrightson wrote:
<blockquote
cite="mid:9C0171DCCD4B472E83975812F5D6A20A@xxxxxxx"
type="cite"><span style="display:
none;"> </span>
<div id="ygrp-text">
<p><!-- Converted from text/rtf format --> </p>
<p><span lang="en-au"><font size="2"
face="Arial">Hi All,</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial"> </font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">Below are the
following points that I would like to see added to the xAP
Schema.</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial"> </font></span> </p>
<p><span lang="en-au"><font size="2"
face="Arial">xAP Address
renaming</font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">This is a means of
changing the instance field and the Sub Address
field.</font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">Note - The UID does
not change. This is specified by the manufacture of the
product.</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">The Logical human
readable area of the message is what I propose that we allow the name
changing of.</font></span> <br>
<span lang="en-au"><font size="2"
face="Arial"> </font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">To Change the
Instance
name of a device I suggest the following schema</font></span>
<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.<wbr>cmd</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">source=ACME.<wbr>Controller.<wbr>Central</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">target=ACME.<wbr>Lighting.<wbr>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=<wbr>House</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">This would now mean
that the device has been renamed to </font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">target=ACME.<wbr>Lighting.<wbr>House</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial"> </font></span> </p>
<p><span lang="en-au"><font size="2"
face="Arial">To Change the
SubAddress name of a device I suggest the following
schema</font></span>
<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=FF123405</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">class=xAPBSC.<wbr>cmd</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">source=ACME.<wbr>Controller.<wbr>Central</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">target=ACME.<wbr>Lighting.<wbr>apartment:<wbr>KitchenLight</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">SubAddrRename=<wbr>HallLight</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">}</font></span> </p>
<p><span lang="en-au"><font size="2"
face="Arial">This would now
mean
that this device SubAddress has been renamed to
</font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">ACME.Lighting.<wbr>apartment:<wbr>HallLight</font></span>
</p>
<br>
<p><span lang="en-au"><font size="2"
face="Arial">Or would both of
the above examples be better as a separate class</font></span>
<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.<wbr>rename</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">source=ACME.<wbr>Controller.<wbr>Central</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">target=ACME.<wbr>Lighting.<wbr>house</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">}</font></span> </p>
<p><span lang="en-au"><font size="2"
face="Arial">OR</font></span> </p>
<p><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=FF123405</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">class=xAPBSC.<wbr>rename</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">source=ACME.<wbr>Controller.<wbr>Central</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">target=ACME.<wbr>Lighting.<wbr>apartment:<wbr>KitchenLight</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">}</font></span> </p>
<p><span lang="en-au"><font size="2"
face="Arial"> </font></span> </p>
<p><span lang="en-au"><font size="2"
face="Arial">The other area I
would like to look at are Watch Dog capabilities on the BSC
outputs.</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">For those that
aren’t
familiar with the WatchDog terminology. A example should set the
scene.</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">I have a xAP device
with a relay output that is used to control the watering system on my
garden.</font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">An application on my
server monitors the rain fall in the area via the internet
weather.</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">When it has been
determined that the ground is probably too dry, it turns on the xAP
devices relay.</font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">Half an hour later
it
turns the relay back off. </font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">Well it was supposed
to , the network switch died and the server was unable to talk to the
xAP Device and the garden has been watered for the next 6 hours until I
got home and saw the mess.</font></span></p>
<p><span lang="en-au"><font size="2"
face="Arial">However, if I had
watchdog facility in the xAP device hardware, it would have
automatically turned the output off after a preset
period.</font></span></p>
<p><span lang="en-au"><font size="2"
face="Arial">So in this
instance
the “WatchDog” functionality is a software function in
the xAP device,
that monitors the xAP commands received and safely puts the outputs
into a certain state. </font></span></p>
<p><span lang="en-au"><font size="2"
face="Arial">See </font></span><a
moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/Watchdog_timer";><span
lang="en-au"><u><font
size="2" color="#0000ff" face="Arial">http://en.wikipedia<wbr>.org/wiki/<wbr>Watchdog_<wbr>timer</font></u></span></a><span
lang="en-au"><font size="2"
face="Arial"> <</font></span><a
moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/Watchdog_timer";><span
lang="en-au"><u><font
size="2" color="#0000ff" face="Arial">http://en.wikipedia<wbr>.org/wiki/<wbr>Watchdog_<wbr>timer</font></u></span></a><span
lang="en-au"><font size="2"
face="Arial">> for some further
information.</font></span></p>
<p><span lang="en-au"><font size="2"
face="Arial">So what I’m
proposing, is the following functionality be added to the BSC commands
and applies to each sub address.</font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">
WD_Enable
: Boolean ; //</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">
WD_Timer_Val
: Byte ; //
Seconds</font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">
WD_Timeout_Val
: Byte ; //
0/1/255</font></span> </p>
<p><span lang="en-au"><font size="2"
face="Arial">WD_Enable</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">If ON then this Sub
address has watchdog functionality turned ON</font></span>
</p>
<p><span lang="en-au"><font size="2"
face="Arial"> WD_Timer_Val</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">This is how long to
wait before changing the output to the
WD_Timeout_Value</font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">This value is in
seconds.</font></span> </p>
<p><span lang="en-au"><font size="2"
face="Arial">In the watering
example above, if the server sent a command to turn the device relay on
every 120 seconds, than you would probably want the WD_Timer_Val set at
240 seconds.</font></span></p>
<p><span lang="en-au"><font size="2"
face="Arial">This allows a bit
of time in case the server does a brief go slow.</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">The draw back here
is
that the server needs to send an output command every two minutes for
the half hour watering period, otherwise the watchdog kicks in and
turns the output off.</font></span></p>
<p><span lang="en-au"><font size="2"
face="Arial">WD_Timeout_Val
</font></span><br>
<span lang="en-au"><font size="2"
face="Arial">This is the value
the
device outputs when the watchdog state has been triggered for this
device and sub address. </font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">A 0 or 1 to be used
for a logic output or a value from 0..255 for an analogue
output.</font></span>
</p>
<p><span lang="en-au"><font size="2"
face="Arial">Sometimes the
output would be best set to ON, to turn on an ERROR lamp to indicate a
fault or turn on minimal lighting when the server has died instead of
leaving the house in darkness.</font></span></p>
<p><span lang="en-au"><font size="2"
face="Arial"> </font></span> </p>
<p><span lang="en-au"><font size="2"
face="Arial">The other BSC
command is</font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">
RestoreLastState
: Boolean ; //</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">
RestoreLastStateTim<wbr>er :
Byte ; // Minutes</font></span>
</p>
<p><span lang="en-au"><font size="2"
face="Arial">The idea of this,
is that when a xAP device experiences a brief (say 30 second) power
loss, it restores itself to the last known
state.</font></span></p>
<p><span lang="en-au"><font size="2"
face="Arial">I.e. the 240VAC
mains into the house was briefly interrupted, it would be preferable if
the light outputs went back to their last known
state.</font></span></p>
<p><span lang="en-au"><font size="2"
face="Arial">RestoreLastState
</font></span><br>
<span lang="en-au"><font size="2"
face="Arial">If ON then the
specified sub address is restored to its prior
state</font></span> </p>
<br>
<p><span lang="en-au"><font size="2"
face="Arial">RestoreLastStateTim<wbr>er</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">If this value is 0
then the output is restored to its previous value regardless of how
long the power was off.</font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">If the value is
greater than 0 and it is less than (the last known time - the current
time) then the output is restored to its last state else left
off.</font></span></p>
<p><span lang="en-au"><font size="2"
face="Arial"> </font></span> </p>
<p><span lang="en-au"><font size="2"
face="Arial">Xap-TimeStamp</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">Send a timestamp
message to the network at pre-defined periods.</font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">This is used to
synchronize any devices that are not capable of NTP.
</font></span> </p>
<p><span lang="en-au"><font size="2"
face="Arial"> </font></span> </p>
<p><span lang="en-au"><font size="2"
face="Arial">Regards, </font></span>
</p>
<p><span lang="en-au"><font size="2"
face="Arial">Neil Wrightson. </font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">N.W.Electronics </font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">ABN 76 768 513 867 </font></span>
<br>
<span lang="en-au"><font size="2"
face="Arial">Embedded Controllers
and Home Automation Products </font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">Skype :
Neil_Wrightson </font></span> <br>
<span lang="en-au"><font size="2"
face="Arial">Web :
</font></span><a
moz-do-not-send="true"
href="file://www.nwe.net.au"><span
lang="en-au"><u><font
size="2" color="#0000ff"
face="Arial">www.nwe.net.<wbr>au</font></u></span></a><span
lang="en-au"><font size="2"
face="Arial"> </font></span> </p>
</div>
<!-- end group email --></blockquote>
<br>
<div width="1" style="color: white; clear:
both;"></div>
</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=2092/stime=1268736424";
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=X3oDMTJmaDc3Zmc4BF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNjg3MzY0MjQ-";>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=X3oDMTJkcHN1NjRxBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjY4NzM2NDI0";>
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>
--------------060907040103040606010906--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|