Private boolean won't return to false after delay

I have a rule that triggers on the power level of my dishwasher starting, and then sends a notification after delay.
I cannot set it to notify on power level drop, because it fluctuates quite low during the cycle. After it finishes, it does some drying while it waits to be opened, so the power doesn't go as low as those other parts of the cycle.
I added a private boolean to stop it sending multiple notifications, but the problem is it never sets the private boolean back after the delay.

There is also the error Cannot pop() an empty List, but I'm not sure this is related, since the logs say they're setting the private boolean false, then the following notification works. (I see from this thread that error is because of the rule being triggered multiple times - but that's exactly what I was trying to stop with the private boolean! There doesn't seem to be a way to get it to work listed on that thread though?? other than remove nested IFs, which I don't have.)

So, why doesn't my private boolean return to false OR how else can I stop the rule from triggering multiple times?



(in between were many logs of the rule being triggered again, but all said "(skipped)")

It looks ok to me, the only thing I can offer is I quit using the private Boolean. I tried using it serval times and I had the same kind of issues. I switched to creating a local Boolean and they worked.

You already answered your own question: because it never gets to that code due to being retriggered. Each time a rule is triggered Waits are cancelled. You could use a separate rule triggered by the power dropping below 20.0, and use it to set Private Boolean to False for the first rule.

I haven't tried that, because I thought each trigger of the rule would have its own local variable - so I wouldn't be able to use that to see if the rule was already triggered... Are they local to the rule then, not each instance of it running?
EDIT: I've changed the rule to try using a local variable instead - will post back next time it runs with the results :slight_smile:

The logs say it does trigger that line at the right time - it just doesn't seem to work. The notification following that line works correctly, so it's definitely running that part of the code.

Hmmm... I need the power drop part to wait the 2 hours before triggering though. I'll see if I can make that work with two rules, and two private booleans (setting each other's)...

Its just a Boolean variable local to that rule. There really shouldn't be any difference, but I had some issues using the private Boolean in the past. Switching to a local seem to work, it was probably something I was doing wrong, but it worked, so I left it alone.

You say your rule isnā€™t working right, and you say that the private boolean didnā€™t get set to false. But the logs show that it did get set to false. If it stayed true, your rule would never run again, because your ā€œIFā€ statement would stop it. You would just see a bunch of skips in the log, and it would never run any of the lines. So the boolean is going false. You can check that by looking at the ruleā€™s status page. Click on the gear next to the ruleā€™s name. On that page, under ā€œApplication Stateā€ look for ā€œPrivateā€. It will show true or false.

Regarding the line that waits for the power to drop below 20 you saidā€¦

The logs show that when the 2 hr and 5 minute delay was done, it did process the wait line - but at that point the power level was already at 5, so it didnā€™t wait for anything, the logs say ā€œ(not waiting)ā€.

It did the same thing on the line that looked for presence. The presence was true so it didnā€™t wait. So the rule worked ok, except at the end it got a POP error. That is from all of the re-triggering. When the boolean was true, your IF statement successfully kept the lines between the IF and END-IF from running, but the re-triggering still messed up the rule and caused an error.

So your rule itself is fine, and it is working ok. You donā€™t need to do anything with the part that waits for power to go below 20, you just need to stop the re-triggering when the power is going over 1000.

That is real easy with a real short second rule. Just a one-line action to set the private boolean of your main rule to True.

Dishwasher Trigger
Trigger:
Power level of dishwasher reports > 1000

Action:
Rule Boolean True: Dishwasher Done

Now change your main rule, you wonā€™t need the IF statement now.

Dishwasher done
Trigger:
Private boolean reports true

Actions:
Delay 2:05:00
Wait for condition: Power Level of Dishwasher is < 20
Wait for condition: Presence Comet present TRUE
(send notification here)
Set Private Boolean False

No matter how many times the dishwasher power level triggers Dishwasher Trigger, once the PB is set to true it canā€™t be set to true again until it is set to false. So that means only one trigger for the main rule, and when the dishwasher is done, the main rule sets it back to false, so it can be used the next time you run the dishwasher.

One word of caution. Whenever you are setting something in a rule that can trigger that same rule, you need to be very sure there is some sort of delay. If you make any changes to this that would set the PB false and then back to true without any delay in between, then you will get a runaway superfast loop and it will lock up your hub. May or may not be recoverable.

1 Like

That's what I said - the logs say it did (or they show that that line ran), but it didn't ACTUALLY happen.

Yes, that's my exact problem - the rule runs once, and never again :laughing:
I have had to manually go to the rule machine & set it back to 'false' for every run.

It's not. I could post a screenshot where it's still 'true' after the rule completes, but it looks like you've already decided I'm just plain wrong, so I don't think that will change your mind either...

Thanks for the example - I will be trying the two-rule method if the change to a local variable doesn't work next time it runs :slight_smile:

Update: This worked, thankyou!

With the exact same rule, but using a local variable instead of the private boolean, the variable returned to 'false' correctly after I received the notification. So there's definitely something broken with the private boolean.

(note: the 'cannot pop() an empty list' error still happened, so that wasn't related).

i think the issue is the error you got for whatever reason.. not that private boolean is not working.. i use it here c7 latest f/w and it works fine.

No, I said I still got the error when it worked. I am also on the latest firmware (though not C7).

Your rule does not look like it would trigger multiple times while waiting for the delay, which is what apparently causes that specific error (see my first post).
Perhaps the private boolean does not like triggering multiple times either.

It's an issue/bug if the exact same rule works for a local variable, but not for a private boolean variable.

I agree with Kahn-hubitat. Private booleans work fine. But apparently when you get an error in a rule, the rule stops and doesnā€™t completely finish whatever it was doing. Different types of variables are handled by different parts of Rule Machine. So using a global variable worked ok, but using a private boolean got messed up by the error, since it may be handled by a different part of Rule Machine.

Not sure its a good idea to continue to run a rule that is getting an error. It might not hurt anything, or it might not clear out memory or something in the database correctly if it stops with an error.

The two rule method I suggested before will work, but I tried something else that worked. Just exit the rule if the private boolean is true, using a ā€œsimple conditionalā€ IF statement. Then you donā€™t even need the other IF - END-IF lines.

This works with no errors, and it uses the private boolean.

I used a button to repeatedly trigger it while it was in its delay, it just exited, never got any error and did set the PB to false. Stick in your notification right after your second wait, before you set the PB back to false.

yes it triggers multiple times.. in fact the time to check the ups for runtime gets more often through the app when on battery.. the timeout is 30 minutes but currently checks every 10 minutes so i can shutdown the hub before the battery runs out. The app changes the UPSstatus to unknown when running the check so it case it fails it is visible then back to either online or onbattery, I may change that so as NOT to trigger the rule as often to decrease load on the hub but that is the way it works currently.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.