CoRE and Piston Rules Engine, first design steps

Yeah, what I did for this is caching the last event using the deviceId dash attribute as the key. This may touch up the 100k limit on the state though - we’ll see. I can purge the list so that I only keep events that happened in the last hour for example, this way I minimize the size of said cache.

So I save the event value and the time the event was generated. Then when a new event comes in, for the same device and attribute, if it has the same value, then I check the following:

a) were the two events generated within 1000ms of each other (they seem to be at very low intervals < 100ms) - I may change the 1000ms
b) is the value a string value?

If any of the two is true, then I completely ignore the event.

Just an fyi… I’m predicting a huge new experience fit us ST users in the very near future.

This new rule builder is shaping up to be incredibly powerful yet simplistic in use.

Couple this power with the upcoming ask Alexa app from @MichaelS

Our HA is about to take on a whole new level…

I certainly hope that ST @slagle @jody.albritton @Ben @Tyler are paying attention!

I know for a fact that my system is already transforming into a true home automation system in which I will hardly ever touch the app… (yeah right… Me not tweaking… Lol)


I am not a fan of big rules either, they tend to get very hard to grasp when revisiting them. But I’m also not a big fan of having to build two rules just because one can’t do a simple task like, for example, tell me when the fridge door was left open for too long…


Get outta town… :slight_smile:

1 Like

In all honesty, I think rules should not be trigger/event-centric, but controlled-device-centric. That is, if you have ten lights in your home, you should have one rule for each light or group of lights having the same expected behavior, not one rule for each device that can trigger events, trying to control a multitude of devices. That’s what I’m aiming at.

UPDATE: It should be “DO THIS IF THAT” rather than “IF THIS DO THAT”. That may simplify the thinking patterns for some people but complicate it for others…


One more thing coming in the future which may or may not affect SmartThings, but I think will have an impact on UI design for home automation, so I just wanted to mention it…

We already have some community members who have added automatic window openers to their systems. These are becoming more popular, particularly for skylights and in hurricaneprone locations where they are often combined with automatic shutter systems.

There are also some homes which have automatic door openers. I have friends Who use wheelchairs that rely on these and the cost has come way down just in the last two years.

The newest version of HomeKit distinguishes between open/close sensors and motorized doors. The first group is called “door sensors” and the second group is called doors.

This is pretty new for home automation, where in the past the open/close sensors were usually given the name of “door” In most UIs. Not “door sensor.”

However, it seems possible that the distinction will be made in many future systems, if only because the motorized devices are becoming more common.

As I said, we do already have some SmartThings community members using motorized windows.

So just one more thing to think about:


Thank you for pointing that out. ST made sure to append the “Control” word at the end of them. And I passed that separately into the UI, though I removed the word Control. There is no capability that I know of that acts as a contact sensor but is called a Door or a Window. So we have to use Contact Sensor to know if a manual door is open or closed.

        [ name: "doorControl",                        display: "Door",                            attribute: "door",                        commands: ["open", "close"],                                                        multiple: true,            ],
        [ name: "garageDoorControl",                display: "Garage Door",                        attribute: "door",                        commands: ["open", "close"],                                                        multiple: true,            ],

Also, the attribute is called “door” instead of “contact” so there’s a pretty clear separation.
Should I rename the display value to Door Control? Or perhaps Automatic Door?

Most automatic entrances would be very easily integrated into an HA system, If anyone needs help particularly with Record, or Stanley brands pm me and I can probably point you to the correct contact terminal that you could hook a relay up to for simple open commands.

1 Like

As @schapper05 mentions, I think most of these control devices are integrated with a relay. Some of them have remote controls that allow for integration through a bridge. I don’t think SmartThings defines them as a separate capability the way they do with garage doors. Maybe someday. :sunglasses:

Personally, I like the term “automatic door” because that’s the ADA term, so it’s what you usually see in product descriptions and I think most people in the US are familiar with it. Same with “automatic skylight.” I don’t think you see “automatic window,” that often, it seems to be more “motorized window.” Probably just historical convention on all of those.

But I think all these terms are very understandable once someone asks the question so I think you can use whichever seems more sensible to you.

(Garage doors are a separate device class in SmartThings because they allowed for two physical devices: a tilt sensor and a switch.)

@JDRoberts maybe something changed, but the documentation shows Door Control as well as Garage Door Control

Both only have the “door” attribute (open, closed, opening, closing, unknown)
Both only have the open and close commands

They seem to be identical except for the name. Of course, programmers can add any amount of other capabilities, for example, in a garage door device handler: Garage Door Control, Contact Sensor and Three Axis.

I’ll call them Automatic, I like that as well.

On top of the list present in their documentation, I have also added the powerSource capability, as per Platform Update - Release Notes - 4/13/16

1 Like

I’m blown away how developers here design these programs! Hats off to you guys. Your like mad scientists. :clap:


It’s fun to watch how things progress for sure!

1 Like

OK, hats off to @ady624 you’re doing an amazing job! Been going through your code as well (from the ones in various posts on this thread) and its well laid out. If I could spare a bit more time I would love to help (although a bit busy currently… ok make that 20 hour work days due to a few projects I am in charge of).

1 Like

Thank you @Boston_B, @michaelahess, and @ZebraBlinds

I’ve updated the code. It can now do simple evaluations. No triggers yet, but all simple conditions should work. All “is” kind of conditions, at least. The “was” conditions are not there yet.

I wish ST allowed a list of options in an input where I could specify id/value pairs instead of just strings for display - they make it into settings and we won’t be able to change the names later…

Since it takes no actions yet, results are in the live logging.

Link for the lazy?

Btw I saw you bragging about stable your system was in another thread. I don’t know whether to be jealous or challenge you. :slight_smile: I see my system doing some things it forgot how to do for 4 weeks or so, but I am traveling so I don’t have time to check in on the details yet. Maybe things have gotten better. I hope.

1 Like

Yeah, it is running great… I’m just pissed off at the way Amazon has screwed up the echo…n

Progress report: For whomever wants to test condition evaluation, find the code at

No actions can be added yet, but conditions can be built with or without triggers. All conditions should work, and simple triggers should work too. Simple means “changes …”, “drops…”, “raises…”, “enters…”, “exits…”. Timed triggers do not work as of now (no trigger of the “…stays…” form), so please don’t use those yet.

Little background:

Triggers are shown with a full dot, regular conditions (non-triggers) are shown with an empty dot.

if you DO NOT use any triggers, any change into any of the devices involved in the condition will lead to an evaluation of the condition. If you DO use triggers, only those devices involved in the triggers are monitored and only their changes lead to evaluations.

The “was” conditions refer to the immediately previous state/value. If you have a single condition “if door was open for at least 3 minutes” and the door closes, the evaluation will run (because we have no triggers) and will return true (provided the door was indeed open for at least three minutes before it got closed). Makes more sense when paired with triggers and the door state doesn’t change, but you’ll get it.

Let me know if things should be changed. Anything. I have done minimal testing on this, I haven’t tested the advanced option in a group (negate group) - but it should work. Evaluation seems to take around 200ms for a low number of conditions. Haven’t gone berserk on conditions yet. The “was” conditions are much heavier on resources since they rely on lists of events to figure out if state/value changed and if it did within the comparison conditions.

Last but not least, every evaluation ends in a sendPush which will put the condition, event and result in the Notifications page in the ST app. Live logging gives a bit more info, including time it took to process the event.

Have fun


Please note: I’ve updated the app to make the push message easier to read. Also included event delay time (time to received) and event processing time. The processing time displayed in the live logs includes the time it takes to send the push notification, whereas the push message obviously doesn’t. This leads to some apparent discrepancies, they’re normal.

I am watching 13 temperature sensors throughout the house and for example, last event was received 606ms after it was generated, was processed (up to and not including the notification sending) in 440ms. Live logging reports 1253ms - this includes one action, the sendPush().

There were some type casting issues I resolved, not sure if many more will arise, they may. I also have to handle several data types. Currently handling “number”, “decimal”, “string” and “enum”. Need to handle “color” (a map I haven’t yet studied), “hexcolor” (technically a 24-bit value) , “three-axis” (a map of three numbers, apparently ranging 0-1024) and time.

Here’s one for those who like to tinker:

The three axis is a map of three numbers: X, Y and Z, each describing a position on one axis, relative to the start position, which is defined by the device manufacturer. There is no way currently that I know of to trigger things based on this, so we’re covering new territory here. Let’s brainstorm on a list of possible and useful comparisons.

Should we go the “easy” way with:
X axis is
X axis is less than
X axis is less than or equal to
X axis is greater than
X axis is greater than or equal to
X axis is in range (possibly the most useful one to figure out if the device rotated along the X axis)
X axis is outside of range

and repeat them for Y and Z, or figure out some more complicated comparisons?

For example, the device is “moved” or “rotated” if any of the three moves, which would require three OR’ed comparisons. Not user friendly.

Here’s an example of a trigger:
"rotated along X by " - parameter1 is a number representing a threshold to look for, in degrees (or radians for those who fancy them ha ha)
"rotated along Y by " - parameter1 is a number representing a threshold to look for, in degrees
"rotated along Z by " - parameter1 is a number representing a threshold to look for, in degrees
"rotated in any direction by " - parameter1 is a number representing a threshold to look for - this would help because you don’t have to place the device in a certain way, it will work in any direction - say you’re monitoring your dog’s door, you just attach the device to the door in any position you can.

Let the ideas pour in :slight_smile:

1 Like