Announcement

Collapse
No announcement yet.

more temp control condition logic problems

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

    more temp control condition logic problems

    In addition to the problem with a lower limit not using a device as a value (see "line 970 Type mismatch", for which I haven't tried the fix yet), I noticed this morning some temperature events that seem to be triggering strangely.

    I have two events related to temp differentials of 1 degree. One is "delta increases above upper limit" of value "1", the other is "delta decreases below lower limit" of value "1". Both have "persists" value of 3 and "retrigger" value of 15.

    Below is what was in my HS logs this morning that show each event triggering from about 4 am to 7 am, and attached is what the DB stored over the same approx. time period. The latter shows the temp never differing by more than about 0.3 degrees over the time period.

    Have seen the logic work (and, in fact, have not been checking up on these events for some time because they appeared to be working fine when I set them up and checked them over several weeks a few months ago). It's very strange that I get (well, notice) this weird behaviour today.

    What's going on with the logic? (Am running version 4.32.9)

    Also, can you calculate retrigger time delays so they don't vary by more than +/- 1 minute? You'll see several occurances below of a retrigger 4 minutes early. Not the end of the world for these events, but for some other situations (e.g. events that need to retrigger in less than the 4 minute variation, or weather forecast data retrieval from weather.com that we are not supposed to retrieve more than once every 30 minutes to meet licensing requirements and that one wants to retrieve every 30 minutes)


    19/02/2005 4:01:24 AM~!~Temp Info~!~Upstairs and downstairs temp differs by LESS than 1 degree
    19/02/2005 4:11:27 AM~!~Temp Info~!~Upstairs/downstairs temperature differs by MORE than 1 degree
    19/02/2005 4:15:28 AM~!~Temp Info~!~Upstairs and downstairs temp differs by LESS than 1 degree
    19/02/2005 4:22:30 AM~!~Temp Info~!~Upstairs/downstairs temperature differs by MORE than 1 degree
    19/02/2005 4:26:30 AM~!~Temp Info~!~Upstairs and downstairs temp differs by LESS than 1 degree
    19/02/2005 4:34:32 AM~!~Temp Info~!~Upstairs/downstairs temperature differs by MORE than 1 degree
    19/02/2005 4:38:34 AM~!~Temp Info~!~Upstairs and downstairs temp differs by LESS than 1 degree
    19/02/2005 4:45:35 AM~!~Temp Info~!~Upstairs/downstairs temperature differs by MORE than 1 degree
    19/02/2005 4:56:40 AM~!~Temp Info~!~Upstairs/downstairs temperature differs by MORE than 1 degree
    19/02/2005 5:08:43 AM~!~Temp Info~!~Upstairs/downstairs temperature differs by MORE than 1 degree
    19/02/2005 5:18:48 AM~!~Temp Info~!~Upstairs/downstairs temperature differs by MORE than 1 degree
    19/02/2005 5:34:53 AM~!~Temp Info~!~Upstairs/downstairs temperature differs by MORE than 1 degree
    19/02/2005 5:51:08 AM~!~Temp Info~!~Upstairs/downstairs temperature differs by MORE than 1 degree
    19/02/2005 6:07:24 AM~!~Temp Info~!~Upstairs/downstairs temperature differs by MORE than 1 degree
    19/02/2005 6:23:27 AM~!~Temp Info~!~Upstairs/downstairs temperature differs by MORE than 1 degree
    19/02/2005 6:39:32 AM~!~Temp Info~!~Upstairs/downstairs temperature differs by MORE than 1 degree
    19/02/2005 6:55:36 AM~!~Temp Info~!~Upstairs/downstairs temperature differs by MORE than 1 degree
    19/02/2005 7:08:44 AM~!~Temp Info~!~Upstairs and downstairs temp differs by LESS than 1 degree
    Attached Files
    Last edited by johnnyt; February 19, 2005, 10:45 AM. Reason: add attachment

    #2
    In V4.32.12 I changed the dwelll and retrigger timing to be based upon elapsed time rather than making the assumption that the timer will provide control to mcsTemperature on 1 minute intervals. I use a 30 second threshold so the time will be a minimum of 30 seconds and the maximum will be dictated by when mcsTemperature actually gets control which should be every 60 seconds, but appears that it can fluctuate. I did my testing on a laptop using the xAP version and there was not too much else running that would cause timing variability. With my tests the variation between trigger events and retriggers was about 2 seconds. I suspect I would of had the same variation before I made the change from interval to elapsed time calculations.

    I also tried to you your data set with two triggers setup and obtained consistent results rather than what you observed. I did evaluate with the V4.32.12. Your behavior looks as if an OR condition is setup on the trigger and the OR'd evaluation is what is causing the over limit condition to trigger. I don't have any other rationale explanation. I did add the same debug logic to the delta evaluations that I had for the simple limit evaluations so if debug is turned on then a trace in the homeseer log will exist in this area of the logic.

    Comment


      #3
      Argh! HS crashed restarting with new mcsTemperature.exe.

      I rebooted my HS server after watching HS hung at "Checking plug-ins..." for a long time on restart after I replaced the EXE. I lost all my devices and events. This happened to me once before last fall. Fortunately I make daily backups and was able to restore config file and device files. Unfortunately the data is a day old so I lost some stuff.

      The only thing I believe I did differently this time from previous mcsTemp updates was "CUTting/pasting" mcsTemperature.exe instead of "COPYing/pasting" it to a backup directory before extracting the new file. I can't see how this matters, unless I happened to be "cutting" the file while it was in use (although I did issue a shutdown to HS before doing this). For what it's worth, I won't be doing that again.

      My HS log shows the shutdown I initiated followed by the shutdown my reboot initiated (I think).

      20/02/2005 7:16:15 PM~!~Info~!~Application shutdown now...
      20/02/2005 7:16:19 PM~!~Info~!~MR26A Interface stopped
      20/02/2005 7:16:19 PM~!~mcsTemperature~!~Closed Comm Port 5
      20/02/2005 7:16:19 PM~!~Info~!~Web Server stopped
      20/02/2005 7:18:46 PM~!~Info~!~Application shutdown now...
      20/02/2005 7:18:48 PM~!~Error~!~Script error in file: shutdown.txt Error: Object variable or With block variable not set

      Given the last entry, I checkd my shutdown. txt file and it's the one that came with HS, i.e.

      sub main()
      ' run any shutdown scripts here using hs.run "script name"
      end sub

      If there's anything that can prevent this corruption of my config and devices files, I would appreciate it.

      Comment


        #4
        My guess is that the registry information is likely different because I compiled it on a new computer that I'm traveling with. If you first unregister the existing one, copy over the new one, and then register the new one. That should eliminate this problem. Normally compiles are done with binary compatibility enabled so registration information does not change.

        It is always safe to update any ActiveX component using this process so the registry will always be consistent with the file you intend to execute. I'm glad you have a recent backup. Many are not so diligent.

        There is a registration utility posted a few places on this board that makes this process very easy. I think it is called RegUnreg.reg and likely will be packaged in a similarly named zip file.

        Comment


          #5
          Michael,

          With respect, your answer to this and other similar answers to previous problems I've reported indicate to me that you appear to:

          1) consider it reasonable for a user of your software (who's not a programmer otherwise he would have just programmed the stuff himself) to be manually registering and unregistering your software, and

          2) consider it reasonable that a user of your software (who's not a programmer, etc.) somehow just know that he's supposed to do that, and

          3) consider it reasonable that a purchaser of your software also be its tester for basic advertised functionality and bug fixes.

          Maybe my expectation that this plug-in was going to do what it said it could do and be as reliable for me as HomeSeer has been was too high, but since purchasing it last fall, I consider the number of bugs I've found, the crashes/data losses I've had, and the testing I've had to do (for you, in my opinion) to be excessive considering it isn't free and I'm using it for very basic advertised functionality (Temp0x sensor readings and forecast information).

          I just thought you should know.

          Comment


            #6
            I agree with you that you have been very helpful and patient working through problems. The information you provide is well filtered to zero-in on the information of interest and this goes beyond what the typical user will have insight to provide.

            You have been using capabilities that others do not appear to use so the burden of discovery has been with you. mcsTemperature is continually changing to add pretty much whatever anyone wants. It is not unusual for new capabilities to break something. It is also true that my testing focuses on the mainstream and does not include the fringes.

            I'm sorry for your negative experience. The registration thing is something that I did not anticipate. Had I though of it before hand I would have provided a warning or instructions. Only after you reported your mishap did I associate it with having compiled the executable on a computer that was freshly rebuilt. When I'm home I do maintain binary compatibility so this is never an issue.

            I'm just trying to do the best I can to contribute to the community. I'll make lots of mistakes as I juggle things, learn a little from these, and hopefully reach the desired result with the help that you and others provide.

            Comment

            Working...
            X