Groovy is on the way out Smartthings Edge is the replacement

I guess difference of opinions on this. I’ve been using Lua for ages and have never encountered a problem with the way they develop. Their development practices are a little old school, but it just means it’s robust and stable.

The lack of a glitzy batteries included installer/distribution probably comes down to the fact that they’re more interested in in the embedded use case than the general scripting language use case. Which, is perfect for us.

I genuinely believe there wasn’t a better option for us to choose for our use case.

Ah, yeah, good note. Until about a month ago, the live logger was a separate tool. It probably doesn’t make sense to keep that section separated anymore. I’ll bookmark my post for a reminder on Monday.

Yeah, this beta release is somewhat developer focused. We need to base functionality there first, then we’ll go about making it more non-developer tinkerer friendly.

There’s only so much time to get everything done with a small number of engineers working on it. :slight_smile:


True, but what you get is a DLL and I’ve absolutely no idea what to do with it.

Doesn’t really matter. Those who really need it will probably have a suitable development environment for it, or will be able to create one.

I just don’t, and even something as seemingly trivial as an RPi represents more clutter. It also makes no sense for me.

1 Like

For Windows development, I would like to see documentation to use / package integrated with a major IDE, like VSCode, which has a zero cost to entry. Being able to develop with templates straight in the IDE, with hooks to run the CLI and even debugging/logging access right there.

Something along the line of:

  • install Visual Studio Code
  • install development package for ST Edge
  • link to ST CLI

You’ll get a lot more buy-in if the barrier to entry is low under Windows.

As much as I didn’t care for the Groovy web IDE it was mostly feature complete and allowed development anywhere. You had a basic editor, some code control, test harnesses and logging, all without installing anything.


To be fair, Groovy doesn’t need to be compiled, so The tools can be a lot simpler.

1 Like

We are working to make the setup more streamlined, and for VSCode we already have auto completion and some other features.

Code templates and a full plugin for VSCode is an interesting idea.



If I understand correctly, this is only for device handlers, how do we integrate smart app with device handler?

I need a way to specify what LAN device type and IP address (no ssdp, mdns, etc), and also general settings for all the LAN devices?

You can configure settings as device preferences.

1 Like

Groovy was compiled into byte code and runs on a JVM.

Lua is also compiled into byte code and runs on It’s own interpreter/vm.

They’re similar from that point of view.

1 Like

Fair enough. I was unclear, so thanks for the correction. :sunglasses: My point was intended to be that using them with SmartThings is different, because the person writing in Groovy will just need to write their code statements; everything else is in the SmartThings cloud. From the original ST developer documentation:

SmartThings development does not require you to have a copy of Groovy installed, since SmartThings code is executed within SmartThings infrastructure, but having a local copy of Groovy is useful for learning.

But you made the same point more elegantly in your post above:

{In the existing groovy IDE} You had a basic editor, some code control, test harnesses and logging, all without installing anything.

1 Like

For modifying existing drivers you only need a code editor and the CLI. The key word with the web IDE was that it was limited. VSCode is very good, on all platforms, and free. Change always comes with some kind of learning curve, but we really do want the developer experience to be better than it was before.


My angle was just that the existing web IDE was super simple to work with and as you said easy to modify existing drivers for customization or tinkering.

I’d love to see a similar curve for Windows for Edge. Make it easy to bring down existing drivers, customize and publish back to your hub, all within VSCode. Sounds like that’s part of the plan, just wanting to give a vote for all of it under Windows.

I’m really excited to get started with porting some of my more obscure devices. Especially once I have some of @krlaframboise work on Edge to learn and build from.


Jody - During alpha, using anything later than Lua 5.3 led to problems for me. Have those issues been resolved and we can safely use more recent versions?

Which version of Lua should I install? My working environment cannot load the API normally now, I suspect it is the Lua version problem, ordinary Lua programs can run normally.

There are still some unanswered questions regarding when the shutdown of groovy happens and what it will actually look like.

I believe you should use this one just to be on the safe side for now, until they provide an official update on the issue.

Correct - stick with 5.3 for now for your off- hub development and testing.

And if you have multiple versions installed, take care that LUA_PATH is pointing to the 5.3 libraries.

1 Like

this statement should be in the DOCUMENTATION. i just killed half a day trying to figure out where to get a usable LUA package.


Without replying to any specific comment here, I wanted to thank everyone here for the feedback. As you know, we’re still in beta and hope to address feedback items (e.g. improving docs or otherwise improving the getting started experience on all platforms) as we move forward.

As Jody alluded, hopefully in the future we can provide a bit more of a picture into why we made some of the design/architecture/technology decisions around edge drivers. Large designs always involve tradeoff and we believe are well on our way to shipping a solution that moves the platform forward in a significant and exciting way that will be a better experience for users and for software developers building on the platform.

As compared with Groovy DTHs, the development and deployment methodology for edge drivers does definitely require familiarity with the CLI, out of browser development environments, etc. While this model does make it a bit more difficult to get started (especially early in the beta) driver channels and other mechanisms should reduce the need for non-developers to need to directly interact with code. And for driver developers, the design of the APIs and deployment via CLI/APIs makes possible and encourages mature projects to adopt CI (Continuous Integration), module decomposition, version control, unit testing, and other methods which aid with building mature, correct software. It also provides a solid base on which to build more rich tooling to improve the developer experience (e.g. a vscode extension).


I’m more of a VisiCalc user.