Replace Groovy with Automations—what’s your plan?

If you are using a custom device handler you can switch back. If you are using a stock device handler and they have switched over to Edge then you will not be able to. If you provide the brand/model, someone may be able to provide a definite answer,

Question is - why would you want to switch back with less than 8 weeks left using groovy :slight_smile:

During the transition period for the next few weeks, maybe, at least to a custom groovy handler that you already had on your account. But once the free Groovy cloud is shut down, it’s gone, and you won’t be able to switch back.

It’s for a FortrezZ MIMOlite, which I was using to send a notification for my smoke detectors. I copied the handler from somewhere else, but then I published it for myself if that sounds right.

I normally don’t keep up on Smartthings that much, but I have a Zooz Zen17 that I’m trying to add for some garage control. And when I went to add that I discovered I couldn’t add things to Groovy anymore. So, I was contemplating on abandoning the groovy stuff and switching things over to Edge. Homeseer leak sensors are the other hardware that’s in handlers.

Clarification: how would you switch back if you have to delete the custom device handler in order to get the new edge drivers to take priority over the legacy custom device handler?

Have a similar situation I’m trying to solve for across multiple hubs using the same custom device handler.

at this point, you are kinda trapped. You can switch to Edge but you can’t switch back to a custom device handler that you would need to remove in order to get the Edge Driver. In 2 weeks (tentative), groovy should go away unless they modify the end date.

2 posts were split to a new topic: Need help with after groovy options


Also the ability to pause/unpause a rule.
Add variables too?

When is RULES API going into effect? I want to have better notification options like when Door opens, push notify me, but only once every xxx minutes.

Maybe I’m a little confused, but how do I activate and use the Rules API on ST? I’m been using Routines, after the disabling of Webcore.

You can use the rules api now.

Rules Docs

Github rules docs and examples

Rules Api community

Once I got postman set up I was able to replicate all of my webcore stuff, plus add a few new automations which I had been thinking of doing but never got around to.

Start with the smartthings cli. Having that set up makes postman easier, for me.


Routines is a GUI for the Rules API. So is Smart Lighting.

Routines are slightly different, in my experience. For example, routines sunrise/sunset work dynamically, sunrise/sunset only pick up the time when the rule is published (is static) in rules api.

Rules support if/then/else, with nested if/then/else. Routines are if/then.

Just because the API supports it doesn’t mean the GUI does :slightly_smiling_face:

1 Like

So for clarification, the Rules API is the “engine” that supports the Routines (which is the GUI). So if I’m still seeing lack of options on Routines setup, I just know this is the best we got natively using ST routines at this moment?

1 Like

That is a bug which I believe only appears in cloud executing Rules. It broke in about September 2021 and hasn’t been fixed yet.

Aside from the limitations of the simple structure, the Routines are actually exploiting a significant amount of the functionality of the Rules API. Indeed functionality appears in Routines long before it makes it to the public Rules, if indeed it does at all. You can’t use notifications in the public Rules API, for example (a really sore point …).

I wouldn’t say ‘at the moment’ though. It seems just as likely that Routines are deliberately limited Noddy and Big Ears automations.

Rules and routines are the same, but they work differently if they are executed locally versus the cloud? So a cloud executed routine will not have valid sunrise/sunset, and a local executed rule will? And you can send a notification with a routine, but you can’t with a rule.

But, typing this reply it says the topic has been solved. Disregard.

Not deliberately, but it can happen. Back in time you’ll find differences in behaviour between the SmartLighting ‘rules’ in the cloud and the ones baked in the hub firmware. I’d imagine it may have happened to device handlers and the protocol handlers in the hub too.

The topic says it has been solved because the original poster who created the thread got their questions answered in one of the following posts. But that doesn’t keep people from continuing to post comments and questions, and continuing to get responses to them. If we get too far off topic, some comments may be moved to a new thread. But “solved” is just from the point of view of the original poster.

I have no clue what this means.

But overall, I was able to set up my notifications in Routines the way I needed with just a virtual switch as an intermediary. Thanks to others with that suggestion.

1 Like