Announcement

Collapse
No announcement yet.

New Error on .460

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

    Originally posted by rjh View Post
    I posted a build 495 with the queue size changed to 2000, so you are welcome to see if that helps with the warning message. I also posted builds for the Zee S2 and the SEL so you can update from setup to this build. Windows build is here:

    http://homeseer.com/updates3/SetupHS3_3_0_0_495.msi
    .496 and .497 are also out...
    My home is smarter than your honor roll student.

    Comment


      I have been dealing with an issue for a long time relative to plugins and HsEvents processing. If have several plugins that run remotely (tenScripting for example) that register for VALUE CHANGE STRING CHANGE and LOG events. When the remote plugin disconnects from HS and then terminates, something isn't being cleaned up properly as plugins will not receive HsEvents for around 8 minutes after the remote plugin terminated. After 8 minutes, and error appears in the log that HS was trying to access the HsEvents routine of the plugin that disconnected and terminated 8 minutes prior, and received an exception for null object reference.

      I just recently (and accidentally) discovered that this problem goes away if I register for the device and string change events, but not the LOG events.

      I've tried to created a debug log for HS, but as stated in the thread, if you turn debug on and have a plugin registering for LOG events, a race condition occurs.

      Any chance someone at HS could look at this issue of plugins with LOG HsEvents disconnecting causing problems?

      Also, I'm another that votes that these debug entries should be written to a debug file, NOT THE HS LOG
      tenholde

      Comment


        Although I do not read any threads anymore that que's are filling up, in my case it does. I upgraded recently from .435 to to .534 and now my log fills itself with tons of warnings. Especially when I connect to the HS server by web. For example opening event groups. HS uses in normal state about 25% of the CPU the whole system about 38%. Only HS is running. And is prioritized evenwel as all the plugins. And it hasn't been there in .435. At least far far less.
        Warning Dropping event callbacks due to full queue (Type: RUN_SCRIPT_SPECIAL) (2000 entries), system may be too busy, plugins and HSTouch may not receive all device updates
        jun-23 02:03:52 Warning Dropping event callbacks due to full queue (Type: VALUE_CHANGE Device Ref: 993) (2000 entries), system may be too busy, plugins and HSTouch may not receive all device updates
        jun-23 02:03:51 Warning Dropping event callbacks due to full queue (Type: RUN_SCRIPT_SPECIAL) (2000 entries), system may be too busy, plugins and HSTouch may not receive all device updates
        Sometimes the warning points out a device. But when I take a look at this, these devices are normal devices that are used within events in HS and not (directly) related to a plugin. In this case this is a counter that is set in HS and by script hs.counterincrement. But also timers, just running for an event trigger by example every 3 hours. So very basic.

        What do these clue's mean?

        And how can get rid of these warnings? Or better solve the underlaying problem?

        Many thanks for your advice!

        Comment


          Originally posted by Ralfmen View Post
          Although I do not read any threads anymore that que's are filling up, in my case it does. I upgraded recently from .435 to to .534 and now my log fills itself with tons of warnings. Especially when I connect to the HS server by web. For example opening event groups. HS uses in normal state about 25% of the CPU the whole system about 38%. Only HS is running. And is prioritized evenwel as all the plugins. And it hasn't been there in .435. At least far far less.

          Sometimes the warning points out a device. But when I take a look at this, these devices are normal devices that are used within events in HS and not (directly) related to a plugin. In this case this is a counter that is set in HS and by script hs.counterincrement. But also timers, just running for an event trigger by example every 3 hours. So very basic.

          What do these clue's mean?

          And how can get rid of these warnings? Or better solve the underlaying problem?

          Many thanks for your advice!
          Best way to try and troubleshoot this is to disable plugins one at a time to see if there's one that's causing the system to slow down. Based on your other recent posts for the Arduino plugin, there's something going on in your system that is causing it to run slow. If there's no plugin causing it, then start looking at events, scripts and timers.
          HS 4.2.8.0: 2134 Devices 1252 Events
          Z-Wave 3.0.10.0: 133 Nodes on one Z-Net

          Comment


            Thanks! I did shutdown all the plugins before. Unfortunately that was not helping. I did as you write upgraded the system and Arduino plugin. From that moment on, the warning caused by the Arduino plugin (the same regarding entries, in that case 500) is gone. This was as I see it, another warning related to the plugin. But I understand what you say.

            The strange thing is however that the system is in idle working mode working great. The problem (mainly) occurs when I have to work in HS. So what I can't point out is, why in idle mode the system is working great and slow CPU usage, but when I work in HS some part of the system does not work correct anymore (because of higher CPU usage). And above of that, I can't point out why this is happening in .534 and not in .435 (or earlier).

            I did once try very short .500 but that gave problems with the NETCAM plugin. I rolled back fast, so I don't know if .500 does have the same warnings. To be complete. In .534 the NETCAM problem was stil there. I worked around that bij uning HSTouch html element video in stead of option video=true element. But I can't see in anyway why this could be related. Video works fine now. Do you?

            An other thing I can't point out, is where to begin the search. Because the problem is only there when I work in HS.

            Do you have any clue, reading the above information?

            Many thanks!

            Comment


              tenHsEvents will show you which plugins are generating device changes (which trigger HsEvents for each plugin that registered for them). There are two things to look at: (1) which plugins are continually updating devices (media plugins many times update devices containing track info each second, etc), and (2) which plugins that have registers for HsEvents are taking excessive time to process before returning to HS, thus backlogging HS Qs. tenHsEvents will help identify high volumes of device updates.
              tenholde

              Comment


                Thank you! So I did. tenHsEvents seems working, however I get these errors in de HS log file:
                jun-26 19:58:35 Error Exception in GetLogDetail_Real: Input string was not in a correct format.
                jun-26 19:58:10 Error Exception in GetLogDetail_Real: Input string was not in a correct format.
                jun-26 19:57:35 Error Exception in GetLogDetail_Real: Input string was not in a correct format.
                jun-26 19:57:08 Error Exception in GetLogDetail_Real: Input string was not in a correct format.
                There is nothing on the forum about this error. When I close tenHsEvents the error is gone. Do you have any clue?

                Then I did some research. What I see is that by far the most rows are caused by timers. I use about 20, that seems a small amount to me for HS to handle. But I get the log:

                08:06:22 Excessive Queue count, Events scrolling stopped
                And the events/min is massive, 4000-5000 or more /min.

                So something is wrong. You are pointing in the right direction. And it are the timers that are messing up my system. When i stop them, everything is ok. At least so seems.

                I use the timers as I think HS must be able to handle. For example:

                IF timer T > set duration
                And var X is not Y
                THEN
                Some action
                Var X = Y

                So that the event is executed once. Timers can run for days but that depends. What is wrong?

                UPDATE 1. I did some more research. And I see that when I uncheck the timers in tenHsEvents, that from that moment on, the queue showed in tenHsEvents, is counting down to zero. It was running up fast with all the timers selected. So this queue only fills when the timers are selected in tenHsEvents. But the problem in HS still is there.
                jun-28 10:44:42 Warning Dropping event callbacks due to full queue (Type: RUN_SCRIPT_SPECIAL) (2000 entries), system may be too busy, plugins and HSTouch may not receive all device updates
                When this error occurs, in tenHsEvents the queue is (or can be) zero or filled a little bit for a moment with lets say 50 when the timers are not selected in tenHsEvents. This is very volatile. So the queue seems ok, but this error occurs. Only when I stop all the timers in HS, the warning is gone. So the timers are the problem. But why can't I use them in HS as trigger or condition?

                UPDATE 2: Again I did some more research and I see now that it does not matter if a timer is used or not in an event. When a timer is started and there is no event related (it can be deleted in HS if wanted) then this timer (also) shows up every second in tenHsEvents. So I unchecked timers in tenHsEvents. That works to get the log readable. As expected the events/min is still massive.

                To solve the above HS error "full queue", I coded around this, by eliminating the timers af far as possible. All the timers that I used to trigger (or as a condition) that do not need the timers function "less" are replaced by virtual devices. Now the total event/min in tenHsEvents is down by a massive 90% to 400 events/min. So this works great for me.

                But still, I can't understand why HS can not handle timers very well, when this is used in more (or al lot) events at once. This should be no problem at all for HS is my opinion.

                So far so good. But if anyone has any suggestions that also could work. I really would like to know.
                Many thanks!

                Comment


                  Hmm ralf this indeed can also be my issue, i mostly ise timers for indicating runtimes but also standytimers. How did you code around them? Ising timestamps of virtual devices i guess?
                  Regards Bart
                  ------------------------------------------
                  Win7 64Bit on Intel NUCI7 with SSD
                  HSPRO 3.
                  Devices; 1370 Events; 691

                  Jon00 Scripts, JowHue, HSTouch, Plugwise, Z-wave, Ultranetatmo, Ultracam, PHlocation, BLUSBUIRT, MeiHarmony, Buienradar, MEiUnifi Pushover 3P, Random, Nest HSPhone and Blueiris

                  Visonic Powermax Alarm System (HS3) Interface: http://www.domoticaforum.eu/viewtopic.php?f=68&t=11129

                  Comment


                    Btw i do not get the messages in the log as u about the callback, but i can recall i had these in the past
                    Regards Bart
                    ------------------------------------------
                    Win7 64Bit on Intel NUCI7 with SSD
                    HSPRO 3.
                    Devices; 1370 Events; 691

                    Jon00 Scripts, JowHue, HSTouch, Plugwise, Z-wave, Ultranetatmo, Ultracam, PHlocation, BLUSBUIRT, MeiHarmony, Buienradar, MEiUnifi Pushover 3P, Random, Nest HSPhone and Blueiris

                    Visonic Powermax Alarm System (HS3) Interface: http://www.domoticaforum.eu/viewtopic.php?f=68&t=11129

                    Comment


                      The tenHsEvents queue is showing the events that are being sent to tenHsEvents and how long it takes for tenHsEvents to process each event. If you have timers active, they generate a device change every second for each enabled timer. By unchecking the timers in tenHsEvents, you only stop the display of each device change, but that lessens the processing for tenHsEvents, so much less queueing. The devices are still changing values each second, and EVERY plugin that registers for device change must process every one. The queue that HS error messages refer to is different than the tenHsEvents queue. When a device change value, HS queues up a call for every plugin that registered for device changes, calls each plugin, and waits for a return. If device changes happen faster than the plugins can process these calls, then the queue keeps getting bigger. That's why you must look at two things. One, how many device changes are taking place (timers and counters are culprits), and how many plugins are processing these device changes and how long does each take to process a device change. tenHsEvents cannot help with the second, but it can give you an idea of how many device changes are taking place. Many have seen that using many timers and counters can create a problem, but that will also depend on how many plugins are processing all of these device changes.
                      tenholde

                      Comment


                        Originally posted by tenholde View Post
                        The tenHsEvents queue is showing the events that are being sent to tenHsEvents and how long it takes for tenHsEvents to process each event. If you have timers active, they generate a device change every second for each enabled timer. By unchecking the timers in tenHsEvents, you only stop the display of each device change, but that lessens the processing for tenHsEvents, so much less queueing. The devices are still changing values each second, and EVERY plugin that registers for device change must process every one. The queue that HS error messages refer to is different than the tenHsEvents queue. When a device change value, HS queues up a call for every plugin that registered for device changes, calls each plugin, and waits for a return. If device changes happen faster than the plugins can process these calls, then the queue keeps getting bigger. That's why you must look at two things. One, how many device changes are taking place (timers and counters are culprits), and how many plugins are processing these device changes and how long does each take to process a device change. tenHsEvents cannot help with the second, but it can give you an idea of how many device changes are taking place. Many have seen that using many timers and counters can create a problem, but that will also depend on how many plugins are processing all of these device changes.
                        Okay,

                        So I am not familiar with tenHSevents, I will look into that. But I do not get the callback warnings. when my HS3 starts using high CPU. Next to that when it happens, that HS3 is eating CPU, I cant stop it. I tried disabling all plugins, and hstouch and there were no script running. The only way to restore the cpu usage for me is restarting HS3.
                        Regards Bart
                        ------------------------------------------
                        Win7 64Bit on Intel NUCI7 with SSD
                        HSPRO 3.
                        Devices; 1370 Events; 691

                        Jon00 Scripts, JowHue, HSTouch, Plugwise, Z-wave, Ultranetatmo, Ultracam, PHlocation, BLUSBUIRT, MeiHarmony, Buienradar, MEiUnifi Pushover 3P, Random, Nest HSPhone and Blueiris

                        Visonic Powermax Alarm System (HS3) Interface: http://www.domoticaforum.eu/viewtopic.php?f=68&t=11129

                        Comment


                          Originally posted by bartbakels View Post
                          Hmm ralf this indeed can also be my issue, i mostly ise timers for indicating runtimes but also standytimers. How did you code around them? Ising timestamps of virtual devices i guess?
                          yes I do use the timestamps of the virtual devices in HS and in the scripts. by setting the device off/on the timestamp changes and acts as timer start. timer functions pause and "less then" are not supported. works good.

                          Comment


                            I found the problem while troubleshooting my AKShelly plugin. In some update HS introduced strange behaviour - it triggers "CONFIG_CHANGE" HSEvent callback for each HS device after start-up. So every plugin that is registered for this callback starts to process it and that is causing high cpu usage.

                            I contacted HST about this issue, but giving my experience I don't hope too much. So I will add some workaround to all my plugins asap. Today.

                            Comment


                              I have 83 timers, and each one has an associated HS Device. I use all the timers, but don't use any of the HS Devices. I turned off the "Create Devices for Counters and Timers" setting and deleted all of the devices to avoid the Callback Error problem. However, when HS3 restarted it recreated all the HS Devices again. Anybody know how to get rid of them without rebuilding all my events and scripts with new timers?

                              Comment

                              Working...
                              X