CoRE and Piston Rules Engine, first design steps

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

As for designing your own rules engine smartapp, sounds great, here is a new thread for that to keep people from getting confused. :sunglasses:

This thread is for discussion about desired features and development of the core smartapp. If you’re just looking for the rules engine code for CoRE, it’s in the following thread:

If you need assistance setting up a piston after you have installed core, as in the following thread:

You can continue to report bugs, request features, or discuss design ideas in this thread.


I’m intrigued

Anyone who tries to create a new rule engine should create a web-based graphical one. That way it can be much friendlier than trying to dig through tiny menus in your SmartThings app…


SmartRules 2.0 was just released.


Very good idea. Let’s try and compile a list of “rules” that this app should be able to accomodate. From simple if that do that to most complex ones involving historical events (i.e. trigger an action if and only when an attribute’s value exceeds a certain threshold, after it’s been below the threshold. Subsequent reads over the threshold should not trigger the action again, unless the value drops below the threshold and then goes over that threshold again)

Useless for those of us with Android only unfortunately.


There are benefits and drawbacks to every approach.

SmartRules uses an iOS app frontend (with Android in development).

Simple Rules Engine uses a web frontend:

Rule Machine worked entirely within the confines of the SmartThings Smart App

All are viable options.

I think any rules engine needs support for both rules and conditional triggers :slight_smile:

Seriously though…

I need to be able to write this:

When Door Contact Opens AND my Light Switch is ON do something… However, DO NOT do anything if my Light Switch Turns On while my Door Contact is Open.


As for the difference between one time events and subscription events, this is the same reason that IFTTT introduced a “do button .”

SmartThings allows you to subscribe to events like a switch turning on or a motion sensor being triggered.

The original rule machine, as I understand it, was based on responding to events.

Then people wanted the ability to trigger a one time execution of a rule just like turning on a switch. Or like the Do button. No subscription, just a manual initiation.

That led to a second app which was called, I think, “triggers.”

And that in turn led to requests for one time events that would have conditionals around them.

The purpose of the one time event is that they could then be used from other parts of SmartThings. It was no longer all automatically driven by subscription events.

And then the conditionals let you say “but only if” other conditions were true.

In my experience, many UIs do distinguish between subscription events and “at will” events, whatever you want to call them. But other UIs will just count an at will request as a different type of subscription. I don’t think it really matters one way or the other, it’s just a question of what fits your particular design. :sunglasses:

IFTTT added the do button not so much because of the “do” part as because of the button. It’s essentially the same as a recipe without an if other than the at will request. And they knew they wanted that at will request to have a button UI. So they went ahead and set it up separately.


I like that you are trying to work on this. Even if Bruce decides to come back, the more ideas we get with this app, the better each app could become! I’m trying to be positive here towards RM, but at the same time, hoping this new engine could become an evolution of that as well. CHOICES!

I see three variations that are the same as RM far as I can tell, but this sounds simpler to me:

  1. This than that.
  2. This than if a,b,c, then that.
  3. If a,b,c, then that.

1 and 2 are triggered, 3 is like RM rules which subscribe and follow events.


A birdy told me that @Mike_Maxwell might know a little bit about web based integration. I am thinking out loud here, but what if we can all create the first community rule engine where we can all contribute to building it a little?

They are all viable because no-one has combined the strong points of all 3 yet. SmartRules is great but limited to a phone/tablet, Simple Rules Engine is very basic, and Rule Machine is extremely powerful but difficult to use effectively… (these are gross over exaggerations, but you get my point.)

If someone is going to pour time and effort into reinventing the wheel, they better take the lessons from the existing rules platforms and improve on them.


Perfectly said. Which is exactly what I am trying to do. Rather than complaining that RM is gone (and by all means, I want it back too), let’s put our shoulders together to push this through.


There is a fourth, which is the ability to initiate a “that” without any “if” other than the initiation request itself. This is what the IFTTT “do” button is.

And there is a fifth, which puts conditionals on the at will request. So do that when I ask you to but only while…

1 Like

So your fifth example would be like a conditional trigger?

The fourth would be…a switch? That does nothing? Used by other rules possibly though?

I don’t think I follow the logic on those. But since it took me a month to (think) I understood RM, I’m not surprised… :slight_smile:

1 Like

I think @JDRoberts is saying RM is missing the ability to trigger an action from the app itself, much like the Routines allow you to click them. I concur with him, I could have used that a couple of times…


A lot of power of RM lied in it being a completely mobile driven app, that power also exposed the limitations, bugs and mobile os platform parity issues.
The UI and UX flow of RM would likely be different had Bruce elected to re-write the code from scratch, forcing users to re-enter all their rules from scratch upon every release…
He didn’t do that, with very few exceptions, your old rules worked perfectly in new feature releases.
Maintaining backward compatibility on the smartApp side is very difficult.


The fourth, the at will request, just says “do this because I told you to do it.” It isn’t automatically initiated by anything. I have a headache, I’m going to take a nap in the afternoon, I want everything set exactly the way it gets set when my good night rule triggers. But I want it to happen NOW just because I said so. A “that” without an “if.”

And yes, I think the fifth ones are conditional triggers in rule machine terminology but @Mike_Maxwell would know better.

I did a tiny bit of brainstorming with Bruce when he was first writing rule machine, but I never actually used it and as you know, I can’t follow code these days since I’m now dependent on voice readers. So I don’t know anything about the internal details.

1 Like

this is a limitation in the current UI, you get one button for a smart app ( > ), anything else needs to be triggered from submitOnChange events within dynamic pages.

There is a smartApp button input, however it isn’t completely implemented, I’ve been pushing for them to fix it, but there seems to be no interest from ST in doing so.

For any of you guys that think writing an SA of the complexity of RM is easy, have a go at writing a decent UI in ST…
I’m not being an ass here, I’m serious.


Never said it was going to be easy, but someone’s got to do it. Web can be used with endpoints and JSON comms to an angularjs+bootstrap responsive app wrapped by a dummy container app within ios and android.