No announcement yet.

Unexpected "Last Value" Event Trigger Condition

This topic is closed.
  • Filter
  • Time
  • Show
Clear All
new posts

  • Unexpected "Last Value" Event Trigger Condition

    I'm having a problem, and I'm not sure which forum should post it. If this is the wrong one, please forgive.
    I'm having an event triggered when I don't think it should happen. Here's the event:
    Click image for larger version

Name:	2019-03-21_14-04-44.jpg
Views:	1
Size:	74.1 KB
ID:	1294110
    And the log entry:
    Click image for larger version

Name:	2019-03-21_14-01-48.jpg
Views:	1
Size:	51.0 KB
ID:	1294111
    I stipulate that all of the trigger conditions except the last one were satisfied. I think the last condition was not satisfied, and therefore the event should not have run. At sunrise today, my OMNIPro II Area Mode Home status did change, as expected, from Arm Night Delayed to Disarmed. I have confirmed this by inspecting the relevant device history chart.
    So what happened? Do I misunderstand what "last value" means, or is this a bug somewhere? Any help will be sincerely appreciated. Thanks.

    Current Date/Time: 3/21/2019 2:07:44 PM
    HomeSeer Version: HS3 Pro Edition
    Linux version: Linux hometrollerSEL 3.16.0-031600-generic #201408031935 SMP Sun Aug 3 23:56:17 UTC 2014 i686 i686 i686 GNU/Linux System Uptime: 21 Days 22 Hours 21 Minutes 13 Seconds
    IP Address:
    Number of Devices: 194
    Number of Events: 51
    Available Threads: 199
    HSTouch Enabled: True
    Event Threads: 0
    Event Trigger Eval Queue: 0
    Event Trigger Priority Eval Queue: 0
    Device Exec Queue: 0
    HSTouch Event Queue: 0
    Email Send Queue: 0

    Enabled Plug-Ins Arduino Plugin BLLock Device History EasyTrigger OMNI Z-Wave

  • #2
    I'll have to do some more experimentation, but I think the issue is timing. When something causes the "Mode" device to change, the fact that it's "changed" is broadcast throughout HomeSeer (to trigger events, to notify plugins, etc.). So before it changes, I know the current mode is "Night" and the previous mode was "Disarmed" (or whatever). Then when it does change, this event fires AND evaluates the conditions at the same time I'm getting the message that the new current mode is "Disarmed" and saving the previous mode as "Night".

    So you may need to change your trigger to "has been for..." so that they don't fire at the exact same time.


    • #3
      Steve, your argument is persuasive. FWIW, the unmodified event did not trigger this morning, under identical ephemeral conditions. That seems to support the hypothesis of a race condition.
      I wasn't sure what you meant by: So you may need to change your trigger to "has been for...". I made the following modification:
      Click image for larger version

Name:	2019-03-22_11-43-37.jpg
Views:	1
Size:	75.1 KB
ID:	1294246
      I hope that was consistent with your suggestion.


      • #4
        Yes, that's what I meant - I used the terminology from the conditions, not the trigger in my verbiage, which is why it didn't line up correctly.


        • #5
          Problem Update: I implemented the 3 second trigger delay shown in my March 22 post above, and the event still triggered yesterday morning. So I increased the trigger delay to 30 seconds, and this morning the event still triggered when it should have not.

          For a while today I thought that the problem might be related to sloppy synchronization between my OP2 system and HS3. Time is synchronized daily with an event that keeps the two clocks synchronized within about one second. (Thanks, Rob Mason!) But the change of Area Mode Home from Arm Night Delayed to Disarmed is triggered by the OP2 computation of sunrise time, which differs from the HS3 computation.

          (Historical note: I know accurately the latitude and longitude of my home. Although HS3 will allow me to specify any values I want, PC Access will allow me to give OP2 only integers for lat/long. Thinking that system agreement is more important than absolute accuracy, I originally set up the HS3 numbers to match OP2. It turns out that the sunrise (and sunset) times still disagree by roughly a minute. I assume that there is a discrepancy in the two computation algorithms.)

          Closer inspection suggests, however, that sunrise time computation has nothing to do with this problem. OP2 may have initiated the Disarm mode change nowhere near actual sunrise, but (in latest event definition) the AND IF "last value" condition still had 30 seconds to catch up with the OP2 security mode change.
          Click image for larger version

Name:	2019-03-24_9-22-41.jpg
Views:	1
Size:	74.7 KB
ID:	1294736
          Conclusion: I'm still stuck. I have no idea why this event is triggering.


          • #6
            Possibly helpful information:
            The device chart recognized the mode change at HS3 time 7:08:00:
            Click image for larger version

Name:	2019-03-24_10-59-10.jpg
Views:	1
Size:	17.5 KB
ID:	1294740
            The unwanted event ran about 30 seconds later:
            Click image for larger version

Name:	2019-03-24_9-08-26.jpg
Views:	1
Size:	92.7 KB
ID:	1294741
            (The unrelated "Lighting Sunrise Test" event was triggered when HS3 detected sunrise.)


            • #7
              Hmmm... ok, more investigating needed here! I'll let you know as soon as I figure something out.


              • #8
                Steve, I have some more information that you might find helpful. A few minutes ago I conducted an experiment that produced an interesting result.

                I created the following test event:
                Click image for larger version

Name:	2019-03-27_13-05-50.jpg
Views:	1
Size:	62.0 KB
ID:	1295565
                And at 1:05:00 PM the Living Room Reading Lamps came on.
                Now, this is what the relevant chart data looks like:
                Click image for larger version

Name:	2019-03-27_13-08-29.jpg
Views:	1
Size:	63.7 KB
ID:	1295566

                The chart data is unquestionably correct. During the night, my Omnipro II home security mode was Arm Night Delayed, and at 7:03 AM today the mode changed to Disarmed. There have been no security mode changes since then. I can verify this a couple of ways, so I consider the state changes a fact that is supported by the above chart data.

                Because the lamps came on, both of the AND IF conditions in the test event had to be satisfied. But I wanted them not to be, because, in my mind, the "last value" was Arm Night Delayed.

                My hypothesis is this: Is it possible that you are getting the "last value" from the first row of your device history array, rather than the second? (See the red arrows.) If so, that would account for the test event turning on the reading lamps.


                • #9
                  Found the problem - the first time you ask about this, I look it up from the database. After that, I cache the "last value" after each change, and I was (stupidly) caching the "new value", not the "old value". The new version has been submitted to the updater, hopefully it will show up for download tomorrow!


                  • #10
                    Problem SOLVED! I have installed and tested Device History The issue addressed by this thread no longer exists. Thanks, Steve.


                    • #11
                      Glad to hear it. Closing this thread since it's resolved!