Why Did SmartThings Move Away From Groovy?

I am trying to find some information and hoping the community here can help. I’ve been using the SmartThings move from cloud to local as a case study with my students as we watch how it all plays out and what we can learn from this if we had our own smart home hub.

This isn’t a question of cloud vs local processing - I think for a lot of things local is the right way to go. What I am curious about is why SmartThings decided to change from Groovy to Edge (Lua) when they decided to make the swap from cloud to local. We know Groovy can be used for local execution quite well (Hubitat does it).

I am curious if the SmartThings team has released a business reason for the change as I haven’t been able to find anything about why the change was made or what benefits we get from Lua we didn’t from Groovy.

They discussed this briefly in one of the official announcements. Lua is a very lightweight client used in a number of embedded platforms, including Ezlo Vera, Roblox, and a bunch of others. They just felt it was a better fit.

I would note that the hubitat hardware specs were designed from the beginning for lots of local processing, which was not true of SmartThings hubs. Although the very first model was a little low on memory, they expanded that significantly in later models, and from the beginning, it was always easy to add more hubs to share the load, something which is typical in Z wave hubs, but which smartthings never did well, except for the Wi-Fi mesh models. (Even now, as soon as you have two hubs in the same routine in smartthings, you force the processing to the cloud.)

Give me a minute and I’ll see if I can find the link to that announcement.

1 Like

Thanks @Puzzling and @JDRoberts. I did read that announcement when it came out and we’ve referenced it in class. It mentions some limitations but not really what those are, or why they can’t solve some of the issues with Groovy that Hubitat doesn’t seem to encounter. I think JD’s point that Hubitat was designed for local processing from the start where SmartThings is trying to retrofit their devices for that is likely a big part of it too when it comes to how much space the compiler and architecture take up on tje device.


Also, remember that the smartthings system does have a continual cloud connection even if you are using edge drivers. That’s how the app gets updated with device state and how the hub receives requests from the app. Also, some automations still run in the cloud. And everything gets logged there. So that’s a whole set of processing requirements that Hubitat does not have.

If you’re wanting to run device drivers on a local hub with limited resources, Lua makes an excellent choice over Groovy or other JVM based environments.

The SmartThings hub has a single core 1GHz (for V2) or 528MHz (for V3) CPU. The Hubitat C5/C7/C8 all have quad core ~1.5GHz CPUs.

SmartThings V2 and V3 hubs have 512MB and 256MB of RAM respectively. The C5/C7/C8 all have 1GB of RAM.

Trying to fit a JVM based environment into those constraints would be difficult at best and would likely not offer the performance needed when supporting a large number of devices. Lua offers a tight byte code interpreter and a memory and co-routine (threading) model that fits an existing device with limited resources.

Samsung was wise to not try and wedge Groovy running locally for devices into the V2 and V3 hubs.


Still puzzle’s me why they cut everything in half with the V3 instead of doubling it like they should have.


Just designing to a price point, I think. Probably the same reason they dropped Zwave from the new Station.

Part of the explanation at the time was that the V2 had been designed with the thought that they were going to have a much tighter video integration with security cameras (at one point, this was a paid subscription option.) than they ended up with, so they decided they didn’t need the same specs for the V3.

But I think mostly it was just price point.


Maybe, if we assume that there is somebody responsable for the long term product development, the concept is to incorporate hubs into TV, washing machine, oven etc and so price and a lightweight design are important. Although initially considered that Matter would be the end of the hub, it’s not clear that it will control all specialised functions.