Announcement | SmartThings Edge for Devices and Automations

Yes, I saw the original post and shared it with the corresponding team. They mentioned they were analyzing that part but I haven’t received an update yet. Once I get more info, I’ll let you know.

1 Like

all beta participants should have in by tomorrow

1 Like

Wow thank you; evidently I’ve been out of the loop!


Hi All. I’ve moved a lot of my devices over to Edge drivers. And now I have some questions on the App.

  1. How do I get a list of devices from the Driver ?
  2. How do I get the manufacturer: and model of an installed device. I particular when they are reporting as a thing and we have no IDE ?
1 Like

I just worry about the transition to edge. I mean, ST could let the groovy works for few weeks or so to make the transition smootly… Now for what I see, edge is not 100% ready and seem to be very complicated and with very few feature compared to webcore… What about the web-based, rule building GUI that is supposed to be close from webcore? Almost all my automation arte webcore based and need to use web request (for sure outside my lan) to share variable and so on! I have some request that makes my piston run (from alexa skills so I talk to alexa and she s setting my piston variable so my piston is doing the right things on variable change…) I have a lot of things like that…
I just hope of a web interface where I could use webcore as it is now but that I could extract json to the new api or something… For now I have NO ideas of what it ll be and it makes me feel pretty worry! Is there a video to show what it ll looks like? All I saw is the drivers (wich is ok) but I only saw a kind of scene builder that looks like the actual one in the app and it s just unusable to do other things that simple automation…
I understand that for ST its a big thing to annonce but as user we are in the dark and I feel like its a big step back.



To see which devices are connected to a driver, you can get the driver ID and, when you list the devices, search which entries have this ID on their properties.
We cannot filter the devices based on the driver used. I will create a feature request about that, I think it would be useful.

I suggest you enable the logcat in the ST CLI (command: smartthings edge:drivers:logcat) before pairing the device so you can see its fingerprint. However, there are Community drivers that show these values on the detail view of the device, like the one from @Mariano_Colmenarejo in this post.

just a little thing because I saw many comments by ST or by other users and some are on contradiction…
Here a post from Andy himself and I would like to know if its still true?

Because in other place its telling that its the community responsability to update webcore… Its hard to know where to start and what to do… and now with less than 40 days… What can you tell us on this? I know that webcore is already running local (hubitat for example) and it could supply json output to feed the rules api, this way we could keep the piston interface and each piston would be an automation on its own that could be run with url using edge drivers…
and in the other way it could send web request with a driver again… The rules api would be the real brain and webcore the interface if setup this way… the rules api could then extend those webcore function and have its own wich could be added to the interface or in other place where we could use it as variable or other things to append it to pistons/automations so… thanks again!


It looks like that post is probably more than a year old. :thinking:

What Ady is describing there was the original plan. He was the author of Webcore before he worked for SmartThings, then they hired him and he worked on the Rules API for a while, then he eventually left Samsung and now works for a different company and no longer works on Webcore officially or unofficially.


What you read in the following thread is current. SmartThings has no official plans at this point to do anything with Webcore, and the Rules API, while still in development, has unfortunately not yet reached parity with Webcore. (The topic title is a clickable link.)

Sometimes businesses change their plans.

Webcore has their own forum, you might check there to see how different people are handling it.

1 Like

I knew about that… Its just that the edge things seems not to be ready as they said they will works on it and try to match webcore but then why dont let groovy works for a while to let users making transition? By closing it directly, I’m not the only that will loose almost all his automations and for undetermined period of time! I dont think that in few weeks they will match webcore since they seems to be, according to what I read, to adding is equal or greather than… inside the rule engine that is inside the app wich will be hard to see the entire thing for complex automation if it even could be done… So a hudge step back for many!
I know that the api is maybe as powerfull as webcore and more since it operated locally and access parallell execution… but for now it like replacing a mustang by a ferrari without keys! Pretty worry about it… I buy the ST hub because it was the most ‘sky is the limit’ thing and I hope that it still the case and not withing 10 years…


In fairness, it was about 2 years ago they announced Groovy was to be fazed out, i agree prior to the recent post we did not have an end date for Groovy but now we do.


OK thanks. I’ll use the command line and see what I get. Was hoping it would be possible from the app.

It is possible from the app if you use the driver “Zigbee or Z-Wave thing” from @Mariano_Colmenarejo, he created custom capabilities that show those values in the Detail View of the device. As it has a generic fingerprint, it will recognize all devices, so, once you install the driver, follow these steps:

  1. In the app, go to the device and open it to see its details
  2. Select “menu” (three-dot symbol in the upper-right corner)
  3. Tap on “Driver” and then on “Select different driver”
    Note: Only the compatible drivers will appear on the list. This means those that include the device’s fingerprint (Zigbee/Z-Wave), or generic fingerprints
  4. Select the Driver and tap on “Use this driver”. Click on “OK”
    You might have to reopen the app so the new device profile is loaded.

I started using SmartThings around 2018. Groovy and the Graph API was already presented as the legacy system back then, even though the ‘new’ platform had no practical function and the legacy system basically was SmartThings and continued to be for a long while.

Thanks. That will do. I will mostly need it when adding new devices that don’t have a driver. With this installed all “Things” should default to this driver

I just saw something that could be great! Someone have done a edge driver to allows MQTT communication from rules api to webcore or any others. So the only thing it missing is a place where to run webcore. If we could make it run on a pc or rasberry pi or any other place, it could send devices update to rules api and rules api could also send devices status updates so it should run normally… Set up like this have been done to link hubitat hub to ST hub to be able to control devices…
If someone have any ideas on how to do to install webcore somewhere without the need of buying another hub, I m sure that will be interesting for a lot of users!

1 Like

This might be downplaying how massive an effort this would be just a little bit. :rofl:

The webCoRE interface you access is just a frontend for editing your pistons. All the actual logic runs in SmartThings Groovy environment and is highly dependent on all the various objects, methods, properties they’ve exposed. It would be a massive rewrite.


I think taht the thing that they should have consider from the start. If users could host their own part or something… From the hubitat side they install it on the hub so they should have a groovy thing somewhere… Those codes line where created to make it run on the groovy! So its a doable thing to migrate DTH to drivers but for the rest it just could not?
Sorry about those ideas but I try to bypass a step back and the lost of all my valuable automations…

1 Like

Do you mean if users could host their own version of the SmartThings platform?

You can host your own Groovy environment, but that would just run Groovy code. What I was saying above is that SmartThings has built their own platform with their own code on top of Groovy. So when a SmartApp like webCoRE runs, it’s not just running Groovy, it’s running on top of a bunch of parts that SmartThings provides.

I’m not saying it’s not possible. When Hubitat launched, it was basically a giant emulation layer for SmartThings and effectively does what you’re asking for. You can export your pistons and run them in webCoRE in Hubitat… but you’ll have to connect the pistons to your devices somehow. There’s a Hubitat SmartThings connector, but its going to die with Groovy which is probably why @JDRoberts was suggesting using some connection layer like MQTT. Either that or you could connect the physical devices directly to Hubitat and update them when you import your pistons.

1 Like

Hi, Thanks !
I was not aware of all the stuff under the groovy things… So even if someone convert the webcore smartapps into lua it would still need some integration? I was expecting something like a list of devices with their state to be communicated to webcore and then webcore doing the same after running pistons so the api have just to update the state of those devices… So I was thinking of a kind of webcore interface or something (webcore is running on a server elsewhere so I was thinking that it would not need ST groovy to run and just exchange devices and state) for sure if embeded with groovy its better but that was under my idea… Because rules api with drivers could built a list of devices with their state to be used by webcore and the same updated list could be send back… That s why I was thinking about a kind of place to just make webcore running… Hope I explain it as well as you done!
Thanks again!

If you absolutely must run groovy smart apps, the only way to do so would be to use MQTT and run the apps in habitat.

1 Like