ST Rules Api or Webcore


1) Give a description of the problem
Hi new to both webcore and ST and trying to determine the best route to take for this project.
Looking to implement an integration to ST api that does 3 things:
1: Create and delete user codes on my schlage lock based on a Date Time schedule
2: Turn zwave thermostat on and off based on that same schedule.
3. Turn On and off a switch (controls pool heater) based on same schedule.

Date/Time and Username and lock code will be generated from a third party software that has an api connection.
I’ve read that webcore is phasing out and ST rules api is coming in? So wondering if it is best to just start with ST rules?
Any tips and advice are appreciated
Thank you


You can think of the webCoRE dashboard as a kind of integrated development environment where you can build, test and monitor pistons. The pistons are effectively compiled into ST Groovy SmartApps which plumb into the ST Cloud. The plan is that instead webCoRE should become an IDE building rules for the ST Rules API. All the logic would be implemented by the Rules API and not by a SmartApp.

The plan is that most things that webCoRE can do now, it will be able to do in the future, and it helps that the author of webCoRE is working for SmartThings now.

I haven’t looked at the Rules API too closely, mainly because at the moment it is pretty basic and it seems to me that there is a way to go yet. You can do a lot building on simple conditionals, but where webCoRE scores is being able to adapt to real world requirements by stopping things happening. For example, new users to webCoRE tend to quickly encounter the Task Cancellation Policy (TCP). Imagine you have a light come on when open a door. Once you’ve closed the door you want it to stay on for 30 seconds. That’s pretty straight forward logic. Now supposing you quickly open the door again. Do you still want that light to turn off after the original 30 seconds? By default, webCoRE will assume you don’t and stop it happening, but it will also allow you to decide how you want it to behave. That takes a lot more complexity.

My personal opinion is that you’ll always want to abstract the Rules API using something like webCoRE, or SharpTools, or anything else that comes along.

If you have something you can host your own code on, like an RPi, then you can go down the SmartThings API route ( So code your logic in your choice of language and interact with ST by REST calls.

Depends what floats your boat really.


Not sure about changing the Schlage lock codes but #2 and #3 are a piece of cake for webcore.

Currently, the ST rules API is geared towards ST developers. I am sure it will be enhanced for general users and I look forward to working with it. With that said, there are thousands of webcore users. And the developer of webcore, Adrian Caramaliu, now works for ST and has recently lectured on a "Rebuilt webCoRE that is in development. Like me, many of the webcore users have over 100 pistons running. I personally think that webcore, or a version of it, will be around for many years to come.


Nope, schlage won’t allow that to happen.
The only way to change codes or assign codes is thru lock itself, schlage app with schlage wifi adapter.

But as others stated, you can check to see what # is entered.


The only way to change codes or assign codes is thru lock itself, schlage app with schlage wifi adapter.

I change the codes remotely on my Schlage locks all the time, and also create codes that have a limited number of uses and/or work only on schedule. You just need the proper DTH and/or SmartApp.

Universal Enhanced Z-Wave Plus Lock Device Handler

Lock User Management - Door lock code manager


Thank you so much for the links… I will check them right now…


Yes I’m currently using the Lock Manager (ethayer) which works well to schedule adding codes etc but looking to take that to the automated level by sending the Date and time and user code through the api. Totally new to this so if anyone has any examples using pistons that would be much appreciated! I think with the feedback so far I will move forward testing this through WebCore. Thank you