This is a nightmare

The recent announcement by SmartThings about retiring the Groovy platform has created a nightmare for me. After reading so much, here my conclusion:

There is absolutely nothing I can do to find out if my device has an Edge driver or not.

How am I supposed to know if my device will continue to work after the transition? No idea.

Why isn’t there a spot where I can easily see if my device will definitely continue to work after transition? Then I can focus on just the ones which will not work.

SmartThings FAQ page has this:

  • Open the SmartThings app and select the device
  • Choose More Options (⋮) at the top right
  • Edge-enabled devices will list Driver as an option

Which app are they referring to? In the phone app, I do not see More Options anywhere. The app is the most updated available.

1 Like

“more options” doesn’t have any text, it’s just three little dots in a row. In the regular smartthings app. But you won’t see the “driver“ option there until you have at least one edge driver downloaded onto your hub so most people don’t have that yet.

If you’d like to list the specific brand/model of your devices in this thread, we can try and help you figure out if there are edge drivers for them, either stock or custom.

I agree absolutely: there should be an official list where you can go look. But there isn’t. :disappointed_relieved:

The quick browse lists in the community-created wiki do have all the publicly available custom edge Drivers listed, sorted by device class. So one list for locks, another list for sensors, etc. It’s a good place to go if you’re looking for a custom driver.

We have also started a table in the community-created wiki to list all the models and whether they have a stock or custom driver, but that table itself is very new so it’s not complete by any means. If you see an entry for your device there, that’s accurate. But if you look and you don’t see an entry for your device, it doesn’t mean there isn’t an edge Driver, it might just mean that nobody’s put the entry in the table yet.

Table of Edge Drivers - Things That Are Smart Wiki

I’m sorry I don’t have a better answer, but at least that might help a little.

Oh, and the following community FAQ might also be helpful:

FAQ: I have no idea what Edge is. Is that a new developer tool? (2022)


What he said :point_up:

1 Like

As a pretty good rule of thumb, if you installed a device via the SmartThings app and it just worked then you shouldn’t have anything to worry about (unless it is one of the exceptions mentioned in the FAQ, or it exploited a custom handler that had already been installed). That isn’t to say it will work correctly from day one, but if it doesn’t it would be a bug.

If, however, you had to use the IDE to get things going you may need to do some further investigation. This is perhaps obvious if you used custom handlers but there is another scenario that has appeared all too often in this forum that may be a problem.

Supposing a device initially paired with a hypothetical Zigbee Widget handler but you found it didn’t work unless you changed it to use the Brand X Widget handler. When it comes to Edge you might find it pairs with a Zigbee Widget driver but the Brand X Widget is now a special case (a sub-driver) in the same driver. There is no way you can force the driver to treat your device like a Brand X Widget. It has to already know what to do.

Thank you so much for your reply. I did read the very long post you had created about the transition. Excellent post and I learned a lot from that. Your posts are always very well researched and extremely helpful. You are also very patient in answering questions and always eager to help. I appreciate that very much.

My thought is that, in the graph IDE, if a device execution is showing local then most likely it will work without any issues. If a device is showing cloud, then it may or may not work. I don’t know if this assumption is correct.

My devices are several years old and getting the make and model of each device may not be possible. Some of them are from no name manufacturers. The best I can do is pull out the raw device string from each device like:

Aeon RGBW Bulb Device:

zw:L type:1101 mfr:0086 prod:0103 model:0062 ver:1.05 zwv:4.05 lib:03 cc:5E,26,33,27,2C,2B,70,59,85,72,86,7A,73,5A ccOut:82
zw:Ls type:1101 mfr:0086 prod:0103 model:0062 ver:1.05 zwv:4.05 lib:03 cc:5E,86,72,98,5A ccOut:82 sec:26,33,27,2B,2C,70,85,59,72,86,73,7A,5A,82 role:05 ff:8600 ui:8600

I purchased both these bulbs together and from same vendor. As you can see, the raw device information for both is different. I know for a fact that these bulbs will need a dedicated Edge driver as they are very complicated. They have several registers with different bits performing different functions. Extremely hard to program by hand, even though I have very good knowledge of hex/binary numbers and assembly language programming.

Some devices like both the Schlage locks are using DTH from Rboy.

Here are all the devices that are currently executing in cloud:

Aeotec Remote Control Device

zw:Ss2 type:1801 mfr:0371 prod:0102 model:0003 ver:1.03 zwv:4.61 lib:03 cc:5E,55,98,9F,6C sec:86,85,59,72,5A,73,80,84,5B,70,7A

Aeon RGBW Bulb Device:

zw:L type:1101 mfr:0086 prod:0103 model:0062 ver:1.05 zwv:4.05 lib:03 cc:5E,26,33,27,2C,2B,70,59,85,72,86,7A,73,5A ccOut:82
zw:Ls type:1101 mfr:0086 prod:0103 model:0062 ver:1.05 zwv:4.05 lib:03 cc:5E,86,72,98,5A ccOut:82 sec:26,33,27,2B,2C,70,85,59,72,86,73,7A,5A,82 role:05 ff:8600 ui:8600

Min Smart Plug Dimmer:
zw:Ls2a type:1100 mfr:0312 prod:FF00 model:FF0D ver:1.00 zwv:7.13 lib:03 cc:5E,55,9F,6C sec:86,26,70,85,8E,71,31,59,72,5A,73,7A

Schlage Touchscreen Deadbolt BE469NX CAM 716 Z-Wave Lock Device
zw:Fs type:4003 mfr:003B prod:6341 model:5044 ver:113.22 zwv:3.42 lib:06 cc:22,72,7A,98,86 sec:5D,85,20,80,70,62,71,63

Schlage FE599 Z-Wave Lock Device
zw:Fs type:4003 mfr:003B prod:634B model:504C ver:43.37 zwv:2.64 lib:06 cc:85,73,72,98 sec:62,63,80,71,70,86,20

Monoprice 4 in 1 Motion, Humidity, Illuminance and Temperature Sensor
zw:S type:2001 mfr:0109 prod:2002 model:0203 ver:4.84 zwv:3.52 lib:06 cc:71,85,80,72,30,86,31,70,84

Aeon RGBW LED Strip Device

zw:L type:1101 mfr:0086 prod:0103 model:0079 ver:1.01 zwv:4.34 lib:03 cc:5E,20,26,27,33,2C,2B,70,86,72,73,85,59,7A,5A ccOut:82
zw:L type:1101 mfr:0086 prod:0103 model:0079 ver:1.01 zwv:4.34 lib:03 cc:5E,20,26,27,33,2C,2B,70,86,72,73,85,59,7A,5A ccOut:82

I apologize for expressing my frustration but please understand that it is directed towards SmartThings who have just dropped the ball on the transition. They have left all the work to the user community. The community has done excellent work by creating drivers, creating list of working devices and so on.

Can I transition a device manually to the new driver?
What will happen to the Graph IDE? Will it stay or vanish?
How would I access the hub? Cloud interface or as a local device? Would there even be an interface to access the hub?
What happens to the SmartThings phone app? Will it stay or be removed?
What about Alexa and Google integrations? They are cloud based.

Most important:
Which direction SmartThings is going? Are they planning to shutdown operations or still stay a viable option for Z-Wave devices? How does Samsung fit into all this? SmartThings was taken over by Samsung but all transition related emails are coming from SmartThings. So, is it Samsung or SmartThings? At this stage, should I look to staying with SmartThings platform or reconfigure Z-Wave devices to some other platform like Hubitat or Home Assistant?

Your insight would be much appreciated.

You can by installing the driver, removing the device from Smartthings and then reinstalling the device. You will loose all automations unless you use a virtual device as a place holder.
Or you can wait and see what happens after the transition.

It will go away

You can access devices through the CLI. There are some very good write ups with instructions how to do this. CLI: How to install and use

The app will stay.

Alexa and Google are both working with the new architecture so you should be fine. The only issue is that multicomponent devices that were installed with separate child devices on a DTH are now installed as a single device. Voice assistance can only see the main switch so you would need to mirror any additional switches to a virtual device to allow voice control of all the switches.


One additional step before reinstalling… if using any custom device handlers…, you will need to remove the DTH from IDE or comment out the fingerprints of the device. :slight_smile:


Thanks @jkp! I forgot that part!


But if IDE is going away, how can I remove the custom DTH?

By that time, ST will have migrated devices to Edge Drivers or modified it so Edge Drivers are assigned before Custom device handlers.

1 Like

Samsung bought SmartThings more than 5 years ago and has operated it as a division. So it’s sort of like General Motors and Chevrolet (a division of GM). You could get an email from either GM or Chevrolet and either would be official communications from the company.

As far as the future of zwave at SmartThings, there’s no way for us as customers to tell for sure.

On the one hand, the hardware partner for ST is Aeotec, a major global manufacturer of zwave devices.

On the other hand, the next generation dongle for Samsung smart televisions will have WiFi, Thread, and Zigbee, as well as Matter support, but no Zwave.

So there are signs both for and against future zwave support. Which is confusing.

As far as the present: the SmartThings’ implementation of zwave is one of the weakest in its class from a customer point of view. And it’s only getting worse with the new architecture. I have previously documented the gaps as I see them:

If you know that you are going to run only zwave devices, there are certainly much better hubs out there, including Homeseer, Hubitat, vera, and perhaps the new Zbox from Zooz.

SmartThings’ strength is in its flexibility in handling multiple protocols, including Zwave, Zigbee, WiFi, LAN, and eventually Matter. But as a standalone Zwave hub it drops down to the middle of the pack at best.

However: it may be that the future of inexpensive DIY home automation systems is Matter, and at present Zwave doesn’t have Matter-compatibility plans. It might someday, but for technical reasons it will be harder to do for zwave than for WiFi, Thread, Zigbee or Bluetooth.

silicon Labs, who make the zwave chips, have promised that someday there will be a chip that can make zwave work with Matter: but it’s not here yet and that would require getting a whole new hub anyway. And it’s likely at least 3 years off.

So…if it was me, I lived in the US, I ran all my critical use cases on zwave, and I wasn’t concerned about Matter, I would be looking at moving to a platform with better zwave utilities. At minimum official UI management of associations and central scenes. But that’s just me. Everyone has to decide for themselves if the many pluses that ST offers outweighs a relatively weak zwave implementation.


Thanks for an excellent reply.

To wrap up this discussion, I have one final question which may or may be relevant here:

Will SmartThings hub be converted from a cloud connected device to a LAN device? The reason I am asking is because currently, the SmartThings hub is connected to Home Assistant via an integration which accesses the SmartThings hub using webhook and personal access token. The personal access token is created by accessing my account at With cloud based access gone, will the hub still be accessible to Home Assistant?

Since this question relates to integration between SmartThings hub and Home Assistant, I will search/ask on their forum also.


1 Like

SmartThings will continue to be a largely cloud-based architecture, and the ST hub itself needs to be connected to the Internet most of the time. For one thing, the ST app can only communicate with the hub via cloud even if both the phone and hub are on the same WiFi. (Technically they didn’t have to design it that way, but they did.)

Here’s the official schematic:

See the Smartthings API in the lower left? That will continue to be available.

However, if the integration had a custom smartapp written in Groovy running in the old cloud, that would have to be rewritten to use the new API.