Announcement

Collapse
No announcement yet.

Extremely weird events run on their own but not as a group

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

    Extremely weird events run on their own but not as a group

    I have 5 identical events (different IP address content) that perform a simple action to issue a single HTML GetURL using native HS4 command
    Execute the command:
    &nhs.GetURL("http://192.168.1.111" , "/cm?cmnd=Power%20off", True, 80)



    I can run each one of them without any problem. They do what they are supposed to.

    If I make a master event to run them all at once than I'm getting this error in the log and only one of the 5 doesn't do it's job. It is always the same one that fails. Changing the order or adding "wait" between them doesn't help. For the record K3 is not my script should've come with HS4. Again the error doesn't happen if I run the events individually.
    12/2/2020 5:13:57 PM


    HomeSeer
    Error
    Compiling script C:\Program Files (x86)\HomeSeer HS4\Temp\K3.vb: Syntax error.
    12/2/2020 5:13:57 PM


    HomeSeer
    Error
    Compiling script C:\Program Files (x86)\HomeSeer HS4\Temp\K3.vb: ')' expected.
    12/2/2020 5:13:57 PM


    HomeSeer
    Error
    Compiling script C:\Program Files (x86)\HomeSeer HS4\Temp\K3.vb: 'http' is not declared. It may be inaccessible due to its protection level.
    12/2/2020 5:13:57 PM


    HomeSeer
    Error
    Compiling script C:\Program Files (x86)\HomeSeer HS4\Temp\K3.vb: Namespace or type specified in the Imports 'System.Core' doesn't contain any public member or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases.

    #2
    Can you share the script?

    Comment


      #3
      There is no script on my side. My events use single command (not script). The errors in the log mention some script that is not mine.

      Comment


        #4
        HS4 takes your command and puts it in a script file called Knn.vb. That is what you are seeing. I guess in one of your statements you use as command there is a ')' missing. If you check the temp directory (if my memory serves right) you will find the Kn.vb files that have been created. If you edit these files you migh see why that one step fails?

        Wim
        -- Wim

        Plugins:RFXCOM, HSTouch Server, Squeezebox, BLGData, Restart, Jon00's Perfmon and Network monitor, WeatherXML, BLBackup, TenScripting, BC4, Pushover, PHLocation, JowiHue, Zwave, Sonos
        650 devices ---- 336 events ----- 40 scripts

        Comment


          #5
          Can you share a screen shot of your master event?
          Mike____________________________________________________________ __________________
          HS3 Pro Edition 3.0.0.548, NUC i3

          HW: Stargate | NX8e | CAV6.6 | Squeezebox | PCS | WGL 800RF | RFXCOM | Vantage Pro | Green-Eye | Edgeport/8 | Way2Call | Ecobee3 | EtherRain | Ubiquiti

          Comment


            #6
            I've seen a similar issue on HS3. Two immediate scripts that run at the same time can clobber each other.

            Those Kn.vb scripts are generated when the &nhs object is used in the script code. The n normally increments for subsequently compiled scripts. But when multiple immediate script action events are called at once, there's a race condition where two or more can grab the same n and they overwrite each other. In HS3, this results in a log entry like

            Exception handling event action ACTION SCRIPT for event Sandbox GetURL i c: The process cannot access the file 'C:\Program Files\HomeSeer HS3\Temp\K3.vb' because it is being used by another process.

            Note that if you can run multiple immediate script actions in the same event without issue. It's when you have separate events (perhaps called by a master event) that the problem occurs.

            Interestingly, when using the &hs object instead of &nhs, the Kn.vb scripts aren't generated. But this fails in a different way - log indicates all the events were initiated and no errors, but some of the actions simply don't run. Then a pop-up appears on the server desktop saying that a script is taking longer than expected to run and do you want to stop it.

            Comment


              #7
              zwolfpack Thanks for the informative feedback. It is confirmed by my experience. Red ink disappears from the log if I introduce a delay between the execution of the events thus eliminating the "competition" between them. However as I mentioned above it didn't solve my problem as the dimmer under control didn't turn off.

              I then used my Homeseer's Big5 plug-in as a "sniffer" to report exactly what's going on with the GET command coming out of HomeSeer.
              As a result of the "sniffing" I realized that I'm making a major mistake looking at the GET URL as one long sequence of characters that should do the job for GET URL controlled devices. This believe was supported by the fact that when I enter the whole thing in a browser it does the job. So what's the difference if it comes from a browser or generated by HS4? Not true apparently. The first part is the address and the second part is the actual content - call for action. Big5 distinguished between the address part and the content part and showed the two parts separately in the log. So I modified the native HS4 command like this

              was:
              &nhs.GetURL("http://192.168.1.111" , "/cm?cmnd=Power%20off", True, 80)

              changed to:
              &nhs.GetURL("http://192.168.1.111/cm?" , "cmnd=Power%20off", True, 80)

              It is working now even with the master event running the 5 events simultaneously without delays between them. I know that this maybe basics for pros like you but for me it was like great enlightenment.

              Comment


                #8
                I'm impressed! ... however I can't replicate your success. One thing I'd advise is to stop & restart HomeSeer, then test again. Compiled scripts are cached and the conflict may not show up if successful entries are in the cache.

                Comment


                  #9
                  Why not stick the vb statement in a simple .vb file and invoke it from there?
                  tenholde

                  Comment

                  Working...
                  X