Announcement

Collapse
No announcement yet.

xAP BSC - Basic Status and Control

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    xAP BSC - Basic Status and Control

    xAP has a new very 'basic' schema to allow for interoperability between low level devices. This schema would typically operate in addition to a more feature rich schema for the device. We called it 'Basic status and control' or BSC -- does what it say on the tin type approach .
    The idea is that simple devices drop into three categories 'BINARY' devices whose state is only ON|OFF , 'LEVEL' devices represented as a 0-100% value and 'TEXT' devices where a value is a string. The latter also brings in some stream devices eg say newsfeeds but not high bandwidth or binary stream devices eg Audio (this is not classes as a simple device).
    BSC caters for limited discovery - you can ask a device what hardware endpoints it has and of what type they are, you can also control them in a standard way and ask their state, lastly they report state changes (events) in a standard way. This allows a very simple interconnect between devices to be made and also a controller application like HS to adopt the devices quite naturally within its state model, allowing for control using contextual clicks etc. HomeSeer devices implemented via plugins appear as BSC devices on xAP and report their state and are controllable as xAP devices. More complex xAP devices can also be supported using their fuller schemas by import of the schema definition documents supplied by the xAPp author.
    I have attached to this post v1.2 of the xAP BSC document and will now bring a section of a post over from Michael McSharry in the beta thread.
    K
    Attached Files

    #2
    <BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR> The first thing I noticed when I started it up was the xap viewer identified a subset of my homeseer devices as nodes on the network. The attachment shows this view.

    I looked at a message associated with an event and saw the xAPstatus.event class message, output.state with a key/value pair of 3c=OFF. The device that it reported on contains text in the device string, but I do not recognize the 3c or OFF as being part of it. What is this message trying to tell me and under what conditions will it be generated? Will these nodes eventually appear for all my homeseer devices?
    <HR></BLOCKQUOTE>

    The nodes that have appeared are correct Michael - you have a bucketload of temp sensors in HS and these now appear as BSC devices via xAP - xAP makes best guesses as to the type of these devices based on how HomeSeer reflects their state.
    The xAPstatus.event message is a xAP BSC message that will be sent whenever the device changes state in HS - it will also be sent if it is asked to change state from xAP but was already in that state. You are interestingly seeing this as a BINARY type device with ON|OFF and I think this just reflects the type of device as installed in HS (James ?) - what type of device is it ? You are right that all HS devices will appear this way on xAP.

    The 3C=OFF is part of BSC - each hardware endpoint (and each HS device is one) creates a unique UID on xAP and the 3C reflects the last two digits of this UID value - it could be something like FF41123C perhaps. It will also have a unique name after the : in the xAP source address - this is known as the sub address. Basically each device in xAP has an address and then there is a ':' and then each endpoint on that device (eg input /output ports) has a unique sub address within the device. xAP allows for currently 254 endpoints within one device but because theoretically HomeSeer could have more than this it uses several main application addresses to accomodate them all eg 'A' for Housecode A on X10.

    source=ACME.DimmerPack.Lounge:TableLamp
    source=ACME.DimmerPack.Lounge:CentreLight
    source=ACME.DimmerPack.Upstairs:MasterBedroom
    Source=ACME.DimmerPack.Upstairs:Hallway

    etc. Note there is a hierarchical inference and addresses can be wildcarded to achieve results

    target=ACME.DimmerPack.*:&gt; to address all DimmerPacks manufactured by ACME. The number of levels in the hierarchy is arbitrary.

    One other point.. xAP devices that are created as HomeSeer devices will also send BSC information. However if the device was originally created from a BSC xAP device then HomeSeer knows this and will not send xAPcmd.state commands for example to control it. It will send these commands if you locally control the device however within HS eg by a script or user action (right click context menu or web interaction). K

    Comment


      #3
      I generally understand the BSC schema, but I'm still confused on two elements. The attachment contains a message to talk from. This device reflects the voltage of an analog input device. From the homeseer perspective the integer component of the voltage is contained in the DeviceValue. The full value formatted for HTML display is contained in the DeviceString.

      I see the DeviceString has been picked up and output via XapStatus.info / output.state. In my prior message it looks like the DeviceStatus of another device was used for the BINARY output. How does one tell the plugin the information that is to be conveyed? It is not unusual to utilize two pieces of state information in Homeseeer for the same device. For example, DeviceStatus is used to indicate if a device is on or off and the DeviceString of the same device used to describe characteristics of the state. Does this mean there should be multiple xap UID's for a single Homeseer device?

      The xap Conduit elected to call this device FF41344 and used the 44 as the key value in the output.state block. How is any other xap application going to know what this represents? If I was going to run this on a different computer will 44 still be uniquely associated with the exact same homeseer device?

      The plugin selected 96 as part of the source address. Is this selected dynamically or is it unique to the xap conduit plugin. When you run the plugin do you also see 96 as part of the address?

      It was my understanding that a uid is unique across an xap network. It is the case that the uid is only unique within a given source xap address?
      Attached Files

      Comment


        #4
        I think maybe we have not covered an option here then - where the 'status' of a device is reflected in two (or more ?) pieces of information within HS and determining which - (or both) to report. I guess it is possible that these pieces of info could be inconsistent as well in terms of cursory examination depending on how they are maintained. I'll defer to James but we might have to think about this a little more.

        There definitely shouldn't be multiple UIDs for one hardware endpoint though. We need a way of selecting more dependably the mapping of the device state to one of the three BSC models. There is no reason I guess why the other extra detail associated with the device (eg html formatted) can't be appended into the same message somehow perhaps as a second block, within the same body.

        Now onto UID's - the 44 is contextual in that it relates to the current UID which is FF414344 so to that extent it IS unique on your network - (really the 44 is an abbreviation for FF414344 if you like). The reason it is done like this is that we are avoiding having repeating parameter names within one message block eg "state=" and so we use the UID end digits (the subUID) which is guaranteed to be unique in one message. This is particularly important when you perhaps want to ask several endpoints to change state at once (synchronised) as you can include all the subUID identifiers in one block.

        target=ACME.DimmerPack.Upstairs
        ...
        }
        xAPcmd.state
        {
        01=OFF
        07=56%
        08=ON
        09=Some Text
        15=10%
        }
        Note it is also possible (although not recommended) to wildcard the target address above in which case combinational analysis should be made to ensure the UIDs in the body are (valid) matched by the target. A more useful wildcard application is with a xAPcmd.query message where - for example, asking Target=SCENTIUM.HomeVision.Server:InputPorts.&gt; could ask the status of all the input ports on a HomeVision controller to be reported.

        K

        Comment


          #5
          What are the rules by which this UID value is assigned and how persistent is it? The 44 associated with this device is not something I selected. It happened automatically.

          If I rename my homeseer device from "6100000010854V3" to "Filter Backpressure" then will I get a new UID or will it remain the same? If I change the device code from "[33" to "[44" then what happens with the UID. What if it changes to "Z44"? What if I change the homeseer location from "Temperature" to "Mechanical Room" on this device? What if I delete the device and recreate it?

          If another xap app wanted to know the current voltage reading of this sensor then it would send a .Query message to this target address. I'm guessing it would need to know that this is FF414344 or at least 44 in the subaddress field.

          My homeseer logical interface to this device is sometimes its device code, sometimes its device location and name, and sometimes its ref property. (Only the ref property is unique among homeseer devices). This is how all my scripts and web pages want to address them. Does this mean I need a off-line ledger to map a homeseer device ref property to a xap UID so I will be able to know what is what? How would the example you gave below be done logically with the xap Conduit plugin without the need to know the guts of xap UID's but with the context of homeseer device names or codes?

          xAPcmd.state
          {
          01=OFF
          07=56%
          08=ON
          09=Some Text
          15=10%


          What is the relationship between the sensor that provides this 4.6 volt reading in my "talk-from" message, the homeseer device, and the UID? If this sensor is located at another xap application does it need to know anything about FF414344? I'm assuming that this sensor will provide the reading without any congizance of Homeseer/xap Conduit and the Homeseer virtual devices that contains the same value. I'm assuming, however, that by default the xap Conduit will recognize this sensor's message and will provide the option to create a second homeseer device to hold its value/text/binary. The user can select if it should be created of the messages from this sensor ignored.

          The device strings in some homeseer devices can hold some pretty unpleasant stuff. It could be an entire HTML web page for example. Will the xap Conduit send a BSC message everytime this device that is used to cache downloads is updated with a new download or is there a configuration mechanism by which selective devices are enabled to be xap-visible on the outbound direction?

          Comment


            #6
            Given the wide range of uses of HomeSeer devices, and the fact that the use of a large percentage of them are local to HomeSeer (at least in my system) it would make sense to have a way to configure which HomeSeer devices are visible to xAp at all and also to possibly define their xAp "type" independent of the defined type in HomeSeer. Something like the motion sensors in the DooMotion plugin.

            Bill

            Comment


              #7
              Im going to defer again to James on the UID allocation - I can see that it is awkward if it moves around and I am not sure what exact algorithm he uses here to choose UIDs

              Bill - yes I was thinking the same - an ability to choose which HS devices particpate in xAP would be nice. For users with a large HS device list this is going to be really desireable. I don't use the DooMotion plugin but I'll take a peek with a trial code.

              K

              Comment


                #8
                I just wanted to mention that the current BSC 1.2 specification is about to undergo a revision to v1.3 (in case anyone is coding to v1.2).

                HomeSeer has been the first major application that we have xAP enabled without requiring any specific code changes and BSC has proven itself as ideal for the job. Indeed the majority of my own house automation is now managed via xAP and BSC including all the Clipsal C-Bus lighting system .
                From what we have now learned we are looking to change/enhance BSC slightly to better support interaction with the HomeSeer state model and to change the block message format very slightly to aid parsing. The new spec should be released within a couple of weeks and I will post details here.

                Kevin

                Comment


                  #9
                  The new xAP BSC v13 specification (attached) has now been released and a new plugin for HomeSeer is about to appear here 'any day now' that fully supports BSC13 . Several other applications have been updated too including my C-Bus to xAP gateway, the X10 xFX connector and xAP Desktop. More are imminent.

                  In addition I have some xAP Desktop Widgets that I will release when the HS plugin is posted to provide lamp faders that work in realtime and float over the Windows Desktop. These can control any ON/OFF or LEVEL based HS device via xAP so for example will work with existing X10 lighting via HS.

                  Please note that BSCv13 is a far more capable spec than v12 and integrates far better with HomeSeers' state model. As such BSCv12 will be deprecated. Please only develop to v13 if you implement BSC. The xAP spec remains stable and unchanged at V12 as BSC is layered as a schema/ policy layer on top of xAP.

                  K

                  Comment


                    #10
                    Please note the BSC v1.3 spec is now available from
                    http://wiki.xapautomation.org/tiki-i...0and%20Control
                    Kevin

                    Comment


                      #11
                      The ownership of names used in BSC messages is something I've been going back and forth on and a lot of code written for both ways of thinking. I tend to view the Homeseer device location and name to be the friendly identification of a device. The HS console is where this information is entered and viewed.

                      In a BSC message as well as in the general xap case the Source/Subaddress often carries the location and name information of the device. This typically means that this is entered at the sending xap node through a gui or text file edit. Homeseer can capture this identification, but it is a one-way street and the ability to change it at the HS console is not readily supported by the schemas.

                      For my local and web-based sensors I have a connector application that manages the relationships and provides the mechanism by which 16 character sensor ID is correlated to Homeseer's name and location. It is the way a sensor's calibration is specified and the configuration in which the hardware part is operating (e.g. as a rain counter or a wind counter).

                      In Edward's X10 connector that supports both xap-x10 and BSC there is intentionally no relationship between the physical device addresss (e.g. D5) and the xap Source/Subaddress namnig of this device. This means that the physical address is unknown to the system and the only mechanism to discover it is with visual inspection of the hardware or offline viewing of some configuration files maintained in an unspecified format by the connector.

                      This boils down to opinions on two related items. One has to do with the use of xap Source/Subaddress to identify how something is used vs. its physical characteristics (Bedroom.Lamp vs D5) and then how to manage the physical to logical relationships. The second is the user interface for management of of Homeseer device properties and xap addresses.

                      Comment


                        #12
                        Originally posted by Michael McSharry
                        Homeseer can capture this identification, but it is a one-way street and the ability to change it at the HS console is not readily supported by the schemas.
                        This will be addressed when the xAP configuration schema/policy is released, then you will be able to set it bi-directionally.


                        Originally posted by Michael McSharry

                        In Edward's X10 connector that supports both xap-x10 and BSC there is intentionally no relationship between the physical device addresss (e.g. D5) and the xap Source/Subaddress namnig of this device. This means that the physical address is unknown to the system and the only mechanism to discover it is with visual inspection of the hardware or offline viewing of some configuration files maintained in an unspecified format by the connector.
                        It is totally at the discretion of the user how you name the devices . If you wish to call your devices D5 D6 etc then you can, even within BSC. Also if you wish to control via X10 address then you can use the X10 schema rather than the BSC one, indeed you could use the dual schema to intelligently (programatically) associate the mapping of Kitchen > D5 should you wish.

                        It could also be considered to add another parameter into the BSC blocks that included the X10 address but I believe that damages the purity of BSC. Having to control devices by address is very 'legacy' for example you would never dream of controlling an Ethernet device by Mac address, the ability to use friendly names is undoubtedly the correct route. Should you wish to use X10 addresses then the X10 schema is the one to use ( or name your BSC devices as D5 D6 etc )
                        Kevin

                        Comment


                          #13
                          Guys, I know this thread is quite old now, but has anyone been able to reach Kevin (CouchPotatoe)? I'm desperately trying to link HS to my Clipsal C-Bus system and xAP seems like the only way to do it right now.
                          Author of Highpeak Plugins | SMS-Gateway Plugin | Blue Iris Plugin | Paradox (Beta) Plugin | Modbus Plugin | Yamaha Plugin

                          Comment


                            #14
                            I'm here and have been watching these threads, I'm always available either by PM on this board or
                            hsxap (at) <at>ukusa<dot> (dot) co<dot> (dot) uk
                            Sorry if you've been having difficulty - give me a shout - I do have a hardware board available that converts C-Bus to xAP and using the xAP plugin you get realtime status and control of your C-Bus setup in HomeSeer.

                            Kevin</dot></dot></at>

                            Comment


                              #15
                              Hey Gavin (BeeryGaz) - your emails are bouncing and I wanted to get in touch with you - please could you PM or email me... I have a C-Bus xAP board for you to use C-Bus in HomeSeer should you want.... Kevin
                              Last edited by CouchPotatoe; May 2, 2007, 05:09 AM.

                              Comment

                              Working...
                              X