FAQ: Getting Started with the new Rules API

In YAML it would look like:

        - between:
            value:
              time:
                reference: Now
            start:
              time:
                reference: Noon
                offset:
                  value:
                    integer: -7
                  unit: Hour
            end:
              time:
                reference: Sunrise
                offset:
                  value:
                    integer: 30
                  unit: Minute
1 Like

Interesting. Why the NOW reference in the between section?

A between is testing if value is between start and end. In this case we are dealing with times and in Rules times are defined in terms of a reference and an offset. As we are interested in comparing the current time at the moment the Rule is executed the appropriate reference is Now. As an aside you could apply an offset so you could effectively say ‘ten minutes ago it was between …’ or ‘in thirty seconds time it will be between …’. It probably doesn’t gain you anything but it is fun.

You might like to keep an eye on the sunrise time if your rule runs in the cloud. For the last year I’ve had a bug with sunrise and sunset not updating daily in cloud based rules.

Got ya. Simple answer- comparing current time to beginning and start times of condition. Thanks!!

Indeed, so I thought I’d dress it up a bit for those who haven’t encountered the Rules way of handling times.

2 Likes

Very much appreciated!

Hi,
I would like to know if someone could tell us what is needed to be done to brings webcore on the new api? Could it be store locally? is it just to translate the smart apps in lua? I mean we see that the cummunity should do the conversion but we just dont know what to do and where to start… If it could be possible to have a kind of explannation list or something, so we could check the duty…
Thanks!

1 Like

As a matter of practicality. This simply isn’t going to happen.

WebCore’s ST implementation runs as a Groovy SmartApp INSIDE your personal ‘shard’ (read: tenant in modern terms) in ST’s Groovy cloud. So to recreate that… You need the ENTIRETY of SmartThings implementation of the Groovy API IN your hub or some other device. (That’[s a TON of work, like multiple people, months of time in the best of cases…)

And, anecdotally, that’s essentially what Hubitat was when they first started. It was intended to be as near as possible toa local implementation of SmartThings as thier creators could manage. Hubitat runs WebCore - that also means, what you need to run webCore locally is - do what Hubitat did. So essentially you need to design a device that implements Groovy in a compatible enough way to SmartThings’ implementation that copying the WebCore SmartApp would run recognizing it as SmartThings and still work. That means you need timers and interconnects and plumbing to talk to devices… (Hint - that was a multi-year journey for the creators of Hubitat… And they ended up with a new hub / ecosystem because of it.)

There is no magic bullet here to “make WebCoRE run locally.” It’s like asking NASA to just launch Artemis I to the moon tomorrow… Sorry, its just not a practical thing at this point. There’s plenty of other threads on the community site about how to connect Hubitat to ST so you can use their implementation of WebCoRE or switch to SharpTools or Node-Red or the Rules API as this thread covers.

Thanks for those explanations! So there s no way someone could host groovy things on a home server or something to make it run?
Since sharptool or node red or any other things wont allow me to do my automations I ll start looking for a hubitat hub… If I were aware of all of those changes I would have buy that hub directly from the start…

Home user… None. Zero. Zip. Nada.

And if you had inclination to build a platform to do it get a team of techies, 12-18 months and a couple hundred thousand dollars in seed funding.

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