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

Hey Bruce -

Laid out one example previously. Will come up with more. Thanks for making this awesome app.

Example 1 - (ACTION LIMITATION) Possible in SR Builder:
Say I make a rule to determine if the mode changes to home - if true then:
Front Door Lock UNLOCK
Light Living Room Turn switch ON
Light Driveway Turn switch ON
Light Front Door Turn switch ON
Wait 1800 seconds THEN Light Living Room Turn switch OFF
Wait 600 seconds THEN Light Front Door Turn switch OFF
Wait 600 seconds THEN Light Driveway Turn switch OFF
Wait 1200 seconds THEN Front Door Lock LOCK

Example 2 (INPUT Limitation) Possible in SRBuilder:
Aeon Minimote button 4 is pushed

Other INPUT limits I have noted:
Battery Level

Output Limits:
Thermostat Heat / Cool Setting Points

1 Like

possibly turn X on after delay, or do X to Y device after Z delay (which i think you might be doing)

Thanks for this app. It is working great here.

This can be done with Rule Machine now, except for the Lock after a delay. It would take 2 rules, one with the 30 minute turn off, and the other with 10 minute turn off. The rules would have identical conditions.

For your Minimote button push, you could set up a virtual switch integration to work it with Rule Machine. (not as clean, but could be done)

and the thermostat set point is on the list of future improvements.

Hey Bruce - looks good - there is still a bug in displaying the false (and probably true) action status with the new ‘turn off after delay, pending cancellation’

After you select this, and click done, it’s there, but not displayed on the previous screen. Going back into that screen shows that it was saved though. This is on Android BTW - not sure if you’re seeing this on iOS.

Update - something got transposed, when you save the turn after delay, it shows up in the ‘Actions for True’… :smile:

Correct. The universal delay is what what prevents me from locking the locks on a delay. Currently the delay only available to swtiches.

That’s a bug for sure. Will fix it shortly. A typo…

EDITED TO ADD:

Fixed now. Version 1.106

2 Likes

I believe you could do this easily with this App, but not in a single Rule. Why not just build one set of conditions, and then use that in N number of rules that contain all of the different timed actions. While having the ability to trigger N different types of actions from a single rule might save a few steps (rebuilding those conditions in the second rule), I don’t see the NEED for them to be in a single rule even if they are all triggered from a single condition set.

If/when Bruce builds functionality to have a different rule be a condition, you will be able to make one rule contain many simultaneous conditions, then just use the True condition of that Conditional Rule be the single condition for all other all other action rules that depend on that group of complex conditions without reprogramming. This will also allow simple updates to those action rule conditions by simply changing the complex conditions in a single Conditional Rule. This will be awesome.

This gives me an idea for a Feature Request: To save time, it would be nice to have the option to “Copy a Rule” and/or “Make rule based on Rule X”. This would eliminate the need to re-enter all of the conditions if one is only setting a slightly different action and/or only a tweak to a complex condition set.

Bruce beat me to the punch:

yeah, the trick is the ability to add a delay to other capabilities.

Bruce has that on the “to do” list.

yep. I will add sufficient characters to this post to meet the post requirements :smile:

This looks awesome but it does beg the question…maybe answered in the last 250 posts but I missed it?
The V2 hub promised local processing of native ST apps to avoid Internet outages and general ST server loads. If we convert all the apps over to the Rule Machine will these now be back to the vulnerability of the V1 hub and Internet dependency?

Automatelt.

You can’t delay any action other than a switch. So you can only lock immediately upon rule evaluation = true/false.

Actually, I have it on the to be looked at list. This is harder than meets the eye, at least with the codebase as it is now. I’m knocking off the straight forward stuff first, such as additional conditions (energy, power, battery), and additional actions (garage door control, thermostats, SHM arm/disarm). Linking rules and general delay are both doable, just more difficult.

Yes. The only app that runs local on hub V2 is Smart Lighting, and there is no provision at this time for us mere community developers to cause our apps to run local. We may be waiting for this feature indefinitely.

2 Likes

would adding delay actions to specific items be easier? like lock/unlock these locks or contacts after x minutes, like you have the switch delay now? that way it’s not a separate action to apply to a condition?

I did some digging on capabilities, and it looks like new ones would have to get defined by ST. Here’s a link to the forum section for requesting new capabilities.

https://community.smartthings.com/c/developers/new-capability-types

I’m not much of a developer, but I can take a rough stab at a new capability (e.g. weather) and post it to this area. Thoughts?

@bravenel - are you managing the todo items in github issues or just here?

One more to add the request list would be manual override of rule evaluation.

Example: my wife would prefer if a switch was physically used to turn on a light, that the Rule Machine rule attached to that light (or lights) be suspended until a manual/physical off happens on that switch (or switches).

Thanks.

1 Like

Why can’t you do that with a rule? By adding a condition for the switch, making the rule be true only if the switch is off?

1 Like

Duh… yeah… sorry - my brain is slowly starting to grok conditions as opposed to rules/triggers… I’ll try that.

Thanks.

Update: I’m not sure that will work, unless I’m missing something. Switch state is not using isPhysical() in the code, so this would be in effect if another automation turned on the switch.

Even beyond that, the specific behavior can basically be boiled down to another conditional - ‘don’t turn off lights in the false state if switch was physically turned on.’

I’ll need to noodle on this a bit more to see if I’ve got the right thoughts on logic for this… I had something hacked together for an earlier version of your code that sort of worked, but had issues.

UPDATE #2: I have some basic logic worked into this now which satisfies my use case, but may need to be made more generic. Basically, I have a UI element called ‘physicalOverride’ (Bool) which lets the user say that they want switches associated with the ‘True’ case to be able to override the rule evaluation. If this is set to true, I set a state variable which is checked in runRule() to determine if it should execute an of the rule logic. If override is false, everything proceeds normally - if true, it doesn’t execute any of the rule logic.

Physically switch on the switch activates the override, a Physical off returns the rule machine to normal operation.

If interested, I’ll drop you a pull request in git.

Thanks.