Another "Object reference not set"

[ericg]

I have a simple problem that has cost me way more time than it should have.

I want to beep a horn controlled by a Z-Wave device, subject to the following requirements:

1. The horn beeps only while the state of a controlling virtual device is True.
2. While beeping, the horn sounds for 3 seconds, then is quiet for 17 seconds. The cycle is repeated every 20 seconds while the controlling device value is True.
3. Because the horn is expected to beep only once every few days – perhaps every few months, the event design should minimize system overhead when it is not beeping.

There is at least one simple way to meet requirements (1) and (2), and it works:

What I don’t like about this approach is the overhead. Even if the horn isn’t triggered for the next three months, the event engine still has to check every 20 seconds to determine whether beeping is to be done.
An alternative approach, though it requires two events, ought to add zero overhead to event processing during those same three months while the horn is not needed. The first event is triggered when the controlling device becomes True:

The second event has a trigger condition requiring that the controlling device value is still True. If so, it simply invokes the first event:

To my mind, the alternative design is superior because it respects requirement (3). For three months, the event engine doesn’t have to do anything to support the horn. And it works for a minute or so– until it encounters an “Object reference not set” and quits:

That log message may provide info for somebody, but certainly not for me.

Perhaps I have made a logic error in my alternative design, though it seems quite simple, and it does work for just a little while. But I do believe that, if one’s system isn’t running scripts (as mine is not), then any “Object reference not set” in a logged error message amounts to a confession of a bug in somebody’s software. Am I wrong?

One of the many things that I really like about the HomeSeer forums is the courtesy members extend to one another. From what I’ve seen, flame exchanges are almost nonexistent. On the other hand, I sometimes wonder whether that same courtesy encourages folks to look the other way when bugs should be addressed.

My personal priority wish list puts bug fixes ahead of eye candy every time.

[ericg]

For fun, I built a set of 5 events named Event A through Event E. I chained them by having Event A invoke Event B after a one second delay, Event B invokes Event C after a one second delay, etc. Finally, I completed the loop by having Event E invoke Event A after a one second delay.

Result: The chain executed 2.5 times before it blew up with the same error:



etc.

[Tillsy]

Delayed events make me uncomfortable - HS creates a temporary event to hold that in so the current event can immediately continue on, that temporary event then executes later and then self-deletes, which in theory is cool but I think when you start recursively doing this or if you're firing off other events from within that temporary event that eventually HS loses its marbles a little.

Personally I would suggest a more simpler approach like this...

Event: Pulse MBR Horn While WakeUpEric True
IF "SECURITY ERIC WAKEUPERIC" CHANGES AND BECOMES TRUE
THEN SET DEVICE "Security Eric Wakeup Horn MBR" TO ON
THEN WAIT 3 SECONDS
THEN SET DEVICE "Security Eric Wakeup Horn MBR" TO OFF
THEN WAIT 17 SECONDS
THEN RUN ANOTHER EVENT "Pulse MBR Horn While WakeUpEric True"

Event: Stop MBR Horn When WakeUpEric False
IF "SECURITY ERIC WAKEUPERIC" CHANGES AND BECOMES TRUE
THEN CANCEL ANOTHER RUNNING EVENT "Pulse MBR Horn While WakeUpEric True"

What I'm proposing is once your trigger occurs the first event does the full horn ON, wait, horn OFF, wait, and keeps repeating itself - the second event triggers under the opposite condition and simply aborts the loop. As no temporary events are being fired off this should not crash out over time.

P.S. And still meeting your condition of the events consuming no resources until the condition occurs.

[ericg]

In post #2 of this thread I described an experiment in which I created a loop of 5 similar events, where each event in the loop invoked the next one. Each event in the loop looked like this:



The 5 events executed at one second intervals, completing 2.5 loops before the "Object reference not set" crash.

Taking a cue from @Tillsy:

Delayed events make me uncomfortable

, I rebuilt the loop events to do the same thing in a slightly different manner:



This time the loop ran forever with no problems. I find that interesting.

"Forever" turned out to be too literal. Having neglected to provide a control device to terminate loop execution, I decided to shut it down by disabling one of the loop events:



The loop events kept triggering merrily away. I tried disabling every event in the loop, but to no avail. Am I misunderstanding a basic event definition feature here? I have always believed that if one disables an event, then the event engine won't run it. If this isn't a bug, I would certainly appreciate somebody's explanation why.

Anyway, as I was contemplating a system restart just to stop the loop execution, it occurred that perhaps deleting one of the loop events might work. It did: