Yes I have been able to consolidate some rules as well although some I appreciate to keep separate. I learned keeping some things separate in simplify was mandatory because there was no good way to cancel a delay in that system ... or at least I never figured out how to do it.
Anyway, sometime separate is easier to keep you sane.
Will this work - moving from Rule 3 to 4? The purpose of the rule is not to have the lights turning on/off if the lux hovers around 150. I want a delay (short for getting darker, longer delay for getting brighter)
Rule 3
Rule 4 (the 10 second delay is so as to not cancel the newly cancellable delay)
I'm having problems with a rule that used to work fine. The problems started with the 2.1.3.120 update. I thought it was just a problem with the cloud endpoints not working, but the problem is continuing with 2.1.3.125.
At bed time, I tell Alexa goodnight. Alexa turns a switch off that triggers the Mode Manager to change the mode to Asleep. That triggers my "everything mode change" rule (RM4). Here's the relevant snip:
Before 2.1.3.125, HE didn't see Alexa throw the switch, so the mode never changed.
Last night, after 2.1.3.125, the rule is getting hung up on the Wait. Even though all 3 of the motion sensors are inactive, it does not move forward and the last two action are never performed.
I changed the rule to add a time out as below. This worked, but only because the timeout triggered.
As I mentioned, this rule was dead solid before. I'm not sure if something changed with the Wait action? If the rule hits a Wait that's already true, shouldn't it continue?
And here's a snip from the rule after I added the timeout and changed the mode back to Asleep, showing that it's the timeout that actually made it continue:
In the top log you show, Wait for Condition, the condition is FALSE. So, after that something has to happen for it to become true, for the Wait to end.
In the bottom one, you have Wait for Events. The same idea would apply here, that something has to actually happen for it to end.
Yes it was false, but you can see from the motion sensor logs that they all did become inactive very shortly after, yet it didn't continue. Same for the bottom one. They were all still inactive because they had never been active since the first snip.
@bravenel, I posted this further up, but it got lost in the mix, and the Rule 4 rule didnt work this morning. Can you please check logic?
Will this work - moving from Rule 3 to 4? The purpose of the rule is not to have the lights turning on/off if the lux hovers around 150. I want a delay (short for getting darker, longer delay for getting brighter)
Rule 3
Rule 4 (the 10 second delay is so as to not cancel the newly cancellable delay)
Yeah, I was coming to that conclusion. I can see now what the problem was with mine. The Lux sensor reports in every 10 mins. The 10 minute (plus 10 seconds) delay resultsed the newest lux value which was also >150 cancelling the delay from the previous reading, which meant that the GV did NOT change.
@bravenel, It seems that it's not possible to use a simple condition with the condition being private boolean of a different rule. I want to set the PB of the other rule, but only if the PB is false. Is that by design?
Yes it is. Only a the rule itself can read the state of the private Boolean. Why don’t you use a global variable for that? Global variables can be read and set by any rule.
Even though I am not sure why you want to do it that way. If the PB is true, what is the problem with setting it to true again? It won’t invoke a change...