Replace Groovy with Automations—what’s your plan?

SmartApps & Automations
1

So Groovy has reached EOL and many of the cool things we all have made goes with it.

There are especially two things I am very fun of in my programming:

  1. Dim light when no one is in the room, but only for a while before switching off (instead of just shutting it off right away)
  2. The ability to know who currently owns a device at a given time.

Number two is about having more than one automation schemes to control a group if devices without interfering with each other. The automation that is first activated, will then own the devices until another automation decides to take ownership of the same devices and run it from there. Eg. depending on how you enter the house and/or the time of day, you might want the light to reflect that.

Looking at the Automation today, I might be able to achieve pretty much the same, except that for every Automation I build, I will have to build the entire chain of events every time. That will be huge and complex to build.

With Groovy I only had to build this once, and then I could simply add a new instance in the SmartThings app without having to deal with all the logic behind. Also, with Groovy I could build forms only containing what needed to get it right in my house.

It seems to me, that SmartThings now replace “smart” with “easy”. It is easy to build an automation with one sensor and two light bulbs, but very difficult if you want to extend this further.

What are you guys’ plan to do after Groovy?

I am particularly interested to hear if you have found easier ways to handle the complexity or perhaps if you have found new platforms where you are in better control.

1 Like
2

one option in regards to Automations → SharpTools Rules Engine is probably going to be the easiest.

There is also Rules API

4 Likes
3

Before we start, for any given piston/custom smartapp it’s worth checking to see if you can do that with routines in the smartthings app. You can ask for help figuring out how to solve any one use case in the following part of the forum:

So far, it looks like most people who have found that the basic routines in the ST app aren’t enough to replace the custom groovy they are losing are doing one of the following:

  1. try the third party rules engine in SharpTools. Very nice browser-based visual interface. More powerful than the basic ST app, although not as powerful as Webcore. They have a free tier and a pro tier at $30/year. Free trial. Works with the new ST architecture. They do accept feature requests for new features voted on by the community, but as you can imagine there’s a long wish list right now. Worth a look for most people. (It doesn’t run locally, but then neither did your old custom groovy.)

This option lets you keep your ST/Aeotec hub and continue to use the ST app. It just gives you a new place to create rules. So probably the least disruptive choice.

2.a. jump ship, rebuild everything from scratch in Hubitat, use Webcore over there, and maybe add SharpTools since the hubitat app is a little rough.

This is a lot of work to setup, but it still runs groovy so will feel very familiar to developers. Most devices will work although early generation GE switches might not. Everything runs local except third party integrations like voice assistants. Active forum community. But Family members will have to learn a new interface.

2.b. keep your devices in SmartThings, add a hubitat hub (hubitat just announced in late December 2022 that they are going to offer Webcore as a built-in application on their hub.) and use a community-created integration between the two platforms.

This will probably be a little more fragile than option 2a, but means you don’t have to go through the effort of moving each individual device over. Instead, you’ll be creating proxies for them on the hubitat system.

[Endpoint SmartApp] HubiThings Replica

  1. move most logic to home assistant, while maybe keeping your ST network running as well. This might be the most powerful option but also requires the most technical skill. Open source. Programmers who switch to HA generally say “Why didn’t I do this sooner?” Non programmers often try it for a month or so, then move on to a friendlier system. It’s always a candidate just because of its power and relatively low cost, but it can be overwhelming. Some people add SharpTools to it for a family-friendly interface.

——-
Of course there are other options as well, including writing and hosting your own custom smartapps that use the ST REST API, but so far the above 3 seem to be the most popular.

  1. The official replacement is the new Rules API, but it seems to have a steep learning curve and not a lot of documentation so there haven’t been that many people who report using it. It does have its own section in the forum.
  1. Tasker and the REST API. If you have an android phone and are comfortable using the third party app Tasker, @Jake_Mohl has been doing some great work figuring out how to use Tasker to access the smartthings cloud API, essentially substituting Tasker for some of the previous custom groovy smartapps. It’s very clever work, and as long as you’re OK paying the license fee for Tasker, or already have it, it can be very useful for those with android phones. Here’s the thread with the examples that he has so far:

This method feels more technical than using SharpTools, but it’s also less expensive, and may not cost anything extra if you’re already using Tasker for other android functions.

  1. If you have strong, technical skills, and you’re willing to set up a separate device to be a server, one community member has a “how to“ on creating an “automation box“ (that server device) using Node Red to create the automations. This supports some very complex rules, but it definitely has more of a learning curve than Sharptools.

Unleash the Power of SmartThings with Advanced Automations Using Node-Red

SPECIAL PURPOSE SMARTAPPS WITH OTHER ALTERNATIVES ON THE NEW PLATFORM

A) Probably the most common of these was combining a relay and a tilt sensor into a garage door control. Zooz had a smartapp to do this with its devices. There were a couple of other custom smartapps with a similar purpose.

For those specific use cases, there is a very clever virtual device edge driver that might be able to give you the same outcome. Here’s that one.

[ST Edge] Virtual Hub Kit [BETA]

B) vacation Lighting was another popular smartapp on the old architecture. As of September 2023 there are now several different ways to replace this, depending on your exact needs and set up. Here’s the thread discussing those:

Is it possible to create a routine to turn lights on/off when away?

Rboy Smartapps

If you are using any Rboy SmartApps, he has been working with SmartThings on a transition plan, but there aren’t a lot of details. There is a transition FAQ on his site:

9 Likes
4

I have started #3, and I agree its a bigger pain in the butt than one would think. In the long run, its probably the correct decision, but man nothing definitely works out of the box, it requires a lot of tweaking and searching forums.

2 Likes
5

Samsung Automation Studio and/or Node Red are also an option

3 Likes
6

No plans, I dropped it a year or so ago. Smart Lighting and webCoRE were replaced by the Rules API. I don’t want to use Routines and Scenes because although they are built on the Rules API they are managed by the mobile app and I do not consider them safe to use. However I do use Routines because the functionality to handle announcements and notifications is not yet available and/or not documented for the public API. I also use Scenes because it is possible to execute them directly from a Rule, but I would be happier to see them removed from the API and treated like Routines, with the ability to execute another Rule added to the Rules API.

If I want any SmartApps I host them in the cloud and I currently just use PHP because I haven’t found a reason not to. I have had a dabble with the Samsung Automation Studio but don’t really have anything I need to create with it. It really needs some third party stuff adding to it to be worthwhile though.

5 Likes
7

Thanks all for your suggestions and comments, highly appreciated :+1:
I have always considered Samsung SmartThings Hub a bit like a toy because the entire infrastructure rely on having a working internet connection along with all the other systems needed out there to get it to work. It happens almost every day that I enter a room and the light doesn’t switch on :grinning: Perhaps its time to change.

Hubitat Elevation sounds like a good choice, but also SharpTools Rules Engine on top of my existing Smartthings hub could be an option (must read more about it).

Thanks
Peter

1 Like
8

I saw the writing on the wall 2 years ago - SmartThings was going to end Groovy SmartApps without first having a clear, complete, local platform for automations. At the time, the WAF for all automations I had using SmartThings was terrible - she hated that everything was unreliable or randomly delayed.

As a result, with my new kitchen (Recommendations for kitchen remodeling (2020)), I went with Hubitat. The advantage is an all local, reliable automation platform. The WAF in our household has gone from “no way” to “can you make the pantry lights go on when I open the door?”.

Home Assistent will likely give you a similar result (reliable, local).

Clarification: it’s 2 years later and SmartThings still doesn’t have a clear, complete, local platform for automations. Nor are Edge device handlers out of their extended “beta”.

4 Likes
9

The irony is that Edge is designed to allow for an more local more reliable platform, increasing WAF with quick automations for things like lighting. So far, for our use case, its doing that. There’s pain to get there, sure. I agree that the extended-extended-extended-beta is troubling!

10

Clear being the keyword here IMO. We know Edge devices run local, and that’s great. Rules API can run local, which is great. But it isn’t documented anywhere (that I know of) what combinations of capabilities, conditions, etc. determine a local Rule vs cloud Rule. People in the forum only know from testing themselves and even then it seems to change by some background config that SmartThings changes without any notice (i.e. remains changing a month or so ago from cloud to local and back to cloud. Add on top of that the mobile app that, with seemingly every update, seems to add functionality and break others in the Routine builder, also without any notice/change logs.

6 Likes
11

One of the most important aspects of my current ST setup up is sending HTTP requests to local devices on my LAN based on events (switches/virtual switches/sensors). So far I have yet to discover if this will be possible using any of the new stuff.

Does anybody know?

12

Should be, thanks to some amazing work by @taustin.

Take a look at the custom edge drivers on the “Services” quick browse list in the Edge Driver section in the community-created wiki. :sunglasses:

https://thingsthataresmart.wiki/index.php?title=Quick_Browse_Lists_for_Edge_Drivers

1 Like
13

Thanks JD! This might actually save ST for me.

Now if I can just figure out if it is possible to port the Alexa/Lambda SmartApp I have based on @N8XD 's work.

1 Like
14

I am facing the exact same conundrum as the OP…

My options:

Stay with ST and just ditch the idea of persisting all my WC pistons somehow altogether, losing all that functionality I have spent ages building. This would make me cry and is not really a feasible option for me.

Make the move over to Hubitat completely. From what I have read, seems like a great move to do. Local execution. Reliable platform. Could still use WC and all my existing WC pistons. Aside from the pain of migrating devices etc. across to the new platform, minimal disruption to my smart home.

What’s not to like? Well, the answer to that is the HE mobile app; it is terrible. The ST mobile app is quite polished (in my opinion) and I would miss it a lot. Also, will Hubitat continue to support Groovy SmartApps such as WC forever…who knows?

Run ST and Hubitat in parallel (2 hubs). Use Hubitat as my master hub and migrate all devices etc. across to that. Use the HubConnect SmartApp to bi-directionally send/receive device messages between a master Hubitat hub and slave ST hub. This would mean I could benefit from the brilliance of Hubitat (local, reliable) and still get to use the more polished ST mobile app. Sounds great, right? Except for the problem that the HubConnect SmartApp is a Groovy app, and would therefore fall foul of Groovy being shut down on the ST side. So not really an option after all.

Explore the possibility of using SharpTools instead of WC, and keep everything on SmartThings. I already have. I registered for my free account as I was impressed by what I had previously read about SharpTools’ rules engine and its capabilities. However, the very first WC piston I attempted to migrate across to SharpTools - at random from my collection of pistons - instantly met with a blocker. It appears that SharpTools doesn’t (yet?) have the functionality to remember a device’s state before performing some other action.

Example: my Ring doorbell button is pressed, WC piston is triggered, a certain set of Hue lightbulbs’ states (dimmer level, colour, on/off etc.) are remembered by storing the states, then the aforementioned lightbulbs are turned on and made to be blue for 5 seconds, to visually indicate the pressing of the doorbell button in case I failed to hear it for some reason, after those 5 seconds the lightbulbs are each returned to whatever their previous states were (on/off, dimmer level, colour etc.) before the doorbell button was pressed.

WC does this just fine. SharpTools doesn’t appear to be able to remember device state, so I cannot migrate that particular piston functionality from WC to SharpTools. Of course, I’m not going to be a total idiot and simply write off SharpTools altogether just because it fails to mimic the functionality of that 1 WC piston (that I’ve found so far), but I do want to retain some order in my smart home and try to keep everything in a single-ish place. WC lets me achieve that, SharpTools - at the moment - will not.

I have read a lot recently, given the impending doom of losing Groovy SmartApp execution in ST, that between the ST mobile app’s built-in Routines/Scenes and new Rules API, I could probably manage to migrate all of my WC piston functionality into that architecture. Adding to my confidence in doing so is that the new Rules API was apparently designed with WC in mind, as ST knows how important WC is to its power users. The original author of WC, Ady, was also involved in the design of the new Rules API, so I have read. I have even stumbled across some old SDC presentations, where the new Rules API was said to be being built with WC’s power and functionality in mind. This is all great so far.

But Ady has left ST. Nobody on the WC side seems to be visibly doing anything to get WC working with the new Rules API. And the SDC presentations I have watched appear to show a design direction that “seemed a great idea at the time”, but hasn’t made any movement towards those goals since. I might be wrong.

I am comfortable with JSON, as I use it everyday in my job, but in order to achieve some complex WC piston functionality and logic in that JSON for the new Rules API, it seems I need to be able to write God-level JSON and place all my faith in not getting confused too quickly by the new Rules API’s JSON constructs and getting lost in it all. On the face of things, it would seem to lead to a debugging/troubleshooting nightmare too.

I have also read about the “SmartThings Rules Manager”, and seen a demo of it on the glitch.me website (that link, by the way, was extremely difficult to find amongst all the noise on the various forums surrounding this impending issue). However, I have no idea how to use it.

I would happily try to gradually migrate all my WC pistons into the new Rules API, if only there were some decent documentation to begin with. It just seems non-existent, other than mentioning the API endpoints and JSON schema. Is there any dashboard/GUI thing for using Rules API?

Just my contribution to this thread really. Many people seem to be in the exact same boat with this, yet there doesn’t appear to be a clear way forward yet. And time is ticking.

4 Likes
15

I was originally planning on using that since i also own a Hubitat hub, but didnt bother since Groovy is going away.

I’m hoping someone figures an easy way for the two systems to talk.

16

Their whole platform is Groovy. They’d be fools to toss away 7 years of device handler and SmartApp development.

(and they don’t run Groovy in the cloud like SmartThings; it runs on your hub. No ongoing support costs to stay they way they are)

1 Like
17

Never say “forever,” but since the Hubitat platform runs most things locally and you always have the option to refuse a platform update, if you have something that runs well now you can continue to run that for as long as you like as long as the hardware is still working. :sunglasses: that’s true for other locally based systems as well.

Smartthings has a double vulnerability because so much runs in the cloud and because they can force an update to our hubs which we can neither decline nor delay. So you have to accept that they are in charge of what changes when. But that’s not true of all systems.

1 Like
18

JD… If I unplug a Hubitat hub from the internet, any idea how long it will work? I get it is supposed to be local… but is it really?

19

it really is. It will run everything locally and never needs the internet. Cloud integrations fail of course. But there are those that run theirs completely off the grid and are fine. Only putting it online (perhaps via cellular) for occasional updates.

4 Likes
20

What about the mobile app? Same there as well?