Re: xAP BSC

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Stuart Booth wrote:

>Also,
>
>What about Shutdown? Is that considered a change of state too?
>
>The way my app is implemented the endpoint defaults to OFF. If it's
>disabled at startup it pumps out a xAPBSC.Info message as the state
>hasn't changed from OFF.
>
>
I think what you're saying is that your reflecting the state of the
application as a BSC endpoint ??  In which case your reasoning sounds ok
. The difference here is that whilst your application isn't running then
the state of this endpoint can't change. As such reporting an 'event' at
startup and shutdown seems logical.   Compare this with an endpoint that
could change whilst the app isn't running, eg an input to a Netiom or a
piece of data being reported from the internet,( for example  perhaps
'message waiting' based on there being an email waiting in your pop3
server) and the difference is apparent.

>If it's enabled at startup it pumps out a xAPBSC.Event message as the
>state was OFF but it's now been activated.
>
>Then, when it shutsdown its state changes to OFF before terminating.
>
>
We have an overlap here between the function of heartbeats
(start/end) and a BSC state endpoint . There is also one aspect that is
awkward in that once your app has terminated then it will no longer
respond to BSC query messages.   Applying BSC to software endpoints
requires more interpretation than hardware where the state is absolute -
but I do in a way like this 'running state' being accessible easily to
devices supporting BSC .  For example HomeSeer can tell via a simple
binary test if your app is present and can even monitor it in
realtime.   If it polls your device when off though it won't respond ...

I think finding what and how we can apply BSC  is an evolving
exercise.  Devices shouldn't be shoehorned into BSC if they don't
naturally fit. For such devices other richer schema are more
approriate.  Perhaps in some devices limited functionality is reported
via BSC and the more intricate control available via another schema.
Netiom and C-Bus do this. An amplifier might for example expose OnOff
and Volume via BSC but all source selection, tonal control etc via a
more appropriate schema.  Whilst it is probably possible to represent an
amplifier in total using BSC it would become messy.  The fact for
example that selecting 'CD' disables 'Radio' is not apparent from BSC.
However supporting BSC has some immediate benefits in  that other
devices can track state in realtime and can control the device without
any schema knowledge.  Most importantly this applies to the various
controllers out there (eg HomeSeer, Floorplan, Mapper etc).  BSC allows
a 'plug and play' style of interaction which is very desireable and
facilitates easy scripting.  It is not apparent how to monitor or
control devices that use more complex schema just by inspection of a
schema message.  This was my big issue at last xAPCon with regard to
'context' parameters appearing within a block.  Until we have a
structure definition for schema accesible somewhere, or a mechanism for
conveying this information within a message / config then manual
interpretation will be required to interact with such devices
meaningfully.  An issue that applies to both xAP and xPL btw although
xAP fortunately has more addressing (context) available in the header,
particularly with sub addressing.

eg  from the X10 schema.....

*xap-x10.event*
{
event=dim
device=B3,B5      <<< MULTIPLE CONTEXT WITHIN THE BODY :-(
count=50
}

OR

*xap-x10.event*
{
command=all_lights_on
device=B                 <<< MULTIPLE COMPLEX CONTEXT
}

This one is even more awkward as the recipients are effectively a
wildcard and the units that will react are those devices on house code B
that are dimmer modules.  Tracking correctly the state of X10 module B7
which is a dimmer module and B8 which is an appliance module is very
awkward from a controller application.



>If it had been disabled at startup, remained disabled during its
>lifetime, then was shutdown, it would pump out a xAPBSC.Info message
>upon termination, which seems somewhat odd if essentially correct.
>
>
That seems sensible to me ...  the 'info' messages are just periodic
state messages ... do you also allow for a periodic update here ?
C-Bus and Netiom for example send them every xx minutes (configurable)
for all nodes . They can also be disabled totally if wanted.  xAP Netiom
can either cycle through all it's 102 nodes individually sending an info
for the current node every xx seconds or it can send all the 102 infos
in one burst every xx mins.
The purpose of periodic info's is just to update the network with
current state. It serves the purpose of informing new devices that have
joined the network and also should any devices miss an 'event' message
it will resynch them . Obviously any device can ask for 'current state'
at any time by issuing a 'query'.  Controllers issue this 'query'  at
startup for two purposes, firstly they can discover every available BSC
device /node on a network and secondly they can immediately synch
themselves with every nodes current state.

>Is this suitable?
>
>

Seems so... the slight difference being that you are issuing 'event' at
startup because you know that the last state reported was different
(Off) and couldn't have changed whilst you were absent.  - unless you
had crashed ;-)

K

PS Sorry - that meandered a bit ...