Please talk me down off this

I’ve just received a notification that my hub will cease to operate on June 30th. That’s fine, but really I’m concerned with the future direction of smartthings. My concern started when I was forced to move to the new app. I had a couple of smartapps that I had written to handle things, and suddenly the logging ceased to tell me what was going on. I also noticed that one of the device handlers had some funky interface elements, and I thought, well maybe I could fix it. I logged into Samsung’s developer workbench, and noticed that the system doesn’t appear to allow for community development. This is by far the most concerning thing to me. Very few corporate developed device handlers have worked very well. Most of the time the device handlers have either been tweaked by the community, or flat out developed because the device manufacturer never bothered to develop one. Also any app development seems far more complicated than it used to be. I’ve also heard that Groovy is on it’s way out as well, which means the apps that I have created are soon to stop working. My big concern is that Samsung seems to have little concern for the community that made Smartthings what it was. That eventually they will kill the old IDE, and will have developer workbench, but with very little documentation, and zero concern that the old guard of smartthings will be able to adapt.

This concern is driving me to start considering alternatives. Does someone have an idea or can point me to something that sums up Samsungs plan/roadmap for the platform?

That’s a lot of different questions, and I’m sure you’ll get a lot of different answers. :sunglasses:

The official announcement of the roadmap is here:

But note that there aren’t a lot of details. Details have been coming out piece by piece, and you will find them in the developer section of the forum.

We’ve gotten a lot of information on how cloud cloud integrations will work, and a recent detailed breakout on how “direct connected“ (Wi-Fi devices that use the smartthings cloud but don’t have their own cloud) will work.

But as yet we have not been given many details on how “hub connected“ Devices, meaning zigbee and zwave, are going to work, or even if it will still be possible to do custom DTHs for these.

OTOH, if smartthings really got their act together and supported more of the third-party standard functions, we might not need custom DTHs for hub connected devices. :thinking: The main reason for custom DTHs for Z wave devices, for example, is because the smartthings Z wave implementation has not fully implemented features like central scenes. So people are always trying to work around the limitations of the smartthings platform. Fewer limitations would mean fewer workarounds were needed.

Anyway, you’ll find the discussions about the various development options in the following section of the forum

As far as alternatives, there has been tons of discussion on that. You can try the following threads which are specific to the announcement of the hub retirements:

https://community.smartthings.com/tag/eol_hub_migration

And you can also check the following section of the forum:

Not sure any of that will really help immediately address the feeling of falling off the ledge, but it’s a place to start.

1 Like

The reality is that most custom DTHs are implemented as hub connected devices, even if they technically aren’t. For example, the Roomba dth which I updated to work better with the new app relies on the hub to communicate with the node.js server, even though strictly speaking this is a wifi device.

Because we don’t know what the solution for hub connected devices is, it’s also impossible to say what the future of custom DTHs is.

1 Like