The End of Groovy Has Arrived

Yeah, that was sort of the point of that post. It’s not as simple as “if you’re using a stock device type handler you’ll be OK.“ There are too many exceptions. :thinking:



I have a question about the Connected Services SmartApp.

I created a SmartApp in Developer Workspace, and it is hosted by us as a Webhook SmartApp. So it is not based on Groovy.
Can I continue using it in SmartThings mobile app?
Can I create SmartApp like this after 15th Oct 2022?


Tagging @nayelyz , but as far as I know the announcement only affects SmartApps running in the groovy cloud, you should be fine since you are already using the new architecture.

I’ve been using WebCoRE like many others on this site to do things that the basic rules in the SmartThings App can’t accomplish; I accept and acknowledge that things are changing! If you’re staying still in technology then you’re dying…

I started looking at the Rules API as I don’t particularly want to rush out and buy new hardware or switch to an alternative platform; I realize I have to spend some time and energy to make things “right” again! OK!

So why write?..

  1. To vent
  2. Is it me or is the rules engine really ugly to use?
  3. I look on the Sample-RulesAPI on github and don’t really see too many commits; is this dead before it even starts? I’m not sure I want to invest time only for it to get replaced with something else (hopefully better and clearer)?

Come on Samsung, give us something concrete to work with please?

If I’m misplaced please tell me why :slight_smile: I’d be very happy to be corrected…

1 Like

Thank you for the tag, @JDRoberts :smiley:
@Jun_Li, yes, the dates shared here correspond to the Groovy-based integrations (SmartApps and DTHs) in the IDE. The endpoint app registered in the Dev Workspace isn’t part of that environment.

1 Like

yes, its very ugly because it’s an API. It’s not really meant to be used directly. Instead it should have an application for the UI to call the API. Routines in the mobile app does this. But there has yet to be a more complex UI for Rules API created.


Isn’t that what “Routine Creator” (beta) is supposed to be?

The app needs a way to group or sort routines by room or something, it’s not great.

Makes sense; the problem being that one rules UI is deprecated without a replacement being made available… Folks will undoubtedly leave the platform in this case, chose your poison so to speak!

gst - where’s the “Routine Creator”? I think the app needs lots of things but to be honest there’s a UI/UX challenge in not making it overly complicated for new users.

1 Like (currently a closed beta)

Thanks - Just found it in another thread :slight_smile:

Depends how you choose to use it. Currently I write Rules in raw YAML in text files as the CLI will consume those directly. I find them quite readable, although quite spaced out, and with nesting they get awfully wide. It meets my needs at the moment.

However Rules are just simple data objects. A combination of however you prefer to describe arrays and key-value pairs. They are defined in JSON because the SmartThings API consumes and outputs JSON, but you can write them in any language you like that supports those constructs. There is a strong chance you can trivially export to JSON given its ubiquity. You can write them as scripts that automatically install the Rule if you really want.

How do we get access to the closed beta? Might be helpful to many of us…

1 Like

Its a depricated project.

Look at post 662


Multi gang switch.
I have a 2 gang Zemismart switch in my kitchen currently using a DTH.
When this migrates to edge will this now move to a single switch with two controls, and will I lose the ability to control both lights from Alexa?

As it stands now, only the master component will be exposed to Alexa.

The workaround is to create a virtual device for each subcomponent, use routines to keep those in sync with the actual switches, and have Alexa control the virtual devices.

It’s annoying, and it’s extra work, but the problem was reported last year and isn’t fixed yet, so I’m not holding my breath on it. :thinking:


Thanks, workaround is a bit painful, thankfully I only have one multigang switch at the moment

1 Like

@Mariano_Colmenarejo ZigBee switch with child’s Mc Edge Driver is probably what you are looking for. It will give you 2 separate switches if that is what you want. It works well with my 3gang Zemismart switch.


Thanks for chiming in - I can see this as quite powerful. I have the cli setup this week but didn’t really digest everything just yet; I took a look at the example using Postman but given I like to keep things simple I’m reluctant to go down this path. A yaml file with cli injection would be a good place to start playing around. Are there any decent examples (or tutorials yet); this all needs a modicum of comprehension in terms of exploring device-id, things that can be changed etc… (I’m not there yet!)

A simple task I’m looking to complete, I turn on a light based on motion detection, after 10 minutes it switches off (I have kids!), however, if I turn on the light switch manually it stays on. I believe a variable is needed to store the state (e.g. manualActivation == True/False). If I’m reading the threads correctly this can’t be done as there are no variables in the rules engine?

thanks for that, will that be deployed automagically when groovy is shut down or will i need to take action then?

You can use a virtual switch to store status