Still waiting on the Rules API (July 2021)

I am trying to move from webCoRE, Smart Lighting and Automations to the Rules API. Although much of the functionality I require looks like it may already be in use by Automations, the exposed and/or documented functionality doesn’t seem to have changed in the last nine months or so, and nor does the undocumented functionality that can be extracted by reading the Core SDK code. My requirements are actually extremely basic and I know I’ve banged on about all this before. This is what is still stopping me …

I use a lot of IKEA On/Off Switches, which present as two different buttons with pushed and held functionality, and I also use multiple buttons for the same functionality.

Buttons do not have a standby value so they always show the last value used. You can use an if Button button is pushed condition for a single button and it will work fine, but only as long as nothing else will trigger the piston, be that a device or timer event, or some other form of ‘manual’ piston execution such as the Test button. As soon as that happens the button will be returning the last thing that happened with it. At a push, though, for a single button it is an effective but compromised solution.

The if Button button changes to pushed trigger would only work if the button pushes alternated between different values so that is no use. However webCoRE does have if Button button gets pushed which does the job perfectly.

Unfortunately, when it comes to the Rules API, the only documented option is currently equals, which is the equivalent of is pushed. So I could port my pistons over, but I would have to use the compromised solution, split the piston in two, and then have multiple copies of each, and that is really a compromise too far.

So I am stymied by there not being a useful way of handling a button press.

Most other things I can do as I have simple needs, though something as simple as the $currentEventDevice would be a game changer by itself.

Smart Lighting
I have actually managed to remove Smart Lighting, but only by using Automations for the ‘power allowance’ functionality and the similar delay after a contact changes, and because I have changed my motion sensors and no longer need the delay there. It is the absence of remains on for x minutes that is the particular limitation there.

I have always formed the impression that Smart Lighting was almost exclusively driven by subscriptions, and with each automation being a SmartApp it could constantly be updating its restrictions as they changed, not as the automation was triggered. Trying to replicate those automations would be a lot easier if there were a changes type of condition (ironically this was actually in the proof of concept over a year and half ago but I don’t think it worked when I tried it).

Automations and Quick Controls
Automations and, at a very large push, Quick Controls are useful toys for a limited number of automations, though if I had a switch to disable the latter they would be gone in an instant. I don’t mind using Automations for temporary things, and for simple Automations that might need to be easily enabled and disabled, and perhaps even for audio notifications (though I’ve no idea why Automations don’t support the Speech Synthesis capability). However I can not accept that they get edited or even deleted when they are perceived as no longer being viable. That might mean deleting a device with the expectation of replacing it a few seconds later, or it might mean something that should be irrelevant has occurred, such as STHM being deleted (it seems to be assumed that the Security Mode has no purpose outside of STHM, which is utter rot). The same functionality implemented directly in Rules is left well alone.

I am pleased to say that I can both read and set the Security Mode in the Rules API, even though the two functions lack consistency. Unfortunately what I can’t do is either execute Scenes, even though that is even mentioned as being possible in the documentation, or send push notifications, and those are game changers.

So close, and yet so far, and with just no visible signs of progress.


FYI @ady624 and @vlad

1 Like

I had similar experience in Rules with button events.

I solved this problem by splitting into two separate rules.
One rule with Button trigger only, and the another rule with triggers other than button event.

On the rule with button trigger, all other device conditions need to be coded with

trigger : Never
1 Like

It is not that I can’t deal with the button pistons. It is just that it feels so unnecessary to do so.

1 Like

That’s right.

Recently I ported one WebCoRE automation, but it finally required 3 separate rules, and lots of rearrangements and unneccessary codes to work properly.

Dealing with Rules API is still not that much straightforward, and all about hassles for dealing with workarounds.

I hope these would be improved the near future. Everyone in the ST seems to be working hard. :slight_smile:

1 Like

In starting this thread I was really commenting that we haven’t had so much as a scrap from the Rules API table since about last October, and most of what we’d had by then was actually already pretty old. Meanwhile the Automations seem to have had a relative feast.

I am not after webCoRE #2, I don’t even want anything new as such, I am just hoping for something like parity with what Automations can already do. I could do a lot with that. I just can’t quite do it now.

1 Like

I guess there should be a lot of new features in Rules API, which is not yet documented.

The reason, I think, why these are not documented is…
it is not yet fully tested in various situations for public use, other than use in the Smartthings App automations.

It is necessary to document those good new features.

If Smartthings company think that some of them need more validation, developer preview would be good choice, like the one below.

I hope these new features get documented.

This wouldn’t be the reason, in fact this is Samsungs’ modus operandi.

Oh well I decided to do things the very long way with one Rule per button so now I’ve got rid of my webCoRE pistons too, so it is just the Automations I have to deal with until I want to do something a bit more complicated and then the cycle might start again.

With much trial and error caused by a failure to follow a vital clue, I eventually figured out how ‘remains’ is implemented in Rules and that has got rid of most of the Automations that troubled me.

I find ‘remains’ interesting. It isn’t like a webCoRE stays (which is a relief) as it can return true immediately if the device has already been in a certain state for the required time. I am intrigued to know the mechanism.

The messages pointed out to me when you add buttons to Automations (not something I do) make me suspect there isn’t actually an equivalent of webCoRE gets at the moment. I still reckon there is, or will be, a changes of some sort in there to isolate whether a particular device event triggered the rule. It doesn’t need to be changes to, as the to can be deduced.

I also think there has to be a toggle too. You can do it the long way but there is enough information in well constructed capabilities to specify a toggle with just the device attribute, and I can’t think what the point of it is otherwise.

Notifications aren’t something I am going to figure out but there is something to be said for retaining them in Automations anyway as it makes it easier to shut them up. Just becomes a matter of removing any other functionality from the Automations.


It is only right that I comment that the Rules API documentation has changed. It now covers the remains condition, as well as changes and was. Surprisingly it still doesn’t cover the security mode stuff, even though it partly featured in tutorials last year, and it doesn’t yet mention scenes, or indeed the toggle I am sure must be in there somewhere. As an aside the API documentation also covers the Coordinates endpoints, which works with services such as weather and air quality obs and forecasts, and the TTS endpoint which is something to do with, well you can guess that one.

The three conditions can pretty much be considered together. They sit one level above conditions such as and, or and equals. Changes means that the contained condition evaluates to true, but last time it was evaluated it was false. Remains means that the condition is true and stays that way for a certain duration. Was means that the condition was true for a certain duration.

The implementation of changes suggests I need to get webCoRE out of my head. The Rules API is just a very different animal and so far I much prefer it.


Thanks for the heads-up Graham - am just getting back after vacation and who knows how long it would have took to figure out there are now new documented options in the API. :clinking_glasses:

1 Like

I’m forever checking it and it still took me by surprise. It had suddenly occurred to me that for there to be a Member Location condition like ‘after being away for how long’ there must be a condition that implemented ‘was’ in some way and went to see if there was something subtle I had missed somewhere. Nothing subtle about it now.


I should note that this is NOT the way I had previously discovered of doing ‘remains’. That used a remainsEqual condition. I like the documented way better.