Re: MisterHouse xAP BSC Support ??

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

At some point - if this get's involved we'll move it over to the xAP
Developer list..... K

Gregg Liming wrote:

>Kevin Hawkins wrote:
>
>
>
>>When using BSC then X10 appears as any other Binary or Level based
>>device so you can't tell if a light is X10 or C-Bus for example
(indeed
>>it shouldn't matter). It is called by its name There is of course a
>>specific X10 schema as well in xAP should you so wish and then you
get
>>the X10 house/unit codes back.
>>
>>
>>
>>
>>
>That seems reasonable, and later you mention that some
"vendors" are
>using both BSC and some "extended/special purpose" schemas.
Does that
>mean that they are essentially broadcasting like events twice (once w/
>BSC and a second w/ something "better/different") or is the
"rule" only
>one schema transmission per event?
>
>
There aren't any rules here. BSC is an excellent schema for realtime
eventing and control - it also supports status queries and (optionally)
periodically provides status updates.  The other richer schema usually
come into play when extra features or data are required - for example in
lighting, ramp times are often used, or for a complex I/O device a
status system where all the I/O connected to the device is reported in
one xAP message.  ( BSC reports each end node as an individual
message).   I guess BSC is very suitable for the event based messages
and so you wouldn't tend to clutter the network with other event
messages. Network clutter on Ethernet is not really a major concern as
single UDP packets are almost insignificant in the overall utilisation
of the bandwidth. So you can do whatever is most approriate to the
task.   However BSC isn't appropriate for all devices and hence they
would have their own schema. BSC is meant to do exactly what it says -
support Basic devices not complex ones that should have their own
approriate schema . BSC might be supported for just a few key features
of a complex device.  HomeSeer, xAP Desktop  etc support both BSC and
rich schema devices so you can choose either, BSC is just a bit more
'plug and play' as the automation application knows immediately how to
support/control such devices.

>
>
>>>
>>>
>>>
>>>
>>Is every <devicename> in Misterhouse unique ?
>>
>>
>>
>yes
>
>
>
>>If so this will work, each
>>unique <devicename> will also have a corresponding unique UID
 eg
>>FF123401 FF123402 etc etc.  This will limit you (currently) to 254
>>different devices 01-FE - if you need more then you will have to
divide
>>the devices into groups somehow and start witha  new UID eg
FF1235xx
>>
>>
>>
>>
>>
>hmmm... I could personally see a situation in whch more than 254 is
>reasonable. Are there any xAP modules that "expect" (or are
sensitive
>to) a specific subgroup set of names?  Otherwise, I'm somewhat thinking
>of automatic grouping via device "type".
>
>
Group by whatever you wish really.  X10 for example has 16 housecodes
and 16 device codes so even that doesn't quite fit in 254 devices - if
virtual X10 devices exist (as in HomeSeer) then you well exceed 254 so
the HomeSeer implementation groups based on the device codes A B C ...
etc etc.   It is really simply a way of dividing devices to comply with
the 254 limit.

<Sneak preview> Later btw we will likely extend the UID length  to
support 4 or 6 hex digits for the sub address which will provide 64K or
16 million devices per application.

>
>
>>With regard to
>>TEXT devices then you can add any length of text up to the limit of
your
>>packet size which on UDP will be 1500 bytes.
>>
>>
>>
>I forgot about UDP packet size; I'd better watch that.  I'm guessing a
>better/safer number might be <=1492 for aDSL clamped users?
>
>
Remember it's the overall packet size as well....  including header and
full body etc.

>
>
>>The text must be in the
>>ascii printable range
>>
>>
>>
>I had assumed chars like curly braces, equals signs and other symbols
>used to delimit xAP messages would be "off-limits".  Am I
wrong?
>
>
The only character that is significant after an   "="    in a
body is
the CHR(10) which delimits the parameter value. So the above characters
are all allowable (I think).  It is true that badly coded receivers
might falsely recognise a } for example but they shouldn't.  This did
come up on the list a few months back and I believe that was the
concensus -  I will try this through a hub and check.  Netiom I believe
passes characters 20 to 7E hex inclusive using an =   and if a character
is outside this range it automatically changes to ascii hex encoding
using the pling !

>
>
>>>Perhaps a tangent, but Bruce Winter (Misterhouse's creator)
recently
>>>added support into mh to "sync" the state of two
running mh instances
>>>using xAP (albeit--again, a mh-specific schema).  Currently,
the support
>>>is really only applicable for "slaving" or
monitoring--not for real-time
>>>failover/redundancy.  However, I'm interested in the latter
(for more
>>>critical operations).  Has any thought gone into this specific
to xAP
>>>(additions to schema; guidelines on target wildcarding; etc.)?
>>>
>>>
>>>
>>>
>>>
>>>
>>James might have some comments here as he has used xAP and BSC to
>>achieve similar with a couple of apps including HomeSeer - the two
apps
>>stay in  synch via BSC and I guess if both were addressed with a
>>'wildcarded' target then both would respond. This leads to thinking
that
>>if one could be 'active' and one 'reserve' with a  way of switching
in
>>the second should the first fail then you achieve your goal. So, a
>>script running on instance B that monitored the heartbeats (and
expected
>>xAPBSC.events) from 'A' could take over 'transparently as soon as A
failed.
>>
>>
>>
>>
>>
>Precisely!  So, how do the apps "agree" as to who is the
master?
>Further, how is this communicated via xAP (maybe a new attribute in the
>header for heartbeats)?  If a "slave" decides that it must
become the
>"master" (either a "slave" config'd timeout--or
perhaps something
>transmitted via xAP), how does it communicate that? Again, I would
think
>via heartbeat--as it's the only repetitive message that an errant
>"master" might see on regaining network consciousness.
>
>
We do not have a specification or policy layer /schema yet for handling
redundany/fallback.  It is an interesting area to look at though and
perhaps propose something.  The fallback to the slave would be automatic
in the scenario above as the targets are wildcarded or absent and so all
that is required is the slave to set a flag saying it knows the master
is awol. However we do need something that tells the rest of the xAP
world which application is currently acting as Master and maybe this is
accomplished via heartbeat or just adding something to the header of all
messages (or even a schema).  The situation where the master re-appeared
would have to be handled too.   There are 'test' parameters that can be
added to headers if needed without breaking the xAP spec for exactly
this purpose should you wish to experiment. Test00 to Test99 . If it
proves to be the right way to do these sort of things then the xAP
specification committee would consider them for formal adoption..    If
this can be achieved just by using a Schema then no formal adoption is
required.

Just to mention one golden xAP rule ....  If you encounter unexpected
parameters in a header or body you should gracefully ignore them. This
allows header and body expansions to be made without breaking your
application, and allows you to supplement information in an existing
schema. It is recommended that where possible such info be added as an
additional block but sometimes this is inappropriate.  Gracefully
basically means just ignore the values,  don't abandon parsing the
remaining values and dont break ;-)


>BTW: I quite appreciate the dialog.  I've been a "lurker" for
some time
>on both this and the xpl lists.  You've been most informative and I
hope
>that I might eventually reciprocate.
>
>
NP - we all learn this way and as xAP is a group effort others may have
different interpretations of the spec too.   I want to learn more about
MisterHouse and if we can help get fuller xAP support there then great.

K

>Regards,
>
>Gregg
>
>
>
>