Error : Cannot pop() an empty list

Any thoughts on why this error appears for a rule which is protected from running simultaneously through a private boolean:

Here is the rule:

This one is interesting. From looking at your log snippet, it appears to run. Until the rule runs the first time, won't the Private Boolean be false and force the rule to exit? Also, what is the point of the 8 hour delay?

This rule isn't one that would normally have concurrent execution with another instance. Do you have a motion sensor that sends multiple "active" events in a row? If so, I'd recommend seeing if that can be fixed at the driver level instead. I'm guessing what's why you're using Private Boolean here; otherwise, it's hard for me to imagine it happening that often where you'd consider doing this. The error you're getting about pop(), however, is indicative of that problem. Staff have in the past recommended a local variable instead of Private Boolean for this use, presumably because the former saves faster and therefore has a better chance of catching this in a true subsequent, simultaneous execution situation.

If you're just trying to avoid changing the lights after they've already been changed, you could use Private Boolean to track that, too, though I'd probably lay the rule out in a different format (Private Boolean is true by default, and you might have a hard time getting this rule started). I assume that's not all you're going for here since you did say "simultaneously," but I thought I'd bring this up because some people think that delays keep a rule "running" and that future triggers create another instance on top of that (the reality is that the rule will schedule an event to wake up after the delay and you'd normally only have one instance running at a time--situations like I mentioned in my opening paragraph being an exception).

@bertabcd1234 My whole goal of using the "private boolean" was to avoid the possibility of the rule running twice. I see lots of calls where it hits the first line and then immediately exits which is what I intended but never closer together than 15sec apart. I didn't see any occurrence in the log where it triggered so fast back-to-back that it would be an issue of firing the rule before the first exited the first if statement.
image

@Boredom yes, that right. The first time it runs great. Then, after the 8hr delay, it continues execution by dies on the END-IF statement.

The 8-hr delay is to prevent the rule from running every time the motion is triggered. So, for example, if the rule turns on the light (as early as 4am when there is motion) and then some one turns them off. I don't want the rule to turn them on again until the next morning.

Also, I wanted to experiment with the "private boolean" feature for my other more complicated rules.

Gotcha, makes sense. Do you see multiple triggers of the rule at 5:42am this morning? Even if it ran twice in rapid succession, the second run should have continued as well and just set the Bool true...again. Not sure what the failed Pop would have been doing. Did you have any other rules between 5:42 and 1:42 that would have cancelled delayed actions?

@Boredom No - I don't see any instance of it running twice at the same time, or in rapid succession.

YES! I do have another rule which has "cancel delayed actions" and "stop repeating actions" and even "cancel wait". I've been working under the assumption that another rule is only applying those rules to itself (and other running instances of itself). Which certainly seems to hold true because when that rule fired the "cancel delayed actions" it didn't cancel this rules delay (which took the full 8hrs). I realize this rule's delay is not marked cancelable either - but would one rule's cancel effect other rules?

It shouldn't. They should each be independent. One should not cancel the other. I have no clue how the list of delayed actions is managed. Was wondering if there is a counter that may not be updated properly. (Purely a swag....) I see it occasionally as well. I'm going to have to dig through my logs to see if I am trying to cancel actions that were never created.

@bravenel any possibility a cancellation of actions could throw off a running count of delayed actions, thus attempting to pop something that isn't there? (Apologies, understand that I'm really just making $&^# up at this point.)

Edit: Dug into my logs, found an instance where I had a door contact throw a few open/closed/open/closed messages, which queued four instances of the same rule. (What you're trying to eliminate.) Interestingly, all four ran their delayed actions, with each one throwing the pop() error.

You would have to show the full logs of what is happening in order to give you a more accurate picture.

But regardless of what the sequence of events that caused it, the solution is the same. You have to rework the rule to fix the issue.

What I don't understand is why you have set the rule up this way. If you have a motion sensor in the den, why do you have to do anything but motion control of the lights. I'd be very interested to hear what you are trying to accomplish with this rule. Because, as i see it, the lights are going to come on every day at 6am. Then do nothing else all day long. Absolutely nothing. The trigger by motion any other time is going to do nothing but set the PB alse and then true because the light will already be on.
It will do nothing but schedule another execution of the same rule. Then at 11pm it will turn the lights off.

I would like to hear, in words, what you would like to do, then maybe we can help you get a rule to do that.

I would recommend creating a simple Motion Lighting app to turn the lights on when there is motion and then off after a timeout after motion goes inactive. That is how Motion Lighting is typically handled. Why bother turning the lights on a specific time and also having the rule triggered on motion? it doesn't make a whole lot of sense.

That actually makes no sense at all. The rule will be triggered every time motion goes active, regardless of whether there is a delay or not. A trigger event means the rule will fire. Simple as that.

Yes you do...that's what a POP error means.

Thanks @Boredom. Reading your edit and from my understanding on the limitations of the RM, that would be an expected error right? It doesn't like when there are multiple instances of the same rule all in a delay state.

But, in this case since the rule shutdown on the first line every time it is triggered, I didn't think it would be an issue.

I switched it to a local variable to see if that fixes it (long shot, I know). I like the local variable better anyway because if it's out-of-sync then I can just set it back easily through the UI. I didn't see a way to do that with the private boolean.

Good luck. Was interesting seeing how the triggers and execution occurred in the instance I dug up from my logs. Looked like a bad sensor for mine.

1 Like

@Boredom, I think I'm also going to change the delay from 8hr to 2hr as well (since 4am-6am is all I really want to block) - I had a bigger value initially, hence the 8hr delay. I wrote the rule this way to test out the Private Boolean for future complex rules, so that didn't really work out. :slight_smile: I'll report back tomorrow how the modified rule turns out. Thanks for you help!

image

Thank you for your post. You have sent me down a bit of a rabbit hole. I happen to have a few rules that are motion-triggered during certain times. I am going to try just pausing the rule at the end of this time, resuming once the time period starts. For example, I have a motion sensor on my front porch that will turn on multiple lights if triggered between 11PM and Sunrise, turning off after a delay. There's no reason to waste any processing outside of that window of time each time someone walks up. Just need to make sure that the lights turn off at sunrise, when the rule is paused. I'd guess the delay wouldn't fire if the rule were paused.

No, that is incorrect. That is how delayed actions within a rule get canceled. You are not understanding the difference between a scheduled task an app that is running. When an app is waiting on a delay it is not active in memory and running.

Apps cannot be in a "delayed state". They have a scheduled task that will wake them up when the delay is over.

Surly once your PB or your new LV is false that's it the rule will never run again. This is because as soon as it's triggered, you have then asked it to exit, so it won't complete the rest of the rule.

Well - looking at the full log it looks like there are motion events that are happening twice (in quick succession). Even though there is not overlap of the TRIGGERED long entry, maybe all those extra log entries are causing the RM to get messed up.

NOTE: changing from PB to variable didn't help (as expected), changing from 8hrs to 2hrs didn't help (as expected)

The interesting thing about all those duplicate log entries is that when I look at the device events, there are no duplicates:

@BorrisTheCat that is correct. The rule works great, it's just that POP() error at the end (which prevents it from setting the PB back to true) which is the problem. The whole purpose of me adding the PB was to block multiple simultaneous execution, but... somehow things are getting gunked up.

Sounds like what I mentioned at the beginning:

This was common with some Z-Wave contact and motion sensors. I think many of these were addressed in the driver a few firmware versions ago with an option to suppress duplicate events (basically, the sensor was reporting the event in two different ways, and Hubitat was parsing them both; this will cause it to ignore one). Before this happened, a local variable (not PB) was the recommendation to work around it in a rule. That may still work here if you can't do it there. If it's not causing problems, you could probably just ignore it, too--this was causing problems for things like a rule that sends a notification as soon as the sensor was opened. Your existing solution does stop the rule from changing the lights for a while once they've already been changed if that is your goal (though you may want to move your "off" stuff to a different app/rule--what happens if motion becomes active at 11 PM?).

The confusion is that when I look at the motion sensor "events" there are no duplicate events. (See above screen shot) Every time it reports motion the rule has a log entry for triggered. All those other "motion is active" entries in the log don't correlate to the events from the device event list. So, from the event list it seems the motion is perfect (and the triggers certainly correlate to that).

"Nothing" is my goal - The rule is built to only turn on the lights one time and only during a 4am-6am window and then off at 11pm. I don't want the rule doing anything outside of that. So, the rule is working perfectly from a logic standpoint, just the POP() error which is a problem for me.

Then create two rules. One to turn them on in that window when motion is active and then one at 11 pm to turn them off. There is no need to do this all in one rule with multiple triggers and delays and private boolean. There simply is no reason to make it that complicated and cause the errors.