Announcement

Collapse
No announcement yet.

xap for beginners

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

    xap for beginners

    I am hearing more and more about xap. Did a bunch of reading on the net and have a very basic concept ot what it is.

    Can anyone give me a laymans explanation and what I might use it for.

    TIA

    #2
    Hi JOM

    (My) Simple explanation:

    xAP is the glue which enables ** distributed ** home automation

    My definition of home automation is wide and does not just include control, but also a wide range of other information

    So you can have a network with devices and software from different suppliers and sources carrying out home automation tasks

    Homeseer is just one of those sources.
    With the xAP plugin all homeseer devices can have their status queried and broadcast over xAP and can have there state changed via xAP

    Other xAP devices elsewhere on the network can have their state reflected in Homeseer or can be changed from Homeseer

    Clearly Homeseer is a highly capable home automation environment and coming from the point of view of a Homeseer user xAP will enable more devices to be used. A non Homeseer user might have a slightly different view

    What to use it for, (I am at the early stages)
    I can have Caller ID on my Desktops (transmitted by Homeseer)
    I get weather and TV schedules on my desktop
    I can view my webcams on my Desktop
    I can turn off the screens of my touchscreens
    I monitor the status of my network
    I can control some Homeseer devices from my desktop

    I have a working prototype of the equivilant of the parallel port plugin ( so this means I can use the parallel ports on another machine on the network for inputs and outputs)
    I plan on doing the equivilant for the Game port and also for my serial VFD customer pole displays

    Everyone has there own interest(s) and uses it at their own level

    Hope this helps

    Kevin

    Comment


      #3
      HS has migrated away from the Windows GUI and toward the HTML/Browser one. They did this because the HTML/Browser is an adopted standard that is widely supported. It allows a terminaal or computer running Unix, QNX, Mac, or any other OS to act as the user interface to HS. It allows HS to be "embedded" without a concern about the user interface of the hosting computer.

      HS provides an SDK so anyone who wants to write Window's based applications, preferably in VB, can integrate their special hardware with HS. If you are a Unix-Java guy or gal then it becomes hard to customize around HS. It would be the same situation with the user GUI if HS did not provide an HTML/browser interface, but only a Window's one.

      What XAP/XPL provides is an interfacing mechanism that is not oriented toward the human GUI interface, but toward the machine to machine interface. It lends itself to application on very small processors, but can easily be applied to standard desktop computers. It does not dictate a physical layer, but today's technology tends to make ethernet/IP-based instances the most common.

      In my case my applications have become smaller and single-purposed. Other applications, including HS, integrate the xap communications. For example, my mcsTemperature plugin is now a set of xap applications. One collects data from DS9097's, one from the Temp05, one stores data into a database, one provides weather from AWS sites, one from WeatherXML site, one from MSNBC site, another does the charting and other user-interface related functions. If I restart HS for any reason I will still continue to collect sensor and weather data becasue these are indepenent of HS and use XAP as the mechanism by which HS can be connected when HS is running.

      My X10 interface and my IR interface are distributed. I use both the ocelot and cm11a at the same time as my HS X10 interface. Both are implemented as xap applications rather than as HS plugins. With the xap architecture I'm not restricted to a single X10 interface, nor am I limited by physical location of where the software runs. When "spurious" X10 signals appear in the HS log I know if the signal is from a CM11A, W800, ocelot, CM19A or any other source that provides the X10 interface into HS. When all bundled in the same package as HS Plugins then knowledge of the source is not available and problem resolutionn is more difficult.

      HS and XAP/XPL can play in the same sandbox . It up to the user/developer to decide if they want to write an HS Plugin per the HS SDK or write an XAP application. In one case it is a Memory-to-Memory interface and in the other it is a communications protocol interface. There are several HS plugins and there are several XAP/XPL applications. There is some overlap in functionality and there are unique capabilities provided with each.

      I started as HS-centric and added some XAP functionality to enhance the capability of HS. Now I am more XAP-centric with many applications runnings and HS primariliy as my GUI for devices and events. I still have some plugins running in HS, but most are now applications that use XAP to interact with HS.

      Comment


        #4
        To clarify

        Michael has mentioned both xAP and xPL in his post above

        These both have broadly the same aims, but are different.
        I have not deciphered the philosophical difference myself yet. but definitely a different implementation.

        Some brave souls have implemented both using some sort of bridge, but I have not yet bitten the bullet. Device support is different but overlapping, the xPL support of the Hauppage MVP may yet tempt me to have a look, but there are still many good things to do in xAP

        The Homeseer plugin supports xAP directly, but I am not aware of any direct support for xPL being available yet

        Kevin

        Comment


          #5
          XAP and XPL started as the same and forked. By chance I took the XAP path. It does appear that while there may be more older XAP applications, there appears to be more and richer XPL ones coming online.

          I'm by no means an expert, but XPL appears to be a lighter weight protocol with some capabilities designed into the protocol. It is more more solution-oriented to a specific environment while XAP is more general. In particular, xpl has a built-in mechanism to handle configuration setup while in xap's case this is an application layer for which no policies or guidance exists. I proposed an approach about 6 months ago and had no comments so I just proceeded with it. XAP supports multiple message groups within the same packet while xpl application need only deal with a single one. As an analogy, with HTML forms there is a single QueryString just as there is a single set of key/value pairs per message in XPL In XAP there can be multiple groups of key/value pairs and that would be like having to specify the name of the form in an HTML QueryString to distinguish data delivered from one form vs. another on the same HTML page.

          I also have not tried to bridge the two, but since they are so similiar it should not be too difficult of a task.

          The general concept of both protocols is that there is a schema that defines the language that a certain class of device will support. This is like XML and its namespaces.

          Within the schema there is typically a way to request the current state, provide the current state, and to trigger an event when the state changes. "State" is a generic term that fits with the schema. An X10-type schema with have ON, OFF, DIM, etc. A CID Schema will have the Name/Number etc. An Audio schema will have volume, output device, etc.

          I've got about 10 or 15 XAP applications running and the computer that hosts most of them runs at a pretty steady utilization of under 5% with short peaks of 25% and occasional 75% on the more intense web pages. If I add streaming video then steady state goes up by another 25%. VR/TTS is handled on a second computer that is my primary desktop and I really do not notice any peaks associated with it.

          What I no longer get is the burst of activity pegging HS at 100% for several seconds, but rather a flatter utilization pattern. I suspect the overall cpu utilization is higher, but more evenly distributed. When HS 2.0 arrives it may also flatten the utilization. Just need to wait and see.

          There is no perceivable difference in response times from motion detected to action taken. This is true independent of which computer the sensor is connected. If I run a MR26A and W800 on two different computers then sometimes the MR26A is first to announce and sometimes the W800 is first.

          Comment


            #6
            Here is a great introduction: http://patrick.lidstone.net/ha/xAP/Introduction
            The "official" website is www.xapautomation.org

            Comment


              #7
              Originally posted by Michael McSharry
              My X10 interface and my IR interface are distributed. I use both the ocelot and cm11a at the same time as my HS X10 interface. Both are implemented as xap applications rather than as HS plugins. With the xap architecture I'm not restricted to a single X10 interface, nor am I limited by physical location of where the software runs.
              Michael -
              Can you elaborate a little bit more on how you distributed your X10 and IR interfaces using xAP? Are you using the xAP X10 Connector from www.xapframework.net or did you develop you own? How about the W800, or the Ocelot?

              You also mentioned that "VR/TTS is handled on a second computer that is my primary desktop", are you using xAP Speech for that?

              I guess that you are using the xAP HomeSeer plugin to handle the communication back and forth with HS?

              I have got as far as using xAP Weather, but I would really like to undestand how you are achieving your home automation distributed architecture.
              Thanks in advance for your help.

              Comment


                #8
                The basic concept was published at the following link. Things have changed when going from the design into the implementation as more was learned as to what works and what is awkward, but the basic approach is still the same.

                http://board.homeseer.com/showthread...ed+environment

                I use Stuart's Message Viewer from xapFramework.net, but otherwise the applications are those that I developed. My mcsXap plugin is the Homeseer interface into the xap world. I was using this before James make his available on the HS board. These have some overlap, but also some difference in objectives. My main objective is to make the internals of Homeseer available on the xap network while Jame's objetive is closer to integrating xap devices and events into Homeseer.

                In a Homeseer configuration the X10 and IR interfaces are selected to be mcsXap. In the mcsXap setup there are two fields to describe how the X10 or IR interface should operate. In one case it will pass the X10 requests from Homeseer onto another Homeseer Plugin. It also contains an entry for the XAP target address field. This can be wildcarded or a specific target identified. Both of these can be active at the same time or either one individually. Any X10 request from HS will now go onto the network as an xap-x10.request message. The plugin recognizes xap-x10.event messages and provides the callback to HS for reception. The same approach applies for IR with an IR xap schema rather than an x10 schema.

                I put the HomeseerOverThere (as described in above reference document) wrapper around the ADIOcelot plugin and it then becomes an xap application. In my case it runs on the same PC as Homeseer and it acts upon the xap messages just as if it was acting directly with Homeseer. I originally had my ADIOcelot plugin as the passthrough. I later made ADIOcelot an xap node and removed it as a plugin passthrough.

                On my developmnet desktop computer I have a CM11A xap application. It sees the xap x10 messages at the same time as the ADIOcelot sees them. What this does is doubles the traffic on the powerline. Generally this is not event noticed since the CM11A is faster than the ocelot and when the Ocelot is sending the CM11A is already done. In my case I also found that two interfaces were needed to get the coverage desired. Without it there would be some areas of the house that would be x10-dead.

                I did use Edward's CM11A/CM12U connector originally and help him work out some problems since my environment was more taxing than his. He helped me understand the raw protocol and from that I wrote my xapmcsCM11A application. One of my objectives of a distributed environment is to be able to support redundancy of functionality to improve overall system availability. To accomplish this I defined a policy-layer schema to allow redundant nodes to know who was doing what. Since this "roles" schema was never generally adopted I need to write the xap applications that I want to participate in the management of redundancy. The CM11A is one such application.

                James' xapSpeech seems to handle only TTS so I ventured off and did xapmcsVoice that does VR as well. When it is setup to use the Homseer VR grammar file then the recognized speech generates the same Homeseer VR events via the xap.Voice schema that is recognized by mcsXap plugin. What I did not do with xapmcsVoice was support dynamic changes to the grammar file that is supported by Homeseer scripting. I put one instance on my wife's laptop so I'm able to send send little love messages at the appropriate time.

                I've provided some of these applications to those that have a particular need such as remote VR/TTS, but have not generally made them available because I want the freedom to make changes without concerns worring about how the change will affect others.

                One of the thing that I found a little awkward was that Homeseer ignores commands and events associated with plugins that are not installed. When I migrate a plugin that has devices or events associated with it to an xap application then I also need to run a utility to change the interface property of the removed plugin's items to be the mcsXap interface. It really is supported via mcsXap from Homeseer's perspective, but it would of been nice not to have to take that step. Another awkward item for which I have not done any automation in mcsXap is the coordination of new plugin housecodes. I now need to manually assign the new house code, but this can be made transparent without manual intervention. The last awkward item is when multiple new devices are added to Homeseer. It does not happen very often since new toys are rationed. When it does happen then it takes Homeseer seconds per device to do all of its bookkeeping.
                Attached Files

                Comment


                  #9
                  Link out of order

                  The link http://patrick.lidstone.net/ha/xAP/Introduction does not function anymory. Still, I am very interested in this story. Is this story copied somewhere? Anyone an idea why this link does not work?

                  Regards,

                  Richard

                  Comment


                    #10
                    Patricks site can best be described as up and down a lot

                    Try http://www.xapautomation.org/

                    and
                    http://www.mi4.biz/

                    Kevin

                    Comment


                      #11
                      Originally posted by JustOneMore
                      I am hearing more and more about xap. Did a bunch of reading on the net and have a very basic concept ot what it is.

                      Can anyone give me a laymans explanation and what I might use it for.

                      TIA
                      Also a while back there was this description of the methodology behind xAP so people can understand a little better how it operates and why its so promising...

                      http://board.homeseer.com/showthread.php?t=89501

                      K

                      Comment


                        #12
                        Media + smarthome solution for XPL users

                        Pluto is a new, open source smart home solution that seamlessly integrates: 1) media with a server for music, movies and tv shows, plus a PVR and DVD Player, 2) a home automation system with touch-screen tablet and Bluetooth mobile phone controllers, 3) a phone system with video conferencing, 4) a security system that feeds you live video on your mobile phone when there are interruptions, and lets you speak to visitors through your stereos, and 5) a home PC solution. Check it out at www.plutohome.com.

                        We also posted a page at www.plutohome.com/dce.phpwww.plutohome.com/support

                        Comment

                        Working...
                        X