The End of Groovy Has Arrived

I have read thru the email I received from ST as well as the transition FAQ and also browsed thru a bunch of threads on all this here in the ST Community. At this point I’ve decided to go with Option 1 and just wait and see what breaks and then try to fix those items. But how can I easily tell how big of a problem I might end up having? Is there some way to just look thru my list of devices in Groovy and get a general feel for which ones might be a problem? My devices are just run of the mill z-wave or zigbee devices. Device types are listed in Groovy as - Z-Wave Dimmer Switch Generic, ZigBee Switch, Zigbee Metering Plug, SmartSense Button, Fibaro Motion Sensor ZW5, Z-Wave Switch Generic, ZLL Dimmer Bulb, and SmartSense Moisture Sensor. How do I know if any of those will be a problem? Seems to me the guidance and instructions to prepare for the transition could be a bit more specific.

1 Like

Did you install a custom device handler for this device or is that built in? All the others look like stock DTH, which means they should (should!) transition gracefully to a stock Edge driver during the migration.

I did not install any custom drivers for any of my devices.

Then you shouldn’t need to worry about anything.

1 Like

Thanks for that and that is what I was thinking/hoping but the way the ST folks are communicating about this is really unnerving. For instance the email I received from ST states that 1 - “You may have one or more devices using legacy device handlers” and 2 - “ You may be using a SmartApp automation” without providing any indication of which ones or even how to determine which ones. And then it goes on to say that MOST will be automatically transitioned. But no guidance as to if the ones I’m using, which they didn’t identify, may or may not be and no guidance as to how to know. The email may have just as well said…”all your stuff may stop working, or it may keep working, good luck!”…:man_shrugging:t2:

1 Like

It’s a little more complicated than has been suggested. For example, if you manually changed your device to use a stock DTH in the IDE, it may not be transitioned.

See the following for the details of some of the special cases that might affect you

What do I need to do to get ready for Sept 30? - #2 by JDRoberts

TAustin has a very comprehensive Edge Virtual Devices driver that supports lots and lots of different device types. Check it out [ST Edge] vEdge Creator: a virtual device generator for end users

2 Likes

I read thru that post early on and it provides lots of good info but honestly just created more confusion than clarity. It just made me even less sure of the size of the problem I may or may not have…

1 Like

I recently switched from using SmartLighting, where you can mix specific time and Sunrise/Sunset for time periods, to using virtual devices as precondition to control when a trigger is allowed to happen. I then set the On Time and Off Time for the virtual device in its config dialog. I thought about using Location Modes, but there are too many various combinations of when I change modes for various situations to keep things straight. Using virtual devices to represent specific states that you want to detect is easier to manage. This is a straight forward and simple to use method until Routines support mixing specific and relative times.

2 Likes

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:

2 Likes

Hi

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?

Thanks.
Jun

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.

4 Likes

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

https://routinecreator.smartthings.com (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.