The End of Groovy Has Arrived

@alissa.dornbos , can you help answer my question above?

2 Likes

The device handler seems to have used an old style fingerprint so unless I’ve missed another handler it isn’t clear where the model numbers came from. Have you asked Keen?

hi i have no idea if it is posible but could we not use something like a raspberry pi to run a local groovy thingy ?
@nayelyz
@TAustin
@Mariano_Colmenarejo

No, it’s not that simple. The architecture would be completely different (would need to rewrite any groovy apps to make API requests to the new ST API)

@RBoy - what does this mean for your apps and device handlers?

-Signed a very grateful RBoy user

2 Likes

We were given to understand that this would be a staggered, orderly transition with about 6 months of notice before the final date. Starting with a migration of stock DTH’s, then removing the button to add new DTH’s, followed by removing the button to add new SmartApps and finally moving towards retiring running custom devices and apps. That was the basis of planning for the migration priorities. There were promises of APIs such as managing subscribers and bridging the gap between the current SmartApp capabilities and the EndpointApp capabilities to make the transition manageable. This is disconcerting, frustrating and conflicting with messages provided to us in the past.

25 Likes

Hi John, We could not integrate these to Lua. Those devices will be eventually migrated to a Thing Lua Driver. We cannot release that code to the public.

We know this means that it will affect your set up and the devices won’t function in ways previous. We apologize for any inconvenience.

I don’t know for you, but I feel I don’t know what I need to do

-How can I know what devices can be migrate to edge?
-How can we migrate those (doesn’t seem to have a lot of driver available)
-Is there a way to migrate without having to start over with all our device ? (70+)
-Is there any plan for webcore, all my automation are there, cause it’s simple and a lot can’t be done with routine

… I don’t know where to start…this deadline is too close, people doesn’t seem to be ready or we doesn’t have something to migrate to…

5 Likes

They’re also pushing a notification through the mobile app. I believe towards the end of August.

After looking at my device, seem like 95% doesn’t seem to be ‘edge’ ready with the ‘drivers’ option . STILL DON’T KNOW WHAT I SHOULD DO.

Does ST look at the most use custom device handler and provide alternative? Is it based only on developers of those device handler to migrate fast and provide an alternative solution ?

The deadline seem way too close to be able to migrate correctly. Could it be in the plan to keep the old architecture in parallel during a correct migration. Otherwise I feel a lot will feel lonely and will have to start again, or leave ST for another hub…

1 Like

Wait a bit and you should get more answers. There is no need for you to start over with all your devices. Let ST migrate them and see what happens. As for webcore… you will need to handle that on your own. If Routines are not adequate, you can check out the SharpTool Rules Engine to see if it gives additional features

3 Likes

Most z-wave and zigbee devices are already supported in Edge, though possibly not with all of the features that could be found in community DTHs. The stock drivers written by ST can be found here and the list of community drivers can be found here. While each list may look small, each driver can cover a pretty wide range of devices.

You can either migrate manually now (which requires removing and adding each device) or wait for the automatic migration to kick in as described here:

1 Like

Wow this is a sad day for SmartThings power users… Thank you for validating my decision to migrate to Hubitat years ago!

10 Likes

SmartThings without Core/WebCore is like an engine without pistons!

6 Likes

While the article has a short list of what will be and what will not be supported, is there a comprehensive list of what will not be supported (for instance is green tech one power mode a legacy device that I’ll need to chuck?). Also, for the “at risk” devices, when they are moved to being a “thing”, will the logic developed in routines be lost (meaning I need to write it down manually now)?

Not even as a basic smoke detector? If that’s the case I guess I’m left to try something in Edge on my own to at lease replicate ST’s “Zigbee Smoke Detector” driver and just add the Halo fingerprint to it.

That’s all I’m really asking. Just add the fingerprint so its joined as a simple smoke detector, and forget about all the LED light ring and other capabilities.

3 Likes

I should have started this a long while back but I’m wondering about converting DTHs and SmartApps since I have several. Is there a “getting started” resource that covers making the transition? I assume yes but am not sure where to look or what different types of resources are available.

Does anyone have a list of helpful “official” links?

1 Like

not official links…
https://thingsthataresmart.wiki/index.php?title=How_to_Quick_Browse_the_Community-Created_SmartApps_Forum_Section#Quick_Browse_Links_for_Edge_Drivers

There are no plans to integrate these fingerprints associated with Halo.

As @mvevitsis says, it’s not that simple because that still wouldn’t bring the device into your SmartThings account.

If you really can’t imagine giving up Webcore or some other groovy smartapp, the simplest solution is likely to switch those use cases to a Hubitat hub, which will run Groovy locally.

It would be a big project, you’d need to also add a raspberry pi so SmartThings and Hubitat could talk to each other, I think you’d have to rebuild all your pistons on the new platform, but you would still have Webcore.

Might be worth it for someone who has several Samsung smart tvs and appliances or just doesn’t want to lose the ST app, is comfortable learning mqtt if they don’t know it already, and is heavily invested in being able to write new Webcore pistons or has other existing groovy projects they don’t want to give up. But way too much work and complexity for most people, I think. :thinking:

Hubitat to run Webcore, MQTT to integrate back to SmartThings

Here’s how this would work.

  1. use Hubitat to run Webcore. I believe you would have to recreate all your pistons over there, but I don’t know the details.

  2. Use proxy virtual devices on one system or the other. If you create virtual devices on Hubitat, you could leave the actual zwave and Zigbee devices on your SmartThings hub. Or you might have some devices that need custom code not yet available in an Edge driver, so you move those devices over to hubitat to take advantage of groovy there and add a proxy virtual device for them on the ST side.

There would be a lot of code needed to synch everything up, but you wouldn’t have to reset any physical devices that worked with an Edge Driver.

  1. Hubitat has a built-in interface to communicate with an MQTT broker. And @taustin has written a SmartApp for the new platform that supports communications with an MQTT broker. So you could communicate between the two hubs that way.

The good news is everything would run locally. The bad news is this is obviously just for power users willing to run 3 systems. But it should be doable. :thinking:

1 Like