Rule machine - as per the app developer, this app is no longer available for new installs, distribution, or support

When there is a will, there is a way! :smile:

All good suggestions, but this one continues to throw an UndeclaredThrowableException through any of those paths (but thanks for the suggestions, now I know all of the different paths!)

I’m surmising here (educated guess from a still-sometimes-engineer) that all of those paths lead back through the same set of code for deleting these objects from the graph, and that the problem is inherently deeper than what it appears.

Part of me is hesitant to actually file the ticket, because (knock on wood) my system (with all of my other normal rules, including the duplicate working one I created for this bad one) has been really stable since the firmware upgrade and DB migration. I’d hate to temp fate, but the OCD in me is annoyed that I have a hanging rule that’s out there… :smile:

1 Like

Ok looking for some general guidance on creating a rule.

I would like to turn on a light when motion is detected, and turn it off again after a specified moment of time if the motion has stopped, this bit i think i can figure out myself.

However i would like to stop this action from happening if the switch/light is already on.

How would i go about doing this?



Don’t you just need to have the switch check as a condition?

1 Like

We are all OCD and paranoia patients here, so don’t feel bad :smile: geeks cannot be geeks if they are not perfectionists. And ST feeds us good!

1 Like

This looks great but I’m not a developer and feel I need the for dummies step by step guide with video. Any others start from my level and get ramped up?

Update: Got this working based on FAQ: An Overview of Using Custom Code in SmartThings - thanks @JDRoberts

1 Like

You need to be able to describe what you want to happen, under what circumstances or conditions. If you can say this in words, then it’s easy to create a Rule to match.


I’m having problems with a rule that uses both pending off (cancel), and switch to disable rule. Basically, at the first rule truth lights are on, but then they are never turned off…

My guess is that due to switch to disable rule (in my case on), and pending cancellation, the rule understand the light is on, and therefore don’t listen to the pending cancellation.

Is this correct?

Is there a way to trigger an action based on the fact motion is not detected for a certain period of time?

I want to change to a Sleep mode when motion has not been detected for 5 minutes between 11:30pm-1am.

I see there is delay off, but for light switches only.

@bravenel, I love this smart app. It’s amazing. I have a tablet mounted in my wall that runs a webapp I call jarvis, Like Smartiles but built by me. I want to be able to use RuleMachine in Jarvis. This would require adding an API to RuleMachine and or Rule. I was just gonna fork and add it myself. Are there any plans for this? To rephrase, I want the RuleMachine logic and abilities but with a different interface other than a using the Smarthings app.

I contacted ST support. They did something at the backend and the errors went away thereafter. These are related to errors with th scheduling api’s

Thanks @RBoy I think I’ll have to go that route as I’m not able to remove it through the IDE.

You should have an option at the top of actions ‘Delay These Actions.’ Within there is the option to cancel on truth change. If you do not find the option you are on an old version of Rule Machine and should update.

1 Like

@bravenel I’m working on an Ecobee thermostat Device Handler. One of my users is trying to use Rule Machine to turn on the fan when there is a big temp differential.

I have a question about the Thermostat Fan Settings rules. For the modes in the rule you are using fanOn and fanAuto and then you pass these to setThermostatFanMode. However, fanOn and fanAuto are not valid parameters for this function per the capabilities definitions:

The valid values are simply on, auto or circulate.

There are also helper functions (commands) called fanOn, fanAuto, fanCirculate that are perhaps what was causing the confusion.

I’ll probably go ahead and add some code in my device handler to recover from this bad input, but for this to work with any thermostat out there then Rule Machine probably needs to be updated as well.

It’s an easy fix and I’ll head over to github and open an Issue on it and can even fork the project to create the pull request if you want. Just wanted to make sure I’m not missing anything first.

FWIW, the existing Rule Machine fan control code works perfectly with my Nest thermostat (and always has), so I tend to think this is not a fault. However, there is the matter of my confirmed but unacknowledged bug report regarding thermostat mode detection:


The documentation for the thermostatFanMode attribute clearly states that the allowed values are “on”, “auto” and “circulate”. So that is what I implemented for the Ecobee device handler per the api specs. I will likely add code that will correct for this invalid input (again per the specs) so that it can handle both cases.

So just because Nest accepts the invalid input does not mean that it is not a fault. :smile:

I’ve also looked at a few other thermostat impelementations (zen-thermostat, ct100-thermostat) and they are using “on”, “auto” and “circulate”

And even the previously released SmartThings code for the Ecobee had the following listed:

def setThermostatFanMode(String value) {
if ( debugLevel(3) ) { log.debug “setThermostatFanMode(${value}) - Not yet implemented!” }
// “auto” “on” “circulate”

And then there is the Template for a z-wave Thermostat that has this:

def getFanModeMap() { [
“auto”: 0,
“on”: 1,
“circulate”: 6

If you were to use fanOn with any of these devices they would fail to change the fan mode properly.

So, I’m pretty sure that the fault is on the Rule Machine side.

Yea, well the documents don’t list the required commands for playText… either, and yet both the sonos and Samsung devices use them internally.

Apples vs Oranges.

In this case the documentation does list the command inputs. But since I know the docs are often outdated/wrong I also referenced some actual Device Handlers that will not work with the current implementation.

Wasn’t really trying to start a debate here, was just trying to get things working properly for end-users.

And just because it’s documented, doesn’t mean it’s documented correctly.
Check out the documentation for multiAttributeTile and see how that works for you on Android. :smile:

The warning that now appears on that page was only after I pointed out that SECONDARY_CONTROL does not render except for type = “lighting”…

Fully aware of that one actually since I was planning to use that for the Thermostat tile. Have an open ticket and response from support that changes coming to multiAttributeTiles in the next mobile release. Changes that might impact existing Device Handlers.