CoRE and Piston Rules Engine, first design steps

Interesting. I didn’t know that. Thanks!

This part in RM was called actions. You could have actions that could be called from any other rule.


In 6 to 18 months (?) HTML “cards” for SmartApps will be released and facilitate rich integrated UI development. Saw the demo today… It’s not vapor ware, but there’s no way to guess when it will be released and supported.

My recommendation… Hibernate. Why bothering building a new Rule Machine until the platform is stable and the UI tools are available??


I agree. My plan is to use RM until the platform will no longer support it. And once that happens I’ll break it apart into smaller more specialized apps that will meet my needs and continue working.

There isn’t much that can’t be done in RM, at least I haven run across a scenario that I couldn’t program into it.

I see no reason to reinvent the wheel.

1 Like

Just going to throw something out there.
Does anyone know if it’s possible to get Bruce and support at ST talking to each other again.
Wouldn’t it be better to resolve the issues that exist between the two parties, and agree a way forward that is mutually agreeable.
RM is an awesome app and for me is not causing any issues on my ST setup.
So for me both products go hand in hand and if I was to recommend this product it would be on the basis of the two.
So, how about it guys. How about sitting down over a beer and see if you can resolve your issues.
That’s my 2 pence worth. Sorry 2 cents.


I think providing a way to run the rules manually is important and shouldn’t be that difficult to implement.

I’m not saying it’s a great UI, but the Switches screen of the Simple Device Viewer SmartApp toggles the switches when they are pressed without using “submitOnChange”.

You mean you’ll use SmartThings in the way the platform was designed?

Bruce said it way too many times:

1 Like

Yeah, but with specialized apps that do more than the flagship one.

You know, it will turn the lights off too…

Smart Lighting does that too, no need to reinvent the wheel there …

href generated vs submitOnChange generated events, potatoes patatoes…

where’s the GD button input?, why do we have to hack into dynamic page events in the first place?

How about a freaking button…
Oh, wait!, here we go, how annoying is this?

def buttonsPage() {
    dynamicPage(name: "buttonsPage", title: "Every 'button' type") {
        section("Simple Buttons") {
            paragraph "If there are an odd number of buttons, the last button will span the entire view area."
            buttons(name: "buttons1", title: "1 button", buttons: [
                    [label: "bar", action: "bar"]
            buttons(name: "buttons2", title: "2 buttons", buttons: [
                    [label: "foo", action: "foo"],
                    [label: "bar", action: "bar"]
            buttons(name: "buttons3", title: "3 buttons", buttons: [
                    [label: "foo", action: "foo"],
                    [label: "bar", action: "bar"],
                    [label: "baz", action: "baz"]
            buttons(name: "buttonsWithImage", title: "This element has an image and a long title.", description: "I am setting long title and descriptions to test the offset", image: "", buttons: [
                    [label: "foo", action: "foo"],
                    [label: "bar", action: "bar"]
        section("Colored Buttons") {
            buttons(name: "buttonsColoredSpecial", title: "special strings", description: "SmartThings highly recommends using these colors", buttons: [
                    [label: "complete", action: "bar", backgroundColor: "complete"],
                    [label: "required", action: "bar", backgroundColor: "required"]
            buttons(name: "buttonsColoredHex", title: "hex values work", buttons: [
                    [label: "bg: #000dff", action: "foo", backgroundColor: "#000dff"],
                    [label: "fg: #ffac00", action: "foo", color: "#ffac00"],
                    [label: "both fg and bg", action: "foo", color: "#ffac00", backgroundColor: "#000dff"]
            buttons(name: "buttonsColoredString", title: "strings work too", buttons: [
                    [label: "green", action: "foo", backgroundColor: "green"],
                    [label: "red", action: "foo", backgroundColor: "red"],
                    [label: "both fg and bg", action: "foo", color: "red", backgroundColor: "green"]

1 Like

I was being facicious. Lol. Thing is, that’s almost all it can do!

href doesn’t have the Android issue and I was just pointing out that it is possible to create a screen that allows you to execute rules.

You’re right, there should be a button and a bunch of other UI related features like full size images.

:point_up_2: what Mike said… +1,000!!!

I am hacking my way through this pain now with a SA I am trying to create for multi-branded cameras… ponderous!

you can do images right now…, unless you mean something different…

href (
	url			: ""
	, style			: "embedded"
	, required		: false
	, description		: "Tap to view the zone graphic..."
	, title			: ""
1 Like

Time to put my money where my mouth is. So I’ve starting meddling with the ST UI trying to implement something RM did not directly allow: condition grouping. I know RM allows evaluation of other rules within a rule, effectively providing such grouping capabilities, but I think having it right in the engine as an option is better/easier to use/maintain.

I only concentrated on getting the UI to allow adding groups/conditions up to 3 levels over the main level. So you can go as deep as A AND (B OR (C AND (D OR E))). Also added the XOR logical operation - which may never be useful, not sure yet.

I also tried to maintain an object-oriented version of the app for easy JSON conversion, but if this is to ever allow both UI and web configuration, then the app information itself has to rely on the State variable, as I cannot modify the Settings variable programmatically (outside the UI - with the user actually typing in things). Data is not yet populated into the object. To do.

The app doesn’t actually do anything, other than allowing the creation of conditions (which also don’t do anything yet) and groups of conditions. Just a proof of concept, if you want.

Any positive comments are welcome. Any critical ones, no. Just kidding, any comments are welcome, please feel free to propose changes.

And to those who are saying they don’t need anything since they have RM and that nothing will ever better RM, they don’t have to use anything else than RM. But I can only think of the newcomers who are not so lucky to have RM. We cannot be so selfish, can we?

IMPORTANT: If anyone decides to help on this project, then they have to agree to Apache License v2.0 being the only license to be used for this project. I am willing to work on this as long as it stays Open Source and available to anyone. Thank you.

Thank you,


Rule Machine does allow condition grouping… unless I’m not understanding what you’re saying?

I’m looking forward to seeing what direction you head. I think you’ll find nothing but support from this community for another freely-available rules engine that can exist without any outside hosting.

Regardless of how ST was originally designed, I think the success of generalized rules engines speaks for itself.

1 Like

Can you combine ORs and ANDs in a single rule? Say:

([First Floor Door is open] and [First Floor Window is open]) OR [Back Porch Motion detected]

UPDATE: Apparently there is something with parenthesis support, but it’s so convoluted and apparently complicated that I can’t really imagine how most people would use it :frowning:

I don’t think is complicated man, you just need to get used to it. For those with BO, SQL even Excel exposure comes natural…



It’s not so bad once you get used to it. The UI leaves a ton to be desired… that’s the downside of building this all within a Smart App. Keeping a Smart App simple allows for better UI… but then of course you have a simple Smart App.

1 Like

Do you find this easy for the average user?