Announcement

Collapse
No announcement yet.

Polling Interval!?!

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

  • Polling Interval!?!

    Okay, I'm fustrated. Vanna, can I buy a clue please? [img]/infopop/emoticons/icon_confused.gif[/img]

    The plugin is communicating with the panel, but the updated changes are not reflected in HS. I.e. I run a button on the "HAI Units & Devices" page that tells the panel that the people in the guest bedroom have gone to sleep. The panel correctly executes the button which changes a bunch of flags, and decrements a counter telling how many people are still awake. Using the PC Access software I can verify that the button ran correctly, but the HS web page does not show any changes.

    Where do I look to determine what the current polling interval is so I can change it if necessary? I haven't changed the interval from the default, but then I had all the betas go through the machine and I might have some garbage hiding somewhere.

    Just checked. It's been an hour since I ran the button, and the changes are still not showing in HS.
    My system is described in my profile.
    My system is described in my profile.

  • #2
    I am unclear as to what is suppose to update. Is it a counter that should change or the button or something else? Remember that web pages do not automatically refresh unless you turn that feature on in HomeSeer, but that in itself can cause some problems too. If you executed a button, then the status device "Button Pushed" would reflect that button. If the logic behind the button in the HAI panel changes a unit, then you would have to refresh the HAI Units web page to see the new value, AND the refresh might have to be after a minute or so because of the polling rate. Let me explain: Most of the things that happen in the panel cause an event in the event log immediately, and the plug-in grabs those every 1/2 second. Some things, however, do not log an event in the event log and thus the update does not appear until that regular cycle of polling the entire system, which typically takes at least a minute. If you change a unit in the panel using a plug-in web page, then since I know you have changed the item, I can get the status immediately. When the panel makes the change as the result of the built in automation in the HAI system, then the plug-in does not know about it unless it is one of those things that does make an entry in the event log right away.

    Does that make sense?

    If you want to experiment with the two polling intervals in the system, then check the on-line documentation under "Other Plugin Features" as the PollingInterval and GroupPollingInterval settings are explained in detail there.

    If you can provide more detail on what exactly you are looking for the change on, then I can see what the factors are involved in its display update.

    Comment


    • #3
      GRR! Replied once, and the board went down and lost it. [img]/infopop/emoticons/icon_mad.gif[/img]

      Okay, I made entries for the polling interval and group polling interval in the hspi_HAI section of config.ini. That is the correct location I hope? Since there was no pollinginterval line in the INI file, I added a line for each parameter using the default 500/24 settings. In either case, still the same result.

      I'm pushing a HAI button using the plugin webpage. The button causes lights to go on/off, and a counter to decrement/increment. The HS->HAI connection is working fine, as the lights go on/off correctly. Using PCAccess, I can also see that the counter value has changed correctly. However, six minutes later and several refreshes, the changes are NOT being displayed on the HS webpage. The zone names info was downloaded from the panel with no trouble, so the HAI->HS connection is also working. I'm not seeing any error messages in the HS log about communication problems, so I don't think we are losing synch.

      My system is described in my profile.
      My system is described in my profile.

      Comment


      • #4
        Okay. After a weekend of fiddling with the two polling variables, I've got it (sort of) working. Unfortunately, to have any reasonable response, I've got it cranked down to 200 and 12. Even now, it still takes around 2 minutes for any changes to be reflected.

        Any idea how sensative the plugin is to the speed of the CPU? I'm running Win2K on an older PII 450 mhz machine.

        My system is described in my profile.
        My system is described in my profile.

        Comment


        • #5
          The plugin is not inherently sensitive to the CPU speed - it will work on a 50MHz or a 5GHz machine just the same so long as the plugin got adequate CPU time. For what it is doing without any events that have HAI triggers or HAI actions, it won't take much CPU at all. The more often HomeSeer has to query the plugin for the status of a sensor because it was used as a conditional trigger, then the more sensitive the plugin becomes to anything taking CPU time because it then has so much work to do.

          The unfortunate thing here is HAI's seemingly inconsistent behavior. When you do something like arm or disarm the system using a command with this interface, it still writes an event to the event log which causes the plugin to update immediately. When you change a unit, however, it does not do the same thing so we are at the mercy, somewhat, of the group polling interval.

          You should also be aware that the group poll can get interrupted with a higher priority event, so in some cases a unit might take much longer to update than it should just because the group polling interval is too short.

          I will take a look at this and see if there is something more I can do. Nobody else has mentioned the update time being a problem, but if I can squeeze in an immediate status request command right after you change a unit, then I will have immediate updating. When I was doing that on the security page after each click of the Bypass or Restore links, it was taking way too long for the web page to return and repaint the screen because of all of the CPU processing going on. I don't want to create a situation like that again. If the item you are looking to update is a third party item - e.g. you used HAI program lines to change it instead of HomeSeer actions, then there will be nothing I can do about it unless HAI has some way to generate an event when the unit changes.

          With that in mind and if that is the case here, then you may wish to consider using HomeSeer/HAI actions instead of HAI code exclusively when you want immediate feedback.

          Comment


          • #6
            If I can be sure things are getting updated consistently, I would be happy. I could even live with a 10 minute update cycle, *IF* I could be sure that the updates are occuring. At this point I'm not confident that they are. [img]/infopop/emoticons/icon_mad.gif[/img]

            I've been doing some Omni programming work this evening, so I've had PC Access on the screen (via Tight VNC) all evening. At the same time, I've had the HAI Units page up on the browser. Every so often I'd update the web page, then compare against the status page of PCAccess. Almost all the time, they didn't match. At all. In one case, a counter was set to 1 around 9:30 this morning. All day it showed as 0 on the web page, no matter how many times clicked on "HAI Units", "status" and then back to "Units, etc. Finally, around 8:15 tonight, it showed up correctly, as did everything else. [img]/infopop/emoticons/icon_confused.gif[/img]

            Some background on what I'm doing, and why I'm pulling my hair out. I do room lighting based on occupancy sensing. This is all done on the Omni for speed reasons. The system also keeps track of how many bedrooms are in use, and how many people are still awake. Once the "awake count" reaches zero, everyone is in bed and the system switches over to night mode. In night mode, different lights might come on than in the evening, and any lights that do come on do so only at 20% light level. In the morning when the first person gets up, the "awake count" goes back up to one, and the system goes into day or evening mode depending on if the sun is up yet. This is all working well, with the exception of setting the light levels.

            Homeseer does all the holiday and decorative lighting, along with the integration with phone, sprinkler system, weather station, and eventually the whole house audio. I would like HS to shut down the holiday lights in the bedrooms as people go to bed. I would also like HS to be able to change the lighting levels when everyone goes to bed, as the Omni X10 interface has trouble getting all the lights set correctly. BUT, since I can't get HS to accurate reflect the current state of the "awake count", I hesitate to do it. If I have to, I can go back to using X10 semaphores to communicate from the Omni to HS, but that negates part of the usefullness of the plugin.

            Enough typing for one night. [img]/infopop/emoticons/icon_razz.gif[/img] I'm going to stick some events in HS to monitor some of the HAI units, so I can get a better idea of the response time. Let me know if you have any other thoughts or questions.

            My system is described in my profile.
            My system is described in my profile.

            Comment


            • #7
              What I wrote earlier does apply here. The counter being maintained by the HAI, not HomeSeer, is why you are not seeing it update very often. Just as an experiment, write some events in HomeSeer that set, increment, and decrement a counter. Using the Windows UI or a 2nd web page, execute these events. After executing one of the events, refresh the web page display and tell me if you notice a difference. You will see that it does reflect the change - immediately.

              As I mentioned before, the group polling interval is meant to catch these items that HAI does not generate an event notification for when they change. I poll for these events every half second by default, but most of the time there is no data to process. Imagine if I did not break the units, zones, thermostats, etc. into groups and polled for all 500+ (On an Omni Pro II system) every second so that you would see pseudo realtime display - the system would be on its knees.

              Thus, unless you change the unit using HomeSeer where my plug-in can immediately retrieve the current status, there is no way to poll for the status often enough without compromising the entire system. It's that or get HAI to put out a firmware update where thermostat and unit changes (other than X-10/ALC units) generate entries in the event log.

              Something that should suffice as a workaround that is better and more reliable than X-10 would be to use one of the units as a flag (e.g. it does not have a physical relay attached to it) and then have HAI change the unit (On/Off) and HomeSeer uses that as a trigger. I believe the On/Off (output) units do generate events and so this would work pretty well. If they do not generate events (e.g. does not trigger immediately when the HAI changes the output) then it would be possible to set it up as a CONDITION and then specifying a unit condition. Conditions are checked by HomeSeer, not the HAI plugin, and they are checked at least once a minute if not every couple of seconds depending upon system load.

              Comment


              • #8
                Uh uh. The problem is not limited to the counters and units. I'm not getting regular updates on ANY data from the Omni. I went shopping tonight around 8:30 and arrived home at 11:00. It's now 11:37. Both the web and windows GUI is still showing the Omni as "Armed away", with the last action at 8:33 PM. The Omni event log shows everything correctly (exit & alarm at 8:33, door trip/motion trip/disarm at 11:00).

                I just armed the panel from HS, and then disarmed it from HS. NOW HS shows the correct status for the alarm (but nothing else is correct). Am I understanding you correctly, that the units and counters do not update at ALL unless the change is initiated by HS?

                Is anyone else having this problem? The only other thing I can think of is that the plugin does not work with some of the older HAI ROMs. I'm running the Worthington special 10A05-15 version of 1.8. I'll stick a query out in the HAI mailng list also.

                My system is described in my profile.
                My system is described in my profile.

                Comment


                • #9
                  I wonder if your system is experiencing the same problem I had... To answer your question though, nobody else has reported this problem, and you are correct that the arming status naturally updates immediately as that is something that does cause an event in the event log when it happens. There is definitely something wrong here.

                  On my system, towards the end of the beta, I was absolutely tortured with a problem that I could not figure out for the longest time. As it turns out, I deleted all of my Ocelot variables because Rich said they were not needed. However, deleting them AFTER they were initially created left an entry somewhere such that the Ocelot plug-in still thought it owned that house code, so then along comes my plug-in which just happened to grab that now available house code, and my torment began. It is a long shot if you even happen to have an Ocelot, but the short of it is that if another plug-in, script, or event is modifying the house code/unit code combinations that correspond with the HAI status devices, then they can get locked into one value and never change again. This would explain why the status may appear correctly on the "Security" web page but not in the status page of the Windows or Web UI. Verify that the "Security" web page is working by refreshing that screen after arming/disarming the system, and if it is, then you probably do have a conflict with some plugin or script accessing the devices that were assigned to the HAI plugin.

                  If that is not the case, then remove any references in the INI file to the polling intervals to put them back to the default values, and let me know if that fixes it. Assuming it does not, we will have to go back to doing debug captures.

                  Since the release to production, I have not had any problem on my Omni Pro system (not Omni Pro II, just Omni Pro).

                  Comment


                  • #10
                    I've heard one other person on the HAI mailng list who is also having this problem. What version ROM does your OmniPro have? I have 1.8, and the other person has 1.9.

                    My system is described in my profile.
                    My system is described in my profile.

                    Comment


                    • #11
                      No Ocelot/Leopard here. The only other plugin is the VWS plugin.

                      I've deleted the two INI entries, so the polling interevals are back to defaults. Last night the security page was not correctly showing system status. Tonight it seems to be working just fine (sound of hair being pulled out [img]/infopop/emoticons/icon_mad.gif[/img]). I wish I could find a pattern.

                      My system is described in my profile.
                      My system is described in my profile.

                      Comment


                      • #12
                        Another thought. What does the plugin do if you have multiple partitions (AKA areas) setup? I have one partition for the main house, and another for the garage. Could that have any effect? I looked in the help file, but didn't see any references.

                        My system is described in my profile.
                        My system is described in my profile.

                        Comment


                        • #13
                          I am pretty sure I have 1.8 - next time I have to shut down HomeSeer or go to the basement I will check to make sure. Can you have the other person having this problem and yourself register this with Rich? They are providing first tier support and he needs to know if this is a frequently occurring problem.

                          Thanks.

                          Comment


                          • #14
                            Multiple partitions are not supported by the plugin, which is by design as I was told the plugin would not support it. There would be messages coming back from the panel that have an area number, and those messages could confuse the plugin. I am wondering if there is a way to test for this by perhaps doing absolutely nothing with your 2nd area for a day or two to see if your status updates without any problems.

                            Is there any reason in particular for the partition? I had a partition for home automation stuff on a different type of security system years ago and it created more problems than it solved. I found that by making the sensors (zones) an Auxiliary type that I could instead keep everything in one partition and I had no other problems.

                            If there is somebody else having this problem, then I need to know who and whether or not they have multiple partitions.

                            Comment


                            • #15
                              I know the other person has talked to Rich. He was going to mention that I was having problems also, but I don't know if he did. I'll drop a line to Rich myself.

                              The second partition is for a detached garage, and the third for a future boathouse. I haven't been arming the garage all summer, since a spider took up residence in one of the PIRs and drove me to distraction with false alarms. I'll look into consolidating everything into one and see if it makes a difference.

                              As for the other person having this problem, I've pointed him to this thread. Since he hasn't added a "Me too!", I assume he has some reason for staying anonymous.

                              My system is described in my profile.
                              My system is described in my profile.

                              Comment

                              Working...
                              X