Re: My list of possible xAP Enhancements

["estratosapiens" <dberenguer@xxxxxxxxxxxx>]

>From my point of view, taking your internal parameters as pure
endpoints is=
the easiest way to go. Doing this, you'll be able to cover your needs thro=
ugh the use of a single xAP schema (BSC). This will surely simplify the
xAP=
implementation in your embedded devices as I understand that they have lim=
ited resources.

For my opnodes and other designs I usually provide a mean to configure
inte=
rnal parameters via a Web interface but I understand that some
applications=
could require some kind of auto-configuration from remote devices. Anyway,=
any of the approaches introduced along this thread are valid IMO but I pre=
fer the BSC way because a new schema is not able to cover all possible
conf=
ig parameters in future designs.

Daniel.


--- In xAP_developer@xxxxxxx, Kevin Hawkins <yahoogroupskh@...> wro=
te:
>
> Hi Neill,
>=20
> I agree with Lehane's comments below - in particular the need for a=20
> separate configuration schema - you couldn't implement it in the way
you=
=20
> propose within BSC as it would break the existing schema
specification=20
> and hence all existing BSC implementations and devices.Configuration
is=20
> quite an involved area that also encompasses device discovery,
internal=20
> parameter config, UID allocation etc as well as the renaming of=20
> devices.  I would heartily welcome a thorough schema proposal here.
>=20
> Re the watchdogs - I can see that it is useful for some devices 
Within=20
> BSC it could  be done by supplementing additional parameters within
a=20
> xAPBSC.cmd message.  This is allowable within the existing=20
> specification.    There are some additional aspects to consider such
as=20
> how do you know whether the endpoint you are controlling supports=20
> watchdogs or not and how could you recover (read) any values you had
set =
?
>=20
> The watchdog is essentially a hardware feature supplemented by a need
to=
=20
> configure it from software.  As such existing controllers like the
very=20
> popular xAP Netiom couldn't be supported.   A limited software only=20
> watchdog is possible by a controller monitoring output states but
that=20
> assumes network connectivity remains available or is restored.    
The=20
> application you are using in a way is requiring a programmable
pulse=20
> output with a cancel/retrigger feature .  You could achieve this in=20
> hardware (eg a Netiom) by attaching a diode/capacitor that  is used as
a=
=20
> timer into a highish impedance circuit.     Also Phaedrus make a
device=20
> called the Viom which supports pulse outputs and internal smarts=20
> although this is not available in a xAP version.    You could
attach=20
> this to a xAP driven  serial port , such as the one available on the
xAP=
=20
> Netiom for example or roll your own hardware , as I suspect is your=20
> preference.
>=20
> Another approach instead of , or additional to the inclusion of
watchdog=
=20
> parameters within the xAPBSC.cmd message would be to expose the
watchdog=
=20
> parameters as BSC endpoints in their own right.  That way you can=20
> clearly see if the device has watchdog support and you have a way to
set=
=20
> or read the values .
>=20
> source=3Dacme.irrigation.controller:lawn.sprinkler
> source=3Dacme.irrigation.controller:lawn.WD.timer
> source=3Dacme.irrigation.controller:lawn.WD.enable
> source=3Dacme.irrigation.controller:lawn.WD.timeout
>=20
> BTW I don't think there should be byte value restrictions imposed.
>=20
> Because xAP supports concatenated messages you could include all
the=20
> xapbsc.cmd's within one xAP message which ensures that all are
received=20
> and actioned coincident.  Note however that the feature to include
a=20
> different target =3D line within each message body will be deprecated
in=
=20
> xAP v1.3 and so your addressing of the differing endpoints for each
body=
=20
> block would be achieved by means of the ID=3D parameter.     Doing it
thi=
s=20
> way doesn't need any specific schema changes although it doesn't
address=
=20
> discovery of endpoint watchdog capabilities (aside from naming).
>=20
> Re the time stamp - there is actually an existing date/time schema
for=20
> xAP used in a xAP clock application which I could dig out ( I see
its=20
> schema is not listed on the web site) although it might be preferable
to=
=20
> have better resolution and some accuracy / priority indication.=20=20
> Interestingly I'm passingly familiar with the C-Bus time
application=20
> which handles different accuracy time sources and master slave=20
> negotiation.  As that attests it is horrendously complex to implement
in=
=20
> a complete way  that caters for different capability time sources
that=20
> might come and go as well as time zones,  summer time etc.  I'm sure
the=
=20
> need here is just for something simple so an adaption of the
original=20
> xAP clock application is probably fine.  The C-Bus time application=20
> document is available for download from their site if anyone's
interested=
.
>=20
>    K
>=20
>=20
>=20
>=20
>=20
>   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)=20
> > configuration schema. Something which, from my viewpoint, is
missing.=20
> > This would allow dumb/unconfigured devices to be attached to
the=20
> > network and remotely configured.
> >
> > The watchdog is a good idea - I think there needs to be some=20
> > flexibility as to whether it is seconds/minutes/hours/days
since=20
> > repeat messages aren't something most xAP controllers/mappers
perform.=
=20
> > Therefore the behaviour might be slightly different from your
proposal=
=20
> > in that once sent a command with the watchdog entries, it will=20
> > fallback when the timers expire. So if the controller expects to
turn=20
> > off the watering after, at most, 3 hours then the watchdog is set
to=20
> > that value but can turn off after period up to that.
> >
> > My preference is for the controller to perform the state
restores=20
> > rather than the endpoint devices and can, if it wishes, keep=20
> > persistent the previous device states. Most endpoints aren't
going to=20
> > have the smarts to know how long power was off. Of course, xAP
isn't=20
> > predicated on the use of controllers but most installations use
one.
> >
> > Just as update on my current activities. I've started working on
using=
=20
> > the PIC32 since the cost (=A345) of the Ethernet board (Starter
Kit)  i=
s=20
> > comparable to the Modtronix one but with a much better CPU -
the=20
> > downside is the connector. The implementation is using Free RTOS,
so=20
> > 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=20
> >> xAP Schema.
> >>
> >> xAP Address renaming
> >> This is a means of changing the instance field and the Sub
Address=20
> >> field.
> >> Note - The UID does not change. This is specified by the
manufacture=20
> >> of the product.
> >> The Logical human readable area of the message is what I
propose that=
=20
> >> we allow the name changing of.
> >>
> >> To Change the Instance name of a device I suggest the
following schema
> >> {
> >> v=3D12
> >> hop=3D1
> >> uid=3DFF123400
> >> class=3DxAPBSC.cmd
> >> source=3DACME.Controller.Central
> >> target=3DACME.Lighting.apartment
> >> }
> >> {
> >> InstanceRename=3DHouse
> >> }
> >>
> >> This would now mean that the device has been renamed to
> >> target=3DACME.Lighting.House
> >>
> >> To Change the SubAddress name of a device I suggest the
following sche=
ma
> >> {
> >> v=3D12
> >> hop=3D1
> >> uid=3DFF123405
> >> class=3DxAPBSC.cmd
> >> source=3DACME.Controller.Central
> >> target=3DACME.Lighting.apartment:KitchenLight
> >> }
> >> {
> >> SubAddrRename=3DHallLight
> >> }
> >>
> >> 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=3D12
> >> hop=3D1
> >> uid=3DFF123400
> >> class=3DxAPBSC.rename
> >> source=3DACME.Controller.Central
> >> target=3DACME.Lighting.house
> >> }
> >>
> >> OR
> >>
> >> {
> >> v=3D12
> >> hop=3D1
> >> uid=3DFF123405
> >> class=3DxAPBSC.rename
> >> source=3DACME.Controller.Central
> >> target=3DACME.Lighting.apartment:KitchenLight
> >> }
> >>
> >> The other area I would like to look at are Watch Dog
capabilities on=20
> >> the BSC outputs.
> >> For those that aren't familiar with the WatchDog terminology.
A=20
> >> example should set the scene.
> >> I have a xAP device with a relay output that is used to
control the=20
> >> watering system on my garden.
> >> An application on my server monitors the rain fall in the
area via=20
> >> the internet weather.
> >> When it has been determined that the ground is probably too
dry, it=20
> >> 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=20
> >> unable to talk to the xAP Device and the garden has been
watered for=20
> >> the next 6 hours until I got home and saw the mess.
> >>
> >> However, if I had watchdog facility in the xAP device
hardware, it=20
> >> would have automatically turned the output off after a preset
period.
> >>
> >> So in this instance the "WatchDog" functionality is
a software=20
> >> function in the xAP device, that monitors the xAP commands
received=20
> >> and safely puts the outputs into a certain state.
> >>
> >> See _http://en.wikipedia.org/wiki/Watchdog_timer_=20
> >> <http://en.wikipedia.org/wiki/Watchdog_timer>=20
> >> <_http://en.wikipedia.org/wiki/Watchdog_timer_=20
> >> <http://en.wikipedia.org/wiki/Watchdog_timer>>
 for some further=20
> >> information.
> >>
> >> So what I'm proposing, is the following functionality be
added to the=
=20
> >> 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=20
> >> WD_Timeout_Value
> >> This value is in seconds.
> >>
> >> In the watering example above, if the server sent a command
to turn=20
> >> the device relay on every 120 seconds, than you would
probably want=20
> >> 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=
=20
> >> every two minutes for the half hour watering period,
otherwise the=20
> >> watchdog kicks in and turns the output off.
> >>
> >> WD_Timeout_Val
> >> This is the value the device outputs when the watchdog state
has been=
=20
> >> 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=20
> >> analogue output.
> >>
> >> Sometimes the output would be best set to ON, to turn on an
ERROR=20
> >> lamp to indicate a fault or turn on minimal lighting when the
server=20
> >> 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=20
> >> 30 second) power loss, it restores itself to the last known
state.
> >>
> >> I.e. the 240VAC mains into the house was briefly interrupted,
it=20
> >> would be preferable if the light outputs went back to their
last=20
> >> 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=20
> >> regardless of how long the power was off.
> >> If the value is greater than 0 and it is less than (the last
known=20
> >> time - the current time) then the output is restored to its
last=20
> >> 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>
> >>
> >
> >
> >
> >
>




------------------------------------