Announcement

Collapse

Contacting HomeSeer This Week

HomeSeer is open and operational this week. All orders are being processed and shipped as usual. However, some staff are working from home. If you need to contact HomeSeer for support or customer service, please use our Email or Chat options. https://homeseer.com/contact-us/
See more
See less

xAP Desktop

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • xAP Desktop

    xAP Desktop is a very versatile component that uses xAP schema to display information being passed around the Home Automation network. With the xAP Plugin, xAP conduit in xAP speak, the xAP Desktop is available to Homeseer users.

    Briefy the Desktop is a series of up to 20 displays. each of which have graphical, text and variable components which allow the reception and display of xAP data and also the control of xAP devices from any source

    Since the original description that James (MI4 on this board) posted here

    http://www.xapautomation.org/modules...article&sid=22

    there has been continuous improvement and development including the addition of VBscript capability.

    In addition the number of displays has increased so that there are now (almost) off the shelf displays (some configuration may be required for your environment) for

    Caller ID
    Webcam Displays, single and multiple
    LCD Simulators
    Customer Pole simulation
    Examples using the BSC schema to contol homeseer devices
    TV program guide
    Weather Display
    News Display
    Email displays
    SliMP3 interfaces
    and a number of other coming along

    Kevin
    Last edited by turner228; December 22nd, 2004, 06:00 PM.

  • #2
    Display Schema Homeseer Test Script

    This is a test script for running within Homeseer which generates xAP messages using the Display Schema

    http://www.mi4.biz/modules.php?name=...showpage&pid=9

    The displays I was testing were the simulations of Green, Blue and Orange LCD 4 x 20 screens which I created for xAP Desktop

    To use this script you need the xAP plugin for Homeseer.
    And of course you will need xAP Desktop installed on a PC with one of these displayed loaded

    Kevin
    Attached Files
    Last edited by turner228; December 21st, 2004, 05:54 PM.

    Comment


    • #3
      Here's a picture of the displays "floating" over the xAP Viewer application
      There is also a simulation of a customer pole display (2 x 20)

      Kevin
      Attached Files

      Comment


      • #4
        Caller ID Desktop Display

        This is my version of the Caller ID display which comes with xAP Desktop and the subroutine from the Caller ID script I use in homeseer which creates and sends the CID.incoming message to it.

        There is also a picture so you can see what it looks like

        Kevin
        Attached Files
        Last edited by turner228; December 22nd, 2004, 04:30 AM.

        Comment


        • #5
          I had success with the LCD display and partial success with CID. Thank you for your info on these.

          I tried a few CID combinations, but never able to get anything on the CID other than the number itself. Never a name and never a time. I don't know why I did not see the CID the first time I tried it since my test message was no different than my real CID messages.

          In your CID implementations how is the lookup and reformatting of the name occur? Is there a xap database query done? Is is all done by the xap app that recognizes the CID signal? Is there any integration with Outlook, hsPhone or any other normal sources of phonebook information?

          Does a mechanism exists to restore a widget onto the desktop after it fades away in 30 or so seconds?

          In the UltraMessage control for the popups it provides depth to messages received and a mechanism to scroll through the messages. Much like what is provided with a typcial CID console or answering machine. Do provisions exist in the desktop for such a capability?

          Comment


          • #6
            Michael
            (Reponses in order of your questions/comments)

            Glad the LCD widget works. The limitation currently is that if you have more than one display schema display then thet all get the same message as
            they do not fully support targeting. I have discussed this with James (Mi4 on this board) who is the author of desktop and its on the list

            Your CID experience sounds familiar. Did you see how I formatted the messge in my subroutine? and the corresponding decode in settings.txt in the display?
            If you could post the xAP message from xAP viewer we could probably work it out.

            The Caller ID implemetation I use is a Homeseer script. It does a simple lookup from a flat file (CSV), basically number,name. Its sole interface to the xAP world is the creation and transmission of the message as shown in the subroutine I posted earlier. I don't use HSphone, outlook or any other data source

            The fade of the display is configured in the settings file I think. This is the only display I use that does this, all the others stay up until I hide them. I will have a look when I get home from work

            The CID display only shows the current call. Since is only there for a short time the date/time is not relevant information. I don't think the schema currenty supports a query function that would allow the sort of display you describe. I can think of no reason why this could not be incorporated though. (Changes to the schema need to be proposed to the group and "ratified". This is not a formal process but one which is required to prevent potential incompatibilities and problems)

            Thinking on my feet a bit, A Desktop Display could be created or the existing one modified to incorporate this sort of information (ie the history). The Desktop displays support scripting and have a startup event which can call a script which could generate a "CID.query" message. This would have to be handled by a xAP application which had access to the data and which would then send the data back and the data could then be made available on the display. The xAP application would have to be unique to the data source, so yours would be different to mine. Something like that anyway. So it does not exist currently, but it would probably be possible to build it

            Kevin

            Comment


            • #7
              All of the things that xAP Desktop looks for in messages (the triggers) are setup within the settings.txt file within the appropriate DisplayXX folder of xAP Desktop. Some substitutions can occur based on variable values that are created when you first install the desktop widget. These are stored in the answers.ini file. A substitued value will have %% at the beginning and end of the varaible name in settings.txt

              So if in answers.ini you had

              mySource=acme.device.machine

              then whenever in settings.txt you had %%mySource%% the value will be substitued with acme.device.machine. This is the way that widgets can be distributed that work on different peoples setups without editing teh script.

              If something isn't displaying in xAP Desktop then perusing the settings.txt file for that particular 'widget' will show you what it is looking for and presumably not seeing. The widgets are in no way hard coded with xAP Desktop, every aspect of the widget including the triggers, parameter keys, images, fonts, colours, fades etc are all changeable in the appropriate settings .txt file.

              If anyone has a problem they can't resolve please post as attachments a copy of settings.txt, answers.ini and a sample xAP message they feel should work and we'll try and see why it isnt working.

              Kevin

              Comment


              • #8
                Originally posted by Michael McSharry

                In your CID implementations how is the lookup and reformatting of the name occur? Is there a xap database query done? Is is all done by the xap app that recognizes the CID signal? Is there any integration with Outlook, hsPhone or any other normal sources of phonebook information?
                Good questions...

                I have a (half finished/works for me) xAP DB lookup that sees the CID and looks it up in three places, a local database, Outlook and a standard 'STD' area codes database - should there be no records then at least you know the local area the call came from (UK only). It also logs call history for all calls within a notes field in Outlook maintained by contact . It does 'on the fly' lookups for outgoing calls per digit dialled so you see the area and then the person match which is cute. However I never released it as the current Outlook versions pop up a modal dialog / warning when you access the inbuilt directories (this is a new inbuilt virus protection precaution and I couldn't quickly see how to bypass it ). The app was also likely to be support intensive as it requires Access DB setup. I may resurrect this if there is interest (?) and I can see how to get around or allow 'authorisation' of my app to access Outlook. Other Kevins' route via HomeSeer may appeal to more people on this forum though.
                The xAPTel CID telephone application segments all the messages in a way that allows a xAPDatabase application to just interleave the CID info with the database lookup. A display application also shows this CID/Name on my TV via Tivo and on my music players (SliMP3's). Could announce via TTS too I guess.

                Originally posted by Michael McSharry
                Does a mechanism exists to restore a widget onto the desktop after it fades away in 30 or so seconds?
                Lots of approaches I guess - you could not fade to total transparency and then action a click to restore opacity. Or you could change the size to a 'miminised' version and then click to restore. You could even have another 'dock' type widget that restored/hid other widgets - as you can change position and opacity of any widget via xAP. If it is only one widget you need then clicking on the xAPDesktop tray icon hides/shows all items. I think keyboard function key support is on the 'future ideas' too for xAP Desktop.

                Originally posted by Michael McSharry
                In the UltraMessage control for the popups it provides depth to messages received and a mechanism to scroll through the messages. Much like what is provided with a typcial CID console or answering machine. Do provisions exist in the desktop for such a capability
                Point me to more info on UltraMessage if you would Michael....

                Within xAP Desktop there is no inbuilt support for reviewing history of displayed messages. However (as other Kevin says) you could write something with VBscript in xAP Desktop or HomeSeer that provided a logging of these messages and viewing history eg a list of missed calls. This could be accesible say from a button on a xAPDesktop CID display. Almost everything in xAP Desktop is customisable including every graphic and all actions via VB script. Stepping back through OSD message could work exactly the same.

                It would perhaps be more approriate to use an application like xAP DBLogger ( a xAP message logger) and be able to repeat or step through a history of certain classes of messages eg OSD or CID - this would be a neater approach and more inkeeping with the distributed nature of xAP.

                The Slim devices (SliMP3/Squeezebox) xAP OSD actually includes proper time queuing of OSD messages, over mutiple players such that they display for correct durations even if interrupted by higher priority messages. Hence you can have weather info and new feeds showing cyclicly that are replaced by a higher prority message - say an alarm function or incoming email and then revert back to cycling.

                Kevin

                Comment


                • #9
                  I would not expect the CID schema to need a query, but a display application (e.g. desktop) could do integrated widgets that accept a message component and then do a lookup via some mechanism to synthesize other information. CID lookup to get name for CID.Incomming; UID lookup to get display name, stock symbol to get current info, etc.

                  In your case, as well as in my implementations, The application that is sending the CID.Incomming augments telco data with name-related info. In my case it is the hsPhone address book and a flat friends.txt file. In all cases the mechanism by which the name component is generated is invisible to the network.

                  I'm experimenting with architectural approaches. My initial thinking was to rely upon the receiving end to receive everything it needs from various xap sources and integrate the information at its processing stage into an endpoint use or value-added xap message.

                  Now I'm lookiing at making the sending nodes a little smarter. The CID is one example of this where the sending node did the name lookup before sending. The same thing happened when BSC 1.3 was introduced as it added the Display key. I think this is moving away from the purity of the system, but may be more practical. Now my xapmcs1Wire includes the optional DisplayText key, but it assumes that the desired display formatting is HTML for viewing on a web browser. If any other BSC-compliant display-oriented application receives the message then the displayed result will likeky not be as desired. In the extreme there will be many BSC applications formatting their output to a specific target and the ubiquity of BSC will be lost.

                  Comment


                  • #10
                    Michael

                    In the case of the basic CLID display, all the information necessary for that display is provided in the cid.incoming message.

                    My background thinking was:-
                    In the case of the historical cid data display within desktop we were discussing, we need data which is not there, although I guess it could be collected while that system was running desktop. However multiple systems could be running the CID History display on Desktop and started at different time so the displays could be inconsistent. What I mean is that the Desktop and its displays are not a permanent, always on, component of the HA network and so data of this sort has to retrieved from somewhere.

                    This is similar to the Display Thermo/Controller where it is using BSC to control, in my case, homeseer devices. The first thing it does is find out the current state by sending a BSC query.

                    Kevin

                    Comment


                    • #11
                      I have looked at my version of the CID display and worked out the changes using the displaydesigner program so that the display does not fade away at all
                      Compare this with what you already have in the settings file

                      xAPVar=number,>,cid.incoming,cid.incoming,phone,200,-1,none,,,
                      xAPVar=name,>,cid.incoming,cid.incoming,name,255,-1,none,,,

                      I have also modified the display so that it now uses the telephone as a close button.

                      Note that this display does not use answers.ini, or rather it is there but empty

                      See if this version does what you need. There are enhancements to desktop coming along which allow you to recall displays. My initial solution was a pop up menu display.

                      Kevin
                      Attached Files
                      Last edited by turner228; December 22nd, 2004, 03:01 PM.

                      Comment


                      • #12
                        Even I get confused with all these Kevins

                        Kevin

                        Comment


                        • #13
                          Originally posted by Michael McSharry
                          I would not expect the CID schema to need a query, but a display application (e.g. desktop) could do integrated widgets that accept a message component and then do a lookup via some mechanism to synthesize other information.
                          xAP Desktop as you say just provides the framework to display information, it can be dumb, pretty, clever etc just how it is used is up to the implementation. It has a very powerful script language behind it to make widgets as interactive as you want. I don't feel it should have too many inbuilt 'smarts' though. Better to have it just very capable through scripting. If the capabilities do fall short then the next step up would be a complete integrated xAP script engine/controller... In this forum (the xAP plugin) we are calling upon HomeSeer for that role

                          Originally posted by Michael McSharry
                          In your case, as well as in my implementations, The application that is sending the CID.Incomming augments telco data with name-related info.
                          My CID application is xAPTel - it just sends CID info, no names. I have another decoupled application that watches for these xAP messages and assists where it can with adding name information from a DB lookup, and yet a third application pulls this information together to display it on the SliMP3's. xAP Desktop also acts as a collector of data from the various messages to collate them into one Desktop display window.

                          Originally posted by Michael McSharry
                          I'm experimenting with architectural approaches. My initial thinking was to rely upon the receiving end to receive everything it needs from various xap sources and integrate the information at its processing stage into an endpoint use or value-added xap message.

                          Now I'm lookiing at making the sending nodes a little smarter. The CID is one example of this where the sending node did the name lookup before sending.
                          Your initial approach is how I've done this, having more complex origination of data I reasoned would tend to slow things a little, be a little more specialised and also create dependencies, where one application is reliant on another service being present to originate its complete data. The uncoupled way means if my database goes down or is not running then all that happens is a line disappears from the Desktop display (the callers name). Actually my first approach was one big application and I broke it into 4 mini applications linked by xAP in a non interlocked way. I even re-assembled it back into one application again where the various components communicated via xAP (threads if you like) so that users would only need to run one application which was easier on installation. One of the nice things about xAP is everyone can choose their own approach, interested to see where you get to on this.

                          Originally posted by Michael McSharry

                          The same thing happened when BSC 1.3 was introduced as it added the Display key. I think this is moving away from the purity of the system, but may be more practical. Now my xapmcs1Wire includes the optional DisplayText key, but it assumes that the desired display formatting is HTML for viewing on a web browser. If any other BSC-compliant display-oriented application receives the message then the displayed result will likeky not be as desired. In the extreme there will be many BSC applications formatting their output to a specific target and the ubiquity of BSC will be lost.
                          The original proposal for DisplayText (which can be included in any message btw) was that it should be plain human readable text. However we did also consider HTML , mainly as it was used in HomeSeer - as you say the pure approach is that DisplayText should mean something (or be displayable) to everything but I think html is sufficiently established ;- and therefore the upshot was that we allow it within the spec in DisplayText, so I think this is good and allows rich display data. Whether we set up a series of formal <tags> to identify data for different formats is another whole area but in the end quite how anyone implements and uses xAP is their own choice and only by people pushing the boundaries does it expand and mature. Displaying text in any formatted form is a minefield due to the differing display devices, #chars/lines so a ceryain amount of user matching is unavoidable.
                          So these ideas are all great The xAP keys are well defined only for the purpose of maintaining consistent interoperability across implications - people can of course use their own keys for their own data in whatever ways they want. (for example a htmldisplaytext parameter could be used in addition to displaytext).

                          Kevin

                          Kevin

                          Comment


                          • #14
                            Originally posted by turner228
                            Even I get confused with all these Kevins

                            Kevin
                            I've sent you a deedpole name change form offlist ;-)

                            Kevin

                            Comment


                            • #15
                              Michael

                              Could it be that your problem with the CID desktop display is simply one of spelling?

                              I notice that you seem to spell incoming with 2 'm's a lot

                              Kevin

                              Comment

                              Working...
                              X