I have an RM rule for bathroom exhaust fan, objective is to auto de-humidify during showers, as well as eject hot air from (aka cool) the house during hot days (the bathroom is on the top floor where hottest air in the house naturally migrates to, so its the perfect place to do this).
I have had this rule happily running for a couple of years. It leverages conditional triggers and a Private Boolean (PB) to reduce unnecessary triggers and CPU.
I recently updated from 2.4.0.151 to the latest 2.4.1.167 on my C8 hub. Now the rule doesn't work. It typically starts the fan, but the fan doesn't stop. Looking at logs from the app, the conditional trigger isn't firing any more because the PB is not 'turning false' despite the last action being to set it so.
Below are screenshots of the triggers, actions, and app log.
In the app log, I highlighted in yellow the key decision points/actions which operate as expected, and I pointed in red to where it goes wrong (i.e. the conditional trigger does not fire due to PB evaluation error)
I don't see that happening. At 01:14:17.912, the action sets it to false. The next time it's evaluated in the logs is at 01:18:05.726. At that point, we can see that it is false because that evaluation is printed as the "(false)" you see in parentheses after "Private Boolean." There is "true" a bit after that in this line is because it must be in your conditional trigger that Private Boolean must be true. It's not, so the entire condition itself evaluates to false, which is the all-caps "FALSE" at the end of that line.
That being said, this entire rule is fairly complicated, and it may be easier to both write and troubleshoot if you break it into smaller pieces (i.e., multiple rules).
hi there @bertabcd1234 thanks for your response!
i personally think the wording of the log entry is misleading.
take a closer look at the conditional trigger that fails to fire at that point (01:18:05):
"Humidity <= 80% ONLY IF PB = false"
Well PB IS false, as you pointed out it was set at 01:14:17.
I think the 01:18:05 log entry is saying that the trigger did not fire because PB = true, which is logic false assertion of that expression.
re: your point about complexity, yep the age-old discussion of fewer more complex rules vs many simpler ones (that need to be kept in sync if there are any changes to be made) ...a balance that i always debate. first & easiest step would be to halve the rule size by moving the 08:00 and 20:00 time variable adjustments to a separate rule..but then i need to use global variables instead of local ones, which i prefer to only use if really necessary.
regardless, this rule (as is) ran perfectly fine for a long time across many different code bases until this latest HE update. if there's an unnoticed problem in the PB code somewhere, my thoughts are that its better for us all to confirm & rectify it - either that or show me why i've got it all wrong - which i am absolutely open to. 
It's not saying that. As @bertabcd1234 pointed out, the (false) in that log entry tells you the PB's value. The condition is being evaluated to false because it expects PB = true.
I don't know how that could be but it looks like the wrong trigger condition is being evaluated for that particular humidity event (you have two triggers on the same device attribute with different thresholds and opposite trigger conditionals).
Have you tried re-initializing the rule by hitting "Done" ?
EDIT: come to think of it, not sure how your rule worked before but according to the documentation multiple triggers on the same device attribute aren't supported.
hi @hubitrep thanks for the input & highlighting the "multiple triggers same attribute" issue - i hadn't spotted that before, and i certainly have not had an issue with this rule before, for either of the 2 fans I've been using the same ruleset on.
nevertheless, now i know what i've been doing is not supported i guess i need to re-write the rules to achieve what i had before the update.
thanks all.
EDIT/UPDATE: bit the bullet and got ChatGPT to write me an app, took all of 10 seconds. now THATS automation 
