[Released] Rule Machine 3.0


Did you look at the fan events? This works for me, can't reproduce a problem with set fan speed.


It's hard to tell when took place after I created this rule with the timestamp being inaccurate, but after I noticed it didn't come on I tried changing the rule using it as a dimmer value of 25, to see if anything was different, and one of the "low" was me manually turning it on to make sure the device was working.


Could it be possibly the rule is sending the action to parent device and not the child "fan itself" part? This is a Hampton Bay Fan Module which has the parent and 2 child devices for each light and fan?

EDIT:....Think I just found my issue, as I just typed that and seen what was selected.....sorry for wasting your time, I will change that and if it doesn't work I'll let you know.


Here is my rule that is generating the error above.


I have confirmed this is a bug, found the culprit, and fixed it. Will be in the hot fix release, probably tomorrow.


@bravenel, I seem to be having a problem since the latest hotfix release as well. A rule (see below) was working just fine Friday and now fails (it doesn't run weekends so I didn't catch until today) with a ClassCastException. I haven't decomposed it to see which part (and have to run to work now) but figured I'd share now in case it rings a bell and can make it into the upcoming fixes.

I did just try editing it and chose to edit the first "Fade up" action since I know you changed some lighting stuff... that may be the culprit? trying to edit it has emitted an error and the rule editing is now stuck with this error:

app:9292019-06-10 07:06:28.315 am errorgroovy.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)

Logs from the rule running:

The rule:


Any update on the hotfix for simple condition actions? Could really use it as soon as practical...


Should be today.


Not sure what's going on here. There was a bug reported earlier with fade dim over time, that has been fixed but not released yet. I just edited a fade up action with no issue. So perhaps we should revisit this after the hot fix release comes out, to see if you still have the issue or not.


sure, sounds good. Assuming it's out today I'll try and apply tonight and then edit the rule and see what happens. If it's still broken, I should also have time to recreate the rule and see if it works then (I sort of suspect it will); maybe somewhere something changed underneath and it's in a bad state after that last release?


I don't think so. Not sure why you're getting the error editing it. But, as you suggest, recreating it may clear it all up. Getting the error when the rule runs is most likely fixed, and appears similar to the other bug reported.

split this topic #488

28 posts were split to a new topic: Using RM with Alexa


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.


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.