FAQ: Getting Started with the new Rules API

Hi, @PatPower

If you are trying to migrate complex automations, I would strongly recommend using Rules. Here you can find an introduction about what are they: Getting Started with Automations, and here you can find the API Rules Specification, and we also have some Example Rules.

Give them a try and let me know if there is anything you don’t understand.

1 Like

Out of curiosity, can you post a piston as an example of one you can’t port to SharpTools? The general consensus is that most are easily ported to that tool.

3 Likes

I’m assuming this is irony.

1 Like

can this api store a time into a variable or something that can be updated during the run ? For example, each day at 0:01 I run a every trigger wich look at the variable (wich I update every 15 minutes through another piston) and it gives the last 24h rain precip mm… (I cummulate this last 24h precip for 2 days and reset to 0 because I only can water my lawn on even day) Then in the same every I calculate from variable again, the rain needed (fix value) minus precip mm. Then I calculate the time needed for my sprinkler to run to get the missing rain… then I add a 20 minutes delay (time for the lawn to absorb the water) and I use sunrise- calculated time x2 (2 zone) to get the starting time wich I store in variable.
After that, when the time is on and even day, zone 1 sprinkler start…when it run for the calculated delay in variable, it stop and start zone 2 for the same delay or even another one if the flow is different for that zone…
And inside of that, if it start rainning (I also monitor rain in the 15 minutes update variable) it would stop the sprinkler and also restart it if stop raining…

And if I want to change something, I just need to change some local variable values… Seem complicated and I skip some little details but as soon as its done everything is fine and just need variable setings…

I can supply other example if you want

sharptool is a paid thing and its not webcore. I check it and looks nice but more complicated with complex automation and for sure missed some capability… And then, why sharptool is able to run some things with the new rules api and not webcore? What I try to do from the start is to turn webcore inside a kind of web thing that can interact with the rules api.
I know that with a driver it could send a list of devices with their state and so on to webcore and on every single changes… and webcore could trigger things and send information the same way to the hub…
If I need a paid account to do a part of my automation…I prefer buying a hubitat hub… Just a little deception from ST a this buisiness decision!

As a Sharptools user and fan, and a longtime webCoRE user and fan, I’m actually in agreement with the statement that “most” webCoRE pistons can be ported to Sharptools, largely because most pistons aren’t really that sophisticated.

In your example, you really have multiple “rules” (each one identifiable by the thunderbolt next to the IF statements) and each of those could be broken down into separate rules and (mostly) ported to SharpTools. I see a bit of date/time math and string manipulation, which SharpTools doesn’t do well or at all as yet (though I’ve seen some beta activity on this), but largely I think it could be done. “Easily” is a matter of perspective.

On the other side of the coin, however, webCoRE has more complex capabilities that SharpTools can’t come close to matching yet. I have pistons with complex arrays, webhooks to local addresses, advanced string manipulation and formatting, date/time math, evaluations and comparisons of the age and previousAge of select activity between devices. There are For, For Each, While, and Repeat loops, Switch statements, and such — which can be sometimes be clumsily imitated through workarounds in SharpTools — but often not.

In webCoRE, you can monitor the contacts for a dozen doors in a single line, and store the active or open devices from that first line in an array in a second line. Try that in Sharptools. The first line becomes pages of individual triggers, and the second isn’t possible because SharpTools doesn’t have device variables.

Over the past year, I have moved the simplest tasks to ST Routines, slightly more complex ones and anything requiring a variable to SharpTools, and installed a Hubitat to keep my impossible-to-replicate-elsewhere pistons running on webCoRE. (Sharptools can be a useful bridge for that). I’m puttering with the Rules API and will probably do more with it over time, but it has some significant limitations as well and doesn’t really have a friendly face.

My current setup may sound a bit Rube Goldberg-esque, and it is (and I haven’t event mentioned the various node.js and other servers I’m running, nor the GA and Alexa integration, etc., etc.), but I’ve put all my eggs in one basket before, and I’m not doing it again anytime soon.

But, back to the original point, can “most” webCoRE pistons be ported to Sharptools? Probably. Can it be done easily? Yes and no. But can Routines, SharpTools, or the Rules API completely replace webCoRE’s more complex capabilities? Not yet.

6 Likes

Sharptools doesn’t even come close to webCoRE, they shouldn’t be mentioned in the same sentence.

Here’s another very simple piston that controls 16 button presses of a remote, impossible to do on Sharptools, I tried, and the boxes became illegible, Sharptools couldn’t cope, then I started doing individual rules for each button press, and gave up at 2, why would anyone write 16 individual rules for a single device, and still some wouldn’t work?

How did you try to set it up in SharpTools? You could do this with a single rule using Context Variables.

You can determine which device was used to trigger a rule using the ‘Device Name’ context variable ($context.event.deviceName). When you use it in an IF Condition, the list is automatically populated with devices from the trigger section so you can easily select from a list.

Here’s a simplified example showing a multi-button remote and responding to different button presses:

Similarly, you can use combined conditions if you want to differentiate between different types of button presses (eg. pushed vs held on the same button):

3 Likes

In reviewing your other (first) screenshot, the main thing that sticks out to me is the addMinutes() call. I can take a look at adding this to our Lab environment which has math functionality and date functionality.

The formatting on the screenshot is a bit messed up, but I’m guessing it’s supposed to look something like:

addMinutes(baseTimestamp, minutesToAdd)

I originally built the labs functionality as a quick stop-gap solution for people who were transitioning over from WebCoRE based on the Groovy shutdown, but we plan on integrating it as first-class functionality within the rule UI. Of course, there’s a lot of activity with the Groovy shutdown, so we’re prioritizing based on user feedback. :slight_smile:

If you have other math / date type functionality you are using in rules and feel is missing, I’m all ears. It would helpful to hear what other features people are interested in so we can work to accommodate it in the design if reasonable!

3 Likes

Unfortunately, as it stands, the power of the context variables is not being used to its full potential to simplify rules building.

Let’s say I want to develop a rule that executes on doors or windows opening and closing around the house. To monitor both opening and closing, the user has to enter two triggers for each contact, as follows:

Front Door contact changes to Open
Front Door contact changes to Closed

If you have a lot of doors and windows, that’s a lot of extra triggers. It would be easier to have a trigger like this with an additional, less specific operator:

Front Door contact changes

From that point, one can build the rule’s conditions and flow around $context.event.deviceName and $context.event.value. And instead of, say, 20 triggers, there are only ten.

Add to this (eventually) the ability to select multiple like devices (i.e., contacts) in a single rule, and the entire process is greatly simplified.

I mean, it’s not like you have anything else on your plate right now. :joy:

2 Likes

There’s a feature request for it here if you want to cast a vote and maybe post a comment to bump the thread. :slight_smile:

I don’t have enough votes for all the features requests I’d like to see implemented, and my priorities often change based on the project I’m working on at the moment. Lol.

I’m going to jump off here to avoid contributing further to the thread drift.

I’m jumping off too, but why can’t Sharptools toggle a light switch? Or is there a feature request for that we need to vote on also?

It can. Use a variable.

1 Like

Again use a variable as a workaround? So each device I want to toggle I need to create a separate variable? In my case 60 variables! And as there’s no “Every X” we have to use variables there also, really? What’s so simple with webCoRE, now gets unnecessarily complicated and uses more unnecessary overhead. And yet webCoRE is free. Something I’m not understating here.

2 Likes

If we could turn webcore into a web based system or maybe into an app ? The ST app is aware of any change/device state… so turning it into an app could also communicate with the ST app … Webcore already have an app but it would need major update and the possibility to use a web interface…

1 Like

I can also mow my lawn with a pair of scissors, it doesn’t mean I want to when there is (or should be) a simpler solution available. Even SmartThings allows for toggles.

The question was pertinent, especially to someone coming from webCoRE. Having rules littered with workarounds makes the whole rule-making process cumbersome and fragile. A toggle is a reasonable request, but again I’m going to suggest this discussion move to the SharpTools forum.

2 Likes

The hard truth is webcore is going away for SmartThings. I migrated away using rules and SharpTools. Yes webcore was/is a beast but, it has had a long time to be developed into what it is today.

@joshua_lyon and the team at SharpTools have been working hard to make the rule engine better. It’s not webcore yet but it will get there, same goes for the rules API.

The fact is complaining about webcore going away won’t change the issue. Embrace the suck and figure out how to make SharpTools or Rules API work or move on to a different hub.

8 Likes

Yea the new rules systems is the worst. It is like Samsung is trying to kill their smart home business

Apologies in advance if this has already been discussed (searched long and hard but couldn’t find any references) - am I correct in stating that the Rules API doesn’t support STHM? I just want to simply arm and disarm the STHM but I can’t seem to find any reference to it in the documentation or in any examples. Thoughts?