Re: MisterHouse xAP BSC Support ??

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Gregg Liming wrote:

>Kevin Hawkins wrote:
>
>
>
>>Possibly Gregg can answer this...
>>
>>   Not (currently) being a Misterhouse user, I wonder does it
support
>>the xAP BSC (Basic Status and Control ) schema ?
>>
>>
>>
>Not yet.  But, it is very high on my to-do list.  The real issue for me
>is how best to perform the integration.  Initially, it will probably
>permit automatic inclusion of all x10 supported objects.  I'd also
>include support for manually identifying other objects of interest.  I
>hope to begin working on this soon (e.g., next week).
>
>
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.

>
>
>>BSC is a very simple
>>schema that allows realtime status monitoring and control of
devices in
>>a 'standard' way allowing devices to operate in a  'plug and play'
>>fashion immediately at power on.  Therefore BSC compatible devices
could
>>be directly integrated into Misterhouse or any BSC savvy app
without
>>needing specific code/plugins, (indeed that was one of the main
>>objectives of BSC). Likewise all MisterHouse supported devices can
>>represent themselves on xAP as BSC devices.
>>
>>
>>
>>
>Currently, mh declares the xap header source to essentially reference
>the mh instance (e.g., mhouse.mh.main)--not a specific device.  From
>looking at a recent thread on x10 and BSC, I assume that I now need to
>ensure that the source is appended with :<devicename> (e.g.,
>":hallway_light")--correct?
>
>
Is every <devicename> in Misterhouse unique ? 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

>
>
>>   BSC supports three types of basic device that cover  around 99%
of
>>all device types.  BINARY onoff,   LEVEL (eg lights) at any
resolution
>>or % based, and TEXT eg news. weather,TV listings, serial data etc.
>>
>>
>>
>Oh--I hadn't read the spec closely enough.  Text as well--hunh?  Is
>there a discussion in the spec about what is (more importantly--is not)
>permitted (e.g., max length, special chars, etc.)?
>
>
>
BSC is aimed at controlling basic devices, more complex devices should
use their own specifc schema although they can use both. Indeed C-Bus
and the xAP Netiom use BSC and their own richer schema.  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. The text must be in the
ascii printable range - if it isn't then you must use the pling
datatype  ie text!010A65 instead of text=  .  Data is  readable hex.
Using ! then any binary data can be sent although this isn't really the
intent of a BSC text device.

>On a slightly related note, I have a VR app (multi-platform as it's
>engine is the Sphinx4 java engine) that "talks" whatever xAP
schema
>(and, theoretically, xPL--just untested) is entered into a config file
>(not easy and currently, not documented). It is now just sending out a
>mh-specific schema because I couldn't figure out how to include the VR
>command into BSC. Perhaps TEXT will do the trick.
>
>
Maybe... but it might be better to keep it as a mh schema or use a xAP
standard one if one suits.

>
>
>> A
>>more complex device like the xAP Netiom which has 16 inputs, 16
>>outputs,  4 Analogue inputs and a serial port can be fully
represented
>>using BSC and each node would then be accessible in Misterhouse .
>>
>>
>>
>>
>Yeah--I really want to get me hands on one of these
>
>
Well whip that credit card out and go to
http://www.phaedrusltd.com/pages/html/netiom-xap.html
  ;-)

>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.

K