Announcement

Collapse
No announcement yet.

mcsXap Plugin Discussion

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

  • Michael McSharry
    replied
    xAP transmits on port 3639. Only one application on Windows and Linux computers can bind to a specfic port at any given time. The xAP Hub is reserved the right to listen on this port. It will then forward all the xAP messages to all other xAP applications on the same computer.

    There are cases where a single xAP application is dedicated to a computer. In that case there is no need for an xAP hub and that single xAP application can bind to port 3639. This will rarely ever be the case for a Windows computer, but small Linux computers may exhibit this single-application paradymn.

    The xAP Message Viewer is a utility and has been designed for maximum flexibilty. If it starts and sees there is no xAP hub on the computer then it will serve that role and forward xAP messages to all other xAP applications on that same computer.

    mcsXapHub was developed with VB6 and has flexibilty to route both xAP and xPL traffic. I developed a .NET version so it could be run on a Linux platform. It was a more basic implementation that does not support xPL. In my own Windows environment I continue to use the original VB6 one on PRO100 and new .NET one on Shuttle. In the Shuttle case it is run as a service.

    When an xAP application starts on a computer and appears to be deaf, it had been in the past that some other xAP application started before it and started listening on port 3639. That means nobody else can listen. It also did not complete its responsibilty and perform the hub function to share the xAP messages with others. This is less common now that most xAP applications no longer attempt to bind to port 3639.

    The xAP hub knows how to route messages to xAP applications on the same computer by listening to the heartbeat. Until a heartbeat is produced by the application the xAP hub will not know it is there. Each application has a different heartbeat rate, but typically between 1 and 10 minutes. Waiting for the 10 minutes rather than restarting computers will be a less painful approach to getting desired functionality. If issues arrise, then use of the xAP Message Viewer on the computer where issues appear to exist will help isolate the cause.

    Leave a comment:


  • Wadenut
    replied
    1.2.02 is on his site now. Doesn't look like it's starting up on the HT. Doesn't matter. My devices are populated and that's really all I need for now to work with HST.

    Leave a comment:


  • Pete
    replied
    I still run the old xapmcshub V 1.2.1 on one box and V 1.2.2 on another. Its here:

    http://forums.homeseer.com/showthread.php?t=109125

    Think I tried the dot net versions and had some issues with them.

    Still waiting on the updated Cumulus with the updated xap weather.report info found here:

    http://www.xapautomation.org/index.p...Weather_Schema

    and here:

    http://www.automatedhome.co.uk/vbull...change-request

    It took more than a few months or so to come up with a new consensus for an updated schema as the old weather.report schema was outdated (I tried not to get involved in this but ended up getting a bit involved).
    Attached Files
    Last edited by Pete; August 2, 2012, 12:38 PM.

    Leave a comment:


  • Wadenut
    replied
    I wasn't aware of xapmcshub. Must hunt it down. I'd certainly like to use it.

    Leave a comment:


  • Steve Q
    replied
    I also had mcsxaphub running on all the computers.

    Steve Q

    Leave a comment:


  • Pete
    replied
    I have always run the original mcsXAP hub on the two HS boxes that I am using.

    I do and don't run xap hubs on other wintel machines running xap applications though and I don't notice a difference. I don't have hubs running on the Linux machines running xap though.

    I have never run the xfx-express hub.

    Leave a comment:


  • Wadenut
    replied
    I hadn't thought of the viewer. It indicated the HT was indeed receiving data, and at that point I noticed the HS devices beginning to populate... but only while the viewer was running.
    I've installed the xfx-express hub on the HT and now seem to be OK. I was under the impression that all mcsxap applications could act as a xap hub. Evidently this doesn't include the HS plugin.
    So now, it's off to the extensive task of getting my pad screens up to date. But that's another thread and another even bigger PITA (usually, I get kissed first ).

    Leave a comment:


  • Steve Q
    replied
    Originally posted by Wadenut View Post
    I'm certain there's a simple answer to this. Probably the biggest problem I have is not having a good grasp on xap in the first place.
    I've bitten the bullet and started upgrading my HSTouch to the latest version. To do this, I wanted to leave my existing plugin/screens etc. intact until I'm certain I'm ready to migrate back to my Homeseer machine. The two versions of HST seem to be of course, incompatible.
    I've installed the xap plugin on a separate Hometroller and want to start with my existing weather and other device data from the Homeseer machine.
    The problem I'm encountering as I see it, is receiving the 1Wire data from Homeseer into the Hometroller. Nothing seems to be showing up. Clear as mud so far?
    xap plugin version on both machines is 3.0.0.5. What can I do, without disrupting the working setup on the HS machine, to ensure I'm broadcasting the data over the network so it can be received by the xapmcs plugin in the Hometroller?
    I setup xap on my netbook. I got everything working but it took a lot of effort. If I remember correctly, I had to restart all my network computers multiple times before they were all receiving all the xap messages. I also had to mess with the firewall/antivirus software.

    Steve Q

    Leave a comment:


  • Pete
    replied
    Try using the generic xap viewer on a different computer. Wierd but my wireless laptop sees less than the office desktop.

    I have more issues with the HS xAP generated messages than the separate autonomous programs running on HS that are xAP. I do though have XAP running on multiple servers (Wintel and Linux). DB xap stuff on Linux / Wintel these days and playing with FlashxAP on two Jogglers (very fast response times to xap messaging - I am very impressed).

    You would have to redo your xap configurations but you could run the separate mcsXAP applications (what ever they may be) on another computer and use virtual serial connections which work for me. (it would be a disruption of what you have running- easy though to reconfigure).

    Does that make sense?

    Leave a comment:


  • Wadenut
    replied
    Anyone?

    I'm certain there's a simple answer to this. Probably the biggest problem I have is not having a good grasp on xap in the first place.
    I've bitten the bullet and started upgrading my HSTouch to the latest version. To do this, I wanted to leave my existing plugin/screens etc. intact until I'm certain I'm ready to migrate back to my Homeseer machine. The two versions of HST seem to be of course, incompatible.
    I've installed the xap plugin on a separate Hometroller and want to start with my existing weather and other device data from the Homeseer machine.
    The problem I'm encountering as I see it, is receiving the 1Wire data from Homeseer into the Hometroller. Nothing seems to be showing up. Clear as mud so far?
    xap plugin version on both machines is 3.0.0.5. What can I do, without disrupting the working setup on the HS machine, to ensure I'm broadcasting the data over the network so it can be received by the xapmcs plugin in the Hometroller?

    Leave a comment:


  • Pete
    replied
    Will try that as this morning I had to restart the interface.

    08:17:21 | Port=COM13 Address=640000000DC81C1D Family=DS2423 Counter=137655/47582 |
    24 08:17:23 | Port=COM2 Address=6B000000E772F326 Family=DS2438 Temperature=70.3625 Humidity=92 Voltage= 25 |
    24 08:17:25 | Port=COM2 Address=18000801CB238A10 Family=DS1920 Temperature=21.375 |
    24 08:17:26 | Port=COM2 Address=43000801E197F110 Family=DS1920 Temperature=21.25 |
    24 08:17:28 | Port=COM2 Address=DC00000014C88C26 Family=DS2438 Temperature=74.46875 Humidity=49 Voltage= |
    24 08:17:29 | Port=COM2 Address=BD000000F53A3B26 Family=DS2438 Temperature=73.11875 Humidity=50 Voltage= |
    24 08:17:30 | Port=COM2 Address=43000801E197F110 Family=DS1920 |
    24 08:17:30 | Port=COM2 Address=18000801CB238A10 Family=DS1920 |
    24 08:17:30 | Port=COM2 Address=9600000014CAB326 Family=DS2438 |
    24 08:17:31 | Port=COM2 Address=18000801CB238A10 Family=DS1920 9600000014CAB326 Not Present / 1-Wire Adapter communication exception |
    24 08:17:31 | Port=COM2 Address=6B000000E772F326 Family=DS2438 |
    24 08:17:32 | Port=COM2 Address=DC000000F1D35C26 Family=DS2438 |
    24 08:17:32 | Port=COM13 Address=640000000DC81C1D Family=DS2423 DC000000F1D35C26 Not Present / 1-Wire Adapter communication exception Counter=137655/47582 |
    24 08:17:36 | Port=COM13 Address=640000000DC81C1D Family=DS2423 DC000000F1D35C26 Not Present / 1-Wire Adapter communication exception Counter=137655/47582 DC000000F1D35C26 Not Present / Port in use |
    Last edited by Pete; July 25, 2012, 09:58 AM.

    Leave a comment:


  • Michael McSharry
    replied
    xapmcs1Wire design is to maintain a queue of requests that are to be processed through the adapter. A timer exists for each polling interval used. When the timer expires the sensors at that polling rate are added to the queue if they do not already exists there. The queue is processed continuously until it is empty.

    When using an 1-wire hub it is best to group sensors at the same rate to minimize the number of times the switch has to change. If all sensors on the same 1-wire hub branch are polled at the same rate then the switch can stay in the same position until all are completed.

    Leave a comment:


  • Pete
    replied
    Giving it a try here Greg as I always just picked different intervals never really paying attention. Currently I have 5 9097's running right now with 1 on HS. The other 4 are using the xapmcs1wire application on different computers. Recently have added the old Dallas rain tipping bucket to the mix while testing the RG-11 digital rain guage.
    Attached Files

    Leave a comment:


  • Wadenut
    replied
    Originally posted by Wadenut View Post
    It's been quite a while since I visited this thread. I'm still on 3.0.0.5. Is there any real advantage to me to go to 3.0.0.10?
    The only problem I have currently is with mcsxap1wire where it randomly, after a few days usually, stops reporting data and requires a restart. There are no errors. I've been thinking of writing a script to watch the last date/time on the devices to decide whether or not to force a restart.
    Originally posted by Wadenut View Post
    Thank-you Michael. I'll stay put on that then.
    Any idea ho to best address the xapmcs1wire stopping problem? I'd never had such a problem with mcstemperature.
    Originally posted by Michael McSharry View Post
    One approach is to try to understand why it stops. Likely not practical unless tools are available to trap and investigate.

    xapmcsProcess is intended to do remote computer management via xAP protocol. mcsXap has triggers that can be setup based upon timeout since last xap message from a wildcarded address. The action from this trigger could be to restart xapmcs1wire when messages stop. I'm not home now to provide the schema specifics.

    I do not recall if there is an xAP schema that provides the interface to the tray icon to exit. Again I would have to look. It would be the equivalent to what xapmcsProcess provides as the first level.

    As Pete mentioned there are also other options if it is a local rather than remote host for xapmcs1wire.

    In the case of xapmcs1Wire it is important to have a gracefull application shutdown or to restart the host computer. When communicating through the Dallas drivers there is a period of time when exclusive use of the adapter is made. If I recall it holds it until all sensors in a specific polling cycle have been processed. If there is a shutdown using something like Task Manager or script equivalent when in the middle of a polling cycle then when xapmcs1wire restarts it will never be able to gain access to the adapter.
    I believe I've found a solution to this problem.
    While using mcsTemperature (years), I'd always polled the network at 5 second intervals. This was never a problem.
    When I switched to xap last fall, I changed the poll frequency on some slower reacting parameters devices (temperature, humidity, barometer) to a lower rate of 60 seconds, while leaving devices like wind at the higher rate.
    Still, after time, sometimes days, sometimes only hours, xapmcs1wire stopped responding; requiring me to restart it or eventually reboot the machine when restarting the application failed to fix the problem.

    A couple of weeks ago, I decided to try prime numbers, in seconds (5,7, 61,67,71), for the polling intervals on all devices. My theory is that this would prevent any possibility of any two devices being polled simultaneously. This appears to have done the trick as xapmcs1wire has purred along ever since. <!-- / message --><!-- sig -->

    Leave a comment:


  • Michael McSharry
    replied
    Any idea ho to best address the xapmcs1wire stopping problem?
    One approach is to try to understand why it stops. Likely not practical unless tools are available to trap and investigate.

    xapmcsProcess is intended to do remote computer management via xAP protocol. mcsXap has triggers that can be setup based upon timeout since last xap message from a wildcarded address. The action from this trigger could be to restart xapmcs1wire when messages stop. I'm not home now to provide the schema specifics.

    I do not recall if there is an xAP schema that provides the interface to the tray icon to exit. Again I would have to look. It would be the equivalent to what xapmcsProcess provides as the first level.

    As Pete mentioned there are also other options if it is a local rather than remote host for xapmcs1wire.

    In the case of xapmcs1Wire it is important to have a gracefull application shutdown or to restart the host computer. When communicating through the Dallas drivers there is a period of time when exclusive use of the adapter is made. If I recall it holds it until all sensors in a specific polling cycle have been processed. If there is a shutdown using something like Task Manager or script equivalent when in the middle of a polling cycle then when xapmcs1wire restarts it will never be able to gain access to the adapter.

    Leave a comment:

Working...
X