Turn on action logging, and post those...
@bravenel I believe I found a bug in RM
In the rule in the screenshot I wanted to "edit" the ELSE in the rule and change it to ELSE IF, but when selecting Edit "Else" the following screenshot appears to where the only selection is Done with this Action.
So the Else, must be deleted and action must be readded. Not a big deal but thought I'd let you know.
Yes, you can't change what type of action something is with Edit Action. Edit Action allows you to change selections made within the action only. So, yes, to change ELSE to ELSE-IF, you would have to delete the ELSE and insert the ELSE-IF.
Yes, that was my question if you look at my post.
Will this work? Specifically the double nested if statements at the end.
Cant test as there are a whole stack of 13year old girls at my house - doing "homework"
Yes, that will work. You can have Simple Conditional actions inside an IF-THEN or ELSE-IF block.
2 Likes
@bravenel finally remembered to capture log. The on action is happening out of order and firing before the Off. Odd thing is this isn’t happening 100% of the time this rule is executing. Is this fixed in 4.0?
@bravenel curious if you have any thoughts on why my rule above isn't working. This was working in older versions but now the On action is firing immediately versus waiting for the delay.
You may have multiple instances of the rule running at the same time.
That's how you wrote the rule. The delays you have apply to the specific action they are attached to -- ONLY. So it's going to start a timer for an hour and an instant later start a timer for a minute. So obviously the one minute will expire first, and the hour later.
If the power level drops below 2.0, the rule goes false, cancels the hour timer. But, the minute timer is still running and will still turn on the heater when it's done. Meanwhile, If the level goes above 2.0, the rule will fire true and start another one minute timer, even if the first one hasn't finished.
@bravenel This rule used to work and now it doesn't but I rewrote it and tests have been successful.
But this said, my mailbox notification is no longer working where the boolean true action isn't running and it remains false:
I get a log entry that the Wait at Certain Time happened but it never sets the rule Boolean to True:
I even recreated this rule on my dev hub and made the Wait for event to a more recent time and here are the logs:
As you can see there isn't an entry that "this rule" boolean was set to true.
I happen to have my very old test logs on my dev hub and you can see there is an entry for setting the boolean to true from that time:
Have you tried this with Rule 4.0? Is this a 3.0 rule?
Correct it is one I created months ago and then refactored when 3.0 came out to combine two rules into one.
I have not tried with 4.0. I am happy to if you are no longer addressing defects in 3.0.
Please see if that works for you. I will investigate the 3.0 issue, but it's not top of list.
Will do! Thanks for your time.
@bravenel unfortunately Rule 4.0 didn't work either. I saw in the app properties that there was a schedule entry to fire at Noon today to set the boolean to true but its now 12:02 and the boolean is still false. Unfortunately I forgot to turn on logging so I don't have any logs but looking at the boolean it is still false. Please advise.
It would be awesome if there was a button within the rule to reset the boolean so I don't have to create yet another rule to reset it back to true.
You're going to have to post the rule and logs that demonstrate the issue.
I just made a rule similar to yours, and it works as expected.
My mail came super early today so I turned on logging, reset boolean to true, adjusted the reset time and opened the mailbox. Turned on logging and still broken 
Logs:
Rule:
App Settings:
Why do you have Disable with Private Boolean? That's your problem. The rule is disabled. Turn that off. Instead, use a Simple Conditional action for the notification.
IF (Private Boolean True) Notify...
There was a change made to how setting Private Boolean works for **This Rule**. With the rule disabled by the setting of PB to false, it won't run the actions after the wait.
Unfortunately because I don't know any better and this is the way <= 3.0 worked and this is my first 4.0 rule. Again this doesn't work in 3.0 either so folks with existing rules similar will be impacted.
Thanks for the suggestion I will give that a try! Have a great weekend.
@bravenel one more piece of feedback on this change, should the private boolean restriction be removed on 4.0 rules so others won't be confused?
Good question. I'm thinking about that. It made me realize also that Wait for Event is not properly honoring restrictions. It gets a bit subtle how it should work. For example, if a rule is restricted, should the Wait even come back? Also, nothing gets logged when a rule is restricted, so that's a problem since you can't tell why something didn't happen.
One solution would be to just do away with Restrictions completely for 4.0. You can accomplish everything they do with Conditional Actions. This would make it more obvious what was going on, and everything would show up in the logs.
