RE: xAP v1.3

["Neil Wrightson" <neilw@xxxxxxxxxx>]

Hi Kevin,

Thanks for responding.

To me, things that would have watchdog capability, would generally be
controlled by one governing box PC i.e. MisterHouse (Floorplan?).
These watchdogged outputs would be used for things such as Sprinkler
systems
and would not be controlled by multiple devices.

The other idea of devices that remembered their states, would relate to
outputs such as lighting.
After a short power failure i.e. 5..10 minutes, the lights would turn back
onto their previous state.
If the power was out for an extended period i.e. >1hr, then the outputs
would be set to their watchdogged state.
But this does not mean that this output is a watchdogged output as in the
sprinkler example, it just returns to the watchdogged state.

Regards,
Neil Wrightson.
Skype : Neil_Wrightson


-----Original Message-----
From: xAP_developer@xxxxxxx [mailto:xAP_developer@xxxxxxx]
On Behalf Of Kevin Hawkins
Sent: Thursday, 17 September 2009 10:08 PM
To: xAP_developer@xxxxxxx
Subject: Re: [xAP_developer] xAP v1.3

Hi Neil,

Glad it's all progressing. I think this sort of issue does need a solution
so glad you're tackling it. A couple of thoughts.

I would try and avoid actually altering the xAPBSC schema messages if
possible eg by adding extra parameters as that will create a non standard
implementation but you should I think be able to do what you want without
that anyway - by just creating extra BSC endpoints for the
WatchDog_Timeout_Enable and others and then setting them directly using a
second block in the same message. The xAP spec does however allow you to
include extra parameters should you wish.

In your system the constant 'tickle' by the PC does reaffirm the state but
what would happen if another controller changed the state of the device ?
Then the originating controller would change it back again. Now you could
monitor all 'event' messages from that endpoint to recognise that another
device had originated a change I suppose , or indeed all messages targeted
at that device, and then backoff as the owning controller. It would require
that any controller wanting to interact with your device implemented the
tickle process however. This I suppose might mandate the xAPBSC.cmd
actually
have some identification within the message that it can 'tickle' - which a
dual block message would.
Might need some thinking with regard to multiple controllers and other
existing controllers being able to interact.

Re SNTP - my embedded gateway implements it but I'm not aware of a
standalone xAP app - seems like an obvious one for someone to write - and
there is an existing xAP date/time schema.

Being able to configure BSC devices (likely using a schema similar to
BSC) is something we really need . It's also part of a much larger xAP
config need that Patrick mentioned. I have the same need in my C-Bus
gateway
in terms of matching the endpoint names to those configured in the C-Bus
Toolkit software. I know someone is working on this and so I'll ask them to
contact you (and Patrick) offlist and see if we can come up with something
useful to all.


K

Neil Wrightson wrote:
>
>
> Hi,
> I'm still in the progress of creating my first BSC device and I'm
> looking at adding a few extensions to the common BSC schema.
> From an output end point perspective -
>
>   1.
>       WatchDog_Timeout_Enable : Boolean; // True = Enable Watchdog for
>       this output, False = No watchDog
>   2.
>       Watch_Dog_Timeout_Value : Byte ; // I.e. 0 or 1 for a logic
>       output or 0..255 for an analogue output
>
> From a Device perspective
>
>   1.
>       WatchDog_TimeOut_Interval : Byte ; // 0..255 Minutes
>   2.
>       Restore_State_Value : Byte ; // 0..255 Minutes
>
> My thoughts in this area are.
> A xAP controlling PC (else where on the network) sets an output on the
> above device&endpoint.
> The PC continues to set this output via the same command at an
> interval less then the WatchDog_TimeOut_Interval.
> When the device receives an output command it records the current
> state of each watchdogged output i.e. 0,1 or 0..255 in non volatile
> memory and also a Device comms timestamp.
> If the PC stops sending the output messages, the watchdog times out.
> The device then sets the output to the Watch_Dog_Timeout_Value (This
> may actually be to an output ON i.e. a warning light).
> If there has been a power failure and the device powers up again. The
> device checks the current time against the last comms timestamp. If
> the value is less then Restore_State_Value then the outputs are set to
> the state prior to the power failure. If the time difference is great
> then set the outputs to the Watch_Dog_Timeout_Value.
> The device could either get the time from an internal RTC or an
> external SNTP server (or xAP SNTP Server? Does anybody have one of
> these?).
> I'm also looking at protocols to allow devices and endpoints to be
> dynamically assigned with names.
>
> Regards,
>
> *Neil Wrightson.*
> Skype : Neil_Wrightson
>
>



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