CoRE and Piston Rules Engine, first design steps

Main thread is here [OBSOLETE] [BETA MILESTONE 1] CoRE (Community's own Rules Engine)

@ady624 you may have posted this already, so I may have missed it, but could you please explain the logic behind the TCP and Cancel on piston change. I know what the four TCP are and kind of guess when to apply them but not really. And being a new thing, I am having hard time wrapping my head around it.

FYI, if you are having technical difficulties, here is why, in case you didn’t get the memo:

Investigating
Some users in North America are unable to access the SmartThings mobile app and Developer Tools, https://graph.api.smartthings.com/. We are working to address the issue and will provide updates on our progress here.

Thanks! I got the code from the GitHub. But in looking through the threads, I don’t see any information on what I am supposed to do with it. ST is down right now, but I am guessing I log in via a web browser and can create my own SmartApp with this code? Then once I do that, what’s the next step? Is there a guide or any info that explains how to create rules, their syntax etc?

TCP (Task Cancellation Policy) works in conjunction with the piston state. Individual actions will eventually get a TCP of “Cancel on condition state change”. This feature allows a task to be cancelled if the truth state that led to the task being scheduled changes. For instance:

IF condition is true
THEN reset the world

TCP would have absolutely no effect on the above example, because the task is scheduled and executed immediately, so by the time the piston state may change, there is no task to cancel. But consider this:

IF condition is true
THEN wait 10 minutes, reset the world

The world now waits 10 minutes before it gets reset. If TCP is enabled and the piston flips states (aka condition is false), then the now pending task to reset the world will be cancelled. If TCP is set to None, nothing happens to the “reset the world” task and it will eventually execute when the 10 minutes have passed. TCP is set to None by default.

In contrast, TOS (Task Override Scope) will cancel the “reset the world” task only if and when it asks something else of the world:

IF condition is true
THEN wait 10 minutes, reset the world
ELSE save the world

If the piston turns true, reset the world is scheduled in 10 minutes. If within these 10 minutes the piston turns false, the “save the world” action is executed. If TOS is set to Local or Global, the “save the world” action will cancel the “reset the world” action because they both want something from the same device, world in this case. If you set the TOS to “Action”, then the scope of the override is limited to only the same action. That is, if the piston turns to false and back to true during the same 10 minutes, then the original reset the world task is cancelled and a new one is scheduled in the next 10 minutes. TOS is set to Local by default, which means that when an action is scheduled, all tasks for the same device(s), regardless of which action has scheduled them, gets cancelled and replaced with the new tasks. If you want the tasks to add to the existing ones, set TOS to None.

Hope this helps.

#documentation

5 Likes

This thread explains how to install it…

Thanks @ady624, this is useful. So for below example, sounds like I need to use TOS local and enable TCP ONLY on the last action to cancel the wait on piston change?! Did I get this right?

The events happened like this…the first action fired was the last, then the second was the second action, but the first never fired?

Since you have several actions for the same device happening in the same statement, you either need to split the devices into one action for each device or use TOS Action. The way you have it, the second and third actions in the then cancels the first… The first will never run…

1 Like

Ok, and now I get this: the last fired already and first and second are running concurrently. Is there any way to make them run sequentially? Run first after 5 min, then second after 10 more and then last?

UPDATE

I went with your other suggestion to actions for each device and I like that better. :smile:

Interesting. One of my follow-up pistons re-wrote itself. It was set to fade from 55% to 0% over 600 seconds, then turn off. This is what it re-wrote to:


I’ve re-written it, so we’ll see if it holds. Might this be because of a recent version update that I downloaded? @ady624

I’m new to CoRE and I must totally be overlooking something. I can’t find any THEN actions for sending SMS/Notifications. I’ve looked and looked and searched. It must be right under my nose. What I’ve done is created a new BASIC Piston. I said IF the Relative Humidity of my Aeon Multisensor 6 is GREATER THAN 45. Then I go into the THEN section, and I’m looking for SMS/Notifications but don’t see anything. It says “If (condition) THEN” and “Add an action”. I tap to show the actions.

I then get Convenience, Safety/Security, Comfort, Entertainment, Other, and Control any device. None of these have a notification/sms option, at least that I can find. Clearly I am missing something. I am so curious I can’t wait to see how I am overlooking such a basic thing to do. Thank you!

Think it’s due to updating, mine did similar things

All SMS/notification options are under the ‘location’ section at the top. Flip that to on and you’ll see a whole new section of options.

Ah ha! Thanks. So this may be a silly question, but what is this doing under the Location section? It would be more intuitive to have it labeled or marked differently.

On another note, how can I have it put the value that triggered the condition into the message. For example, “HUMIDITY IS NOW AT XXX”?

Is there a guide or instructions on creating rules with such information so I am not asking lots of beginner like questions? I could not find anything. Thanks!

You’ll need to use a variable for that.

In SMS message

Current humidity is {$currentEventValue}

The list of available system variables is under the piston in the dashboard. I think that’s the one you need, but maybe wrong. Can you put a screenshot of piston in here then I can see?

Wiki is at

http://thingsthataresmart.wiki/index.php?title=CoRE

But it’s a work in progress so may not contain information you need…yet!

2 Likes

It is. I mentioned in the version description that Fade to Level has changed and needs to be redone. I added the optional start level.

1 Like

Everything related to no device is found under that Control location and more. You will also find these tasks when controlling any device, for convenience purposes.

Adrian, any progress on Thermostat Operating State? I would like to use it to see if the AC is running and the downstairs door is left open for a minute to close the downstairs vent and then open it again once the door closes.

No and there won’t be any. The Thermostat Operating State capability was added to ST but I don’t think anyone uses it in their DTH. The Thermostat capability covers everything under several capabilities, among which the Thermostat Operating State. Enable expert mode, go to the Thermostat capability, select your thermostat and then use the attribute thermostatOperatingState from the Attribute select box.

I had a rule that sent an SMS with a bad variable. I had used (currentEventValue} instead of {$currentEventValue}. So when the event fired the message it literally said “{currentEventValue}”. I corrected it and saved it. A few hours later when the trigger happened I was surprised to still see the “{currentEventValue}” literally in the message. When I went back into CoRE I see the SMS message setting is correctly at {$currentEventValue}. So it seems to be saved in the Piston but not “refreshed” or whatever in the engine so it seems to still be using the old one. Any idea what this bug is and how to fix it? Thanks.

© 2019 SmartThings, Inc. All Rights Reserved. Terms of Use | Privacy Policy

SmartThings; SmartApps®; Physical Graph; Hello, Home; and Hello, Smart Home are all trademarks of the SmartThings, Inc.