[Released] Rule Machine 3.0

Try it without putting the delay on the action, but with Delay Actions instead. Read this documentation about delays:

Delay per action and Delay (Pause) all actions

There are three types of delays included in Rule 3.0: 1. Each individual action can have its own delay, which for Rules may include a cancel-on-truth-change option. 2. All actions can be delayed, effectively pausing the action execution for some amount of time. 3. All actions can be delayed for a period of time that depends on the current mode (Delay Actions Per Mode).

These are further described below.

Delay per action

Each action you define can have an optional delay. These delays can be defined with hours, minutes, and seconds. Seconds can have decimal fractions, allowing millisecond resolution. In a Rule, delays can have the option to be cancelled in the event of a change of rule truth. It is important to realize that the delay assigned to an individual action affects only that action, and not subsequent actions. Any subsequent action is executed immediately after the delayed action starts its delay timer -- it doesn't wait for that delay timer to run. When that delay timer expires, the delayed action is executed (unless the delay was cancelled).

Delay all actions

It is also possible to delay all actions (also with optional cancel). The script of actions runs sequentially when the rule runs, with each action happening in order. Actions with delays start their timer, which can vary for each action, and the next action in order then runs. By using the Delay Actions action the entire script can be 'paused' by a delay. This feature can also be specified on a per mode basis, so that the time the script is paused varies according to the current mode.

As a consequence of these new features, some of the actions in Rule 2.5 have not been included in Rule 3.0. Specifically, those actions which incorporated a delay, or a delay with cancel, have not been included, since now every action can have such delays.

FWIW, this error still manifests in the update.

groovy.lang.MissingMethodException: No signature of method: java.lang.Long.getAt() is applicable for argument types: (java.lang.Integer) values: [0] Possible solutions: getAt(java.lang.String), next(), putAt(java.lang.String, java.lang.Object), wait(), grep(), getClass() (selectActionsTrue)

I recreated the rule and all seems ok again. Not sure what happened to land me in that state but if I figure out how to reproduce it (assuming it shows back up), I'll re-post.

Wait for condition seems to be getting confused. :slight_smile:
I am waiting for a switch to be toggled by another rule I'm calling.


Everything is working great until 11:50:55.913 when 'Wait over' wakes up again and begins re-executing the code it already executed.
Did I do something wrong to cause this?

Also, when reading code there is no way (that I know of) to tell if a Wait is a 'Wait for Event' or Wait for Condition'. It would sure be nice if the text made this more clear.

Thanks again for all the work you have put in to RM. And 3.0 is even much better.

I just noticed that if I toggle ' Thermostat Off Complete' on an idle system, then everyone who has previously waited on it wakes up and begins executing the code after the wait!


COOLEST BUG EVER!! :smiley::grin::smiley:
(unless, of course, I somehow caused it)

This looks as though the subscription associated with the wait is not getting cancelled when the wait is over. You could verify this by looking at the app status page Event Subscriptions. I will look into it also.

What kind of device is Thermostat Off Complete?

Update: Found the problem with this. A fix will be in the next release.

1 Like

Its a virtual switch, if that still matters.
Thanks for really fast (as usual) turnaround.
Any idea when that will be? Or am I being pushy? :grinning:

The fix has been released. Hub Update 2.1.1

I have upgraded to and it appears I am still having the same problem with toggling ' Thermostat Off Complete' and everyone who has previously waited on it waking up and beginning execution of the code after the wait.

I like the sound of this.
Without me looking, as I'm out at the moment, can the 'wait for event' have a time limit attached to it?
So it's something like.
Wait for event for 10 minutes.
Or maybe.
Wait for event. Cancel after 10 minutes.
Like I say I'm out a don't want to VPN in to have a look.

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.

1 Like

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.