The End of Groovy Has Arrived

The option exists to run Groovy code on Hubitat, either as a replacement for your SmartThings integration, or in parallel, as I do.


Many options these days, although as @orangebucket noted an even larger group probably don’t have any of those. Most “SmartThings” users have a Samsung smart television, smart appliance, or smart vacuum. Many have a Galaxy phone and some have a Galaxy smart tag. That group alone is millions and millions of people, far more than those that have a hub.

But beyond them, you can have quite a nice hubfree environment with a ring doorbell, Arlo cameras, Nest or Ecobee thermostat, any of several WiFi light switches (including ones from Meross, TP Link Kasa, or even Leviton if you’re in the US), smart plugs (again from TP Link Kasa or Meross), sensors from Shelly (they’ve done remarkable things working with SI labs on improving the battery life of small Wi-Fi devices), Yale or Schlage WiFi smart locks, even inline UL listed WiFi relays from Shelly.

All of the above have official SmartThings integrations and work out of the box without custom code required.

And all of that’s without Matter, which will eventually bring even more hubfree choices.

Add the Thread Border Router inside many smart speaker models these days and that will open up another whole set of easy to install choices once Matter is widely deployed.

So the real question is why have a SmartThings/Aeotec hub if you don’t already? Right now the only answer is Zwave or zigbee devices without another hub.

Choice is good, and there will certainly be people who choose that option. But they are a small percentage of a small percentage now.

I’ve been trying to think of a device class (not protocol) that isn’t available in a hubfree option. :thinking: The only one that comes to mind is batterypowered rotating valve shutoffs. They just use too much power for current WiFi to offer a suitable option right now. There are dumb mainspowered ones that you could run off a WiFi or Thread smart plug, though, so it’s really just the subclass of batterypowered that’s missing. At least until somebody makes a Thread version.

But everything on your list can be done now with mass market products currently available.



To be honest I think I was being a little harsh with my OP and most of my devices still work, all that has broke is the Hive Integration and I only use it for the Lighting side with SmartThings, for that I may move to something like Philips hue or similar.

That being said, I hope ST keeps with support for 3rd party integrations whilst keeping support for Z-Wave and Zigbee; that’s why I invested in ST in the first place after I got fed up with X10’s weakness, mainly prone to interference, lack of stylish/discrete products, and overall archaic nature of a 70’s automation protocol.


Is that a fact or your personal suspicion/prediction on the future?

A diverse centralised communication protocol platform like Z-Wave and Zigbee is king to me, I have 30 Z-Wave/Zigbee devices in total inc remotes. About 80% Z-Wave and 20% Zigbee.

It’s a fact. The new Samsung station hub offers Zigbee, Thread, and Wi-Fi, but no zwave. This has been much discussed in the forum and in blog reviews, but it’s admittedly not obvious from the product description except for the absence of the Z wave logo. :thinking:

Some Community members already have it. Discussion in the following thread.

New SmartThings "hub" the Station


Yes, it’s a fact. It’s been widely discussed that the SmartThings Station does not have a Z-wave radio. No need for a prediction as it’s shipping now.


Same with my ST fridge Family Hub - Zigbee and Thread with the ST Dongle added, Matter and Wi-Fi native to the fridge. No Z-Wave.

Will be the same situation with the TVs.

1 Like

Device execution might happen locally, but I don’t see a decreased dependency on the cloud. Everything still updates the cloud on each event. It still seems a cloud based architecture.


The cloud isn’t required for automations if the devices involved are running locally. That’s the big advantage. If you are using the app directly, then yes, the cloud is involved. If you do something like have your thermostat change state based on windows being open, that can run locally even with the internet down. Depending on the devices involved (Zwave, Zigbee, etc.) it may even work with your wifi down as well.


Yup… and replacing it all with a CLI is just lazy (which pretty much defines ST development since 2015).


The only reason I got involved with SmartThings is, I was starting to read up on home automation about 5 or 6 years ago and saw a SmartThings home kit that included the hub (v2), 2 multi-purpose sensors, and motion sensor for a really great price at Bestbuy, so I bought it. Once I set that up, since the hub had Z-wave, I started to change over some light switches to Leviton z-wave switches. So z-wave is important to me, and the hub is crucial for my scenario.


I decided to test local execution today, after about 90 of my 110 devices now are migrated to edge drivers, either automatic by Smartthings, or by me manually.

I disconnected my router, so no internet in the house, and then I pressed some zigbee buttons that should turn on lights.

It did not work!

Everything is marked to run locally, all devices i used are running with edge drivers, and the rutines are showing this little symbol (a house), that the routine also run locally.

So my questions:
Do local execution (without internet access) work for anybody?
Is local execution only working from the date when Smartthings close down the Grovey IDE?
Do I have to set something on the hub or somewhere to enable the local execution?

I thought the hole idea of transition to rules API, and LUA edge drivers, was to get local execution…

You should be able to get some local execution and it shouldn’t require you doing anything special.

I honestly don’t know how the house icon works now. @jkp might know more.

There are quite a few things that can cause a routine to require the cloud, though. That includes scenes. @h0ckeysk8er has a list of what he’s found so far.

If you can post a screenshot of one of the routines that didn’t run locally when you expected it to and also tell us the brand and model of the devices included, we might be able to say more. :thinking:

1 Like

My understanding is only routines work locally, button pushes still require internet but like @JDRoberts said, im kinda lost these days

I investigated a little more, and found out that the routines for my devices actually was not marked as local, meaning missing the little house symbol.
It seems if Smartthings automatic migrated some devices and not all devices in that routine was migrated, also the routine itself stayed in cloud mode (missing little house symbol).
I then copied each individual routine, made a small edit, and saved it again, and then it show as local routines.
After edit of routines, and they show they are local, it works without internet :slight_smile:

You can see on the picture, the small house symbol, then it’s local. (All text is Danish)


Local execution has worked for me on several occasions when my internet was down. Of course not everything works.

I have broken up some automations into 2 separate automations. The 1st has only local devices and the 2nd has nonlocal devices and/or notifications. This allows the 1st automation to fire without the internet when needed.


It is my understanding that Scenes are not Local, currently. Even if you can get the API Viewer+ to show them as Local, they do not run Local. I am hoping that this will be fixed in the future.

I had to open the automation or scene, make a minor change, reversed the change, and then saved. If they qualified for Local, they then show the House symbol or are reported as Local via API.

If you are not familiar, API Viewer+ is a very helpful tool!

1 Like

My understanding is the the Scenes do run execute locally but there is no way to tell them to so do without the cloud.

1 Like