[Released] Rule Machine 3.0


hmm. I don't think "wait for event" allows for a delay, but i'm running .116 right now, so that is all messed up right now anyway.

I suppose you could always put "stop actions of these rule" prior to wait for event, and then put a 10 min delay on that (so the timer starts when the trigger fires and doesn't wait until after the wait command). not sure if that would work, would need some testing.


OK thanks.
Will have a play with a basic rule when I get home and see what I can do.
Cheers again.


OK, Am I the only one still having this problem?
I know.. Patience in not my strong suite.


Would you care to show what you're having a problem with?


Sure. Yesterday I posted a problem with the Wait for condition and posted rules and logs.

[[Released] Rule Machine 3.0]

You said it was found and fixed in 116. I have installed 116 but I am still having the problem.
When the virtual switch I am waiting for becomes true, ALL of the rules that at one time waited for this switch wake up and start executing after the wait.

I guess my post wasn't as clear as I'd thought.


OK, this was fixed. But you need to do a little bit of diagnostic research. After the wait condition is fulfilled, it should execute the actions after that. But then subsequent events that make that condition true again should not (assuming the rule itself doesn't run again). So what you should do is look at the App Subscriptions after the wait condition has happened, and see if the subscription is gone. It would be a good idea to look at them before the wait condition is fulfilled, and you should see the subscription in question.

If it doesn't go away as I just described, I will need to see your logs again and the before and after app status pages showing the subscription.


So you mean to go to the app, click the gear in the top right, scroll down to the middle of the page at ' Event Subscriptions' and look for something new. Right?
I had no idea that was there, way cool.
First thing tomorrow.


Here is during the 'wait for condition':

and here are the afters:



The logs look identical to the ones previously posted at:


Hope this is what you need. If there's anything else, please let me know.
Don't know if it's important but, when I changed the code in all three rules to wait for the actual thermostat mode to change to off instead of waiting for a semaphore (virtual switch) the problem doesn't occur. No idea why.


Thanks, that's helpful. It looks like the unsubscribe must not be working for the switch, while perhaps it is for the thermostat state. And, actually it could be that the subscribe is wrong. I will investigate. There must still be a bug about these, at least for switches.


Are these from Wait for Condition? or Wait for Event??


'wait for condition'

Good hunting!
And, thanks again for the quick response.


Thanks. The subscriptions you had were for Wait for Event. That's a clue for me to dig further into. This has made me realize that it needs to be visually more explicit which sort of Wait it is, as for now they look identical in the logs. One possibility is that the subscription side of the Wait, that which happens when it begins, erroneously subscribed as if it were Wait for Event, and then later when it went to unsubscribe, it attempted to unsubscribe from the event that would have been subscribed properly for Wait for Condition. The result of that mistake would be consistent with what you've shown. Tomorrow I'll dig into that to find the problem.


I presume that means you guys are working on a fix for whites? Man, I’m getting som funky colours when I select different whites.


Last week I was able to put a 'Simple Conditional Action' as the then part of another 'Simple Conditional Action' but now I can't. Don't know if this is intentional or not. Here is what happens when I try:

Note that the only option I have at this point is to cancel the action.


That should never have worked.


This has been driving me nuts so I thought I'd let this drive you nuts for a while. :wink:
I have a trigger named Morning that turns some stuff on/off, runs an action that turns off the thermostat, waits for it to complete, sets two global variables and then runs the action 'Thermostat SetTemp'.
This action is never executed. Not only does it not show up in the log but I checked its event log.
Instead, the log repeats:

Wait over: variable HeatSetpoint set to 77 by Morning TRUE

and the two Sets 42.5 times and then nothing. It never executes any code after the Run.
And, I NEVER do a wait on a variable being set to 77 in Morning or ANY code in ANY rule.
Driving me crazy for many hours.
Here's the rule and log file:

Hope you can help.
Thanks again for all the hard work you've put into this and if there's anything else you need, please let me know.


So, the way I would debug this is to simplify and be sure that key parts work as expected, or not. For example, I just created a simple set of actions, like this:

The rule "thermo off" turns off the thermostat called "virt therm". My goal here is to verify that the Wait for Condition works as expected. Here are the logs from it running:

These show that everything happened pretty much as expected, although the thermostat state turned to off before the Wait for Condition even had a chance to wait. So next, I'll intentionally delay that happening in the rule called "thermo off" so there is a real check of the Wait for Condition working correctly.

Here are those logs, again with everything working as expected:

Then I'd move on to test the next part of your rule, but I can't tell what it does. Presumably CoolSetpoint and HeatSetpoint are global variables. What does "Thermostat SetTemp" do?

Why are you doing this in such a convoluted manner? Why are you using a separate rule to turn off the thermostat, instead of just turning it off? Same question wrt setting its setpoints? Why introduce all of the waiting for it to be set? Why the Stop Actions? There is nothing to stop.

What are you actually trying to accomplish? It appears that you want to turn some things on, turn some things off, and set the thermostat. Is that not just directly possible?



Should this rule work? Specifially, the double if statments. The last if statement (off and evening did not work today......every other IF statement has worked so far - away, day and night).

(This is a triggered rule, which sucessfully triggered, but did NOT change mode)


Your problem is the two ELSE-IFs in a row with the same condition. Of all of the ELSE-IFs after an IF, only one of them is going to run. The first one did run, although the simple conditional action after it was false so didn't do anything. The second one, the one you have highlighted, did not run because the first one did.


@bravenel this rule isn’t working 100%. The final on is not working and the switch stays off. This used to work in earlier versions of RM